Original-URL des Artikels: https://www.golem.de/news/websicherheit-verraeterische-coredumps-im-webverzeichnis-1706-128377.html    Veröffentlicht: 15.06.2017 09:09    Kurz-URL: https://glm.io/128377

Websicherheit

Verräterische Coredumps im Webverzeichnis

Coredumps sind ein hilfreiches Instrument, um nach einem Softwareabsturz eine Fehleranalye zu betreiben. Doch die Fehlerberichte sind auf zahlreichen Webseiten öffentlich einsehbar, wie wir herausgefunden haben. Dabei werden zum Teil auch private Daten wie Passwörter veröffentlicht.

Wenn unter Linux ein Programm abstürzt, kann es eine Kopie des Programmspeichers in einen sogeannten Coredump speichern. Das kann zum Sicherheitsrisiko werden. Wir haben herausgefunden: Bei vielen Webseiten lassen sich die Coredumps von früheren Abstürzen herunterladen.

Die Ursachen der Abstürze können dabei vielfältig sein: Speicherzugriffe auf ungültige Speicherbereiche, Dereferenzierung von Null-Pointern oder endlose Rekursionen von Funktionsaufrufen - sie alle können dazu führen, dass eine Software vom Betriebssystem beendet wird.



Unter Linux und anderen Unix-Systemen gibt es eine Funktion, die bei der Analyse solcher Abstürzte hilft: Sogenannte Coredumps. Dabei wird der Speicherinhalt eines abgestürzten Programms in eine Datei geschrieben. In der Standardeinstellung des Linux-Kernels heißt diese Datei schlicht "core" und wird im aktuellen Verzeichnis abgelegt. Diese Coredumps lassen sich mit Debugging-Tools wie GDB später analysieren, um die Ursache des Crashs herauszufinden.

So hilfreich dies sein kann, Coredumps können auch zum Sicherheitsrisiko werden. Je nach Konfiguration enthalten sie teilweise oder komplett alle Daten, den eine Applikation zum Zeitpunkt des Absturzes im Arbeitsspeicher hatte. Darunter können sich natürlich auch private Daten befinden, beispielsweise Passwörter. Ein Coredump sollte also niemals an nicht vertrauenswürdige Personen weitergegeben werden.

Coredumps lassen sich oft von Webseiten herunterladen

Doch eine ganze Reihe von Webseiten lassen unbeabsichtigt einen Zugriff auf Coredumps zu. Der Hintergrund: Wenn eine Webapplikation abstürzt, landet der Coredump häufig direkt im Web-Verzeichnis - und kann von dort einfach heruntergeladen werden. Ein Angreifer kann somit Webseiten nach Coredumps absuchen, indem er URLs der Form http://example.com/core abruft.

Bei einem Scan der Alexa-Top-1-Million-Liste waren circa Tausend Webseiten von diesem Problem betroffen. Bei der überwiegenden Mehrzahl handelte es sich um PHP-Applikationen. PHP stürzte in der Vergangenheit relativ häufig ab.

In den vergangenen Jahren wurden sehr viele Bugs gefixt, die in PHP zu Abstürzen führen können, insbesondere da es für PHP seit einiger Zeit ein Bug-Bounty-Programm gibt. Doch nach wie vor kann man PHP mit einfachen Codebeispielen zum Abstürz bringen.



Anlage von Coredumps im Webroot kann verhindert werden

Für Betroffene gilt: Wer einen derartigen Coredump in einem Webverzeichnis vorfindet, sollte ihn dort umgehend entfernen. Aber man sollte auch sicherstellen, dass künftig keine weiteren Coredumps dort abgelegt werden. Unter Linux wird die Erstellung von Coredumps durch zwei Einstellungen beeinflusst.

Zum einen kann über die Konfigurationsdatei /etc/security/limits.conf eingestellt werden, wie groß Coredumps werden dürfen. Stellt man dort die Größe auf Null, dann werden überhaupt keine Coredumps angelegt. Eine entsprechende Konfigurationszeile, die standardmäßig Coredumps für alle Nutzer abschaltet, sieht so aus:

* soft core 0

Eine weitere Einstellungsmöglichkeit findet man in einem Sysctl-Interface unter /proc/sys/kernel/core_pattern. Dort kann man angeben, unter welchem Pfad und Dateinamen Coredumps abgelegt werden. Das ist dann hilfreich, wenn man Coredumps nicht komplett abschalten möchte, etwa weil man sie anschließend mit einem Debugger analysieren möchte, um die Ursache von Abstürzen herauszufinden. Eine mögliche Einstellung wäre etwa diese hier:

/var/log/core/core.%e.%p.%h.%t

Hierbei wird im Verzeichnis /var/log/core/ eine Datei angelegt, deren Dateiname auch Namen der Applikation, die Prozess-ID, den Hostnamen und einen Timestamp enthält. Wichtig: Das Verzeichnis /var/log/core/ muss für alle Nutzer schreibbar sein, dafür kann man es mit dem Sticky Bit (chmod +t) versehen.

Auch wichtig: Man kann zwar diese Einstellung direkt in die virtuelle Datei /proc/sys/kernel/core_pattern schreiben, dann ist sie aber nach dem nächsten Reboot wieder verloren. Dauerhaft konfigurieren kann man sysctl-Optionen in der Datei /etc/sysctl.conf, etwa in dieser Form:

kernel.core_pattern = /var/log/core/core.%e.%p.%h.%t

Einige Linux-Distributionen, darunter etwa Fedora und Ubuntu, leiten Coredumps direkt an ein Tool weiter, das die Crashes analysiert. Unter Ubuntu sieht dies etwa so aus:

|/usr/share/apport/apport %p %s %c %P

Ob diese Vorgehensweise schlau ist, darüber kann man sicher geteilter Meinung sein. Das Tool apport und auch das von Fedora verwendete Abrt waren selbst schon die Ursache von Sicherheitslücken.



Schwieriger Disclosure-Prozess

Wir haben versucht, die Betreiber der betroffenen Webseiten zu erreichen. Bei Hunderten von Betroffenen ist es allerdings kaum praktikabel, diese manuell zu informieren. Die Firma Abusix bietet für derartige Zwecke jedoch einen interessanten Service an: Mittels einer DNS-Anfrage kann man dort zu einer IP-Adresse den passenden Abuse-Kontakt herausfinden.

Wir haben neben anderen Versuchen alle Abuse-Kontakte der IPs, die zu den entsprechenden Webseiten gehören, informiert. In vielen Fällen wurden die Coredumps anschließend gelöscht, doch viele Nachrichten wurden auch ignoriert. Erstaunlich viele Webseiten hatten zudem Abuse-Adressen, die nicht erreichbar waren oder gar keine Abuse-Kontakte.

Einfacher Selbsttest

Da wir nur die Alexa-Top-1-Millionen-Liste gescannt haben sind natürlich zahlreiche kleinere Webseiten betroffen, die wir nicht informiert haben. Ob ein Coredump vorhanden ist, lässt sich relativ trivial testen: Man versucht, die Datei /core von einer Domain herunterzuladen. Falls sich dort eine Datei herunterladen lässt, die wie eine Executable aussieht, gibt es ein Problem.

Unter Linux werden Coredumps im ELF-Format abgelegt. Seltener antreffen dürfte man Mach-O-Dateien, die von OS X verwendet werden. Einige ältere Unix-Derivate nutzen auch das A.Out-Format. Es wäre sicherlich sinnvoll, wenn Sicherheitstests für Webseiten und Pentester diese Lücke bei künftigen Tests berücksichtigen.

Einmal mehr zeigt sich hier, dass sich von Webservern oft private Daten abrufen lassen, die dort nicht hingehören. Erst kürzlich hatten wir darüber berichtet, wie der Webshop Redcoon und die Seite des Projektes Volksverschlüsselung private Git-Verzeichnisse im Webroot liegen ließen. Und bei der Suchmaschine Ask.com konnte man eine Apache-Status-Seite abrufen.  (hab)


Verwandte Artikel:
Sysinternals-Werkzeug: Microsoft stellt Procdump für Linux vor   
(11.12.2017, https://glm.io/131599 )
Librem 5: Purism-Smartphone bekommt Smartcard für Verschlüsselung   
(09.03.2018, https://glm.io/133248 )
Datenschutz: BVG-Webseite verrät Besucher-IPs und Mailadressen   
(01.03.2018, https://glm.io/133054 )
Verschlüsselung: TLS 1.3 ist so gut wie fertig   
(16.02.2018, https://glm.io/132828 )
ROBOT-Angriff: Arbeitsagentur nutzt uralte Cisco-Geräte   
(09.03.2018, https://glm.io/133258 )

© 1997–2019 Golem.de, https://www.golem.de/