Debian-Untersuchungsbericht nach Serverkompromittierungen

[Gast]

Ich poste das mal um einen aktuellen Überblick zu ermöglichen!

------------------------------------------------------------------------
Das Debian-Projekt http://www.debian.org/
Debian-Untersuchungsbericht press@debian.org
2. Dezember 2003
------------------------------------------------------------------------

Debian-Untersuchungsbericht nach Serverkompromittierungen

Das Debian-Administrationsteam und Sicherheitsexperten können schluss- endlich die Quelle des Einbruchs in vier Rechner des Projekts genau festlegen. Jedoch ist die Person, die es getan hat, noch nicht eruiert.

Die Paket-Archive wurden vom Eindringling nicht verändert.

Die Debian-Administration und Sicherheitsteams haben diese Archive (security, us, non-us) ziemlich früh während den Untersuchungen und dem Neuinstallationsprozess geprüft. Das ist der Grund, warum das Projekt die Sicherheitsarchive wieder öffnen konnte und bestätigte, dass die Aktualisierung für stable (3.0r2) nicht beeinträchtigt war.

Falls das Projekt vorhergesehen hätte, zur gleichen Zeit kompromittiert zu werden wie die stable-Aktualisierung durchgeführt wurde, hätten die daran arbeitenden Personen es zurückgestellt. Jedoch waren die aktualisierten Pakete im stable-Archiv und auf den Spiegel-Servern zum Zeitpunkt der Entdeckung des Einbruchs bereits installiert, daher war es nicht möglich, es noch zurückzuhalten.

Mehrere Methoden basierend auf verschiedenen Kontrolldaten wurden verwendet, um die Pakete zu verifizieren und sicherzustellen, dass die Archive vom Angreifer nicht verändert wurde:

. extern gespeicherte Listen von auf nicht beeinträchtigten Rechnern
gesammelten MD5-Summen während der vergangenen Wochen . digital unterschriebene .changes-Dateien von externen
debian-devel-changes Archiven auf nicht beeinträchtigten Rechnern . digital signierte .changes-Dateien auf den entsprechenden
Archiv-Servern
. extern gespeicherte Spiegel-Logdateien


Zeitablauf

Unterhalb ist der Zeitablauf der Entdeckung und Restaurierung der kompromittierten Rechner zu finden. Alle Zeiten sind in UTC angegeben.
Einige Zeiten sind nur geschätzt, da unsere Konversation keine genauen Zeitstempel enthält.

28. Sep 01:33 Linus Torvalds gab 2.6.0-test6 mit do_brk()-Behebung
frei
2. Okt 05:18 Marcello Tosatti wendet do_brk()-Grenzprüfung an
19. Nov 17:00 Angreifer meldet sich auf klecker mit einem
mitprotokollierten Passwort an
19. Nov 17:08 Root-Kit auf klecker installiert
19. Nov 17:20 Angreifer meldet sich auf master mit dem selben
mitprotokollierten Passwort an
19. Nov 17:47 Root-Kit auf master installiert
19. Nov 18:30 Angreifer meldet sich auf murphy mit einem
Service-Konto von master aus an
19. Nov 18:35 Root-Kit auf murphy installiert
19. Nov 19:25 Kernel-Oops auf murphy beginnen
20. Nov 05:38 Kernel-Oops auf master beginnen
20. Nov 20:00 Entdeckung der Kernel-Oops auf master und murphy
20. Nov 20:54 Root-Kit auf gluck installiert
20. Nov 22:00 Bestätigung, dass in debian.org eingebrochen wurde
21. Nov 00:00 Deaktivierung aller Konten
21. Nov 00:34 security.debian.org heruntergefahren
21. Nov 04:00 gluck heruntergefahren (www, cvs, people, ddtp)
21. Nov 08:30 http://www.debian.org auf http://www.de.debian.org umgestellt
21. Nov 10:45 Öffentliche Ankündigung
21. Nov 16:47 Entwicklerinformationen aktualisiert
21. Nov 17:10 murphy (lists) heruntergefahren
22. Nov 02:41 security.debian.org wieder Online
25. Nov 07:40 lists.debian.org wieder Online
28. Nov 22:39 Linux 2.4.23 freigegeben


Entdeckung

