Debian-Untersuchungsbericht nach Serverkompromittierungen

2. Dezember 2003

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

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 der Untersuchungen und des Neuinstallationsprozesses 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 wurden:

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.

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 ließ.

Des Weiteren 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 (1.3b). 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 administratives 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 Kernelcode im September von Andrew Morton verbessert und bereits in einen aktuellen pre-release-Kernel seit Oktober kopiert ist, wurden die Sicherheitsauswirkungen der Verbesserung nicht betrachtet. Deshalb wurde von keinem Distributor eine Sicherheitsankündigung 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 in der Debian-Ankündigung 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 später angesetzte Wartung verschoben, damit das Sicherheitsarchiv rascher als die anderen Dienste wieder Online gebracht werden konnte. Zu dieser Zeit hatten wir keinen physischen Zugriff auf klecker, daher musste die Wiederherstellung aus der Ferne geschehen. Nachdem ein Plattenimage über ein Login auf einer serielle Konsole auf einem 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-Depots 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.

Wenn alle Dienste wieder laufen und die Rechner hinreichend gesichert sind, wird LDAP zurückgesetzt, damit die Entwickler wieder ein neues Passwort erstellen können. Es kann zurzeit jedoch nicht abgeschätzt werden, wann dies passieren wird.

Während des Wiederherstellens 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 hier verfügbar.

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.

Des Weiteren, 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:

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

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 Verschleierns von ELF-Programmen auf der UNIX-Plattform, die in Phrack-Ausgabe 58, Artikel 0x05 (ELF schützen: Binär-Verschlüsselung auf der UNIX-Plattform, 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-Detektion-Systemen, Anti-Viren-Software und dem neugierigen Auge der Forscher verbirgt.

Danksagungen

Pressemeldungen

Kontaktinformationen

Für weitere Informationen besuchen Sie bitte die Debian-Webseiten oder schicken Sie eine E-Mail an press@debian.org.