Git-Repositories als Ziel von digitalen Angreifern

Von Richard Werner, Business Consultant

Ganz so einfach sollte man es sich nicht machen. Der Vorfall zeigt, dass es Cyberkriminellen gelingen kann, auf diese Plattformen zuzugreifen und Codebestandteile bzw. die Arbeit der Entwickler zu beschädigen. Ein Erpressungsversuch dürfte hier kein echtes Businessmodell darstellen, also werden künftige Vorfälle dieser Art vermutlich nicht auf diese Weise erfolgen. Ein Zugriff mag etwa dafür verwendet werden, nur den Code an sich zu beschädigen. Möglich sind beispielsweise Änderungen der Bausteine. Gängige Geschäftsmodelle von Kriminellen beinhalten dabei das Einbauen von Malware – hier sind Kryptominer sehr beliebt – sowie das Hinterlassen von Hintertüren (Backdoors) zur späteren Verwendung. In einem Honeypot-Versuch auf Docker Hub hatten Trend Micro- Forscher kürzlich nachgewiesen, dass Kriminelle sehr aktiv im Bereich DevOps sind und versuchen, den Code für Ihre Zwecke zu missbrauchen.

In den letzten Tagen wurde bekannt, dass Cyberkriminelle mehrere Git Repositories angegriffen hatten. Laut derzeitigem Ermittlungsstand konnten sich die Gangster durch schwach gesicherte bzw. einsehbare Passwörter Zugang zu einigen Accounts verschaffen, welche sie dann für das Löschen von Daten und versuchte Erpressung der betroffenen Entwickler verwendeten. Der tatsächliche Schaden dieser Aktion dürfte vermutlich eher gering ausfallen, da, wie beispielsweise Git Lab in seinem Blog feststellt, die meisten Entwickler lokale Kopien ihrer Daten haben und so die gelöschten Bestandteile schnell ersetzen können. Gilt es also, den Passwortschutz zu verbessern, Daten wieder hochzuladen und Schwamm drüber?

Das direkte Einbauen von Malware lässt sich dabei relativ einfach entdecken, während das Hinterlassen von Sicherheitslöchern (über Backdoors) oft nur schwer zu erkennen ist. So können beispielsweise bestehende Sicherheitslücken in Codebausteinen verschleiert oder Programmbibliotheken durch unsichere ersetzt werden. Diese Arten von „Beeinträchtigungen“ werden, wenn überhaupt, oft erst durch eine zusätzliche externe Überprüfung am Ende des Entwicklungsprozesses entdeckt und dann in einer Risikobewertung geschätzt. Ein durch Passwortdiebstahl ermöglichter Zugriff auf den Code sollte daher immer gleichzusetzen sein mit einer „Vergiftung“. Das System sollte auf den Zustand vor der Beschädigung zurückgesetzt werden — das heißt, wenn man diesen Zugriff erkennt.

Um grundsätzlich gegen solche Art des Eingreifens vorzugehen, bietet es sich an, sowohl den Code als auch die später fertig entwickelte App über automatisierte Runtime- und Image-Scanning-Prozesse zu prüfen, um festzustellen, ob sie manipuliert wurden oder Schwachstellen enthalten. Applikationskontrolle und Integritätsmonitoring tragen ebenfalls dazu bei, verdächtige Veränderungen auf Servern, in Dateien oder Systemen zu erkennen.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.