Analyse des Vorfalls der Intrusion auf helium.ruby-lang.org

Gepostet von Shugo Maeda am 22. Jul 2004

Wie bereits berichtet, wurde helium.ruby-lang.org, ein Server, der verschiedene Dienste im Zusammenhang mit der Ruby-Entwicklung bereitstellte, von einem unbefugten Benutzer kompromittiert. Wir, die Administratoren von ruby-lang.org, berichten über unsere Analyse dieser Intrusion und die von uns ergriffenen Gegenmaßnahmen.

Zeitstrahl des Vorfalls

Der zeitliche Ablauf des Einbruchs ist unten dargestellt. Alle Zeiten sind in UTC.

19 May       The public disclosure of a vulnerability of CVS
             (CAN-2004-0396) is announced.  We believe that this
             vulnerability was used in this intrusion.
20 May 02:46 The Debian CVS package of the host helium.ruby-lang.org
             (hereafter called 'helium') is upgraded. However, the
             chrooted CVS package, which provided the actual pserver,
             is overlooked.
23 May 11:15 Oldest (corroborated) time stamp of the trace of intrusion
27 May 19:03 Opening of the back-door installed by the invader
28 May 09:26 A ruby-lang.org administrator discovers a trace of the
             intrusion.
28 May 09:35 Administrator disconnects 'helium' from network.
28 May 11:53 Administrator reboots 'helium' and resumes mailing list
             services.
29 May 07:28 Our first announcement about this intrusion.

Maschinen und Dienste zu dieser Zeit

Ruby-bezogene Dienste wurden zum Zeitpunkt des Einbruchs von den folgenden zwei Maschinen angeboten.

helium.ruby-lang.org

Die folgenden Dienste wurden von 'helium' bereitgestellt.

• CVS (cvs.ruby-lang.org)
• HTTP (www.ruby-lang.org/raa.ruby-lang.org)
• FTP (ftp.ruby-lang.org)
• RSYNC (für Mirror-Sites)
• ML (<ML-Name>@ruby-lang.org)

hydrogen.ruby-lang.org (im Folgenden 'hydrogen' genannt)

Die folgenden Dienste wurden von 'hydrogen' bereitgestellt.

• HTTP (www.rubyist.net)
• NFS (zum Exportieren von /home nach 'helium')

Details des Einbruchs

Auf 'helium' wurde der pserver-Dienst unter den Berechtigungen des anoncvs-Benutzers in einer chroot-Umgebung angeboten. Dieser CVS-Dienst wurde für die Entwicklung von Ruby verwendet, und mehrere Committer hatten ihre eigenen Konten. Öffentlicher Lesezugriff auf CVS war über das Benutzerkonto 'anonymous' gestattet.

Wie oben erwähnt, wurde die Schwachstelle von CVS am 19. Mai bekannt gegeben. Obwohl das Debian CVS-Paket von 'helium' am 20. Mai aktualisiert wurde, wurde das CVS-Paket der chroot-Umgebung nicht aktualisiert.

Unter diesen Umständen entdeckte ein Administrator von 'helium' am 28. Mai um 09:26 Uhr (UTC) dubiose Prozesse von anoncvs. Mehrere verdächtige, ausführbare Dateien wurden vom oder von den Eindringlingen installiert gefunden, darunter ein Programm, das eine Backdoor erstellte, die auf TCP-Port #54320 lauschte. Dieses Backdoor-Programm lief zum Zeitpunkt der Entdeckung des Einbruchs. Die oben genannte Zeit auf der "Zeitleiste" wurde aus der Ausgabe des 'ps'-Befehls und dem Zeitstempel der intrusiven ausführbaren Datei ermittelt. Wir weisen darauf hin, dass alle externen Verbindungen zur Backdoor durch die IP-Paketfilterfunktion des Linux-Kernels verhindert wurden.

Eine weitere Anmerkung: Normalerweise erstellt der pserver-Prozess ein temporäres Verzeichnis (/tmp/cvs-serv<Prozess-ID>) für jede Sitzung und löscht es am Ende der Sitzung. Zum Zeitpunkt des Einbruchs blieben mehr als ein temporäres Verzeichnis im /tmp-Verzeichnis der chroot-Umgebung zurück. Dies deutet darauf hin, dass die pserver-Prozesse abnormal beendet wurden, möglicherweise durch den Angriff des oder der Eindringlinge. Der älteste Zeitstempel dieser temporären Verzeichnisse stammt vom 23. Mai, 11:15 Uhr (UTC). Die oben genannte Zeit auf der "Zeitleiste" wurde anhand dieses Zeitstempels ermittelt. Beim Vergleich der Zeitstempel dieser Verzeichnisse mit dem pserver-Sitzungsprotokoll scheint es, dass mehrere unabhängige Hacker die Schwachstelle ausgenutzt haben.

Diese Beweise deuten darauf hin, dass der oder die Eindringlinge die CVS-Schwachstelle ausgenutzt und die Berechtigung als anoncvs-Benutzer auf 'helium' erhalten haben. Der oder die Eindringlinge konnten alle Informationen innerhalb der chroot-Umgebung abrufen, verändern und zerstören.

Beweise wie die Übernahme anderer Konten, lokale Privilege-Escalation oder das Eindringen außerhalb der chroot-Umgebung wurden bisher nicht gefunden.

Die Möglichkeit eines Einbruchs außerhalb der chroot-Umgebung

Damit Eindringlinge den chroot-Schutz durchbrechen können, ist eine Beförderung zu einem privilegierten Benutzer erforderlich.

Zum Zeitpunkt des Einbruchs lief der Linux-Kernel auf 'helium' in Version 2.4.24. Der Patch für die Schwachstelle (zurückportiert von Kernel-Version 2.4.25) war angewendet. Der Patch für die setsockopt(2)-Schwachstelle, die in Kernel 2.4.26 behoben wurde, war jedoch nicht angewendet.

Der Code für einen DoS-Angriff, der eine anfällige setsockopt(2)-Funktion ausnutzt, wurde zwar vorgeführt, es wird jedoch als schwierig angesehen, daraus erfolgreich eine lokale Privilege-Escalation zu erreichen. Es scheint unmöglich, eine Privilege-Escalation zu erreichen, wenn der Eindringling das Kernel-Image der Zielumgebung nicht abrufen kann. Auf 'helium' stammte der Kernel nicht aus einem Binärpaket, sondern wurde aus Quellcode mit individuell angewendeten Patches erstellt. Daher wird die Möglichkeit, dass der Eindringling eine Privilegienerhöhung erreichen konnte, als minimal erachtet.

Wiederherstellung von Diensten

Bei der ersten Untersuchung vermuteten wir, dass der Einbruch wahrscheinlich nur innerhalb der chroot-Umgebung stattfand. Zuerst beschlossen wir, den Mailinglisten-Dienst auf 'helium' wieder aufzunehmen, da die Auswirkungen einer Unterbrechung des Mail-Dienstes aus Sicht der Benutzer als am größten eingeschätzt wurden. Nachdem wir überprüft hatten, dass keine Änderung am Binärpaket vorgenommen wurde und auch keine verdächtigen Einstellungen in den Konfigurationsdateien vorhanden waren, haben wir den Mailinglisten-Dienst wiederhergestellt.

Anschließend begannen wir mit der Bestätigungsarbeit für die Wiederaufnahme anderer Dienste auf 'helium', entschieden uns aber bald stattdessen dafür, die Maschine gründlich neu aufzubauen und die Dienste einzeln wieder aufzunehmen, nachdem jeder einzeln überprüft worden war. Diese Entscheidung wurde aufgrund der Schwierigkeit, die große Anzahl von Dateien zu inspizieren, getroffen.

Zur Wiederherstellung des Dienstes benötigten wir eine Maschine als Ersatz für 'helium'. Wir beschlossen, 'hydrogen' zu verwenden, das www.rubyist.net hostete. 'Hydrogen' bot keinen pserver-Dienst an und es wurden keine Spuren des Einbruchs auf der Maschine gefunden, aber 'hydrogen' stellte /home als NFS-gemountetes Dateisystem für 'helium' bereit. Um sicherzustellen, dass 'hydrogen' nicht kompromittiert wurde, haben wir das Betriebssystem von 'hydrogen' neu installiert und den Hostnamen in 'lithium' geändert. Dann haben wir den Mailinglisten-Dienst von 'helium' nach 'lithium' verlegt, zusammen mit der Einbruchsankündigungsseite der Website.

Als Nächstes installierten wir das Betriebssystem von 'helium' neu und änderten den Hostnamen in 'beryllium'. Wir planen, alle öffentlichen Dienste zukünftig nach 'beryllium' zu migrieren.

Maschinen und Dienste aktuell

Derzeit werden Ruby-bezogene Dienste von den folgenden zwei Maschinen angeboten.

lithium.ruby-lang.org

Die folgenden Dienste werden von lithium.ruby-lang.org bereitgestellt.

• CVS (für Committer-Entwicklung, kein öffentlicher Zugriff)
• Mailingliste (Umzug nach 'beryllium' geplant)

beryllium.ruby-lang.org

Die folgenden Dienste werden von beryllium.ruby-lang.org bereitgestellt.

• HTTP (www.ruby-lang.org/raa.ruby-lang.org/www.rubyist.net)
• FTP (ftp.ruby-lang.org)
• Anonymer CVS (cvs.ruby-lang.org)

Verifizierung des Inhalts jedes Dienstes

Im Folgenden erklären wir die Ergebnisse unserer Bemühungen, zu bewerten, ob es durch die Eindringlinge zu Veränderungen oder Zerstörungen der Dienste gekommen ist.

Voraussetzung

Der älteste Beweis, den wir für den Einbruch haben, stammt vom 23. Mai und wurde bestätigt; da diese Spur vom oder von den Eindringlingen mit anoncvs-Benutzerberechtigung hätte gelöscht werden können, konnten wir nicht schlussfolgern, dass dies der erste Tag des Einbruchs war. Da die Beweise für den Einbruch von der CVS-Schwachstelle stammen und da keine andere Schwachstelle bekannt ist, die für einen Einbruch in 'helium' hätte ausgenutzt werden können, sind wir zuversichtlich, dass der oder die Eindringlinge die CVS-Schwachstelle missbraucht und dadurch Zugang zu 'helium' erhalten haben.

Unsere Überprüfung auf Veränderungen oder Zerstörungen bei den Diensten basierte auf der Annahme, dass der erste Einbruch nach dem 19. Mai stattgefunden haben würde, als die CVS-Schwachstelle CAN-2004-0396 öffentlich angekündigt wurde.

CVS

Da davon ausgegangen wird, dass die Eindringlinge anoncvs-Benutzerberechtigungen erhalten haben, waren wir bei CVS unter allen Diensten auf 'helium' am misstrauischsten und besorgtesten bezüglich möglicher Schäden.

Zum Zeitpunkt des Einbruchs gab es die folgenden vier CVS-Repositorys.

/src

Quellcode

/www

WWW-Daten

/doc

Dokumentation

/admin

Die Verwaltungsdatei für CVS

Davon benötigten /www und /doc keine Verifizierung, da ihre Inhalte bereits ungenutzt waren. Außerdem beschlossen wir, die Verwendung von /admin einzustellen und es einfach fallen zu lassen.

Was wir im Folgenden erklären, sind die Ergebnisse der Verifizierung des Quellcodes von Ruby und jedes anderen Moduls, das in /src enthalten ist.

Der Quellcode von Ruby

Wir teilten mögliche Änderungen am CVS-Repository in zwei Kategorien auf:

(1) Änderung historischer Daten in Dateien im CVS-Repository vor dem 19. Mai

(2) Änderungen, die die regulären Einreichungen nach dem 19. Mai verschleiert haben

Für (1) haben wir Dateien im CVS-Repository anhand des cvsup-Logs nach dem 19. Mai überprüft, das sicher außerhalb von 'helium' aufbewahrt wurde. Wir haben bestätigt, dass es keinerlei Anzeichen für Änderungen an Dateien im CVS-Repository gab. Für (2) haben wir alle Inhalte der Commits einzeln überprüft und die Abwesenheit jeglichen bösartigen Codes nach dem 19. Mai bestätigt. Dies bedeutet nicht nur, dass kein bösartiger Code vorhanden ist, sondern auch, dass wir jeden Commit mit dem Committer verifiziert haben.

Unsere Verifizierung wurde durch Daten unter der folgenden URL unterstützt.

• Log von cvsup
  https://ruby-lang.de/check-data/cvs/cvsup-log/
• Inhalte der Commits vom 19. Mai bis 28. Mai
  https://ruby-lang.de/check-data/cvs/cvs-diff/

Darüber hinaus haben wir zusätzlich zu den oben genannten Materialien folgende ergänzende Arbeiten durchgeführt:

• Wir haben bestätigt, dass es am 21. Mai keine Inkonsistenzen zwischen den Dateien im CVS-Repository auf 'helium' und den Dateien auf einem externen, sicheren Server gab.
• Wir haben bestätigt, dass es keine Inkonsistenzen innerhalb der CVS-Snapshots vom 02.11.2003 bis 27.05.2004 (tageweise) und der aus dem CVS-Repository auf 'helium' erstellten Snapshots gab.

