07.31
Arbitrary PHP execution vulnerabilities are both nasty and powerful. However, there is one aspect of these vulnerabilities that people don’t seem to keep in mind: that any code that’s being run, any requests that are being made, etc are being made from the compromised server. That compromised server is a platform for the attacker: once an attacker has compromised one server, he/she is in a better position to compromise more.
Lets take an example. I set up a server to host some websites for me. I’m really paranoid, so I lock the server down as much as I can: I disable any commands that allow processes to be run outside of PHP (proc_*, exec, passthru, system, etc), I stick it behind a firewall that only allows traffic on port 80, and I lock the webserver down in a jail environment (so it doesn’t have access to any other parts of the filesystem, just its files).
I’m safe, right?
Wrong!
One of my applications has a silly bug: it allows the user to enter code which it parses as PHP. An attacker who uses my application finds the vulnerability and starts exploiting it. He quickly realizes that he’s “locked in”: he can’t execute shell commands and he can’t access most of the filesystem. All he can do is execute PHP: that allows him to download any files the webserver can read and/or to run arbitrary PHP code (say, some very expensive calculations designed to cause a DOS attack).
But there’s nothing else he can do, right?
Wrong!
It turns out that the attacker has much more power than he thinks. He’s now inside the firewall: he can execute whatever connections he wants within the supposedly “safe” environment, as long as he uses PHP to start. A savvy attacker could:
- Launch a port scan attack against other servers. You can identify the services on other systems and maybe find a more vulnerable one.
- Gain access to the server via SSH. A pure PHP implementation of SSH can be found at http://phpseclib.sourceforge.net/. If you can upload a large script to the server (all the necessary dependencies combined takes up ~400 KB), you have an SSH client. That gives you the opportunity to launch an attack against the server you’re on, or any other servers on the network. Combined with some social engineering (to gain a username/password without bruteforce), and you have access to the server.
The best part about these attacks is they’re all internal: a sysadmin looking at the logs would see a server attacking itself or attacking other servers. The attack vector isn’t immediately obvious.
Comments