DevOps-Pipelines in Gefahr!

Mitte 2017 gelang es russischen Staatshackern, einen bösartigen Wurm in Finanzsoftware einzuschleusen, die vor allem in der Ukraine zum Einsatz kommt. Alle Unternehmen, die diese Software aktualisierten, wurden infiziert. NotPetya verbreitete sich rasend schnell und richtete weltweit Schäden in Milliardenhöhe an. Drei Jahre später war dann die Softwarelieferkette des IT-Dienstleisters SolarWinds das Ziel von Cyberkriminellen (die ebenfalls im Auftrag des russischen Staats gehandelt haben sollen). Die Auswirkungen waren ähnlich weitreichend wie im Fall von NotPetya.

"Angreifer, die Zugriff auf Softwareentwicklungs-Pipelines haben, können in die Netzwerkinfrastruktur eindringen und sich zum Beispiel Zugang zu geistigem Eigentum verschaffen", erklärt Viktor Gazdag, Senior Security Consultant beim Beratungsunternehmen NCC Group.

DevOps-Pipelines im Angriffsfokus

Dabei ist die Softwarelieferkette nicht nur für raffinierte Angreifer mit staatlichem Auftrag interessant - sondern auch für "gewöhnliche" Cybercrime-Banden. Laut einer aktuellen Studie des Sicherheitsunternehmens Argon, haben Angriffe auf die Software-Supply-Chain im Jahr 2021 (im Vergleich zu 2020) um mehr als 300 Prozent zugelegt. Zu den gängigen Taktiken und beliebten Angriffsvektoren zählen dabei:

• bösartigen Code in besonders verbreitete Open-Source-Pakete einzuschleusen,

• bereits vorhandene Schwachstellen auszunutzen,

• CI/CD-Pipeline-Tools zu kompromittieren, sowie

• Fehlkonfigurationen und andere Sicherheitsprobleme auszunutzen.

Laut einer Studie von Sonatype aus dem September 2021 haben Attacken auf Open-Source-Softwarelieferketten im Vergleich zu 2020 um 650 Prozent zugelegt. Die Angriffsfläche ist dabei riesig: Laut Sonatype befinden sich mehr als 37 Millionen Komponenten und Pakete innerhalb der vier wichtigsten Open-Source-Ökosysteme.

DevOps-Pipelines sind dabei besonders anfällig, weil Softwareentwickler laut Gazdag häufig über ausufernde Berechtigungen und Zugriffsrechte verfügten: "Wenn die produzierte Software für den externen Gebrauch bestimmt ist, können die Auswirkungen dramatisch sein. Die Angreifer haben auch die Möglichkeit, in der endgültigen Anwendung Fuß zu fassen." Die DevOps-Pipelines sollten ein höheres Maß an Sicherheit aufweisen, so der Experte. Stattdessen gebe es viele unzureichende Sicherheitspraktiken, ungeschützte Infrastrukturen und Anmeldedaten: "Wenn Sie Shodan verwenden und nach dem Entwicklungs-Tool Jenkins suchen, stoßen Sie auf eine umfassende Infrastruktur, die im Internet verfügbar und zugänglich ist." Allzu oft werde der CI/CD-Infrastruktur nicht die gleiche Aufmerksamkeit zuteil wie anderen Bereichen im Unternehmens, so Gazdag.

Mit modernen Entwicklungspraktiken verschlimmere sich diese Situation noch, weiß Gartner-Analyst Dale Gardner: "Wenn Unternehmen zu DevOps übergehen, besteht die Tendenz, einige Kontrollmechanismen zu lockern, die im Zusammenhang mit der Entwicklung eingeführt wurden. Schließlich geht es darum, flexibel sein und möglichst schnell Code zu veröffentlichen. Beschränkungen und Kontrollen stehen dabei im Weg."

Wie DevOps-Pipelines angegriffen werden

Laut David Wheeler, Director of Open-Source Supply Chain Security bei der Linux Foundation, sind die drei häufigsten Angriffsarten in Zusammenhang mit DevOps-Pipelines:

• Dependency Confusion

• Typosquatting und

• Malicious Code Injection.

Bei Dependency Confusion erstellen Angreifer Open-Source-Pakete mit offiziellen Bezeichnungen von Business-Softwarepaketen. Wenn bestimmte Pipeline-Tools versuchen, automatisch die neueste Version einer Software herunterzuladen, ziehen sie den bösartigen Payload.

Beim Typosquatting erstellt ein Angreifer ein Open-Source-Softwarepaket mit einer Bezeichnung, die einen Zahlen- oder Buchstabendreher erhält. Die Hoffnung: Wenn ein Developer einen Tippfehler macht, wird die maliziöse Bibliothek verwendet.