Wir kamen zu dem Schluss, dass es keine Änderungen oder Zerstörungen des Quellcodes von Ruby im CVS-Repository gab.

Module außer dem Quellcode von Ruby

Zusätzlich zum Quellcode von Ruby enthält das /src-Verzeichnis des CVS-Repositorys die folgenden Module:

• app
• lib
• rough
• rubicon
• ruby-parser
• shim
• vms
• pocketruby
• oniguruma
• mod_ruby
• eruby

Zuerst stellten wir fest, dass nur die folgenden Dateien nach dem 19. Mai geändert wurden, indem wir die ctime der Dateien im Repository mit den Zeiten der per CVSup auf den externen Server kopierten Dateien verglichen.

• lib/csv/lib/csv.rb,v
• lib/csv/tests/csv_ut.rb,v
• lib/soap4r/lib/wsdl/xmlSchema/parser.rb,v
• lib/soap4r/lib/wsdl/xmlSchema/complexContent.rb,v
• lib/soap4r/lib/wsdl/parser.rb,v
• mod_ruby/lib/apache/eruby-run.rb,v
• mod_ruby/lib/apache/erb-run.rb,v
• mod_ruby/ChangeLog,v

Zweitens verglichen wir das kopierte CVS-Repository mit dem CVS-Repository auf 'helium' und stellten fest, dass es keine Inkonsistenzen zwischen ihnen gab, mit Ausnahme von Binärdateien in 'pocketruby'. Da wir 'wince' bereits in den Hauptzweig von Ruby integriert hatten, haben wir keine weitere Prüfung von pocketruby durchgeführt und die Bereitstellung seines Quellcodes eingestellt.

Jede der nach dem 19. Mai geänderten Dateien ist unten aufgeführt.

lib/csv/lib/csv.rb,v

lib/csv/tests/csv_ut.rb,v

lib/soap4r/lib/wsdl/xmlSchema/parser.rb,v

lib/soap4r/lib/wsdl/xmlSchema/complexContent.rb,v

lib/soap4r/lib/wsdl/parser.rb,v

Wir sind uns bei diesen Dateien unsicher. lib/csv und lib/soap4r sind bereits mit Ruby zusammengeführt und diese Module werden nur von den Maintainern jedes einzelnen verwendet. lib/csv und lib/soap4r wurden aus dem CVS-Repository entfernt und werden woanders entwickelt.

mod_ruby/lib/apache/eruby-run.rb,v

mod_ruby/lib/apache/erb-run.rb,v

Alle Revisionen einschließlich der Branches wurden überprüft und es wurden keine Probleme gefunden. Sie wurden jeweils mit den freigegebenen Quellpaketen verglichen, und es wurde bestätigt, dass es keine Inkonsistenzen gibt.

mod_ruby/ChangeLog,v

Gewöhnliche Änderungen an einer ChangeLog-Datei sind Ergänzungen des/der Inhalts. Die ChangeLog kann wie folgt überprüft werden:

(1) Wir haben bestätigt, dass es in der ersten Revision kein Problem gab.

(2) Wir haben bestätigt, dass es in der neuesten Revision kein Problem gab.

(3) Wir haben alle Revisionen überprüft, die Änderungen enthielten, nicht nur Ergänzungen.

Darüber hinaus wurde die ChangeLog mit den freigegebenen Quellpaketen verglichen, und es wurde bestätigt, dass es keine Inkonsistenzen gibt.

Zudem ist die Entwicklung von mod_ruby und eruby zu Subversion verlagert worden, daher wurden diese CVS-Modulnamen in mod_ruby-old und eruby-old geändert.

HTTP (www.ruby-lang.org)

https://ruby-lang.de/{ja, en}/ wird von tDiary generiert. Wir haben folgende Schritte unternommen, um zu überprüfen, ob beim Ausführen des tDiary CGI-Programms keine Probleme auftreten:

• Überprüfung der Abwesenheit von verdächtigem Code in den CGI-Programmen
• Überprüfung des Codes in <script>-Elementen, die in die Inhalte eingebettet sind
• Überprüfung der Abwesenheit von verdächtigen Daten in den Konfigurationsdateien

Darüber hinaus haben wir die Inhalte und verlinkten URLs überprüft, aber keine Probleme gefunden. Wenn Probleme gefunden werden, kontaktieren Sie bitte webmaster@ruby-lang.org.

Online-Referenzhandbuch

