Artikel Open Source Im Visier

Artikel Open Source im Visier

André Gasser ISPIN AG Version 1.1

21. Februar 2011 Inhaltsverzeichnis

1 Summary 3

2 Einleitung 3

3 Blick in die Vergangenheit 4

4 Schutzmassnahmen 6 4.1 Für Plattform-Betreiber ...... 6 4.2 Für Software-Entwickler ...... 7 4.3 Für Endbenutzer ...... 8

5 Fazit 9

6 Quellennachweis 9

2 1 Summary

Angrie auf Open Source Projekte häufen sich in letzter Zeit. Aktuellstes Ereignis ist der Angri auf die SourceForge-Infrastruktur Ende Januar 2011. Es scheint, als hätten die Angreifer einen neuen und zugleich eektiven Weg gefunden, um Schadcode zu verbreiten. Gelingt es Angreifern erstmal, Zugri auf die kritischen Server der Hoster zu erhalten, so besteht für Angreifer die Möglichkeit, unbemerkt Schadco- de in dort gehostete Software-Projekte einzuschleusen. Betreiber, Software- Entwickler und Endbenutzer sollten sich der Gefahren bewusst werden und entsprechende Gegenmassnahmen vorsehen. Dieser Artikel zeigt anhand vergangener Ereignisse auf, welchen Risiken die Betreiber von Quellcode-Repositories, Software-Entwickler und Endbe- nutzer ausgesetzt sind und wie sie sich dagegen schützen können. Dieser Artikel erhebt keinen Anspruch auf Komplettheit. Feedback zu diesem Artikel nimmt der Autor gerne entgegen.

2 Einleitung

Der gezielte Angri vom 28. Januar 2011 auf die SourceForge-Server zeigen es deutlich: Angreifer haben ein neues und zugleich lukratives Ziel für Angrie gefunden: Hoster von Open Source Software. Der Angri auf die SourceForge-Infrastruktur wurde noch rechtzeitig erkannt. Gemäss SourceForge stellten die Administratoren ungewöhnliches Verhalten auf einigen der Server fest. Als Folge davon wurden einzelne Diens- te vom Netz genommen. Den Angreifern gelang es dabei, über ein Root Privilege Escalation Vul- nerability Schadcode auf einem SSH-Server von SourceForge zu platzieren, der Passwörter aufzeichnen sollte. Dank der schnellen Erkennung des An- gris und einer gut durchdachten Netzwerk-Segmentierung konnte die wei- tere Ausbreitung des Angris verhindert werden. Wäre der Angri unent- deckt geblieben, hätten die Angreifer über legitime Zugänge zur SourceForge- Infrastruktur verfügt und wären somit in der Lage gewesen, gezielt Schadco- de in dort gehostete Open Source Projekte einzuschleusen. Dieser wäre dann wohl verbreitet worden, bevor die betroenen Projektbetreiber das rechtzeitig bemerkt hätten. Obwohl gemäss SourceForge keine Projekte direkt mit Schadcode belastet wurden, war die Infrastruktur doch während rund zwei Wochen nicht voll einsatzbereit. Als präventive Massnahme wurde zudem eine globale Passwort- Reset-Kampagne initiiert, bei dem die Passwörter der SourceForge-Accounts zurückgesetzt wurden. In der Folge mussten alle Konteninhaber ihre Pass- wörter neu vergeben.

3 3 Blick in die Vergangenheit

Was im Fall SourceForge für Aufsehen sorgte, passierte nicht zum ersten Mal. Schon in der Vergangenheit versuchten Kriminelle, sich Zugang zu den Servern von diversen Linux-Distributionen zu verschaen, um so Schadcode in die Pakete der Distributionen einzuschleusen. Man wollte bereits da die Autoupdate-Mechanismen der Distributionen missbrauchen, um Schadcode zu verteilen. Ein sehr lohneswertes Ziel für einen solchen Angri sind dabei die Signing- Server, welche die Pakete jeweils mit dem Schlüssel des Projekts signieren. Bei der Installation der Pakete auf den Clients werden jeweils die Signatu- ren überprüft. Falls es dem Angreifer gelingt, die Schlüssel zu kopieren und dessen Passphrase zu erraten oder anderweitig in Kenntnis zu bringen, ist er in der Lage, Pakete beliebig zu manipulieren und anschliessend mit dem korrekten, privaten Schlüssel zu signieren. Er kann das Paket nun in ein Update-Repository einschleusen und es so in Umlauf bringen. Repositories sind häug gespiegelt und werden von den Autoupdate-Mechanismen der Client-PCs kontaktiert.

Dass solche Angrie keine reine Utopie sind, zeigen folgende Ereignisse:

