Die Softwaretechnologie entwickelte sich weiter und mit ihr auch die Hacker. Das Wettrüsten mit böswilligen Akteuren beschränkte sich größtenteils auf Schwachstellen und Angriffe, die sich gegen die eingesetzte Software richteten. Angriffe auf die Softwarelieferkette waren, wenn auch nicht unbemerkt, nicht das Hauptziel der Bösewichte …
Der Angriff, den viele als Beginn einer Veränderung in der Vorgehensweise bei Advanced Persistent Threats (APTs) betrachteten, war der SolarWinds greifen an. Nicht das erste, aber mit einer solchen Wirkung, dass es Schlagzeilen machte und die IT-Sicherheit im Sturm eroberte.
Beispiele: SolarWinds, Codecov, Kaseya
SolarWinds ist ein bedeutender Softwareanbieter, der Tools zur Netzwerk- und Infrastrukturüberwachung anbietet. Eines der Produkte des Unternehmens ist Orion, eine Plattform zur Überwachung und Verwaltung von Infrastrukturen. Sie wird von mehr als 30,000 öffentlichen und privaten Organisationen zur Verwaltung ihrer IT-Ressourcen verwendet. Orion greift auf IT-Systeme zu, um Protokoll- und Systemleistungsdaten abzurufen.
Im Dezember 2019 griffen Hacker auf die Netzwerke, Systeme und Daten Tausender SolarWinds-Kunden zu. Sie griffen die Software-Lieferkette an und schleusten Schadcode in die Plattform ein. Anschließend lieferte SolarWinds die Backdoor-Malware als Update für die Orion-Software, über die Hacker auf Benutzer und Konten der betroffenen Organisationen zugreifen und sich als diese ausgeben konnten. Der SolarWinds-Angriff bedeutete ein Erwachen der Cybersicherheit für alle Organisationen, die in der Cloud-nativen Welt tätig sind.
Auf diesen Supply-Chain-Angriff folgten weitere, wie etwa Codecov, ein Software-Code-Coverage-Tool. Im Januar 2021 Angreifer extrahierte einen Zugangsdatensatz versehentlich im Docker-Image von Codecov gespeichert, das der Akteur verwendete, um ein Uploader-Skript im Tool zu ändern. Der Akteur fügte lediglich eine einzige Codezeile ein, die bei Ausführung des Skripts alle Umgebungsvariablen der CI an den vom Angreifer kontrollierten Server schickte. Über Monate hinweg erhielten die Angreifer potenziellen Zugriff auf Systeme, die das geänderte Codecov-Skript verwendeten.
Später, am 2. Juli 2021, Angriff auf Kaseya aufgetreten. Seine VSA-Plattform wird von vielen MSPs verwendet, die IT-Dienste für andere Unternehmen bereitstellen, um Patch-Management und Kundenüberwachung durchzuführen. Hacker griffen die Lieferkette von Kaseya VSA an, kompromittierten deren Infrastruktur und veröffentlichten anschließend bösartige Updates auf den lokalen Servern von VSA, um die Systeme der verwalteten Unternehmen zu infizieren, ihre Daten zu verschlüsseln und ein Lösegeld zu fordern. Ransomware über ein trojanisiertes Tool, das von MSPs bei ihren verwalteten Unternehmen eingesetzt wird, die die Endziele sind. Wie clever!
Seit dem SolarWinds-Vorfall kam es immer häufiger zu Angriffen auf die Software-Lieferkette, die das Image und die Wirtschaftlichkeit von Unternehmen wie Samsung, Uber, Nissan, Nvidia und vielen anderen beeinträchtigen. Laut Gartner „werden bis 2025 45 % der Organisationen weltweit Angriffe auf ihre Software-Lieferketten erlebt haben, eine Verdreifachung seit 2021.“
Eine neue Generation von Angriffen auf die Software-Lieferkette
Ein Angriff auf die proprietären Anwendungen oder Produktionsumgebungen eines Unternehmens verursacht nur ein einziges Opfer. Hinzu kommt, dass die überwiegende Mehrheit der Unternehmen bereits AppSec-Schutzmaßnahmen wie AST implementiert hat. SCA oder WAF-Tools, hat zur Entstehung einer neuen Generation von Angreifern geführt, die die Softwareentwicklung anstreben pipeline. Angriffe auf die Lieferkette können Tausende von Unternehmen mit nur einem einfachen Angriff treffen: dem idealen Verstärker.
Die Entwicklungsinfrastruktur ist ein leichtes Ziel für Angreifer. Ihre große Angriffsfläche ermöglicht Zugriff auf die Produktionsumgebung und deren Daten. Die gesamte Infrastruktur der DevOps-Tools – Repositories, Quellcodeverwaltungssysteme, Build-Tools, Deployment-Tools, Infrastructure-as-Code-Vorlagen, Container, Skriptdateien usw. – ist relativ groß und anfällig. Zudem sind all diese Tools weit entfernt von der Kontrolle des Sicherheitsbereichs und werden von den Entwicklungs- und Produktionsteams verwaltet. Hacker wissen das und nutzen diese Schwachstellen aus.
Das neue Ziel
Entwickler schreiben oft Geheimnisse in den Quellcode, wie z. B. Anmeldeinformationen und Schlüssel, um sie während der Entwicklung zu testen. Diese werden in Dateien gespeichert, die häufig der Versionskontrolle unterliegen, und können später von Angreifern gefunden werden, selbst wenn die Dateien oder Geheimnisse entfernt werden. Dadurch können Angreifer Hintertüren installieren, den Quellcode lesen, bösartigen Code einfügen, vertrauliche Daten extrahieren usw. Sobald böswillige Akteure gültige login Anmeldeinformationen können sie sich seitlich durch die SDLC. Mit diesen Anmeldeinformationen können sie zu anderen Tools wechseln und erweiterte Benutzerrechte für die Suche nach wertvolleren Informationen erhalten.
Hacker können Anmeldeinformationen verwenden, um in die SDLC, sie können aber auch in Repositories oder Tools eindringen, die falsch konfiguriert oder unsicher sind, wodurch Systeme und Daten gefährdet werden.
Angriffe zielen auch auf Open-Source-Pakete ab. Wir alle kennen Horrorgeschichten über Angriffe, die bekannte Schwachstellen ausnutzen, wie etwa Log4j. Andererseits laufen Supply-Chain-Angriffe anders ab: Angreifer injizieren Schadcode in beliebte Open-Source-Pakete, um ihn später im Build-Prozess vieler Organisationen auf der ganzen Welt zu verwenden.
Kurz gesagt: Hacker können privilegierten Zugriff, Fehlkonfigurationen und Schwachstellen in der CI/CD pipeline Infrastruktur als Vektor zum Einschleusen von Schadsoftware in eine Software, die von vielen genutzt werden könnte.
So schützen wir unsere SDLC vor Angriffen auf die Software-Lieferkette?
Die Zahl der Angriffe auf die Lieferkette nimmt stetig zu, und der Markt reagiert auf dieses Szenario. Einige Organisationen haben Rahmenbedingungen geschaffen, um software supply chain security, wie das NIST Secure Software Development Framework (SSDF) und Googles Supply Chain Levels for Software Artifacts (SLSA). Es gibt jedoch nicht viele Unternehmen, die den Schutz von DevOps-Tools und -Infrastrukturen zur Priorität machen, um Angriffe auf ihre Lieferkette zu verhindern. Tatsächlich 82 % der CIOs glauben, dass sie durch sie gefährdet sein werden.
Unternehmen müssen sich nicht nur um den Schutz ihrer Anwendungen kümmern, sondern auch um die Software-Infrastruktur und Artefakte, die Teil ihrer SDLC Da Angreifer die Lieferkette ins Visier nehmen, ist die Angriffsfläche groß. Die Breite der Angriffsfläche, das mangelnde Bewusstsein der Entwicklungsteams für diese Art von Angriffen und der Mangel an spezialisierten Sicherheitstools ermöglichen es Angreifern, sich auf die Software-Lieferkette zu konzentrieren.
Abschließende Bemerkungen
Unsere schützen pipeline wird von Tag zu Tag dringlicher und ist eine Priorität für CISOS, der sicherstellen muss, dass Sicherheitsteams auf die Lieferkette achten und mit Devops-Teams zusammenarbeiten, um zu schützen SDLC vor dieser Art von Angriff.
Durch den Einsatz von Tools, die uns helfen, unsere SDLC, Hintertüren und verdächtiges Verhalten zu identifizieren und Angriffe auf die Lieferkette zu stoppen, ist notwendig, um unsere DevOps-Umgebung privat und sicher zu halten. Die ersten Tools zum Schutz software supply chain security beginnen sich zu entwickeln. Einige konzentrieren sich mehr auf die Dev-Seite und andere auf die Ops-Seite. Und einige, wie Xygeni, haben die Mission, die Integrität und Sicherheit des Software-Ökosystems während des gesamten DevOps zu schützen.
Um mehr zu lesen |
|
|
|
|