Das Online-Referenzhandbuch befand sich auf RWiki. Wir stellten zuerst den Inhalt am 29. Februar wieder her, wendeten dann die Patches an, die am 29. Februar an externe E-Mail-Konten gesendet wurden. Dann verglichen wir es mit den Inhalten auf 'helium'.

Der Diff kann bezogen werden von

https://ruby-lang.de/check-data/ruby-man/man-rd-ja.diff

Der Unterschied bei Base64.rd ergibt sich aus Zeilenumbrüchen, die beim Empfang der E-Mail eingefügt wurden. trap%3A%3ANilClass.rd.rej wurde abgelehnt, da derselbe Patch zweimal angewendet wurde. Das Diff-Skript verglich Dateien mit Dateien von 61 Minuten zuvor, daher derselbe Patch zweimal gesendet.

Wir haben bestätigt, dass keiner von ihnen vom Einbruch betroffen war.

RAA

Wir haben die folgende Datenverifizierung durchgeführt.

• Wir haben einen täglichen Diff der RAA-Daten erstellt, von 1) der sauberen RAA-Datensicherung vom 27. März, 2) täglichen Backups vom 4. April bis 28. Mai und 3) den neuesten RAA-Daten vom 28. Mai.

  2) und 3) befinden sich in einem chroot-geschützten Bereich auf der Maschine. 1) ist sauber, da es in einer Entwicklungsumgebung aufbewahrt wird.

  • RAA-Datenaktualisierung
    http://raa.ruby-lang.org/announce/soapbox-diff-all-passphrasemask.txt
  • RAA Neueintrag
    http://raa.ruby-lang.org/announce/soapbox-new-passphrasemask.txt

• Wir haben die Abwesenheit verdächtiger Daten in den oben genannten Diffs bestätigt.

Es kann geschlossen werden, dass die RAA-Daten vom 28. Mai (dieselbe Datensammlung, die wir für den RAA-Dienst-Neustart verwenden) keine verdächtigen Daten enthalten. Wir haben uns daher entschieden, den RAA-Dienst wie am 28. Mai wieder aufzunehmen. Wir können keine Zusicherungen geben, dass keine normal aussehenden Änderungen durch den Eindringling existieren. Zum Beispiel sind die Änderungen an sampleproject am 18. Mai wie folgt:

== sampleproject
- updated: Sun May 09 12:35:19 GMT+9:00 2004
+ updated: Mon May 17 13:00:38 GMT+9:00 2004
- version: 0.0.8
+ version: 0.1.1

Keine dieser Daten ist verdächtig, aber es ist möglich, dass die Änderungen vom Eindringling vorgenommen wurden. Daher bitten wir jeden RAA-Projektbesitzer, IHRE RAA-EINTRÄGE ZU ÜBERPRÜFEN UND ZUR BESTÄTIGUNG ZU AKTUALISIEREN. Gehen Sie dazu wie folgt vor:

(1) Öffnen Sie die Projektseite

(2) Überprüfen Sie die Projektinformationen

(3) Gehen Sie zur "Aktualisieren"-Seite

(4) Drücken Sie die Schaltfläche "Absenden" (tun Sie dies auch, wenn keine Aktualisierung erforderlich ist – dieser Schritt dient zur Bestätigung)

Bitte kontaktieren Sie raa-admin@ruby-lang.org, wenn Sie verdächtige Daten in RAA finden oder Fragen haben. Vielen Dank für Ihre Mitarbeit.

FTP

Wir verglichen die md5sum-Werte der Dateien auf FTP mit den Dateien auf dem externen, sicheren Server, und es gab keine Unterschiede.

Wir konnten jedoch die folgenden Verzeichnisse nicht überprüfen. Folglich werden sie derzeit nicht bereitgestellt.

/pub/ruby/contrib/
/pub/ruby/doc/
/pub/ruby/snapshots/
/pub/ruby/ML/
/pub/ruby/shim/

Wenn Sie Dateien in diesen Verzeichnissen benötigen, wenden Sie sich bitte an ftpadmin@ruby-lang.org.

Mailingliste

Wir haben die Konfigurationsdateien jeder Mailingliste untersucht und keine Probleme gefunden. Mitgliederlisten und Mailarchive wurden jedoch nicht gründlich überprüft.

Wenn Sie Probleme haben, wenden Sie sich bitte an <ML-Name>-admin@ruby-lang.org.

Shugo Maeda <shugo@ruby-lang.org>
Administratorengruppe von ruby-lang.org