Kommentar: Entwickler, seid wachsam!
Die jüngste Erpressungswelle auf Git-Repositorys zeigt, wie angreifbar öffentlicher Code ist. Entwickler müssen jetzt handeln, meint Rainald Menge-Sonnentag.
Jetzt ist schon wieder was passiert: Bitcoin-Erpresser haben versucht, mit einer Löschaktion schnelles Geld zu verdienen. Und wieder waren öffentliche Repositorys Ziel des Hackerangriffs. Nach zwei deutlich hörbaren Warnschüssen sollten jetzt Konsequenzen folgen.
Anfang Mai mussten zahlreiche Maintainer zusehen, wie ihre auf GitHub, GitLab oder BitBucket verwalteten Repositorys gelöscht wurden. Dazu bekamen sie eine Mitteilung, dass sie innerhalb von zehn Tagen ein Lösegeld in Höhe von 0,1 Bitcoin zahlen sollten, damit die Angreifer den angeblich auf eigenen Servern zwischengespeicherten Inhalt wiederherstellen. Die Erpresser gehen hoffentlich leer aus, denn zur Arbeitsweise mit Git gehört, dass Entwickler eine lokale Kopie des Repositorys besitzen. Lediglich in unglücklichen Ausnahmefällen dürfte somit tatsächlich Code verloren gegangen sein.
Richtig peinlich ist der jüngst bekannt gewordene Zwischenfall bei Samsung. Dort war eine komplette GitLab-Instanz ungeschützt erreichbar, da jemand den Zugriff auf "public" gesetzt hatte und der Passwortschutz fehlte. Echt jetzt, Samsung? Ein Sicherheitsforscher konnte dort nicht nur den Sourcecode zum SmartThings-Projekt einsehen, sondern fand zusätzliche Zugangsdaten mit umfangreichen Daten – inklusive weiterer Credentials.
Warnschuss fĂĽr alle Entwickler
Entwickler sollten die Erpressungswelle ebenso wie Samsungs peinliche Panne als Warnschuss verstehen. Denn der Angriff erfolgte offensichtlich weder über Brute Force noch über im Internet verfügbare gestohlene Zugangsdaten von anderen Sites wie seinerzeit bei dem Zugriff auf GitHub-Repositorys vor drei Jahren. Diesmal öffnete schlicht die Achtlosigkeit der Maintainer das Tor für die Erpresser.
Ein Betroffener berichtete auf StackExchange, dass die Zugangsdaten in .git/config lagen. Einige Websites halten das .git/-Verzeichnis im Produktivbetrieb und leider im ungünstigen Fall ungeschützt – hoffentlich lediglich aus Unwissenheit, dass dort etwas Schützenwertes liegt. Das Auslesen der öffentlich verfügbaren Daten ist kein Hack mehr, und ein Beitrag auf Internetwache.com erläutert nicht nur die Schwachstelle, sondern den Schutz davor. Offensichtlich wurden die Erpresser aber auch in Deployments anderer Repositorys fündig, die mit dem angegriffenen in Zusammenhang standen, wie GitLab berichtet hat.
Unabhängig von der Quelle der Daten lässt sich das Problem darauf herunterbrechen, dass in den untersuchten und berichteten Fällen die Zugangsdaten offensichtlich zusammen mit der URL des Repositorys im Klartext relativ leicht zu finden waren. Wie kann so etwas passieren? Natürlich trifft keinen die Schuld, da es immer "irgend jemand" im Team oder der Community war, der den Bock geschossen hat, aber bestimmt nicht man selbst.
Blick nach vorn, nicht zurĂĽck
Jammern über Vergangenes hilft keinem, aber alle Entwickler müssen den Warnschuss ernst nehmen und ab sofort darauf achten, dass keine Zugangsdaten oder sonstige private Informationen versehentlich auf dem Webserver oder im Repository landen. Offenbar ist es keine Seltenheit, dass sich sensible Daten in Repos befinden und beispielsweise als Gedankenstütze in Kommentaren oder vermeintlich nicht genutzten Dateien stehen. Diese sind freilich nicht im kompilierten Code zu finden, aber der Source und die Ressourcen können auch aus nicht für die Öffentlichkeit gedachten Repositorys in fremde Hände geraten, wie der Vorfall bei Samsung belegt.
Die Erpressungswelle war zum Glück schlicht plump. Die Angreifer hätten statt des Löschvorgangs auch Dateien manipulieren können, um andere Attacken vorzubereiten oder durchzuführen. Das mag für ein kleines, privates Repository zunächst wenig lukrativ erscheinen, aber vielleicht befanden sich unter den Zielen auch nützliche Tools, die andere Entwickler in ihre Projekte einbinden.
Ein ebenfalls glimpflich verlaufener Zwischenfall zeigte vor drei Jahren, wie ein vermeintlich kleines Tool großen Wirbel verursachen kann. Betroffen war damals der Paketmanager NPM, aus dem ein Programmierer seine Module aus Ärger zurückgezogen hatte. Zahlreiche Anwendungen nutzten eines der Pakete, das gerade einmal neun Codezeilen umfasste. Das Entfernen führte dazu, dass unter anderem Node.js und Babel beim Build scheiterten. Auch hier galt: Hätte jemand den Code nicht entfernt, sondern manipuliert, wäre der Schaden deutlich größer gewesen.
Bevor es jemand falsch versteht: Ich finde es großartig, dass guter Code öffentlich verfügbar ist. Auf den Hosting-Plattformen finden sich zahlreiche ausgezeichnete Open-Source-Projekte, darunter Libraries zum Einbinden in andere Software. Gerade die Maintainer dieser Tools tragen eine besondere Verantwortung dafür, ihren Code zu schützen – unabhängig von der Größe des Projekts und der Community.
Liebe Entwickler, bitte schaut kritisch euren wie auch immer im Web abgelegten Code an und stellt sicher, dass sich keine Informationen darin befinden, die nicht für die Öffentlichkeit gedacht sind! Auch nicht in Kommentarzeilen. Passwörter im Klartext müssen ebenso tabu sein wie mehrfach verwendete. Euer Code ist vielleicht wichtiger, als ihr selbst glaubt, also schützt ihn angemessen! (rme)
