Tag Archives: php

Kurztipp: PHP Shells mit maldet finden

Maldet ist ein Malware Scanner. Ideal für jegliche Art von Webhosting.

Maldet legt automatisch einen cronjob an und verschickt je nach Wunsch täglich mails.

Mails sehen dann in etwa so aus:

HOST:      web01
SCAN ID:   170610-0654.14910
STARTED:   Jun 10 2017 06:54:15 +0200
COMPLETED: Jun 10 2017 07:07:34 +0200
ELAPSED:   799s [find: 450s]

PATH:          
RANGE:         1 days
TOTAL FILES:   24202
TOTAL HITS:    2
TOTAL CLEANED: 0

WARNING: Automatic quarantine is currently disabled, detected threats are still accessible to users!
To enable, set quarantine_hits=1 and/or to quarantine hits from this scan run:
/usr/local/sbin/maldet -q 170610-0654.14910

FILE HIT LIST:
{HEX}php.cmdshell.unclassed.365 : /pfad/zum/docroot/phpshells/844-4873-1-SM.phtml
{HEX}gzbase64.inject.unclassed.15 : /pfad/zum/docroot2/c.php

Maldet bietet etliche Einstellungsmöglichkeiten.  Man kann es auch in Echtzeit im monitoring mode laufen lassen. Je nach Umfang der docroots stößt man dabei aber an diverse Limits (ulimit &co).

Auf Github findet man Maldet unter https://github.com/rfxn/linux-malware-detect. Debian Pakete gibt es unter https://github.com/waja/maldetect.

php shells

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.