Dass GitHub bei der Lösung gegen RepoJacking-Angriffe mehrere Anläufe brauchte, erweckt nicht gerade Vertrauen. Eine Restgefahr bleibt.
Sicherheitsforscher von Checkmarx haben eine Schwachstelle in GitHub aufgedeckt, die es Angreifern ermöglichte, fremde Repositorys zu übernehmen und dadurch Schadcode in Projekte anderer Benutzer einzuschleusen. Die Forscher warnen davor, dass sich dadurch potenziell Tausende von Softwarepaketen kapern ließen, um Millionen von Anwendern mit schadhaftem Code zu versorgen. Nachdem die Sicherheitsexperten über die Lücke berichtet hatten, schloss die zu Microsoft gehörende Quellcodeverwaltungsplattform die Schwachstelle. Doch die Lösung scheint komplizierter zu sein. Eine gewisse Gefahr bleibt.
RepoJacking zielt auf umbenannte GitHub-Konten
Im Kern basiert der Angriff auf der Tatsache, dass die URLs zu sämtlichen Repositorys an den Benutzernamen des Erstellers gekoppelt sind. Nach einer Umbenennung des Benutzerkontos richtet GitHub schließlich eine automatische Weiterleitung der an den alten Namen gekoppelten URLs auf die jeweilige Variante mit dem neuen Kontonamen ein. Diese Maßnahme sorgt dafür, dass Softwareprojekte, die auf das Repository angewiesen sind, weiterhin auf eine korrekte URL verweisen. Denn viele Entwickler, die das Projekt des umbenannten Kontos nutzen, werden von der Namensänderung gar nichts mitbekommen.
Bei der RepoJacking genannten Angriffstechnik kapern Hacker den Datenverkehr betroffener Repositorys und leiten ihn auf ein eigenes Projekt um. Dafür registrieren sie einfach einen neuen GitHub-Account mit dem vorherigen Namen des Benutzers, der sein Konto umbenannte. Denn dieser ist daraufhin wieder für die Registrierung freigegeben. Infolgedessen wird die Standardumleitung deaktiviert und der gesamte bestehende Datenverkehr greift auf das neue Repository des Angreifers zu.
Die Lösung scheint kompliziert zu sein
Um dies zu verhindern, führte GitHub eine neue Sicherheitsbarriere ein. Jedes Repository, das zum Zeitpunkt der Umbenennung seines Besitzerkontos mehr als 100 Klone aufweist, gilt demzufolge als „im Ruhestand„. Daraufhin kann kein anderer Benutzer unter dem vorherigen Accountnamen den Namen des Repositorys für ein eigenes Projekt verwenden. Einen Versuch, dies dennoch zu tun, quittiert die Plattform mit einer entsprechenden Fehlermeldung.
Doch die Sicherheitsforscher von Checkmarx fanden im Nachhinein noch mehr als einen Weg, den von GitHub implementierten Schutz zu umgehen. Zwar schloss das Unternehmen die Lücken immer wieder, nachdem die Forscher sie gemeldet hatten. Doch dies zeigt, wie fehleranfällig die von GitHub gewählte Lösung ist.
Außerdem warnen die Forscher davor, dass auch GitHub-Actions von derartigen Problemen betroffen sein könnten, da diese „ebenfalls durch Angabe eines GitHub-Namensraums konsumiert werden.“ Ein Angriff auf eine beliebte GitHub-Action könnte demzufolge „zu großen Supply-Chain-Angriffen mit erheblichen Auswirkungen führen.„
„Wie bereits erwähnt, ist diese Schwachstelle inzwischen behoben und kann nicht mehr ausgenutzt werden, was aber nicht bedeutet, dass nicht ein anderer Weg gefunden wird, denselben Schutz zu umgehen.“
Checkmarx Sicherheitsforscher
Benutzer wissen oftmals nicht, ob ihre Projekte gefährdet sind
Somit bleiben umbenannte GitHub-Konten ein attraktiver Angriffspunkt für Hacker, um in die Lieferkette zahlreicher Softwarepakete einzugreifen und erhebliche Schäden zu verursachen. Die Forscher warnen davor, dass der „bereitgestellte Schutz auf der Grundlage interner Metriken aktiviert wird und den Nutzern keinen Hinweis darauf gibt, ob ein bestimmter Namespace durch ihn geschützt ist oder nicht.„
Somit wissen viele Anwender gar nicht, ob ihre eigenen Repositorys und Pakete gefährdet sind. Um betroffene Softwarepakete zu identifizieren, haben die Forscher ein Open-Source-Tool bereitgestellt. Dieses schlägt außerdem einen sichereren Weg vor, die potenziell angreifbaren Projekte zu nutzen.
