Shift-Left-Ansatz in der Cyberkriminalität Die DevOps-Pipeline als beliebtes Angriffsziel

Wenn Cyberkriminelle Software bereits während der Entwicklung kompromittieren, können sie weitreichenden Schaden anrichten. Künftig werden wir verstärkt solche Angriffe sehen. Wo liegen die größten Risiken und wie gelingt es, die DevOps-Pipeline richtig abzusichern?

In der modernen Software-Entwicklung gehört der Shift-Left-Ansatz heute zum Standard: Indem man das Testing im Prozessablauf vorzieht, findet man Fehler bereits in einem frühen Stadium und kann sie leichter beheben. Auch Cyberkriminelle haben das Shift-Left-Prinzip für sich entdeckt – allerdings ganz anders als im Sinne des Erfinders. Immer häufiger versuchen sie, bereits die DevOps-Pipeline anzugreifen. Wenn es ihnen gelingt, Software schon während des Entwicklungsprozesses zu kompromittieren, ist das wie ein Super-Coup. Alle Systeme, auf denen die Anwendung dann später läuft, werden automatisch infiziert. Das betrifft im schlimmsten Fall nicht nur die IT im eigenen Haus, sondern auch unzählige Partner und Kunden. So erzielen Cyberkriminelle mit nur einem Hack eine enorme Reichweite und haben dabei gute Chancen, lange Zeit unbemerkt zu bleiben. Beispiele wie SolarWinds oder Kaseya haben gezeigt, wie weitreichend die Auswirkungen sein können.

Risiken im Entwicklungs- und Bereitstellungsprozess

Beliebte Angriffsvektoren in der CI-Pipeline sind Programmbibliotheken und Frameworks. Wir haben zum Beispiel schon mehrfach gesehen, dass Libraries aus dem Ruby- oder JavaScript-Ökosystem kompromittiert wurden. Sie wirken sich dann auf alle Software-Komponenten aus, die von ihnen abhängig sind. Außerdem können auch Entwicklungsumgebungen als Einfallstor für Cyberkriminelle dienen. Moderne IDEs bestehen meist nicht aus einem Guss, sondern enthalten unzählige Plugins. Eines davon zu kompromittieren reicht aus – und schon steht die Tür offen. Häufig konzentrieren sich Angreifer zudem auf Build-Umgebungen. Hier können sie leicht bösartige Komponenten hinzufügen, selbst wenn alle vorgelagerten Prozesse und alle Bausteine der Software sicher sind. Dafür müssen die Hacker lediglich den Docker Container, PC oder Server kompromittieren, auf dem die Applikation zusammengebaut wird. Ganz abgesehen davon finden Cyberkriminelle in solchen Umgebungen mit etwas Glück noch ganz andere Schätze. Immer wieder kommt es zum Beispiel vor, dass Entwickler hier private Zugangsdaten oder gar Domain-Passwörter integrieren. Für Hacker ist das ein Freifahrschein, um sich lateral im Netzwerk auszubreiten. Da Build-Umgebungen gerne als eine Art „Wegwerf“-Umgebungen betrachtet werden, passieren solche Unachtsamkeiten öfter als gedacht.

Auch in der nachgelagerten CD-Pipeline lauern noch Risiken. Cyberkriminelle suchen zum Beispiel nach Konfigurationsskripten, die sie kapern können, etwa für die Container-Orchestrierungsplattform Kubernetes oder die Infrastructure-as-a-Code-Software Terraform. Jeder Server, der über ein kompromittiertes Script ausgerollt wird, erhält dann den Schadcode automatisch mitgeliefert. Oft ist es schwer, solche Angriffe zu erkennen, da man sie im Script selbst nicht unbedingt sieht. Terraform hat zum Beispiel so viele externe Verknüpfungen und importiert so viele externe Daten, dass es unzählige Möglichkeiten gibt, Schadcode einzuschleusen.

Die Software-Lieferkette berücksichtigen

Selbst wenn Entwicklungsabteilungen ihren eigenen Code penibel absichern, bleiben Risiken in der Software-Lieferkette. Moderne Anwendungen bestehen meist aus vielen verschiedenen Komponenten, darunter zahlreichen Open Source-Libraries und Frameworks, die zum Beispiel Funktionalität für Machine Learning, die Datenverarbeitung oder das Lesen und Schreiben von Bildern zur Verfügung stellen. Am Ende weiß oft kaum noch jemand genau, welche Module in einer Software eigentlich enthalten sind. Aus Security-Sicht ist dieses unübersichtliche Geflecht an Abhängigkeiten ein Problem, denn mit den Dritt-Komponenten bauen Unternehmen auch deren Schwachstellen ein.

Was das bedeutet, hat die Log4Shell-Sicherheitslücke gezeigt. Als beliebteste Java-Library für Log-Architekturen ist log4j Bestandteil fast aller Enterprise-Java-Anwendungen. Seit vielen Jahren kommt die Programmbibliothek nicht nur auf Servern und Clients zum Einsatz, sondern auch in Netzwerk-Equipment, Embedded- und IoT-Systemen. Unzählige Unternehmen auf der ganzen Welt sind daher von der Log4Shell-Schwachstelle betroffen. Die Sicherheitslücke gilt als extrem kritisch, da sie sich besonders leicht remote ausnutzen lässt: Angreifer müssen lediglich einen Code-Schnipsel an ein betroffenes System schicken und dafür sorgen, dass er geloggt wird. Zwar wurden sofort Patches veröffentlicht, um die Schwachstelle zu mindern. Für Administratoren ist es aber äußerst schwer, überhaupt zu erkennen, ob und in welcher Form sie von Log4Shell betroffen sind.

