© saicle/Shutterstock.com
Was gibt es zum Thema Sicherheit bei GitHub zu beachten?

Git und die Sicherheit


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 unterscheiden. 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 Proofs of Concept 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 ern...

Neugierig geworden?

Angebote für Teams

Für Firmen haben wir individuelle Teamlizenzen. Wir erstellen Ihnen gerne ein passendes Angebot.

Das Library-Modell:
IP-Zugang

Das Company-Modell:
Domain-Zugang