Wer Webserver fuer eine groessere Anzahl an Benutzern betreibt, wird wohl oder uebel mit Php Shells konfrontiert werden.
Einen 100% zuverlaessigen Schutz gibt es natuerlich nicht. Ein paar einfache Moeglichkeiten den Schaden in Grenzen zu halten gibt es jedoch:
- open_basedir Direktive fuer vhosts nutzen
- Web und File Server trennen, besonders wenn sinnfreier Weise ssh erlaubt ist
- Beobachten was fuer neue Dateien (auch Besitzerrechte, ggf. nach Mustern grepen) und wann sie angelegt wurden (klingt aufwendiger als es ist)
- Falls man eine shell findet, zeit nah nach Pattern daraus auf dem Fileserver suchen
- clamav laufen lassen
Shells gibt es sowohl im Klartext, als auch in gepackter Form.
Also etwas in der Art wie
<? eval(gzinflate(base64_decode('7X1rcxs5kuBnd0T/B7...oder klassisch etwas wie
$language='ru';
$auth = 0;
$name='r57'; // knchm onk|gnb`rek? (user login)
$pass='r57'; // o`pnk| onk|gnb`rek? (user password)
Die Dateien werden entweder hochgeladen oder ueber cross-site scripting aufgerufen.
Es gibt eine ganze Reihe solcher Php shells: r57, c99, c100, madshell, small php web shell, nst shell, php bypass shell, sim attacker shell, safe0ver bypass shell….
Klar worauf ich hinaus will? Diese shells existieren in unterschiedlichen Versionen und Anpassungen. Der Funktionsumfang der shells reicht dabei vom einfachen Kommando ausfuehren, bis hin zu irc remote und checks auf bestimmte Sicherheitsluecken und vieles mehr.
Kurz gesagt: ist das System nicht aktuell und man findet eine solche Shell, steigen die Chancen auf eine Kompromittierung des gesamten Systems. Einen local root exploit nachzuladen und auszufuheren ist kein grosser Aufwand.
Was tun wenn der Einbruch festgestellt wurde?
Da gibt es sicherlich eine Reihe von Vorgehensweisen, die empfohlen werden. Als ersten Schritt wuerde ich immer den entsprechenden vhost deaktiveren, die Dateien aber nicht loeschen sondern untersuchen (am besten auf einen anderen System). Sich selbst anschauen was fuer Funktionen die Shell bietet, also ruhig ausprobieren was man damit alles so anstellen kann, das hilft den moeglichen Schaden einzuschaetzen. Natuerlich den Vhost Inhaber informieren. Versuchen mit dem Vhost Administrator herauszufinden wie der Einbruch ueberhaupt moeglich war. Relativ haeufig sind nicht geupdatete CMS Systeme das Einstiegstor. Den Vhost erst wieder online nehmen wenn die Luecke gestopft ist.
Intrusion detection ist ein weites (weites) Feld. Daher beschraenke ich mich mal auf diesen kleinen Beitrag. Das man intrusion detection Systeme und diverse Monitoring tools im Einsatz haben sollte, ist selbstverstaendlich. Es ist schwierig bei einer grossen Anzahl von Usern den Ueberblick zu behalten, trotzdem sollte man versuchen besonders CMS Systeme im Auge zu behalten und gegebenenfalls auch zentral anzubieten, bzw. upzudaten.
