Angriff auf die Lieferkette - Einleitung

Es gibt viele Formen von Angriffen auf die Versorgungskette - Repository-Hacking, von Entwicklern initiierte Angriffe, Manipulation von Bibliotheken, Domain-Hijacking und so weiter -, aber ein Angriff, bei dem die Malware gezielt nach Ihrer Entwicklungssoftware sucht und andere Projekte auf Ihrem System während des Builds infiziert, ist etwas anderes.

Auch wenn es sich hierbei nicht um ein aktuelles Ereignis handelt, zeigt es doch deutlich, wie fortschrittlich und innovativ die Vorbereitung solcher Angriffe ist. Die folgende Geschichte basiert auf einem Bericht des GitHub-Sicherheitsteams, der hier. Der Vorfall ereignete sich Anfang 2020, ist aber heute noch genauso interessant wie damals, da die Malware unerwartete Wendungen nimmt, um andere, nicht miteinander verbundene Software zu infizieren.

Die versteckte Bedrohung im Open-Source-Ökosystem

Das Security Incident Response Team (SIRT) von GitHub wurde über Repositories alarmiert, die unwissentlich mit Malware infizierte Open-Source-Projekte bereitstellen. Die Malware mit dem treffenden Namen "Octopus Scanner" wurde speziell für NetBeans-Projekte entwickelt, um diese zu infizieren. Sie nutzte den Build-Prozess und die daraus resultierenden Artefakte, um sich zu verbreiten.

Fassen wir das Ganze etwas zusammen. Wenn Sie den in einem dieser infizierten Repositories enthaltenen Code klonen und erstellen, sucht die Malware aktiv nach installierten NetBeans-Installationen (NetBeans ist eine Java-IDE, eine integrierte Entwicklungsumgebung). Wenn sie gefunden wird, integriert sie sich in den Build-Prozess jedes anderen Projekts, das mit NetBeans erstellt wurde, so dass sie sich selbst (die Malware) in jede Build-Software einfügt. Da NetBeans ein Entwickler-Tool ist, würde es, wenn es gefunden wird, natürlich dazu verwendet werden, Code für mehrere verschiedene Java-Anwendungen zu schreiben und zu erstellen - die nun alle die Malware enthalten würden.

Diese Entdeckung war nicht nur wegen der Existenz der Malware alarmierend, sondern auch wegen ihrer potenziellen Reichweite. Die betroffenen Repositorys waren quelloffen, was bedeutet, dass jeder Entwickler oder jede Organisation unwissentlich den infizierten Code klonen und unbeabsichtigt Schwachstellen in ihre Anwendungen oder Systeme einführen könnte.

Aber was bedeutet das für Java-Entwickler?

Die zugrundeliegende Botschaft: Der Bedarf an einer sicheren Lieferkette

Als Java-Entwickler fragen Sie sich vielleicht, wie Sie sicherstellen können, dass die von Ihnen verwendeten Bibliotheken und Abhängigkeiten sicher sind. Der Octopus-Scanner-Vorfall unterstreicht, wie wichtig die Sicherung der Open-Source-Lieferkette ist. Es geht nicht nur darum, die neuesten CVEs zu patchen. Es geht darum, die Integrität des gesamten Ökosystems der Softwareentwicklung und -bereitstellung zu wahren.

Eingabe SecureChain für Java. Stellen Sie sich einen Dienst vor, bei dem alle Java-Abhängigkeiten und -Bibliotheken, die Sie benötigen, geprüft und auf Schwachstellen gescannt wurden. Sie müssen nicht mehr in Foren suchen, um festzustellen, ob eine Bibliothek sicher zu verwenden ist. Securechain for Java bietet ein kuratiertes Repository für Java-Abhängigkeiten, das sicherstellt, dass Sie nur Bibliotheken verwenden, die frei von Hintertüren oder bekannten Sicherheitslücken sind.

Oktopus-Scanner: Ein genauerer Blick

Die Funktionsweise des Octopus-Scanners war vielschichtig:

• Identifizierung und Infektion: Die Malware identifizierte das NetBeans-Verzeichnis des Benutzers, zählte alle Projekte auf und bettete dann eine bösartige Nutzlast in Projektdateien und JAR-Dateien ein.
• Persistenz: Die bösartige Nutzlast sorgte dafür, dass sie jedes Mal ausgeführt wurde, wenn ein NetBeans-Projekt erstellt wurde, und sorgte so für die weitere Ausbreitung der Malware.
• Subtilität: Im Gegensatz zu anderer Malware waren sich die Besitzer des Repositorys nicht bewusst, dass sie Backdoored-Code verbreiteten, was die Erkennung und Eindämmung noch schwieriger macht.
• Flexibilität: Bei der Ausführung werden sowohl die Nutzlast als auch die Befehls- und Kontrollsoftwarekomponenten in JAR-Dateien anderer Anwendungen abgelegt. Dies ermöglichte den Malware-Betreibern eine große Diversifizierung und Anpassungsfähigkeit, da sie ändern konnten, was auf den infizierten Systemen bereitgestellt wurde, falls Gegenmaßnahmen ergriffen wurden.

Da der Schädling sehr gezielt auf Java-Entwickler abzielte, konnte er auf dem infizierten System nichts ausrichten, wenn NetBeans nicht gefunden wurde. Im Gegensatz zu vielen anderen Formen von Malware und Cyberangriffen, die manchmal auf die größtmögliche Anzahl von Zielen abzielen, in der Hoffnung, dass ein kleiner Prozentsatz der beabsichtigten Opfer in die Falle tappt (wie Ransomware oder E-Mail-Phishing), treffen Supply-Chain-Angriffe die Endbenutzer, bevor sie überhaupt die Möglichkeit haben, etwas dagegen zu unternehmen. Wenn die von Ihnen installierte Software bereits mit einem Backdoor versehen ist, kann Sie keine noch so große Anzahl von Sicherheitstools schützen.

Sich der Herausforderung stellen

Der proaktive Ansatz von GitHub im Umgang mit dem Octopus-Scanner-Vorfall in Verbindung mit den Tools, die sie zum Aufspüren von Schwachstellen in Abhängigkeiten anbieten, setzt einen Maßstab dafür, wie Open-Source-Plattformen arbeiten sollten. Dennoch müssen auch die einzelnen Entwickler und Organisationen ihren Teil dazu beitragen, indem sie sicherstellen, dass sie vertrauenswürdige Quellen für ihre Code-Abhängigkeiten verwenden.

Da die Grenze zwischen einer echten Bibliothek und einer Hintertür immer mehr verschwimmt, ist ein Dienst wie SecureChain für Java von größter Bedeutung. Es geht nicht nur darum, effizienten Code zu schreiben, sondern auch um sicheren Code.

Abschließende Überlegungen

Der Vorfall mit Octopus Scanner ist ein gutes Beispiel für die Schwachstellen im Open-Source-Ökosystem. Er zeigt auch, wie vielfältig und fortgeschritten diese Angriffe sein können. Während Plattformen wie GitHub ihren Teil dazu beitragen, liegt es an den Entwicklern, sicherzustellen, dass sie ihre Abhängigkeiten aus vertrauenswürdigen, überprüften Quellen beziehen.

Mit SecureChain für Javakönnen Sie Ihre Java-Anwendungen in der Gewissheit entwickeln, dass alle verwendeten Bibliotheken und Abhängigkeiten frei von Sicherheitslücken sind. In einer Welt, in der Code frei geteilt wird, sollten wir dafür sorgen, dass das, was wir teilen, sicher ist.

Sichern Sie Ihre Java-Projekte. Vertrauen Sie auf SecureChain für Java.

Zusammenfassung

Artikel Name

Angriff auf die Lieferkette - Einleitung

Beschreibung

Es gibt viele Angriffe auf die Lieferkette, aber ein Angriff, bei dem die Malware gezielt nach Ihrer Entwicklungssoftware sucht, ist etwas anderes. Mehr lesen

Autor

Joao Correia

Name des Herausgebers

TuxCare

Logo des Herausgebers