• Januar 2011: Angrie auf Server von Fedora Am 22. Januar 2011 erhielt ein Fedora Projekt-Mitglied eine Email vom Fedora Account System, in welchem er informiert wurde, dass seine Kontendaten geändert wurden. In der Folge informierte er das Fedora Infrastructure Team, welche nach einer eingehenden Analyse die Kompromittierung des Accounts bestätigten. Der Angri war möglich, da das Mitglied ein schwaches Passwort verwendete.

• Dezember 2010: Angri auf Source Code Repository der Free Software Foundation Die Quellcode-Verwaltungs-Software der Free Software Foundation, GNU Savannah, wurde Opfer eines Angris. Dabei gelang es den Angreifern, mittels SQL Injection Methoden, die Datenbank mit den Usernamen und den MD5-gehashten Passwörtern zu stehlen und die Passwörter teilweise mittels Brute-Force-Methoden zu knacken. Dies war möglich, da die Hashwerte der Passwörter ohne Random Salt generiert wurden. Somit konnten die Angreifer mittels Dictionary-Attack (Wörterbuch- Angri) die Passwörter ermitteln. Der Plattform-Betreiber nahm in der Folge die Server, 48 Stunden nach dem erfolgten Angri, vom Netz.

• Dezember 2010: Angri auf die ProFTPD Server Angreifern gelang es, den Hauptserver des populären Open Source Pro- jekts zu hacken und ein Backdoor einzuschleusen, welche Vollzugri auf das System ermöglichte. Der Angri blieb während 3 Tagen unbemerkt

4 und führte dazu, dass zahlreiche Benutzer Opfer der kompromittierten Version von ProFTPD wurden. Die Angreifer erhielten den Zugang über eine ungepatchte Sicherheitslücke in der FTP-Applikation selbst.

• April 2010: Angri auf Apache Projekt Der Angri erfolgte über JIRA, dem Bug Tracking System der Apache Software Foundation. Die Angreifer eröneten dort einen Bug Report, der einen Link auf eine Webseite, welche eine Cross Site Scripting- Vulnerability ausnützte, beinhaltete. Die Angreifer modizierten in der Folge die Loginmaske zum Bug Tracking System und zeichneten wäh- rend 3 Tagen die Passwörter auf. Im weiteren Verlauf des Angris gelangten die Angreifer zusätzlich in den Besitz einer sehr umfangreichen Passwortdatenbank von Nutzern des Bug Tracking Systems. Obwohl die Passwörter in der Datenbank mittels Einweg-Hashes gesichert waren, waren Teile der Passwortdaten- bank anfällig auf einen Wörterbuch-Angri (Dictionary Attack). Der Grund dafür war, weil Atlasian, der Hersteller von JIRA, für die Ge- nerierung der Hashwerte kein Random Salt verwendete. Random Salt schützt die Passwörter bzw. die Hashwerte vor Wörterbuch-Angrien.

• September 2009: Apache Projekt gehackt Server der Apache Software Foundation wurden Opfer eines Angris. Obwohl die Server stark gesichert waren, gelang es den Angreifern, sich Zugang zu den Systemen zu verschaen. Der Hack begann mit der Kompromittierung von apachecon.com, der Webseite der ApacheCon Konferenz. Die Angreifer verschaten sich auf der Maschine root-Privilegien und zerstörten einen Grossteil der Logdaten. Obwohl diese Maschine nicht direkt von der Apache Soft- ware Foundation betrieben wurde, besassen einige Mitglieder der Apa- che Software Foundation Accounts auf dieser Maschine, unter anderem existierte auch ein Account für Backupzwecke. Von da aus versuchten die Angreifer erfolglos, mittels bekannten Account- Passwörtern einen der Server der Apache Software Foundation anzu- greifen. In einem zweiten Versuch, verwendeten die Angreifer erfolg- reich den SSH-Key des Backup-Accounts. Anschliessend panzten die Angreifer CGI-Skripte in die document root-Verzeichnisse, die ab diesem Zeitpunkt extern sichtbar waren.

• August 2008: Angrie auf Server von Fedora Im August 2008 gelang es Angreifern, kurzzeitig die Kontrolle über Server des Fedora-Projekts zu übernehmen. Einer der betroenen Ser- ver war ein sogenannter Signing Server, der Fedora-Paketen digital signiert. Der Angreifer war somit im Besitz des privaten Schlüssels zum

5 Signieren von Fedora-Paketen. Der Hersteller ersetzte sicherheitshalber den kompromittierten Signaturschlüssel durch einen neuen.

• August 2008: Angrie auf Server von Red Hat Ein anderes Beispiel ist der Einbruch in die Red Hat Server im Jahre 2008, bei welchem sich die Angreifer ebenfalls Zugang auf die Signing Server verschaten und anschliessend manipulierte OpenSSH-Pakete, mit dem oziellen Red Hat Enterprise Linux Schlüssel signiert, in Um- lauf bringen wollten. Glücklicherweise scheiterten sie daran, die Pakete über das RHN (Red Hat Network) automatisch verteilen zu können.

