Skip to content

Wie erkennt man manipulierte Dateien von kompromittierten Servern?

Vom 28. November bis 2. Dezember wurden nach der Kompromittierung des FTP-Servers von ProFTPD manipulierte Sourcecode-Pakete der Version 1.3.3c verteilt, die eine Backdoor enthalten. Betroffen waren der Haupt-FTP-Server des Projekts sowie alle Mirrors, da die die manipulierten Pakete ebenfalls spiegelten. Zur Prüfung der Integrität heruntergeladener Pakete verweisen die Entwickler auf die MD5-Hashwerte und PGP-Signaturen der Dateien. Ob das so eine gute Idee ist?

Server kompromittiert, Dateien manipuliert - wem kann man dann trauen?

Es ist ja nicht das erste Mal, dass Server von Softwareherstellern kompromittiert wurden. Mal mit, mal ohne Auswirkungen auf die Integrität der jeweiligen Programme, immer aber mit einer Folge: Wenn der Server kompromittiert wurde, darf man den darauf gespeicherten und/oder darüber bereit gestellten Daten nicht mehr vertrauen. Aber wie kann man Manipulationen, insbesondere an bereit gestellten Programmen, erkennen? Es gibt verschiedene Möglichkeiten, die Integrität von Programmen, egal ob als Sourcecode oder als Binärdatei, zu prüfen. Welchen Schutz bieten diese Maßnahmen aber, wenn der Server kompromittiert wurde?

Möglichkeit 1: Prüfsummen und einfache Hashwerte

Die Veröffentlichung von Prüfsummen ist eine altbekannte Methode, um Änderungen an Dateien erkennen zu können: Stimmt die Prüfsumme der heruntergeladenen Datei nicht mit der veröffentlichten Prüfsumme überein, wurde die Datei verändert. Übertragungsfehler lassen sich so erkennen, bevor die Datei weiter verarbeitet oder verbreitet wird. Zur Erkennung absichtlicher Manipulationen sind Prüfsummen aber ungeeignet: Der Angreifer kann die manipulierte Datei so präparieren, dass sie die richtige Prüfsumme liefert. Unabhängig davon, ob ein Server kompromittiert wurde oder ein anderer Server manipulierte Versionen der Datei veröffentlicht, ist eine Prüfsumme ein untaugliches Mittel zur Erkennung von Manipulationen.

Das gleiche gilt für einfache Hashwerte. Erst wenn die verwendete Hashfunktion unumkehrbar ist, also eine kryptografische Hashfunktion verwendet wird, können absichtliche Manipulationen erkannt werden.

Möglichkeit 2: Kryptografische Hashwerte

Kryptografische Hashwerte sind deutlich sicherer als Prüfsummen: Da die verwendeten Hashfunktionen nicht umkehrbar sind, kann ein Angreifer die manipulierte Datei nicht so präparieren, dass sie den richtigen Hashwert liefert. Außer Übertragungsfehlern können also auch absichtliche Manipulationen erkannt werden.

Kryptografische Hashfunktionen schützen aber nur vor absichtlichen Manipulationen, wenn der Hashwert selbst nicht manipuliert werden kann. Sie sind nutzlos, wenn der Angreifer sowohl Datei als auch Hashwert manipulieren kann. Befinden sich Datei und Hashwert auf dem gleichen Server, kann nach dessen Kompromittierung der vorhandene Hashwert durch den Hashwert der manipulierten Datei ersetzt werden, so dass die Manipulation nicht auffällt. Oft sind Web- und FTP-Server einer Domain identisch, so dass ein erfolgreicher Angreifer sowohl die über FTP bereit gestellte Datei als auch den über den Webserver bereit gestellten Hashwert austauschen kann.

Aber auch wenn Web- und FTP-Server getrennte Maschinen sind, ist in einem Fall eine Manipulation des Hashwerts möglich: Wenn dieser automatisch aus der per FTP bereitgestellten Datei berechnet wird. Das, was der Arbeitserleichterung der Entwickler dient (bei einer Änderung der Datei muss der Hashwert auf der Webseite nicht manuell geändert werden, sondern wird automatisch angepasst), dient dann genauso der Arbeitserleichterung des Angreifers.

Möglichkeit 3: Digitale Signatur

Wirklich sicher schützen nur digitale Signaturen vor unerkannten Manipulationen. Sofern sie nicht unsicher verwendet werden.

Da für die Berechnung der Signatur der geheime Schlüssel des Signierers benötigt wird, kann ein Angreifer sie nicht fälschen oder manipulieren. Es sei denn, der geheime Schlüssel wird auf dem kompromittierten Server gespeichert und/oder es gibt ein System zur automatischen Signatur von Dateien. Leider kann man einer signierten Datei nicht ansehen, ob der verwendete Schlüssel sicher aufbewahrt wird, i.A. kann man aber davon ausgehen, dass das so ist. Ist die Signatur korrekt, wurde die Datei nicht manipuliert. Aber wie erkennt man, ob die Signatur korrekt ist?

Zum Prüfen der Signatur benötigt man den öffentlichen Schlüssel des Signierers. Im Fall von ProFTPD wurden die Signaturen der Dateien in der E-Mail, mit der vor der Kompromittierung der Pakete gewarnt wurde, veröffentlicht und auf den verwendeten Schlüssel verwiesen:

