Forensische Analyse von Webanwendungen

[gelöschter Benutzer]

Hallo Leute,

Bei einem Kunden von mir trat auf einmal ein PHP-Fehler auf, dass die Header schon gesendet wurden, was auf Zeichen außerhalb von PHP-Code hinweist.

Jetzt habe ich herausgefunden, dass einige PHP-Dateien heute verändert wurden. Anscheinend wurde also eingebrochen.

Wenn ich die Dateien herunterlade, werde ich wohl mit einem Vergleich zwischen der "Originalversion" des eingesetzten CMS und den "gehackten" Dateien den Code finden, der eingeschleust wurde. (Würde ich jetzt mit diff machen, hat wer ne andere Idee?)

Wie finde ich jetzt aber raus, woher der Code kam? Kann ich per FTP rechtssicher irgendwas archivieren, um ohne Beweise zu vernichten darauf zuzugreifen?

Leider habe ich nicht die Möglichkeit, per Shell auf das Dateisystem zuzugreifen und/oder mir ein Festplattenimage mit dd zu ziehen (Shared Hosting). Habe jetzt alle weiteren Untersuchungen erst einmal eingestellt.

 

[accC]

Die Dokumentation, woher der Code stammt, sollte dir je nach Einbruchsquelle der zuständige Server sagen.
Wurde über die Webanwendung oder schlimmer noch den Webserver selbst eingebrochen, dann müsstest du im Serverlog nachschauen.
Wurde über FTP eingebrochen, dann im Log des FTP Servers.
Wurde über SSH eingebrochen, dann im Log des SSH Servers.

Im letzten Fall könntest du jedoch davon ausgehen, dass der Einbrecher versiert genug war seine Spuren zu verstecken, etwa indem entsprechende Logs gelöscht wurden.


Also normalerweise kann ein Server immer nur das loggen, was er selbst bearbeitet hat.
Normalerweise stellt dir der Provider selbst bei shared-Hosting-Paketen deine Logfiles zur Verfügung, so war es jedenfalls bei mir.
Wenn nicht, kannst du ja mal den Support anrufen und nachfragen.

 

[gelöschter Benutzer]

Nehmen wir mal an, es wurde über eine Lücke im CMS eingebrochen. Da sagt mir doch der Server nicht, wo die Lücke ursprünglich war, oder?

Das Modifikationsdatum sagt ja nicht unbedingt etwas über die Quelle aus. Ich könnte höchstens die Logs zu dem Datum durch schauen, aber wenn der Hoster den access.log (nehme an, es ist ein Apache) deaktiviert hat oder die IP dynamisch war, über die zugegriffen wurde, bringt mir das ja nichts.

Unter Umständen habe ich dann selbst über eine Anzeige bzw die Staatsanwaltschaft keine Möglichkeit mehr, die Quelle zu lokalisieren, weil die Logs bei den ISPs nach ein paar Tagen gelöscht werden?

 

[Kugelfisch]

Ohne Mithilfe des Hosters, zumindest in Form der Access- und Error-Logs für den Web- und FTP-Server, wirst du den Angriff nicht nachvollziehen können. Anhand der Dateien (und, nicht zu vergessen, einer eventuellen Datenbank) kannst du, wie du bereits selbst festgestellt hast, nur die konkret vorgenommenen Änderungen untersuchen. Viel wichtiger ist jedoch die Schwachstelle zu finden, über die der Angriff erfolgt ist - schliesslich musst du davon ausgehen, dass sie erneut ausgenutzt wird, wenn du sie nicht schliesst.

Die IP-Adresse der Angreifers zu finden (sofern sie überhaupt geloggt wird), ist hingegen meines Erachtens eher uninteressant - einerseits wird mutmasslich ein Anonymisierungsdienst, ein offener Proxy, oder ein kompromittiertes System eines Dritten missbraucht worden sein um keine verwertbaren Spuren zu hinterlassen, andererseits ist der Angreifer ohnehin beliebig austauschbar. Die Schwachstelle ist das primäre Problem, nicht der Angreifer.

 

[accC]

Nehmen wir mal an, es wurde über eine Lücke im CMS eingebrochen. Da sagt mir doch der Server nicht, wo die Lücke ursprünglich war, oder?

Nein, so direkt nicht.


Nehmen wir mal an du hast eine Schwachstelle beim Upload von Dateien.

