Im Code-Repository von PHP war Schadcode eingebettet. Dieser Vorfall reiht sich in eine lange Serie von Angriffen auf Versorgungsketten ein. PHP zieht Konsequenzen aus dem Vorfall und will den Quellcode ab sofort nicht mehr selbst hosten.
Nachdem das PHP-Entwicklerteam in einem Post bekanntgegeben hat, dass mit hoher Wahrscheinlichkeit die selbst gehostete git-Installation kompromittiert wurde, soll nun die öffentliche Github-Plattform zukünftig das Zuhause des Quellcodes werden. Unbekannte hatten sich Zugriff auf den internen git-Server verschafft und dort Programmcode hinterlegt. Dieser erlaubte das Ausführen von beliebigem Code auf einem System, auf dem die kompromittierte php-Version installiert ist. Der anfällige Quellcode stand nur wenige Stunden online, bevor er wieder entfernt wurde.
Der fragliche Code wurde unter dem Vorwand eingeschleust, einen Tippfehler zu korrigieren. Es stellte sich jedoch schnell heraus, dass der eigentliche Inhalt wesentlich brisanter war als das. Zunächst stand die Befürchtung im Raum, dass der git-Zugang eines Entwicklers kompromittiert war. Das bewahrheitete sich jedoch nicht. Die PHP Group nutzte intern ein selbst entwickeltes („home grown“) System namens „karma“, um Schreibzugriffe auf das Code-Repository zu verwalten. Dieses scheint jedoch nicht in Mitleidenschaft gezogen zu sein.
Für die PHP Group hat der Vorfall ein Nachspiel. Man ist dort zu dem Schluss gekommen, dass es ein „unnötiges Sicherheitsrisiko“ sei, den Quellcode selbst zu hosten. Daher habe man sich entschlossen, künftig auf die Github-Plattform zu setzen und auch die Eigenentwicklung „karma“ aufs Altenteil zu schicken. Wer in Zukunft Quellcode einchecken will, muss erstens von der PHP Group akkreditiert sein und zweitens auch eine Zweifaktoranmeldung in seinem Github-Konto aktiviert haben.
Was ist PHP?
PHP ist eine Skriptsprache, die für die Entwicklung von Webseiten verwendet wird und die auch die Möglichkeit bietet, Funktionen auf einer Internetseite einzubinden. Fast 80 Prozent der Seiten im Internet nutzen auf der Serverseite PHP.
Die Gretchenfrage: Cloud oder nicht?
Die Tendenz, einzelne Dienste auszulagern statt sie selbst zu hosten, hat in letzter Zeit für reichlich Diskussionen gesorgt. Hier haben sich im Wesentlichen zwei Lager gebildet: Die einen bevorzugen es, die Hoheit über die eigenen Daten selbst zu behalten und stehen Cloud-Lösungen eher skeptisch gegenüber. Die anderen vertreten die Position, dass eine Auslagerung in die Cloud die Wirtschaftlichkeit erhöht, da der Verwaltungsaufwand für selbstgehostete Lösungen wegfällt.
Beide Gruppen verfügen über schlagkräftige Argumente, die nicht von der Hand zu weisen sind. Der Vorfall um die Exchange-Sicherheitslücken betraf ausschließlich Unternehmen, die einen eigenen Exchange-Server betreiben. Wer einen von Microsoft gehosteten Exchange nutzte, konnte sich recht entspannt zurücklehnen. Die Betreiber von on-premise-Installationen weltweit mussten praktisch sofort alles stehen und liegen lassen, um die Sicherheitslücken zu stopfen. Auch der Vorfall bei der PHP Group geht in diese Richtung: Da künftig die Github-Plattform genutzt wird, muss sich hier niemand um das Patching und die Wartung der lokalen git-Instanz kümmern. Treten auf Github Sicherheitsschwankungen auf, dann sind dort auch qualifizierte Experten zur Stelle, die sofort handeln können. Der Wunsch, Dienste in die Cloud zu migrieren, ergibt hier also durchaus Sinn.
Dem steht das Dogma „mein Netzwerk, meine Daten“ gegenüber. Der Brand in einem Rechenzentrum vor einigen Wochen ist Wasser auf die Mühlen der Vertreter dieser Schule. „Was, wenn der Clouddienst plötzlich aus irgendeinem Grund vom Netz geht?“ ist eine absolut berechtigte Frage in diesem Zusammenhang. Dazu kommt, dass es vielfach großes Misstrauen gibt, wer eventuell unbefugterweise Zugriff auf Daten eines Unternehmens bekommt, wenn man das Heft aus der Hand gibt. Diese Überlegung wiegt alle anderen Argumente für eine Migration in die Cloud auf.
Wo liegt der Königsweg?
Die Wahrheit liegt irgendwo dazwischen. Die Wirtschaftlichkeit spielt allerdings hier eine hervorgehobene Rolle. Für große Unternehmen ist es einfacher, Ressourcen für selbst gehostete Mailserver, Code Repositories und dergleichen aufzuwenden. Diesen Luxus können oder wollen sich kleine Unternehmen oft nicht leisten. Dabei scheitert es nicht unbedingt an technischen Hürden, sondern an personellen Hindernissen. Wenn es um das Thema Sicherheit geht, dann ist hier in der Regel Spezialwissen vonnöten. Genau das fehlt jedoch den meisten kleineren Unternehmen und es stehen oftmals auch nicht die Mittel zur Verfügung, dieses Know-how und diese Expertise in Form von Neueinstellungen einzukaufen. Erschwerend kommt die Tatsache hinzu, dass genau diese Spezialisten am Markt dünn gesät und daher hoch gefragt sind.
Spinnt man diesen Gedankengang weiter, dann kommt der eine oder andere vielleicht zu dem Schluss, dass Sicherheit für kleinere Unternehmen ein zwar nobles, aber doch unerreichbares Ziel darstellt. Gerade wenn man sich vor Augen führt, dass große Firmen eher die Mittel haben, eigene Spezialisten einzustellen oder auszubilden. Damit steht schnell das Bild im Raum „Entweder ich habe alles selbst im Griff und bin sicher – oder ich bin in der Cloud.“ Das wäre allerdings zu einfach gedacht, denn der Aufwand für die Unterhaltung einer lokale Installation kann schnell die Vorteile zunichte machen - vor allem, wenn im Bedarfsfall nicht schnell genug gepatcht wird. Genau das ist jedoch in vielen Fällen die Realität.
In Wirklichkeit kommt es aber gar nicht in erster Linie darauf an, ob und welcher Cloudlösung ein Unternehmen vertraut, sondern darauf, dass es Ausweichmöglichkeiten gibt. Wer alles auf ein Pferd setzt, tut sich langfristig keinen Gefallen. Fällt beispielsweise ein Clouddienstleister aus – sei es durch einen Brand in einem Rechenzentrum oder „klassisch“ durch den Bagger, der das Kabel vor der Tür erwischt hat – muss ein Unternehmen weiterhin handlungsfähig bleiben. Wenn ein einzelnes Ereignis genügt, um die gesamte Firma zum Stillstand zu bringen, dann stimmt etwas ganz Grundlegendes nicht.
Es ist und bleibt eine Einzelfallentscheidung, ob und welche Teile der eigenen IT ausgelagert werden. Fest steht jedoch, dass die Geschwindigkeit, in der im Falle einer Sicherheitslücke eine Reaktion erfolgt, ober Wohl und Wehe eines Unternehmens entscheidet. Auch die Versorgungsketten - hier in Form der PHP Group, die die quelloffene Webseitenkomponente verwaltet - ist und bleibt die Achillesferse der gesamten IT. Denn hier sind Unternehmen und Kunden darauf angewiesen, dem Anbieter zu vertrauen. Gerade wenn es um Software geht, die an zentraler Stelle zum Einsatz kommt, haben die Endverbraucher kaum eine Möglichkeit, selbst zu reagieren. Selbiges war bereits Ende des vergangenen Jahres in Form der Sunburst-Lücke der Fall, die Netzwerkverwaltungssoftware betraf. Diese wird unter anderem in Behörden eingesetzt.
Insofern kann man der PHP Group aus ihrer Entscheidung keinen Vorwurf machen.
Tim Berghoff
Security Evangelist