Deutsch
Menü

Was ist Lieferkettenangriff (Supply-Chain-Angriff)?

Angriff, der die Zielorganisation nicht direkt angreift, sondern über Schwachstellen in der Versorgungskette (Lieferkette) aus Software, Bauteilen, Auftragnehmern usw., die die Organisation nutzt, indirekt eindringt. Beispiele sind das Einschleusen schädlichen Codes in legitime Update-Programme, die Übernahme von Open-Source-Paketen oder schädliche Pakete mit ähnlichen Namen und das Eindringen über IT-Dienstleister. Beim 2020 bekannt gewordenen Vorfall bei SolarWinds breitete sich der Schaden über legitime, signierte Updates auf viele Organisationen aus. Bei Hardware gehören auch Hardware-Trojaner, bei denen während der Fertigung schädliche Schaltungen hinzugefügt werden, zu dieser Art von Bedrohung.

Japanische Bezeichnung: サプライチェーン攻撃

„Lieferkettenangriff (Supply-Chain-Angriff)“ kommt in 2 Übungsfragen aus 1 Themen vor, z. B. Cyberangriffe und Abwehr in der Praxis.

Fachgebiet: Cyberangriffe und Abwehr in der Praxis

Jetzt üben: Fragen zu Lieferkettenangriff (Supply-Chain-Angriff)

Ein Unternehmen nutzt in seinem internen Paketverzeichnis (private Registry) die nur intern verwendete Bibliothek acme-utils. Ein Angreifer hat im öffentlichen Paketverzeichnis ein Paket mit demselben Namen acme-utils und einer höheren Versionsnummer registriert; dabei stellte sich heraus, dass die interne Build-Umgebung je nach Build-Konfiguration das Paket des Angreifers übernimmt. Welche Maßnahme gegen diese „Dependency Confusion“ ist am besten geeignet?

  1. ADie Versionsnummer der internen Bibliothek klein halten, damit sie sich leicht von Paketen im öffentlichen Verzeichnis unterscheiden lässt
  2. BInterne Pakete in einem von der Organisation verwalteten Namensraum ablegen, sie so konfigurieren, dass sie nur aus dem internen Verzeichnis bezogen werden, und Versionen und Hashwerte in einer Lockfile festschreiben
  3. CPakete im öffentlichen Verzeichnis sind geprüft und vertrauenswürdig; aus welchem Verzeichnis bezogen wird, muss daher nicht konfiguriert werden
Antwort und Erläuterung anzeigen

Antwort: B. Interne Pakete in einem von der Organisation verwalteten Namensraum ablegen, sie so konfigurieren, dass sie nur aus dem internen Verzeichnis bezogen werden, und Versionen und Hashwerte in einer Lockfile festschreiben

Dependency Confusion ist eine Form des Software-Lieferkettenangriffs. Manche Paketverwaltungswerkzeuge sind so konfiguriert, dass sie mehrere Verzeichnisse abfragen und bei gleichem Namen das Paket mit der höheren Versionsnummer wählen; Angreifer nutzen das aus, um ein schädliches Paket mit demselben Namen wie ein internes einschleusen zu lassen. Abhilfe schafft, für interne Pakete einen von der Organisation verwalteten Namensraum (Scope) zu verwenden, diesen Namensraum nur an das interne Verzeichnis zu binden und ausdrücklich festzulegen, aus welchem Verzeichnis bezogen wird. Werden zusätzlich Versionen und Hashwerte der Abhängigkeiten in einer Lockfile festgeschrieben, lässt sich verhindern, dass sie unbemerkt durch etwas anderes ersetzt werden. Auch den Namensraum der Organisation vorab im öffentlichen Verzeichnis zu registrieren, hilft gegen Nachahmung.

Bei dem im Dezember 2020 bekannt gewordenen Vorfall bei SolarWinds drangen Angreifer in die Build-Umgebung einer IT-Verwaltungssoftware ein, und in legitime Update-Programme wurde schädlicher Code eingeschleust. Diese Updates wurden mit der legitimen Codesignatur des Herstellers verteilt. Welche Lehre lässt sich aus diesem Vorfall am ehesten ziehen?

  1. AUpdate-Programme mit gültiger Codesignatur enthalten keinen schädlichen Code; es genügt daher, dass Nutzer die Signatur prüfen
  2. BUpdate-Programme sind gefährlich; Software sollte daher einschließlich Sicherheitskorrekturen überhaupt nicht mehr aktualisiert werden
  3. CEine Codesignatur zeigt nur, wer signiert hat und ob nach dem Signieren manipuliert wurde; daher muss der Hersteller seine Build-Umgebung schützen, und Nutzer überwachen auch das Verhalten vertrauenswürdiger Software
Antwort und Erläuterung anzeigen

Antwort: C. Eine Codesignatur zeigt nur, wer signiert hat und ob nach dem Signieren manipuliert wurde; daher muss der Hersteller seine Build-Umgebung schützen, und Nutzer überwachen auch das Verhalten vertrauenswürdiger Software

Eine Codesignatur bestätigt, wer signiert hat und dass der Inhalt nach dem Signieren nicht verändert wurde; schädlichen Code, der vor dem Signieren eingeschleust wurde, kann sie nicht erkennen. Beim Vorfall bei SolarWinds, einem typischen Beispiel für einen Software-Lieferkettenangriff, wurde der schädliche Code während des Builds hinzugefügt und erreichte daher als signiertes, legitimes Update viele Organisationen. Auch bei der im März 2024 entdeckten Hintertür in xz-utils hatte eine Person, die über lange Zeit als Entwickler Vertrauen gewonnen hatte, schädlichen Code in die Dateien für die Verteilung eingeschmuggelt. Wichtig ist, dass Hersteller ihre Build-Umgebung abgetrennt schützen und die Herkunftskette von den Quellen bis zum Build aufzeichnen und prüfen und dass Nutzer auch bei vertrauenswürdiger Software verdächtige Verbindungen und verdächtiges Verhalten etwa mit EDR überwachen.

„Lieferkettenangriff (Supply-Chain-Angriff)“ in den Erläuterungen

Fragen mit „Lieferkettenangriff (Supply-Chain-Angriff)“ (2)

  1. Ein Unternehmen nutzt in seinem internen Paketverzeichnis (private Registry) die nur intern verwendete Bibliothek acme-utils. Ein Angreifer hat im öffentlichen Paketverzeichnis ein Paket mit demselben Namen acme-utils und einer höheren Versionsnummer registriert; dabei stellte sich heraus, dass die interne Build-Umgebung je nach Build-Konfiguration das Paket des Angreifers übernimmt. Welche Maßnahme gegen diese „Dependency Confusion“ ist am besten geeignet?
  2. Bei dem im Dezember 2020 bekannt gewordenen Vorfall bei SolarWinds drangen Angreifer in die Build-Umgebung einer IT-Verwaltungssoftware ein, und in legitime Update-Programme wurde schädlicher Code eingeschleust. Diese Updates wurden mit der legitimen Codesignatur des Herstellers verteilt. Welche Lehre lässt sich aus diesem Vorfall am ehesten ziehen?

Verwandte Begriffe

EDR (Endpoint Detection and Response) Cyber Kill Chain Digitale Forensik Incident Response Intrusion Detection System (IDS) IoC (Indicator of Compromise) Lateral Movement MITRE ATT&CK Penetrationstest SBOM (Software Bill of Materials)

Zur Glossarübersicht