4 Schutzmassnahmen

4.1 Für Plattform-Betreiber Mögliche Massnahmen für Plattform-Betreiber:

• Sicherheitsoptimierte Netzwerkarchitektur Die Verteilung der Server auf verschiedene, separat geschützte Netz- werksegmente kann einen grossen Beitrag dazu leisten die Ausbreitung von Angrien in der Netzwerk-Infrastruktur zu verhindern.

• Paket-Signierung erzwingen Betreiber von Quellcode-Repositories können die digitale Signierung von Paketen im Release-Prozess erzwingen. Somit ist es für Entwickler (und Angreifer) nicht mehr ohne Weiteres möglich, gültige Pakete zu publizieren. Der private Schlüssel (Private Key) bleibt dabei vollstän- dig im Besitz des Entwicklers. Die Signatur des Pakets kann mit dem öentlichen Schlüssel (Public Key) veriziert werden.

• Zentralisierung der Logdaten Durch eine Zentralisierung der Logdaten können Angrie leichter nach- vollzogen werden, da die Daten nicht ohne Weiteres gelöscht werden können.

• Regelmässiger Austausch der Signatur-Schlüssel Ein regelmässiges Austauschen des Schlüsselpaares zum Signieren der Software-Pakete ist eine gute Massnahme, um das Risiko der Kompro- mittierung des privaten Schlüssels zu minimieren. Das Debian-Projekt beispielsweise wechselt die Signatur-Schlüssel alle 3 Jahre im Rahmen einer Routine-Massnahme.

• Einsatz von Host- und Network-IDS Der Einsatz von hostbasierten oder netzwerkbasierten Intrusion Detec- tion Systemen (IDS) schützt bestehende Systeme vor Angrien.

6 • Einsatz von Hashing mit Random Salt in den Passwort-Datenbanken Passwörter nur mittels zusätzlichem Random Salt speichern. Diese Massnahme schützt vor Wörterbuch-Angrien.

• Starke Passwörter erzwingen Erzwingen von Starken Passwörtern. Dies erfordert ein klar deniertes Passwort-Schema. Sinnvoll sind hier die Denition einer Mindestlänge, der Zwang zur Verwendung von Sonderzeichen und Ziern.

• Anbieten von Verfahren zur starken Authentizierung mittels OTP Der Einsatz von OTPs (One Time Passwords bzw. Einmalpasswör- tern). Beispiele hierfür sind Lösungen wie z.B. der Google Authentica- tor, Produkte von VeriSign oder SMS/mOTP von ISPIN AG ZURICH.

• Regelmässig Vulnerabilty-Scans Die regelmässige Durchführung von Vulnerability-Scans deckt potenti- elle Schwachstellen frühzeitig auf und erlaubt es dem Betreiber, rechtzeitig korrigierende Massnahmen einzuleiten.

• Schutzstufe gegen Injection- und XSS-Angrie Web Application Firewalls (WAFs) können als zusätzliche Schutzstufe eingesetzt werden, um einen Grossteil der Angrie aus dem Internet abzuwehren.

4.2 Für Software-Entwickler Software-Entwickler sind einerseits sicherlich vom Funktionsumfang des Plattform- Betreibers abhängig, haben aber dennoch grundsätzliche Möglichkeiten, zum Schutz vor Kompromittierung beizutragen. Die nachfolgende Liste ist nicht abschliessend, soll aber ein paar grundlegende Möglichkeiten aufzeigen:

• Plattform-Auswahl Bei der Wahl der Plattform für das Open Source Projekt sollte jeweils den Sicherheits-Features spezielle Beachtung geschenkt werden. Welche Features werden angeboten und wo?

• Umgang mit Passwörtern Die Zusammenstellung der Angrie im vorherigen Kapitel hat es ge- zeigt: Der Einsatz von schwachen Passwörtern oder der sorglose Um- gang mit Zugangsdaten kann zur Kompromittierung der Konten füh- ren. Software-Entwickler sollten deshalb für Zugänge mit erhöhten Pri- vilegien unbedingt starke Passwörter verwenden, die nur da eingesetzt werden (keine mehrfache Verwendung der selben Passwörter!). Die Passwörter müssen an einem sicheren Ort aufbewahrt werden.

7 • Einsatz von Random Salt für Passwörter Für eigene Software-Projekte ist unbedingt der Einsatz von Random Salt bei der Generierung von Passwort-Hashes zu empfehlen. Dies verhindert klassische Brute-Force-Angrie auf Passwörter, wie z.B. die Dictionary-Attack (Wörterbuch-Angri).

• Aufbewahrung von kryptograschen Schlüsseln zur Paket- Signierung Was für Passwörter gilt, gilt genauso für private Schlüssel zum Signie- ren von Paketen und anderen Software-Komponenten. Der Schlüssel darf auf keinen Fall in Fremde Hände geraten.

• Commits regelmässig überprüfen Software-Entwickler sollten die Commits von Quellcode ins eigene Package- Repository regelmässig überprüfen und im Zweifelsfall prüfende Schrit- te einleiten.

• Prüfsummen o ine aufbewahren Prüfsummen der Files in den unterschiedlichen Versionen selber o i- ne halten, also lokal auf dem eigenen Rechner abgespeichert. Damit kann der Entwickler im Falle einer Kompromittierung feststellen, ob und welche Files modiziert wurden.

• Eigene Projekte auf kritische Code-Snippets scannen Weiterhin bleibt die Möglickeit, kritische Code-Abschnitte regelmässig einem Code-Review zu unterziehen.

4.3 Für Endbenutzer Für den Endbenutzer ergeben sich u.A. folgende Möglichkeiten zum Schutz vor Malware:

• Datenintegrität prüfen Der Benutzer kann die Datenintegrität der Datei nach dem Download prüfen. Dazu benötigt er den Hashwert (typischerweise z.B. MD5 oder SHA-1), der ebenfalls zur runtergeladenen Datei jeweils separat be- reitgestellt wird. Der Benutzer rechnet dabei den Hashwert nach und vergleicht seinen Wert mit dem der runtergeladenen Datei. Stimmen die Werte überein, kann davon ausgegangen werden, dass man im Be- sitz der Orginaldatei ist. Zudem hat man auch gleich die Garantie, dass während der Übertragung (Download) keine Fehler aufgetreten sind. Sollten dennoch Zweifel an der Integrität der Datei bestehen, hat der Benutzer die Möglichkeit, den Projekt-Owner der Software zu kontak- tieren und so manuell nachzufragen.

8 • Einsatz von Personal Firewalls Personal Firewalls überwachen die lokalen Ports eines Computers und alarmieren den Benutzer über unberechtigte Netzwerk-Zugrie.

• Einsatz aktueller Virenschutz-Software Der Einsatz einer aktuellen Virenschutz-Software mit integrierter Malware- Erkennung kann helfen, installierte Schadsoftware zu erkennen.

• Einsatz von Diagnose-Utilities Mit Hilfe von Diagnose-Utilities kann der ein- und ausgehende Netzwerk- Verkehr überwacht und analysiert werden. Sofern sich Malware in einer Komponente bendet, ist dies früher oder später darin ersichtlich, z.B. dann, wenn Server im Internet kontaktiert werden, obwohl es eigentlich keinen Anlass dazu gibt (Calling Home).

• Gesundes Mass an Misstrauen Do not trust everyone - Glaube nicht Jedem. Ein gesundes Mass an Misstrauen schützt den Endbenutzer davor, leichtfertig Software- Komponenten aus nicht vertrauenswürdigen Quellen zu installieren.

5 Fazit

Das Ereignis von SourceForge hat die Community wachgerüttelt. Obwohl die Infrastruktur von Sourceforge über mehrere Tage nur teilweise einsatzbereit war, hat SourceForge richtig reagiert und konnte somit den Grossteil des Übels abwenden. Trotzdem ist Schaden entstanden. Um solche Angrie in Zukunft längerfristig abwehren zu können, bedarf es an einem seriös denierten Massnahmenkatalog, bestehend aus techni- schen und organisatorischen Massnahmen auf beiden Seiten, Entwickler und Betreiber.

6 Quellennachweis

Angri auf Sourceforge: http://sourceforge.net/blog/sourceforge-attack-full-report/

Angri auf die Fedora-Server / Red Hat Server: https://www.redhat.com/archives/fedora-announce-list/2008-August/ msg00012.html http://lists.fedoraproject.org/pipermail/announce/2011-January/002911. html

Angri auf die ProFTPD-Server: http://www.theregister.co.uk/2010/12/02/proftpd_backdoored/

9 Angri auf GNU Savannah: http://www.theregister.co.uk/2010/12/01/gnu_savannah_hacked/

Angrie auf Apache Projekt: https://blogs.apache.org/infra/entry/apache_org_downtime_report http://www.theregister.co.uk/2009/09/03/apache_website_breach_postmortem/ http://www.theregister.co.uk/2010/04/13/apache_website_breach_postmortem/

Google Zweifaktor-Authentisierung: http://www.google.com/support/accounts/bin/static.py?page=guide. cs&guide=1056283&topic=1056284

Produkte von VeriSign: https://idprotect.verisign.com/orderstart.v