Dann kannst du schauen, wann die Datei modifiziert wurde. Unter Linux (Shell)* etwa:
[src=shell]$ stat header.php
File: `header.php'
Size: Blocks: IO Block:
Device: Inode: Links:
Access: ( / ) Uid: ( / ) Gid: ( / )
Access:
Modify: 2013-10-23 14:24:39.824104000 +0200
Change: 2013-10-23 14:24:39.824104000 +0200
Birth: -
[/src]

Du weißt also, dass die Datei zuletzt um 14:24:39 modifiziert wurde. Du könntest davon ausgehen, dass spätestens(!) dann Schadecode eingefügt wurde.
Jetzt möchtest du natürlich wissen, wie das passiert sein kann. Dazu schaust du dir die Logfiles durch und suchst nach der fraglichen Zeit.

Beispielsweise in deinem Webserver-Log* (z.B. apache2):
[src=shell]
13.124.54.3 - - [23/Oct/2013:14:23:17 +0200] (...)
14.123.32.144 - - [23/Oct/2013:14:24:39 +0200] "GET / HTTP/1.1" 200 483 "-" Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
14.123.32.144 - - [23/Oct/2013:14:24:39 +0200] "GET /favicon.ico HTTP/1.1" 404 504 "-" "Mozilla/5.0 (Windows NT 6.2; WOW64; rv:20.0) Gecko/20100101 Firefox/20.0"
14.123.32.144 - - [23/Oct/2013:14:24:39 +0200] "POST /mysite/upload.php?userid=1&token=82347wfhdouh3980fuw3h.....
23.23.132.233 - - [23/Oct/2013:14:25:04 +0200] (...)
[/src]

Hier siehst du, dass zur fraglichen Zeit 3 Anfragen (von 14.123.32.144) stattgefunden haben.
Insbesondere die letzte Anfrage ist für uns interessant, da diese (1) eine POST-Anfrage ist, (2) einen interessanten [upload.php] Dateiaufruf enthält und (3) zur fraglichen Zeit stattgefunden hat.


Das wären schon Indizien dafür, dass ein Angriff über die Webapplikation stattgefunden hat und die Schwachstelle wohl in der upload.php liegt. Zwar kein eindeutiger Beweis, aber immerhin sieht das schon sehr verdächtig aus.

Um deine Befürchtung erhärten oder verwerfen zu können müsstest du jetzt noch überprüfen, ob etwa dem Apache-Nutzer die Datei gehört (aber auch das kann man ggf. manipulieren!) und was eventuell andere Server zur gleichen Zeit getan haben. Etwa könnte auch der FTP-Log anzeigen, dass er zur fraglichen Zeit die Datei modifiziert hat. Dann wäre klar, dass der FTP-Server der Schuldige ist und über die Webapplikation (vermutlich nur zufällig) gleichzeitig ein Upload stattgefunden hat. Aber wie gesagt, solche Logfiles können, wenn man entsprechenden Zugriff und Kenntnisse hat, auch manipuliert werden und dann keine oder ggf. sogar schicht falsche Informationen enthalten.

Bitte beachte jedoch:
Ich kann dir natürlich nur so viel sagen, wie ich weiß und ich bin jetzt nicht gerade ein Security-Experte. Dass ich ein gewisses Basis-Wissen habe, lässt sich wohl nicht verleugnen, dass ich Profi auf dem Gebiet bin kann ich jedoch ruhigen Gewissens verneinen. Das heißt insbesondere, dass ich dir nicht versprechen kann, dass alle Informationen korrekt und vollständig sind. Insbesondere kann ich dir auch nicht versprechen, dass die Informationen in der Form vor Gericht eine Beweiskraft haben.


*Beide Auszüge sind natürlich fiktiv, gekürzt und nicht vollständig. Sie sollten aber strukturähnlich zu realen Informationen sein.



Edit: Es geht darum erst mal grob zu filtern, woher der Angriff kam. Könnte über die Applikation gekommen sein (sehr wahrscheinlich) oder über den FTP (eher unwahrscheinlich) oder einen fehlerhaft konfigurierten SSH-Server (noch unwahrscheinlicher). Denkbar wäre jedoch alles davon.

Zum Thema IP hat Kugelfisch (Überschneidung übrigens) ja schon gesagt, dass diese höchst wahrscheinlich nicht verwertbar ist.

 

[gelöschter Benutzer]

Okay, dann kann ich es wohl vergessen, den Angreifer zu finden.

Leider habe ich keinen Shell-Zugriff. Soll heißen, ich werde mich wohl auf Dateien, Logs und Datenbanken beschränken müssen und am Dateisystem eh nichts machen können.

Wie man vom Prinzip her die Lücke findet, weiß ich eigentlich. Im Moment bin ich auch auf dermaßen vielen Programmierschulungen, dass es mir selbst langsam in den Fingern juckt, Exploits/SQL-Injections zu konzipieren.

Allerdings habe ich eben im Normalfall immer Zugriff auf den gesamten Server und nicht nur auf FTP und Datenbank (und letzteres auch nur per phpmyadmin). Da sämtliche Kommunikation mit dem Hoster eben auch über den Kunden läuft, geht das ganze eh zäh. Bin nur froh, dass ich das abrechnen kann ;-)

 

[accC]

Für solche Fälle lässt man sich vom Kunden eine Vollmacht unterzeichnen und regelt das dann direkt mit dem Hoster. Dann passiert es auch nicht, dass der Kunde Infos falsch weiter gibt und später mit unvollständigen oder falschen Infos gearbeitet werden muss.