Debian-Untersuchungsbericht nach Serverkompromittierungen
------------------------------------------------------------------------
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 www.debian.org auf 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>.
Reply to: