Was gibt es zum Thema Sicherheit bei GitHub zu beachten?

Git und die Sicherheit
Kommentare

Ein Angriff auf eine Git-Installation gefährdet alle darauf verwalteten Programme, und ein Angriff auf GitHub gleich eine extrem große Anzahl davon. Wie sieht es also mit der Sicherheit von Git aus?

Eigentlich muss man zwischen Git als Versionsverwaltung und GitHub als einen Anbieter einer entsprechenden Servicelösung trennen. Da Git aber vielfach mit GitHub gleichgesetzt wird, gehe ich im Folgenden besonders auf GitHub ein. Wenn man an GitHub denkt, fallen einem sofort zwei Vorfälle ein: Der Angriff vom März 2012 und die mit der neuen Suchfunktion gefundenen sensitiven Informationen, wie zum Beispiel SSH-Schlüssel im Januar 2013. Zwei „prominente“ Angriffe bzw. Schwachstellen seit dem Start im Februar 2008 in einem inzwischen doch recht intensiv genutzten Angebot klingen schon mal nicht schlecht. Aber sehen wir uns diese beiden Vorfälle erst mal genauer an.

Ein Angriff, der keiner war

Fangen wir mit GitHubs Sicht der Dinge an: Am 4. März 2012 meldete Tom Preston-Werner im GitHub-Blog, dass ein Benutzer eine Schwachstelle im Public-Key-Updateformular ausgenutzt hat, um seinen öffentlichen Schlüssel zu Ruby on Rails hinzuzufügen [1]. Als Beweis für das Vorhandensein der Schwachstelle legte er eine neue Datei an und machte auf die Schwachstelle aufmerksam. Schon das klingt nicht nach einem Angriff, sondern einem sog. Proof of Concept – dem Beweis, dass eine Schwachstelle existiert. Bei weiteren Untersuchungen wurden außer dem Ruby-on-Rails-Konto zwei weitere kompromittierte Konten entdeckt, die aber laut GitHub anscheinend ebenfalls Proof of Concepts waren. Ursache für die Schwachstelle war eine sog. Mass-Assignment-Schwachstelle [2], und der GitHub-Code wurde auf das weitere Vorhandensein solcher Schwachstellen überprüft. Als Ergänzung zur Meldung des Angriffs folgte ein Blogbeitrag zur Responsible Disclosure Policy von GitHub [3].

Kein Angriff, sondern ein nötiger Proof of Concept

Kommen wir nun zur Sicht des „Angreifers“, des russischen Entwicklers Egor Homakov. Seine Methode zur Meldung der Schwachstelle war zwar etwas unorthodox, aber zumindest aus seiner Sicht nötig. Er sah sich zum damaligen Zeitpunkt als Programmierer, nicht als Sicherheitsforscher [4], und tat sein Bestes, um auf die Schwachstelle(n) aufmerksam zu machen. Anfangs leider mit mäßigem Erfolg, was dann zum „Angriff“ auf GitHub führte.

Drei Tage vor dem Angriff hatte er die Mass-Assignment-Schwachstelle an die Ruby-on-Rails-Entwickler gemeldet [5], die diese Meldung aber nicht ernst genommen haben. Denn sie sehen MassAssignment nicht als Schwachstelle, sondern als Feature, dem im Securityguide ein eigener Abschnitt gewidmet ist [6]. Die offizielle Lösung des Problems: eine Blacklist. Eine aus Sicherheitssicht falsche Lösung, da Blacklists generell unsicher sind. Es gibt aber auch einen sichereren Whitelist-Ansatz, sodass man den Blacklist-Ansatz eigentlich als unsicher abschaffen sollte. Immerhin wurde inzwischen die Whitelist-Lösung als Default vorgesehen, was aber nur neue Anwendungen schützt [7]. Im Grunde müsste man aus Sicherheitsgründen auch das Mass Assignment abschaffen, aber da dann ein Großteil der vorhandenen Ruby-on-Rails-Anwendungen nicht mehr funktioniert, wird es zu dieser sicheren Lösung sehr wahrscheinlich nie kommen.

Aber hier geht es ja nicht um Ruby on Rails, sondern um GitHub, also zurück zu Egor Homakovs „Angriff“: Egor Homakov suchte nach weiteren Mass-Assignment-Schwachstellen und fand eine im Public-Key-Updateformular von GitHub. Und die hat er dann nicht mehr normal gemeldet, sondern für einen Proof-of-Concept als Beweis der Gefährlichkeit der Schwachstelle genutzt: Er fügte über diese Schwachstelle seinen SSH-Schlüssel zu den Schlüsseln der Ruby on Rails Committer hinzu. Als Beweis für das Vorhandensein der Schwachstelle erzeugte er dann ein neues Issue mit einem 1.001 Jahre in der Zukunft liegenden Datum für ein eigenes Projekt [9] und für Ruby on Rails [10] und fügte eine neue Datei zu Ruby on Rails hinzu [11]. Er hat auch GitHub direkt auf die Schwachstelle aufmerksam gemacht, aber keine Antwort erhalten [12].

Das Ergebnis

GitHubs Reaktion auf den Proof of Concept (außer die Schwachstelle zu beheben): Die temporäre Sperrung von Egor Homakovs Account und eine Klarstellung zur Responsible Disclosure in der eigenen Security Policy [13] – die ungefähr genauso wichtig ist, wie ein Sack Reis, der in China rum steht oder liegt. Denn ob und wie eine Schwachstelle gemeldet und/oder veröffentlicht wird, entscheidet einzig und allein ihr Entdecker. Er kann sich an die Regeln der betroffenen Entwickler halten, aber auch eigene Wege wählen. Da GitHubs Weg der üblichen Responsible Disclosure entspricht, werden sich wohl nur die Entdecker von Schwachstellen daran halten, die die betroffenen Entwickler sowieso vertraulich über entdeckte Schwachstellen informieren würden. Im Fall von Egor Homakov wäre sie aber evtl. nützlich gewesen, wenn es sie schon gegeben hätte. Da er sich mit dem Melden von Schwachstellen nicht auskennt, hätten GitHubs Regeln ihn auf den „richtigen“ Weg führen können. Ob der nach der Ignoranz der Ruby-on-Rails-Entwickler zum Ziel geführt hätte, wage ich zu bezweifeln.

Zwischenfazit

Wichtig sind hier eigentlich nur zwei Punkte:

  1. Der GitHub-Code enthielt eine Schwachstelle, die beim Befolgen der Sicherheitsregeln für Ruby on Rails nicht hätte entstehen können bzw. dürfen. Das wirft natürlich die Frage auf, wie viele weitere Schwachstellen es noch gibt.
  2. GitHub hat schnell auf die Schwachstelle reagiert – nachdem ihr Vorhandensein bekannt wurde. Was passiert wäre, wenn die Schwachstelle nicht von Egor Homakov veröffentlicht, sondern von einem Cyberkriminellen ausgenutzt worden wäre, möchte ich mir lieber nicht vorstellen. Denn der hätte dann unbemerkt jedes Projekt auf GitHub ausspähen können. Die natürlich ebenfalls möglichen Manipulationen wären früher oder später aufgefallen, aber die hätte der Angreifer sicher besonders unauffällig durchgeführt, sodass sein Angriff möglichst spät auffällt.

Was mir persönlich nicht gefällt, ist der Titel des Blogartikels, mit dem GitHub den „Angriff“ gemeldet hat: „Public Key Security Vulnerability and Mitigation“ [1]. Es handelt sich um eine Schwachstelle im GitHub-Code, die entstanden ist, weil man eine Sicherheitsregel von Ruby on Rails nicht beachtet hat. Mit Public-Key-Kryptographie hatte das Ganze rein gar nichts zu tun, wenn man davon absieht, dass über die Schwachstelle in GitHub ein öffentlicher Schlüssel zum Ruby-on-Rails-Projekt hinzugefügt wurde. Und das sollten die GitHub-Entwickler auch sehr genau wissen. Warum also dieser Ablenkungsversuch?

Brisante Suchergebnisse

Kommen wir zur zweiten prominenten „Schwachstelle“. Am 23. Januar 2013 wurde auf GitHub eine neue Suchfunktion aktiviert, die insbesondere die Suche in den Code-Repositories erleichterte [14]. Und diese Suchfunktion funktionierte gut – sogar sehr gut. Denn damit ließen sich auch Daten finden, die eigentlich nicht hätten veröffentlicht werden sollen, wie zum Beispiel private SSH- und SSL-Schlüssel [15], Konfigurationsdateien [16], Google API Keys [17] oder auch das SSH-Passwort für ein Produktivsystem [18].

Am 25. Januar warnte Brian Doll im GitHub-Blog vor den versehentlich veröffentlichten sensitiven Daten [19], und die GitHub-Hilfeseiten wurden um eine Anleitung zum Entfernen sensitiver Informationen erweitert [20].

Die neue Suchfunktion war kurz nach Bekanntwerden der potenziell gefährlichen Suchergebnisse ausgeschaltet worden, was laut Brian Doll aber technische Gründe hatte und nicht im Zusammenhang mit den sensitiven Informationen in den Suchergebnissen stand.

Schwachstelle vor der Tastatur

Diese „Schwachstelle“ ist keine, jedenfalls nicht im GitHub. Stattdessen sitzt sie in Form unvorsichtiger Committer vor der Tastatur so manches Rechners, denn irgendjemand hat die sensitiven Dateien ja hochgeladen. Ich persönlich vermute, dass das oft unbemerkt passiert ist, denn es wurden auch Shell Histories, wie zum Beispiel .bash_history–Dateien, gefunden. Diese Dateien sind normalerweise unsichtbar und wohl kaum absichtlich hochgeladen worden. Beim Kopieren eines kompletten Verzeichnisses werden jedoch auch diese „unsichtbaren“ Dateien erfasst.

Das Gleiche gilt sinngemäß für die privaten SSH- und SSL-Schlüssel: Die wurden vermutlich von den Entwicklern der Einfachheit halber gemeinsam mit ihren öffentlichen Gegenstücken zusammen mit den entsprechenden Quelltexten und Programmdateien gespeichert, und beim Hochladen wurde vergessen, dass diese Dateien vertraulich sind und nicht auf GitHub gespeichert werden dürfen.

Weitere Beispiele für Schwachstellen

Es gab natürlich noch weitere Schwachstellen in GitHub. So wurde zum Beispiel von Dan Palmer eine Schwachstelle beim Verwalten von API Access Token entdeckt [21], und Egor Homakov hat beschrieben, wie sich über Cookie Tossing [22] das CSRF-Token manipulieren und danach der Status von Repositories ändern lässt [23]. Letzteres war ein Grund dafür, die GitHub Pages auf eine eigene Domain (github.io) auszulagern [24]. Ein weiterer war die Gefahr von Phishing-Angriffen. Es ist generell eine schlechte Idee, fremde Webseiten unter der eigenen Domain zu hosten, wenn die auch für sensitive Aufgaben verwendet wird.

Aktuell wird auf der Mailingliste Full Disclosure eine mögliche Schwachstelle in Zusammenhang mit den Session Cookies diskutiert [25]. Gesicherte Session Cookies können evtl. nach dem Ausloggen zum erneuten Zugriff als angemeldeter Benutzer genutzt werden. Eine Reaktion von GitHub steht noch aus. Da die Session Cookies mit gesetzten Secure und HttpOnly Flag über HTTPS gesetzt werden, wären die Folgen dieser Schwachstelle aber gering, da es für einen Angreifer kaum Möglichkeiten gibt, Session Cookies auszuspähen.

Viele Entdecker, viele Schwachstellen?

GitHubs Seite mit den Regeln für die Responsible Disclosure enthält eine Liste der Personen, die eine zuvor unbekannte Schwachstelle, die von GitHub als „high“ oder „critical“ eingestuft wurde, vertraulich gemeldet haben [13]. Leider wird dabei nicht verraten, um was für eine Schwachstelle es sich handelt, und ob evtl. Schwachstellen von mehr als einer Person gemeldet wurden. Die Liste ist recht lang – sie umfasst aktuell sechzig Einträge. Und im schlimmsten Fall sechzig als „high“ oder „critical“ eingestufte Schwachstellen in fünf Jahren: schon ganz beachtlich. Nur mal zum Vergleich: Der Sicherheitsdienstleister Secunia führt in seiner Datenbank für Git 1.x ganze acht Advisories für die Jahre 2006 bis 2013 auf [26].

GitHubs Sicherheitsmaßnahmen

Generell legt GitHub großen Wert auf die Sicherheit, sowohl beim Betrieb des Systems als auch bei der Kommunikation damit [27]. So wird die Kommunikation über SSL geschützt, und auch OAuth wird unterstützt [28]. Für Open-Source-Projekte ist das sicher ausreichend, für Closed-Source-Projekte wären zusätzliche Schutzmaßnahmen wünschenswert. Zum Beispiel kann man zwar festlegen, welche Benutzer auf ein Repository zugreifen dürfen, den Zugriff aber nicht auf bestimmte IP-Adressen oder -Adressbereiche beschränken. Es gibt auch kein Access-Log, lediglich einen Audit Trail für Änderungen. Man kann also nicht feststellen, wer lesend auf das Repository zugegriffen hat, oder ob es fehlgeschlagene Anmeldeversuche gab. Außerdem kann man beispielsweise keine eigenen Passwortregeln durchsetzen oder festlegen, welche E-Mail-Adressen die Benutzer für die Registrierung verwenden.

Git(Hub) sicher nutzen

Die Sicherheit des Servers ist nur die eine Seite der Medaille, wenn es um die Sicherheit geht. Auch die Benutzer müssen ihren Teil zur Sicherheit beitragen. Wenn sie so unvorsichtig sind und vertrauliche Daten auf GitHub bzw. in Git speichern, können sie dort natürlich heruntergeladen werden, wie das Beispiel der über die neue Suchfunktion gefundenen privaten Schlüssel etc. eindrucksvoll gezeigt hat. Und wenn ein Benutzer einen mit Spyware infizierten Rechner benutzt, kann diese Spyware natürlich die Zugangsdaten oder privaten Schlüssel für den Zugriff auf GitHub ausspähen.

Fazit

Kann man aus Sicherheitssicht GitHub nutzen? Bei einem Open-Source-Projekt spricht nichts gegen, aber viel für GitHub. Bei einem Closed-Source-Projekt läuft im Grunde alles auf die Frage hinaus, ob man GitHub vertraut oder nicht.

Grundsätzlich sind die Daten auf einem eigenen Server, der am besten getrennt vom Internet im eigenen lokalen Netz steht, besser aufgehoben als auf den Servern jedes externen Anbieters. Muss bzw. soll die Git-Installation aus dem Internet erreichbar sein, muss man abwägen: Einerseits sind GitHubs Sicherheitsmaßnahmen sehr gut – besser als man sie zum Beispiel mit einem dedizierten Server bei einem normalen Hoster erreichen kann. Andererseits hat man den in Deutschland gehosteten und vom eigenen Admin verwalteten Server zumindest theoretisch besser unter Kontrolle.

Wem vertraut man also mehr? Wenn bei GitHub Daten kopiert oder manipuliert werden und das bekannt wird, ist GitHub schnell aus dem Geschäft. Man hat dort also ein großes Interesse daran, dass den gehosteten Projekten nichts passiert, und auch reichlich Erfahrung mit dem sicheren Betrieb der Git-Server und der GitHub-Infrastruktur. Kann der eigene Admin, der ja im Allgemeinen noch andere Aufgaben hat, da mithalten? Meist dürfte GitHub die sicherere Wahl sein.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -