Rebasing ist eine Git-Aktion, mit der eine Folge von Commits aus einem Feature-Branch auf einen anderen Basis-Branch übertragen wird, um eine lineare Projekthistorie zu erzeugen. Anders als git merge schreibt git rebase die Historie dabei um und legt für jeden Commit des ursprünglichen Branches einen neuen Commit an. Der Befehl akzeptiert über den Parameter –exec einen Shell-Befehl, der nach jedem erneut eingespielten Commit ausgeführt wird – genau hier setzt der Angriff an.

„Jeder registrierte Nutzer, der ein Repository anlegt, wird automatisch dessen Eigentümer", erläutert Burgess. Das Aktivieren des Rebase-Mergens sei anschließend nur ein einzelner Schalter in den Einstellungen, und die gesamte Angriffskette lasse sich ohne Mitwirkung anderer Nutzer durchführen.

In einer anderen Konstellation kann ein Nutzer mit Schreibzugriff auf ein Repository, in dem Rebasing bereits aktiviert ist, die Lücke unmittelbar ausnutzen. Ist das Anlegen von Repositories auf einer Instanz eingeschränkt, benötigt ein Angreifer Schreibzugriff auf ein beliebiges Repository mit aktiviertem Rebase-Merge.

Gelingt der Angriff, kann ein Täter laut Rapid7 in den Server eindringen, auf jedes Repository der Instanz zugreifen, Zugangsdaten auslesen, sich zu weiteren erreichbaren Systemen im Netzwerk bewegen und den Code beliebiger gehosteter Repositories manipulieren. Möglich sei zudem ein mandantenübergreifender Datenabfluss, bei dem der Angreifer die privaten Repositories anderer Nutzer auf demselben Server lesen kann. Betroffen sind laut Rapid7 alle unterstützten Plattformen, darunter Windows, Linux und macOS.

Die Zahl der über das Internet erreichbaren Gogs-Instanzen wird auf rund 1.141 geschätzt; die tatsächliche Zahl dürfte höher liegen, da die meisten Installationen hinter VPNs oder in internen Netzwerken betrieben werden.

Rapid7 hat darüber hinaus ein Metasploit-Modul veröffentlicht, das die vollständige Angriffskette gegen Linux- und Windows-Ziele automatisiert. Es bietet zwei Modi: Im Standardmodus wird ein temporäres Repository unter dem Konto des Angreifers angelegt, der Exploit ausgeführt und das Repository anschließend wieder gelöscht. Der zweite Ansatz richtet sich gegen ein Repository, auf das der Angreifer bereits Schreib- und Merge-Rechte besitzt.

„Wenn der Angreifer sein eigenes Repository anlegt und wieder löscht, bleibt als einzige Spur ein HTTP-500-Fehler in den Server-Protokollen", so Burgess. Beim Ausnutzen eines bestehenden Repositorys blieben hingegen zusätzliche Artefakte zurück.

Da kein Patch verfügbar ist, verweist Rapid7 auf entsprechende Empfehlungen zur Risikominderung.