Am Abend (GMT) von Donnerstag, dem 20. November, bemerkten das Administrationsteam mehrere Kernel-Oops auf master. Da das Rechner über eine lange Zeit ohne Probleme lief, wurde der Rechner für genauere Untersuchungen von möglichen Hardwareproblemen in Wartung genommen.
Jedoch hat ein zweiter Rechner, murphy, zur gleichen Zeit genau die gleichen Probleme gezeigt, was die Administratoren misstrauisch werden lies.

Desweiteren haben klecker, murphy und gluck »Advanced Intrusion Detection Environment« (Paket aide) installiert, um Dateisystem- änderungen zu überwachen und zur etwa der gleichen Zeit fing es an zu warnen, dass /sbin/init ersetzt wurde und dass sich die mtime- und ctime-Werte für /usr/lib/locale/en_US verändert haben.

Weitere Untersuchungen ergaben als Ursache für beide diese Probleme das SucKIT-Root-Kit. Es enthält einen Passwortschnüffler und Versteck- Fähigkeiten (d.h. Werkzeuge, um Prozesse und Dateien zu verbergen), die direkt in den Kernel installiert werden, was die Kernel-Oops verursacht hat, die entdeckt wurden.


Detaillierte Angriffsanalyse

Am Mittwoch, dem 19. November, um etwa 17:00 GMT wurde ein mitprotokolliertes Passwort verwendet, um sich mit einem nicht bevorrechtigtes Entwicklerkonto auf dem Rechner klecker (.debian.org) anzumelden. Der Angreifer holte sich dann über HTTP den Quellcode für eine (zu diesem Zeitpunkt) unbekannte lokale Kernel-Ausnutzung und erhielt root-Berechtigungen mittels dieses Programms. Anschließend wurde das SucKIT-Root-Kit installiert.

Die selben Konto- und Passwort-Daten wurden dann verwendet, um sich auf dem Rechner master anzumelden, um root-Berechtigungen mit dem selben Programm zu erlangen und ebenfalls das SucKIT-Root-Kit zu installieren.

Der Angreifer versuchte anschließend, Zugriff auf den Rechner murphy mit dem selben Konto zu erlangen. Dies schlug fehl, da murphy eine begrenzter Rechner ist und sein einziger Zweck es ist, als Listen-Server zu dienen, auf den sich nur eine kleine Anzahl von Entwicklern anmelden können. Da der ursprüngliche Login-Versuch nicht funktionierte, verwendete die Person ihren root-Zugriff auf master, um ein administra- tives Konto zu verwenden, das für Backup-Zwecke verwendet wurde, und dadurch ebenfalls Zugriff auf murphy zu erlangen. Das SucKIT-Root-Kit wurde auf diesem Rechner ebenfalls installiert.

Am nächsten Tag verwendete der Angreifer ein auf master mitprotokolliertes Passwort, um sich auf gluck anzumelden, dort root zu erhalten und ebenfalls das SucKIT-Root-Kit zu installieren.

Die forensische Analyse enthüllte die genauen Daten und Zeiten, wann das Programm /sbin/init überschrieben und das Root-Kit installiert wurde.
Die Analysten entdeckten ebenfalls die ausführbare Datei, die verwendet wurde, um root-Zugriff auf den Rechnern zu erlangen. Diese wurde durch Burneye verschleiert und geschützt. Bei der Disassemblierung und Entschlüsselung der Datei entdeckten die Sicherheitsexperten, welcher Kernelfehler verwendet wurde.

Ein Integer-Überlauf im brk-Systemaufruf wurde ausgenutzt, um Kernelspeicher (»change page protection bits«) zu überschreiben. Dadurch erhielt der Angreifer komplette Kontrolle über den Kernelspeicher und so war es ihm möglich, jeden Wert im Speicher zu ändern.

Selbst obwohl dieser Kernelfehler im September von Andrew Morton entdeckt und bereits in aktuellen pre-release-Kernel seit Oktober behoben ist, wurden seine Sicherheitsauswirkungen als nicht so schwerwiegend angenommen. Deshalb wurde von keinem Distributor ein Sicherheitsgutachten ausgestellt. Jedoch hat das »Common Vulnerabilities and Exposures«-Projekt diesem Problem die Kennzeichnung CAN-2003-0961 zugewiesen, nachdem entdeckt wurde, dass es für eine lokale root- Ausbeutung benutzt werden kann. Es ist im Debian-Gutachten DSA 403 und im Linux-Kernel 2.4.23 behoben, der während des vergangenen Wochenende freigegeben wurde.

Linux 2.2.x ist für diesen Angriff nicht verwundbar, da hier die Grenzprüfung zuvor stattfindet. Es wird ebenfalls angenommen, dass
Sparc- und PA-RISC-Kernel nicht dafür anfällig sind, da Benutzer- und Kernel-Adressen auf diesen Architekturen in verschiedenen Adressräumen gespeichert werden.

Bitte verstehen Sie, dass wir den verwendeten Exploit nicht an zufällige Personen weitergeben können, die wir nicht kennen. Also fragen Sie uns bitte nicht danach.


Wiederherstellung

Nachdem die Rechner heruntergefahren wurden, wurden Images von allen beeinträchtigten Festplatten erstellt und auf getrennten Rechnern gespeichert. Diese wurden an die Leute verteilt, die die forensische Analyse durchführten. Die drei Rechner in den USA (master, murphy und
gluck) wurden anschließend neu installiert und ihre Dienste einer nach dem anderem nach deren Untersuchung durch den entsprechenden Dienst- Administrator wieder eingesetzt.

Auf klecker jedoch wurde dies für eine eine später angesetzte Wartung verschoben, damit das Sicherheitsarchiv rascher alls die anderen Dienste wieder Online gebracht werden konnte. Zu dieser Zeit hatten wir keinen physikalischen Zugriff auf klecker, daher musste die Wiederherstellung aus der Ferne geschehen. Nachdem ein Plattenimage über eine Login auf einer serielle Konsole auf einen lokalen Rechner über eine geschützte Netzverbindung erstellt wurde, wurde das Root-Kit entfernt, der Kernel ausgetauscht und gehärtet, die Programme doppelt überprüft und das Sicherheitsarchiv gegen mehrere verschiedene externe Quellen geprüft.
Dieser Rechner wird in den nächsten Wochen neu installiert werden.

Als Sicherheitsvorkehrung wurden alle Entwicklerkonten im LDAP deaktiviert und ssh-Schlüssel auf den wichtigeren Rechnern entfernt, damit keine weiteren Rechner beeinträchtigt werden können. Dies jedoch deaktiviert jegliche öffentliche Debianarbeit, die das Hochladen von Dateien und den Zugriff auf die CVS-Repositories bedürfen.

Alle auf quantz verwendeten Passwörter (d.h. alle Alioth-, arch- und
Subversion-Passwörter) wurden ebenfalls für ungültig erklärt. Alle berechtigten ssh-Schlüssel wurden ebenfalls gelöscht. Bitte verwenden Sie das »Verlorenes Passwort«-System, um ein neues zu erhalten:

https://alioth.debian.org/account/lostpw.php

Wenn alle Dienste wieder laufen und die Rechner hinreichend gesichert sind, wird LDAP zurückgesetzt, damit die Entwickler wieder ein neues Passwort (<http://db.debian.org/password.html>) erstellen können. Es kann zur Zeit jedoch nicht abgeschätzt werden, wann dies passieren wird.

Während dem Wiederherstellen wurde SSH auf den beeinträchtigten Rechnern neu installiert. Daher gibt es neue RSA-Rechnerschlüssel und Schlüssel-Fingerabdrücke für diese Rechner. Die Schlüssel werden sobald sie erstellt sind ins LDAP eingefügt und sind unter <http://db.debian.org/machines.cgi> verfügar.


Konsequenzen

!! Erneuern Sie Ihre Passwörter! !!

Da Passwörter auf den beeinträchtigten Rechnern mitprotokolliert wurden, muss jede von dort ausgehende Verbindung ebenfalls als kompromittiert betrachtet werden, d.h. die Passwörter dürften dem Angreifer bekannt sein. Sie sollten daher dringend geändert werden.

Desweiteren, falls jemand Zugriff auf einen Debian-Rechner hatte und das selbe Passwort oder Mantra auch auf anderen Rechnern oder mit anderen Schlüsseln verwendet hat, empfehlen wir dringend, so rasch wie möglich die Passwörter und Mantras zu ändern.

Falls ein SSH-Schlüssel auf einem dieser Rechner generiert oder gespeichert wurde und verwendet wurde, um sich auf anderen Rechnern anzumelden (d.h. durch das Installieren in .ssh/authorized_keys), sollte dieser ebenfalls gelöscht werden.

Die geheimen GnuPG-/PGP-Schlüssel, die auf debian.org-Rechnern gefunden wurden, wurden ebenfalls aus dem Debian-Schlüsselring und gelöscht und dadurch deaktiviert.

Entwickler, die sich Sorgen um ihre eigenen Rechner machen, sollten zumindest chkrootkit aufrufen und dessen Ausgabe prüfen. Matt Taggart betreut eine Rückportierung der aktuellen Version für woody unter der folgenden Adresse:

deb http://lackof.org/taggart/debian woody/chkrootkit main
deb-src http://lackof.org/taggart/debian woody/chkrootkit main

Zusätzlich gibt es eine von Wichert Akkerman und Matt Taggart erstellte ausführliche Liste von Vorsichtsmaßnahmen unter:

http://www.wiggy.net/debian/developer-securing/


SucKIT Root-Kit

SucKIT ist ein Root-Kit, das in der Phrack-Ausgabe 58, Artikel 0x07 (»Linux-Kernel im Vorbeigehen ohne LKM patchen«, von sd & devik), vorgestellt wurde. Es ist ein komplett funktionstüchtiges Root-Kit, das über /dev/kmem geladen wird, d.h. es benötigt keinen Kernel mit Unterstützung für ladbare Kernel-Module. Es bietet eine per Passwort geschützte entfernt nutzbare Shell, die durch ein gefälschtes Paket (das die meisten Firewall-Konfigurationen umgeht) gestartet wird, und versteckt Prozesse, Dateien und Verbindungen.

Üblicherweise wird SucKIT als /sbin/init beim Booten des Systems gestartet, forkt sich, um sich selbst in den Kernel zu installieren, startet eine Hintertür, und ruft eine Kopie des Original-»init«- Programms aus dem Mutterprozess (mit der PID 1) auf. Alle weiteren Ausführungen von /sbin/init werden an den ursprünglichen init weitergeleitet.


TESOs Burneye-Schutz

Burneye ist eine Art des Verschleiens von ELF-Programmen auf der UNIX-Platform, die in Phrack-Ausgabe 58, Artikel 0x05 (»ELF schützen:
Binär-Verschlüsselung auf der UNIX-Platform«, von grugq & scut), vorgestellt wurde. Durch die Verwendung von Hilfsprogrammen wie TESOs Burneye kann ein Angreifer ein ausführbares Programm so verändern, um seinen wahren Zweck zu verschlüsseln, was es vor Firewall-Filtern, Intrusion-Detecktion-Systemen, Anti-Viren-Software und dem neugierigen Auge der Forscher verbirgt.


Dank gebührt

. James Troup und Ryan Murray für ihre allgemeine Arbeit an allen
Rechnern
. Adam Heath und Brian Wolfe für ihre Arbeit an master und murphy
. Wichert Akkerman für seine Arbeit an klecker
. Dann Frazier ünd Matt Taggart für ihre Arbeit an gluck
. Michael Stone und Robert van der Meulen für ihre forensische Arbeit
. Marcus Meissner für das Disassemblieren des verwendeten Exploits
. Jaakko Niemi für seine Arbeit beim Prüfen und
Wiederaktivieren von lists.debian.org
. Colin Watson für seine Arbeit beim Prüfen und
Wiederaktivieren von bugs.debian.org
. Josip Rodin für seine Arbeit beim Prüfen und
Wiederaktivieren der Listen-Webarchive


Kontaktinformationen

Für weitere Informationen besuchen Sie bitte die Debian-Webseiten unter <http://www.debian.org/> oder schicken Sie eine E-Mail an <press@debian.org>.

[x-eniac]

Ich werde mir da zwar Feinde machen, aber den erfolgreichen Einbruch hat sich der Hacker verdient. Ich will nicht wissen wieviele Wochen lang der Hacker mithoeren musste um die Passwoerter zu bekommen.

Ich wuerde jedenfalls noch ein Satz hinzufuegen: NIE PASSWOERTER UNVERSCHLUESSLET UEBER DAS NETZ SCHICKEN!!!!

[ivo]

Also ich muß zugeben, dass ich die Sache nicht richtig verstehe:

Der Bug in do_brk() ist schon lange bekannt, "hat es aber in 2.4.22 nicht mehr geschafft". Wie soll ich denn das bitteschön verstehen. Wieso bringt man dann nicht sofort 2.4.23 mit dem Fix raus? Und das root-Kit wurde ja auch noch in einschlägigen Cracker-Magazinen vorgestellt. Wie kann sowas sein?

Habe ich etwas falsch verstanden?

Und warum kann ich den 2.4.23 nicht richtig installieren (siehe Thread in Kernelfragen)?

*iv

[Spike05]

Ich werde mir da zwar Feinde machen, aber den erfolgreichen Einbruch hat sich der Hacker verdient. Ich will nicht wissen wieviele Wochen lang der Hacker mithoeren musste um die Passwoerter zu bekommen.

Klar kann man soetwas nur anerkennen (auch wenn es ärgerlich ist)

Es ist aber nun mal kein System zu 100% Sicher. Es wurde aber sehr schnell behoben!

Gruß

Jochen

[eagle]

Und das root-Kit wurde ja auch noch in einschlägigen Cracker-Magazinen vorgestellt. Wie kann sowas sein?

Das rootkit ist bekannt, allerdings wusste wohl keiner das der Fehler im Kernel so schwerwiegend ist.

eagle

[spiffi]

Der Bug in do_brk() ist schon lange bekannt, "hat es aber in 2.4.22 nicht mehr geschafft". Wie soll ich denn das bitteschön verstehen. Wieso bringt man dann nicht sofort 2.4.23 mit dem Fix raus? Und das root-Kit wurde ja auch noch in einschlägigen Cracker-Magazinen vorgestellt. Wie kann sowas sein?

Habe ich etwas falsch verstanden?

Ja, hast Du.
Also, der Fehler ist deswegen nicht sofort behoben worden, weil bei seiner Entdeckung nicht klar war, daß man ihn für einen root-exploit nutzen kann.

Das rootkit wurde zwar im Dezember 2001 im Phrack-Magazin vorgestellt, hat aber nichts mit dem Fehler im brk-Systemaufruf zu tun, der ja letztendlich zum Erlangen der root-Rechte genutzt wurde.
rootkits sind Hintertüren, die einen unbemerkten root-Zugang zum System ermöglichen. Um ein rootkit zu installieren, muß der Angreifer aber bereits root-Rechte haben.

[julien]

http://www.heise.de/security/artikel/42546

[eagle]

http://www.heise.de/security/artikel/42546

Ich finde den Kommentar ziemlich schlecht. Der Autor geht davon aus, das den Leuten die Tragweite des Kernel Bugs bekannt war. Ausserdem wird versucht Missgunst zwischen die Entwickler zu streuen.

Das wir gerade nur im Unterhose darstehen ist sehr traurig, allerdings sollten die Ursachen beseitigt werden statt

.. schwarze Peter hin- und herzuschieben ..

Ich weiss ja nicht wo der Autor seine Informationen her hat, aber gibt es zur Zeit wirklich solche Auseinandersetzungen?

eagle

[spiffi]

http://www.heise.de/security/artikel/42546

Ich finde den Kommentar ziemlich schlecht. Der Autor geht davon aus, das den Leuten die Tragweite des Kernel Bugs bekannt war. Ausserdem wird versucht Missgunst zwischen die Entwickler zu streuen.

IMHO geht der Autor nicht davon aus, daß dem Kernel-Team dei Tragweite des Bugs Bugs bekannt war.
Er sagt selbst, daß es nicht Aufgabe der Kernel-Entwickler ist, gefixte Bugs auf ihre Sicherheitsrelevanz zu prüfen. Jedoch sei die Dokumentation der Bugfixes nicht ausreichend, als das die Distributoren diese Prüfung vornehmen könnten.
Hier verstrickt sich der Autor in Widersprüche, weil er wenig später schreibt, daß jeder, der die Kernel-Entwicklung verfolge, in der Lage sei einen Zero-Day-Exploit zu schreiben. Dementsprechend sollten auch die Distributoren in der Lage sein, Sicherheitslücken zu erkennen, wenn sie die Kernel-Entwicklung verfolgen.
Das Problem ist letztendlich, daß die Zuständigkeit für Kernel-Security-Advisories ungeklärt scheint. Und das kann nicht so bleiben.

[eagle]

Das Problem ist letztendlich, daß die Zuständigkeit für Kernel-Security-Advisories ungeklärt scheint. Und das kann nicht so bleiben.

*eagle unterschreib*