A08:2021 – Fehlerhafte Prüfung der Software- und Datenintegrität

Beurteilungskriterien

Zugeordnete CWEs	Maximale Häufigkeit	Durchschn. Häufigkeit	Durchschn. Ausnutzbarkeit (gewichtet)	Durchschn. Auswirkungen (gewichtet)	Maximale Abdeckung	Durchschnittliche Abdeckung	Gesamtanzahl	CVEs insgesamt
10	16.67 %	2.05 %	6.94	7.94	75.04 %	45.35 %	47,972	1,152

Übersicht

Bei der neuen Kategorie für 2021 liegt der Schwerpunkt auf Annahmen in Bezug auf Software-Updates, relevante Daten und CI/CD-Pipelines ohne Überprüfung der Integrität. Eine der am höchsten gewichteten Auswirkungen von Common Vulnerability and Exposures/Common Vulnerability Scoring System (CVE/CVSS) Daten. Zu den erwähnenswerten Common Weakness Enumerations (CWEs) gehören: CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-494: Download of Code Without Integrity Check und CWE-502: Deserialization of Untrusted Data.

Beschreibung

Software- und Datenintegritätsfehler beziehen sich auf Code und Infrastruktur, die keine Schutzmaßnahmen gegen Integritätsverletzungen bieten. Ein Beispiel hierfür ist, wenn eine Anwendung auf Plugins, Bibliotheken oder Module aus nicht vertrauenswürdigen Quellen, Repositories und Content Delivery Networks (CDNs) angewiesen ist. Eine unsichere CI/CD-Pipeline kann das Potenzial für unbefugten Zugriff, bösartigen Code oder Systemkompromittierung bieten. Schließlich enthalten viele Anwendungen heute eine automatische Update-Funktion, bei der Updates ohne ausreichende Integritätsprüfung heruntergeladen und auf die zuvor vertrauenswürdige Anwendung angewendet werden. Angreifende könnten ihre eigenen Updates hochladen, die dann auf alle Installationen verbreitet und ausgeführt werden. Ein weiteres Beispiel besteht darin, dass Objekte oder Daten in eine Struktur kodiert oder serialisiert werden, die Angreifende sehen und ändern können, und die durch eine unsichere Deserialisierung verwundbar sind.

Prävention und Gegenmaßnahmen

Verwenden Sie digitale Signaturen oder ähnliche Mechanismen, um sicherzustellen, dass die Software oder Daten aus der erwarteten Quelle stammen und nicht verändert wurden.
Stellen Sie sicher, dass Bibliotheken und Abhängigkeiten, wie z. B. npm oder Maven, vertrauenswürdige Repositories nutzen. Wenn Sie ein höheres Risikoprofil haben, sollten Sie in Erwägung ziehen, ein internes Repository zu hosten, das als vertrauenswürdig gilt und überprüft wurde.
Stellen Sie sicher, dass ein Software-Supply-Chain-Sicherheitstool wie OWASP Dependency Check oder OWASP CycloneDX verwendet wird, um zu überprüfen, dass Komponenten keine bekannten Schwachstellen enthalten.
Stellen Sie sicher, dass es einen Überprüfungsprozess für Code- und Konfigurationsänderungen gibt, um das Risiko zu minimieren, dass bösartiger Code oder bösartige Konfigurationen in Ihre Software-Pipeline eingeschleust werden.
Stelle Sie sicher, dass Ihre CI/CD-Pipeline über eine angemessene Trennung, Konfiguration und Zugriffskontrolle verfügt, um die Integrität des Codes zu gewährleisten, der den Build- und Bereitstellungsprozess durchläuft.
Stellen Sie sicher, dass unsignierte oder unverschlüsselte serialisierte Daten nicht an nicht vertrauenswürdige Clients ohne eine Form der Integritätsprüfung oder digitalen Signatur gesendet werden, um dadurch eine Manipulation oder ein erneutes Versenden der serialisierten Daten zu erkennen.

Beispielhafte Angriffsszenarien

Szenario Nr. 1: Update ohne Signierung: Viele Heimrouter, Set-Top-Boxen, Geräte-Firmware und Andere verifizieren Updates nicht über signierte Firmware. Unsignierte Firmware ist ein wachsendes Ziel für Angreifende, und es wird erwartet, dass es in Zukunft noch schlimmer werden wird. Dies ist besonders besorgniserregend, da es in vielen Fällen keinen anderen Mechanismus zur Behebung gibt, als die Fehler in einer zukünftigen Version zu beheben und zu warten, bis die vorherigen Versionen veraltet sind.

Szenario #2 SolarWinds bösartiges Update: Nationalstaaten sind dafür bekannt, dass sie Update-Mechanismen angreifen. Ein bemerkenswerter Angriff war vor kurzem der SolarWinds-Orion-Angriff. Das Unternehmen, das die Software entwickelt, verfügte über sichere Build- und Update-Integritätsprozesse. Dennoch konnten diese unterwandert werden, und das Unternehmen verteilte über mehrere Monate hinweg ein sehr gezieltes bösartiges Update an mehr als 18.000 Organisationen, von denen etwa 100 betroffen waren. Dies ist eine der weitreichendsten und bedeutendsten Sicherheitsverletzungen dieser Art in der Geschichte.

Szenario #3 Unsichere Deserialisierung: Eine React-Anwendung ruft eine Reihe von Spring Boot Microservices auf. Als funktionale Programmierer versuchten sie sicherzustellen, dass ihr Code unveränderlich ist. Die Lösung, die sie gefunden haben, besteht darin, den Sitzungszustand zu serialisieren und ihn mit jeder Anfrage hin und her zu schicken. Eine angreifende Person bemerkt die "`rO0" Java-Objektsignatur (in base64) und verwendet das Java Serial Killer-Tool, um Remote-Code-Ausführung auf dem Anwendungsserver zu erlangen.