1

I've been getting the following in my apache access log:

"GET /work//?module=www&section=working=../../../../../../../../../../../../../../../../../../../../../../../..//proc/self/environ%0000 HTTP/1.1" 200 5187 "-" "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.12) Gecko/20101026 Firefox/3.6.12\",\"Mozilla/5.0 (Windows; U; Windows NT 5.1; pl-PL; rv:1.8.1.24pre) Gecko/20100228 K-Meleon/1.5.4\",\"Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/540.0 (KHTML,like Gecko) Chrome/9.1.0.0 Safari/540.0\",\"Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Comodo_Dragon/4.1.1.11 Chrome/4.1.249.1042 Safari/532.5\",\"Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.0.16) Gecko/2009122206 Firefox/3.0.16 Flock/2.5.6\",\"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/533.1 (KHTML, like Gecko) Maxthon/3.0.8.2 Safari/533.1\",\"Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.8pre) Gecko/20070928 Firefox/2.0.0.7 Navigator/9.0RC1\",\"Opera/9.99 (Windows NT 5.1; U; pl) Presto/9.9.9\",\"Mozilla/5.0 (Windows; U; Windows NT 6.1; zh-HK) AppleWebKit/533.18.1 (KHTML, like Gecko) Version/5.0.2 Safari/533.18.5\",\"Seamonkey-1.1.13-1(X11; U; GNU Fedora fc 10) Gecko/20081112\",\"Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0; .NET CLR 2.0.50727; SLCC2; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; Zune 4.0; Tablet PC 2.0; InfoPath.3; .NET4.0C; .NET4.0E)\",\"Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 6.1; WOW64; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; MS-RTC LM 8; .NET4.0C; .NET4.0E; InfoPath.3)"

  1. If I try the URL, I get a 404 instead of 200 which the above request received. Is there a way I can confirm that the 200 was real and not spoofed?

  2. Where is the long info on the client coming from?

1 Answer 1

2

It's a known old joomla exploit as seen here. It works by cramming CGI environment variables with PHP code then convincing the buggy joomla module to load the environment file.

Presumably, whoever wrote the scanner that attempted that on your server provided you with gibberish.

If that's really an unaltered paste from your log, then that query had a 200 response, but what's missing there is the virtualhost that the query was made against. Some scanners try and figure out hostnames of virtualhosts but many will just query against the IP address and/or leave the Host: header out entirely.

2
  • Thanks for the info. Fortunately, we don't have joomla running on the server - so I guess we don't have to worry about this one too much. How was this request able to get a 200 returned when the file specified does not exist on the server?
    – elle
    Oct 10, 2011 at 18:49
  • @lizkim270 At the time of the request, on the virtualhost the attacker queried, there was a folder named /work/ and that folder's index is what apache returned. I linked the joomla exploit since you (or lain?) tagged the question joomla, but it's likely that there are other applications that are vulnerable to the same tactic.
    – DerfK
    Oct 10, 2011 at 19:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .