Nach dem Angriff auf den PHP-Git-Server rät ein Forscher Entwicklern, Verschlüsselung zu aktivieren

Cyber Security News

Laptop mit integrierter Entwicklungsumgebung, der eine in der Programmiersprache PHP geschriebene Datei zeigt. (PXHERE, CC0, via Wikimedia Commons)

Ein Forscher sagte am Mittwoch, dass zwei bösartige Commits, die Anfang dieser Woche auf dem offiziellen Git-Server der Web-Entwicklungssprache PHP hinzugefügt wurden, möglicherweise hätten verhindert werden können, wenn die Betreuer signierte Commits (Verschlüsselung) auf dem Server aktiviert hätten.

Für diejenigen, die nicht in der Programmiersprache geschult sind, ist ein Commit in der Git-Welt, wenn ein Quellcode-Repository aktualisiert wird. Bösartige Commits entstehen, wenn bösartiger Code in die Aktualisierung eingefügt wird. Wenn ein Programmierer einen Commit kryptografisch signiert, wird er als signierter Commit bezeichnet.

Asaf Karas, Mitbegründer und CTO von Vdoo, merkte an, dass es zwar kein Patentrezept gibt und Sicherheitsforscher nicht genau wissen, wie die Angreifer den PHP-Server kompromittiert haben, aber soweit er sagen konnte, waren die bösartigen Commits, die von den PHP-Server-Angreifern verwendet wurden, keine signierten Commits.

“Es ist möglich, einen signierten Commit zu fälschen, aber der Angreifer müsste entweder eine Sicherheitslücke oder einen privaten Schlüssel von einem der Maintainer haben”, sagte Karas. “Wir sagen nur jedem, der einen Git-Server verwaltet, die signierte Commit-Funktion auf dem Server zu aktivieren, es kann eine Menge von Sicherheitsproblemen verhindern.”

Nachrichten über den Angriff hob Augenbrauen unter Sicherheitsforschern, weil, wenn die bösartigen Commits nicht identifiziert worden waren, würden sie durch Testzyklen gegangen sein, bevor sie schließlich als Teil eines offiziellen Release markiert werden – und fast 80 Prozent der Websites verwenden PHP.

“Es würde einige Zeit dauern, aber wenn die Backdoor unentdeckt bliebe, könnte sie sich schließlich auf leicht zehntausende von Systemen ausbreiten”, sagte Craig Young, leitender Sicherheitsforscher bei Tripwire. “Die Anzahl der kompromittierten Systeme würde in erster Linie davon abhängen, wie schnell Endanwender ihre PHP-Umgebung aktualisieren könnten, im Vergleich dazu, wie schnell die Sicherheitsforschungsgemeinschaft die Backdoor identifiziert.”

Offensichtlich wurden die bösartigen Commits nach einer routinemäßigen Post-Commit-Überprüfung entdeckt. Young sagte, was die Entwickler darauf aufmerksam machte, war, dass die bösartigen Commits eine Beschreibung enthielten, die völlig unvereinbar mit der zugehörigen Codeänderung war. Der Angreifer hatte einen der beiden Commits als “Tippfehler-Korrektur” bezeichnet, während er in Wirklichkeit neuen Code einführte. In diesem Fall war der bösartige Code ziemlich offenkundig, aber Young sagte, es sei erwähnenswert, dass ein Angreifer mit einem ausgefeilteren Backdoor-Mechanismus, der über mehrere scheinbar harmlose Code-Commits aufgebaut ist, möglicherweise nicht entdeckt wird.

“Es war eine knappe Sache, da der bösartige Code sehr früh entdeckt wurde und nur in eine Entwicklungsversion eingeschleust wurde, die in der Produktion nicht weit verbreitet ist”, sagte Karas von Vdoo. “Außerdem waren die Angreifer nicht sehr raffiniert darin, wie sie den Code verändert haben. Die Änderungen waren auffällig und enthielten immer noch belastende Zeichenfolgen, wie zum Beispiel die Erwähnung der Schwachstellen-Broker-Firma Zerodium. Man könnte sogar die Hypothese aufstellen, dass es sich um einen Provokationsangriff handelte, der entdeckt werden sollte. Bei der nächsten Attacke könnten die Angreifer sehr viel vorsichtiger sein, wenn sie eine Code-Änderung vornehmen, die lange genug verborgen bleiben kann, um eine Release-Version zu erreichen, die schließlich in der Produktion auf vielen echten Systemen installiert wird.”

Chad Anderson, Senior Security Researcher bei Domain Tools, fügte hinzu, dass sich dieser Beinahe-Angriff nur deshalb nicht zu einem vollwertigen Angriff entwickelte, weil die Entwickler ihn in diesem Fall entdeckten.

“Es gibt allein in diesem Jahr ein halbes Dutzend Fälle, in denen Kompromittierungen der Lieferkette dazu geführt haben, dass Angreifer beliebigen Code auf fremden Rechnern ausgeführt haben – auch bei Apple und Microsoft”, so Anderson. “Deshalb müssen Entwickler die Tools nutzen, die GitHub, GitLab und andere Community-Sites anbieten, die ihre Builds verifizieren, Tests mit ihrem Code durchführen und bestätigen, dass ein Angreifer keine eigenen bösartigen Anweisungen in die Codebasis injiziert hat.”

Die PHP-Maintainer haben ihrerseits entschieden, dass der Betrieb einer eigenen Git-Infrastruktur zu einem unnötigen Sicherheitsrisiko geworden ist, weshalb sie den Server git.php.net einstellen werden. Stattdessen werden die Repositories auf GitHub, die bisher nur Mirrors waren, kanonisch werden, erklärte Nikitia Popov, ein Core PHP-Entwickler. Mit dieser Änderung, so Popov, sollten von nun an alle Code-Änderungen direkt auf GitHub gepusht werden und nicht mehr auf den git.php.net-Server.

DomainTools’ Anderson erklärte weiter, dass Git als das Versionskontrollsystem fungiert, das PHP verwendet, um Entwickler an der Software, die sie erstellen, zusammenarbeiten zu lassen. Wenn es richtig funktioniert, löst es Konflikte auf, wenn ein Entwickler Code über die Änderungen eines anderen hinzufügt, zeigt jeden behobenen Fehler als “diff” an, der über die Zeit wiedergegeben werden kann, und erlaubt es, dass jede Codezeile in der Historie zeigt, welcher Entwickler diese Zeile hinzugefügt hat. Im Gegensatz dazu ist GitHub die Webseite von Microsoft, die öffentliche und private Git Repositories für Entwickler hostet. GitHub verfügt über eine Reihe weiterer Tools wie Code-Sicherheitsüberprüfungen, Foren, Bug-Tracker und andere Community-Teile, die das gemeinsame Arbeiten an Software erleichtern.

“In diesem Fall hat PHP einen eigenen, selbst gehosteten Git-Server verwendet”, so Anderson. “Dieser Server wurde kompromittiert und Angreifer versuchten, den Code auf diesem Server durch eine Hintertür einzuschleusen. Durch den Wechsel zu GitHub verfügt PHP nun über alle Community-Tools, die auf dieser Seite zur Verfügung stehen, sowie über zusätzliche Sicherheitsprüfungen, Test-Pipelines und andere kostenlose Elemente, die mit GitHub einhergehen.

Einige Teile dieses Artikels stammen aus:
www.scmagazine.com