"The PGP key of TJ Saunders has been used to sign the source tarballs; it is available via MIT's public keyserver."

Um die Signatur prüfen zu können, muss man sich also TJ Saunders Public Key vom Keyserver laden und mit Hilfe des Web of Trust seine Vertrauenswürdigkeit prüfen. Vertraut man dem Schlüssel bzw. dessen Inhaber, kann man auch den damit signierten Dateien vertrauen. Dies ist also eine vorbildliche Lösung. Es ginge aber auch anders:

Advocatus Diaboli in Aktion

Man könnte den für die Prüfung der Signatur benötigten öffentlichen Schlüssel der Einfachheit halber auf dem eigenen Webserver bereit stellen, so dass die Benutzer ihn nicht erst anderswo suchen müssen. Und auf so etwas Aufwändiges wie eine Teilnahme am Web of Trust könnte man ja auch verzichten, schließlich laden die Benutzer den Schlüssel ja vom eigenen Webserver herunter, und dann muss es ja der richtige sein, oder?

Damit würden Manipulationen wieder Tür und Tor geöffnet: Ein erfolgreicher Angreifer kann dann die manipulierte Datei mit einem eigenen Schlüssel signieren und den zugehörigen öffentlichen Schlüssel an Stelle des originalen auf dem Webserver speichern. Vertrauen die Benutzer dem vom Webserver herunter geladenen Schlüssel, vertrauen sie auch den damit signierten, manipulierten Dateien.

Das einzige Indiz für eine Manipulation ist dann der ausgetauschte öffentliche Schlüssel, der aber nur auffällt, wenn ein Benutzer einen früher bereits heruntergeladenen Schlüssel zur Prüfung verwendet. Aber dem kann der Angreifer durch einen entsprechenden Hinweis auf der Webseite begegnen. Wer würde schon misstrauisch, wenn da z.B. der Hinweis "Aus Sicherheitsgründen haben wir den Signaturschlüssel gegen einen längeren ausgetauscht, bitte verwenden Sie zum Prüfen in Zukunft nur noch den folgenden Schlüssel:" auftauchen würde? Immer daran denken: Wenn ein Angreifer den Server unter seiner Kontrolle hat, kann er damit machen, was er will. Oder wie wäre es mit einer Mail an alle Benutzer, in der z.B. auf neue Features oder behobene Fehler sowie den neuen Schlüssel hingewiesen wird? Oder einer entsprechenden Mail auf der Mailingliste des Anbieters?

I.A. sollte ein so offensiver Angriff schnell auffallen, aber vielleicht hat der Angreifer dann ja sein Ziel schon erreicht und ein paar Opfer gefunden.

Die sichere Lösung

Wirklich sicher ist nur eine Methode: Die Dateien müssen mit einem überprüfbaren Schlüssel signiert werden, egal ob das nun ein über das Web of Trust für PGP/GPG-Schlüssel oder ein über ein hierarchisches Zertifizierungssystem zertifizierter Schlüssel ist. Der private Schlüssel darf keinesfalls auf einem mit dem Internet verbundenen Server gespeichert werden, und eine wie auch immer geartete Möglichkeit, Dateien automatisch zu signieren, ist natürlich erst recht tabu.

Wenn ein Angreifer dann einen Server kompromittiert und Dateien manipuliert, kann die Manipulation anhand der fehlenden oder falschen Signatur erkannt werden. Wie viele Benutzer die Signaturen überhaupt beachten, ist dann eine andere Frage. Auf die man die Antwort eigentlich gar nicht wissen will, die ist zu deprimierend.

Pikantes Detail am Rande

Was fragt man sich zuerst, wenn der FTP-Server eines FTP-Server-Entwicklers kompromittiert wurde? Welcher Server lief denn da, und wie wurde er kompromittiert? In diesem Fall ist es wirklich ein ProFTPD-Server gewesen - und der Angreifer konnte über eine ungepatchte Schwachstelle eindringen. Das ist natürlich äußerst peinlich, aber auch anderen schon passiert, z.B. den Entwicklern von e107. Den betroffenen Entwicklern dürfte das peinlich genug sein, um den gleichen Fehler nicht nochmal zu machen. Allen anderen sollte es eine Lehre sein: Wenn man im eigenen Programm eine Schwachstelle (oder allgemein einen Fehler) behebt, darf man nicht vergessen, die selbst verwendeten Installationen zu aktualisieren.

Carsten Eilers

Trackbacks

Dipl.-Inform. Carsten Eilers am : 2010 - Ein Rückblick auf ein ereignisreiches Jahr

Vorschau anzeigen
2010 war ein gerade aus Sicht der IT-Sicherheit ereignisreiches Jahr. 2011 kann es gerne ruhiger zugehen, aber vermutlich gilt wie immer die Regel von Bernd dem Brot: "Alles ist wie immer, nur schlimmer! Einige Beispiele: So hat z.B. das Bund

Dipl.-Inform. Carsten Eilers am : php.net war für Drive-by-Infektionen präpariert

Vorschau anzeigen
Am Donnerstag stufte Google php.net als bösartige Website ein. Was zuerst wie ein Fehlalarm, also ein False Positive, aussah, entpuppte sich später als tatsächliche Kompromittierung, es wurde Code für Drive-by-Infektionen