Eine Malicious Code Injection liegt vor, wenn Angreifer Schadcode direkt in legitime Open-Source-Software einschleusen. Das bewerkstelligen sie dabei in der Regel entweder mit gestohlenen Anmeldedaten oder manipulierten Entwickler-Tools.

Ein weiteres Problem liegt in bekannten Schwachstellen von Open-Source-Komponenten, die Angreifer relativ schnell ausnutzen. Das Sicherheitsunternehmen Synopsis untersuchte im Rahmen einer aktuellen Analyse 1.500 interne und kommerzielle Softwareprojekte in Unternehmen. Das Ergebnis: In 98 Prozent der Fälle kam Open-Source-Quellcode zum Einsatz. Erschreckend ist allerdings, dass ganze 84 Prozent der untersuchten Pakete mindestens eine Schwachstelle aufwies. Ebenfalls bemerkenswert: 91 Prozent der verwendeten Open-Source-Komponenten wurden in den letzten zwei Jahren nicht gewartet.

Softwareentwicklungs-Pipelines schützen

Unternehmen sind allerdings nicht machtlos, wenn es um den Schutz von DevOps-Pipelines geht. Diese Maßnahmen sollten Sie dazu umsetzen:

1. Entwickler schulen

David Gochenaur, Senior Director of Cybersecurity beim Managed-Services-Anbieter Ensono, ist der Ansicht, dass sowohl interne als auch externe Softwareanbieter zur Sicherheit des Codeentwicklungs- und -bereitstellungsprozesses beitragen müssen. Dabei sollten beide Gruppen auf unterschiedliche Weise angegangen werden.

Ensono verkauft keine Software, benötigt aber kundenspezifische Software, um Kundenportale zu betreiben. Die Sicherheit dieser Portale ist für das Unternehmen von größter Bedeutung: "Wir verwalten Systeme für viele Kunden, sammeln Daten über deren Status und übertragen diese in ein Portal", erklärt Gochenaur. "Unsere Tools haben Zugriff auf Kundensysteme, was uns zu einem hochwertigen Ziel für Angreifer macht. Da es so viele Kunden gibt, gilt es sicherzustellen, dass Kunde A nicht auf die Daten von Kunde B zugreifen kann."

Dabei stehe viel auf dem Spiel, so der Sicherheitsexperte: "Einige unserer Kunden sind in Sachen Datenschutz sehr sensibel. Die erste Herausforderung besteht deswegen darin, bei der Überprüfung der Anbieter einen strengen Maßstab anzulegen. Der Angriff auf SolarWinds ist das beste Beispiel für einen Drittanbieter, der von Bedrohungsakteuren als Einfallstor genutzt wurde."

Selbiges gelte auch für externe Softwareentwickler: "Wenn wir Dritte beauftragen, überprüfen wir sie sehr genau, um sicherzustellen, dass sie über Prozesse und Kontrollmechanismen verfügen, die gewährleisten, dass die von ihnen gelieferten Daten sicher sind", offenbart Gochenaur. "Dazu gehört auch die Überprüfung ihrer Testverfahren und Sicherheitskontrollen in der Entwicklungsumgebung. Zudem sehen wir in unseren Verträgen Strafen für Fehler vor."

Für unternehmenseigene Entwickler bestehe eines der größten Risiken in der Verwendung von öffentlich zugänglichen Code-Repositories: "Dort ist alles Mögliche zu finden. Es gibt dort tollen Quellcode, der einiges kann - unter Umständen aber auch Bedrohungsakteuren umfassenden Zugang verschafft. Um sicheren Code zu produzieren, können Developer auf viele andere Maßnahmen zurückgreifen."

Eine Strategie, die sowohl bei der Sicherheitsschulung als auch bei der Motivation helfen könne, sei, Penetrationstests von Dritten und eigenen Teams durchführen zu lassen: "Das macht einen großen Qualitätsunterschied beim entwickelten Produkt aus", ist Gochenaur überzeugt.

2. Richtige Tools einsetzen

Um seine Entwickler dabei zu unterstützen, gute Entscheidungen im Sinne der IT-Sicherheit zu treffen, hat Ensono mehrere Sicherheitskontrollmechanismen eingerichtet. So hilft beispielsweise eine Multi-Faktor-Authentifizierung dabei, Außenstehende vom Zugriff auf die DevOps-Pipeline abzuschneiden. Damit die Entwickler auf bereits geprüften und genehmigten Code zurückgreifen können, setzt das Unternehmen zudem auf private Code-Bibliotheken. Darüber hinaus verfügt Ensono über spezielle Teams, die Systeme patchen, um sicherzustellen, dass alles, was bereitgestellt wird, aktuell und auf dem neuesten Stand ist. "Wir scannen unsere gesamte Umgebung regelmäßig auf Schwachstellen", sagt Gochenaur.

Laut Venky Chennapragada, DevOps-Architekt bei Capgemini Americas, können Unternehmen jedoch weitere - häufig übersehene - Maßnahmen ergreifen, um ihre Entwicklungs-Pipeline abzusichern: "Unternehmen sollten zum Beispiel getrennte Pipelines für die nicht produktive Staging-Umgebung und für die Produktionsumgebung einrichten und den Kreis der Personen, die Zugriff auf beide Systeme haben, begrenzen. Um den Zugriff noch weiter einzuschränken, sollten Enterprise-Access-Management-Systeme zum Einsatz kommen - etwa Active Directory oder LDAP."

Viele Unternehmen, so der DevOps-Experte, verfügten über eine separate Benutzerdatenbank für die Softwareentwicklungsteams oder verwendeten integrierte Management-Tools. "Wenn ich eine Integration mit Active Directory oder LDAP vornehme, wird es ein Sicherheitsaudit geben. Manche Techniker wollen das vielleicht umgehen, weil sie etwas nicht richtig installiert haben." Rollenbasierter Zugriff sei ein Kontrollmechanismus, über den sich Entwickler ärgern könnten: "Es ist immer einfach, vollen Zugriff zu gewähren und keine Benutzergruppen und Rollen erstellen zu müssen. Aber es ist das Gegenteil von Best Practice."

Chennapragada empfiehlt Unternehmen, alle Komponenten, die in ihre Software einfließen, sorgfältig zu überprüfen - insbesondere Open-Source-Bibliotheken: "Entwickler neigen dazu, quelloffenen Code in ihre Software einzubauen, der Bugs und Sicherheitslücken enthalten kann. Externe Bibliotheken müssen gescannt und überprüft werden und Entwickler sollten nur zertifizierte Abhängigkeiten verwenden. Es sind nicht nur Bibliotheken, die sich Entwickler aus dem Internet holen können - weitere attraktive Tools sind etwa Betriebssystemvarianten und Plugins."

"Es gibt viele Sicherheitskontrollen und -prozesse, die nicht viel kosten und keinen großen Aufwand verursachen, aber eine durchdachte Planung oder Schulung erfordern", meint Ilia Kolochenko, CEO beim Sicherheitsanbieter ImmuniWeb. "AWS bietet beispielsweise integrierte Sicherheitskontrollen und -Tools, die teilweise sogar kostenlos sind. Die werden oft nicht genutzt, weil sich viele dessen nicht bewusst sind. Oder weil es zu schwierig erscheint, sich mit diesen auseinanderzusetzen."

Dabei mache es die Cloud einfacher, Continuous-Security-Monitoring- oder Incident-Response-Tools einzusetzen: "So können verdächtige Aktivitäten ohne Betriebsunterbrechung erkannt und gestoppt werden. Diese Möglichkeiten müssen nur genutzt werden."

3. SBOMs anfordern

Viele in der Branche drängen auf Software-Stücklisten (Software Bill of Materials, SBOMs). Die Cloud Native Computing Foundation hat ein Whitepaper mit Best Practices veröffentlicht, in dem allen Anbietern empfohlen wird, nach Möglichkeit eine SBOM mit klaren und direkten Links zu Abhängigkeiten bereitzustellen. Eine SBOM würde Unternehmen dabei helfen, Instanzen von anfälligen Komponenten in ihrer Umgebung zu finden. Log4j wurde beispielsweise im Dezember 2021 gepatcht - allerdings waren am 11. Februar 2022 noch immer 40 Prozent aller Downloads mit der anfälligen Version versehen. "Wenn man ein Brot kauft, findet man die Liste der Zutaten auf der Rückseite", sagt Kayne McGladrey, IEEE-Seniormitglied und Cybersicherheitsstratege beim Beratungsunternehmen Ascent Solutions. "Wenn das bei Software der Fall ist, können Unternehmen fundierte Risikoentscheidungen treffen."

McGladrey geht davon aus, dass vorausschauende Softwareanbieter SBOMs anbieten werden, da die Kunden es sich wünschen. Er empfiehlt den Softwareherstellern, sogar noch einen Schritt weiter zu gehen und Informationen darüber bereitzustellen, wie sich ihre Software verhalten soll und wie sie sich nicht verhalten soll: "Wenn Softwarehersteller eine Liste mit normalen Verhaltensweisen zur Verfügung stellen würden, fallen anormale Verhaltensmuster schneller auf."

Unabhängig davon sollten Unternehmen ihre Software auf bekannte Schwachstellen und andere potenzielle Sicherheitsprobleme überprüfen. (fm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.