Mangelnde Transparenz erhöht das Risiko

Viele Unternehmen wissen schlichtweg nicht genau, wo sie die log4j-Library überall einsetzen. In der selbst entwickelten Software mag das noch leicht nachvollziehbar sein. Doch was ist mit den ganzen Applikationen und Services von Drittanbietern? Erschwerend kommt hinzu, dass die Sicherheitslücke nicht nur Java-Programme betrifft. Auch alle Systeme, die in irgendeiner Form Daten zum Loggen an ein Backend schicken, auf dem log4j läuft, sind über die Schwachstelle verwundbar. Dafür muss eine Anwendung die Bibliothek noch nicht einmal selbst im Code enthalten.

Diese Menge an Abhängigkeiten und die mangelnde Transparenz in der Software-Lieferkette erhöhen das Risiko für einen Cyberangriff. Denn bei kritischen Sicherheitslücken wie Log4Shell ist es für Unternehmen extrem wichtig, sofort zu reagieren. Cyberkriminelle nutzen Schwachstellen immer schneller aus. Oft haben sie schon wenige Stunden nach der Veröffentlichung passende Exploits parat. Professionelle Hacker gehen meist stufenweise vor und legen zunächst nur eine Backdoor. Erst Wochen oder Monate später, wenn sich die Aufregung um die Schwachstelle wieder gelegt hat, holen sie zur eigentlichen Attacke aus. Selbst wer seine Systeme mittlerweile gepatcht hat, muss also damit rechnen, dass die Einbrecher schon einen Schlüssel zur Haustür haben.

So lässt sich die Software-Entwicklung besser absichern

Um solche Szenarien zu verhindern, ist es wichtig, Patches möglichst schnell einzuspielen. Dafür müssen IT-Teams in der Lage sein, auf Knopfdruck abzurufen, ob und wo sie von einer Schwachstelle betroffen sind. Hier kommen sogenannte SBOMs (Software Bill of Materials) ins Spiel. Dabei handelt es sich um Inventurlisten, die bis ins Detail anzeigen, welche Komponenten in welcher Version in einer Applikation verbaut sind. SBOMs sollten am besten bereits während der Entwicklung automatisiert erstellt werden, da im Nachgang nicht mehr alle Abhängigkeiten erkennbar sind. Die Daten lassen sich mit wenigen Zeilen Code direkt in der CI/CD-Pipeline auslesen. Anschließend werden sie mithilfe einer Tracking-Plattform in einer Datenbank gespeichert und in einem Dashboard aufbereitet. SBOMs machen die gesamte Software-Lieferkette transparent, sodass IT-Teams die Abhängigkeiten in ihrer Software schnell analysieren können. Derweil hilft eine Technologie wie Virtual Patching, Zeit zu gewinnen. Sie schließt Sicherheitslücken bereits kurz nach deren Veröffentlichung automatisiert auf Netzwerkebene. Dadurch können Administratoren das Risiko für einen Angriff mindern, bis sie die eigentlichen Patches eingespielt haben.

Bereits während der Entwicklung sollten Unternehmen zudem ihre Source Code Repositories, IDEs und Build-Umgebungen automatisiert auf Schwachstellen scannen. So können sie nicht nur Schadcode, sondern auch andere Risiken wie unsichere Hashfunktionen, Schlüssel und Passwörter aufspüren. Generell empfiehlt es sich, schon in der DevOps-Pipeline strenge Security-Policies umzusetzen. Dazu gehört zum Beispiel ein Access-Management mit kurzlebigen Zugriffs-Tokens und die Entwicklung eines Audit-Trails mit Kommando-Zeilen-Tools, um Aktivitäten zu überwachen. Auf organisatorischer Ebene ist es wichtig, dass Entwicklungs- und Bereitstellungs-Teams eng zusammenarbeiten und man Verantwortlichkeiten für die IT-Security definiert. Klare Ansprechpartner und Meldeketten sind unverzichtbar, um im Ernstfall schnell zu reagieren und eine unsichere Komponente sofort aus einer Software zu entfernen.

Fazit

Tools und Maßnahmen, um die Software-Entwicklung besser abzusichern, gibt es viele. Häufig fehlt in Unternehmen aber noch das Bewusstsein für die Abhängigkeiten in der Software-Lieferkette und die Risiken, denen die DevOps-Pipeline ausgesetzt ist. Wenn Cyberkriminelle einen Shift-Left machen, muss auch die Security mitziehen. Die Sicherheitsforscher von Trend Micro prognostizieren, dass wir künftig mehr Angriffe auf die Software-Entwicklung sehen werden. Daher ist es wichtig, Security von Anfang an in DevOps-Prozesse zu integrieren.

Über den Autor: Udo Schneider ist IoT Security Evangelist Europe bei Trend Micro.

(ID:48309304)