A08:2025 Fehler bei der Software- oder Datenintegrität

Hintergrund.

Fehler bei der Software- oder Datenintegrität verbleibt auf Platz #8, mit einer leichten, klarstellenden Namensänderung von „Fehlern bei der Software und Datenintegrität". Diese Kategorie konzentriert sich auf das Versäumnis, Vertrauensgrenzen einzuhalten und die Integrität von Software, Code und Datenartefakten auf einer niedrigeren Ebene als Software Supply Chain Failures zu überprüfen. Der Schwerpunkt liegt auf Annahmen in Bezug auf Software-Updates und kritische Daten, ohne die Integrität zu überprüfen. Zu den erwähnenswerten Common Weakness Enumerations (CWEs) gehören CWE-829: Inclusion of Functionality from Untrusted Control Sphere, CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes und CWE-502: Deserialization of Untrusted Data.

Punktetabelle.

Zugeordnete CWEs	Max. Häufigkeit	Durchschn. Häufigkeit	Max. Abdeckung	Durchschn. Abdeckung	Durchschn. gewichtete Ausnutzbarkeit	Durchschn. gewichtete Auswirkung	Gesamtanzahl	Summe CVEs
14	8.98%	2.75%	78.52%	45.49%	7.11	4.79	501,327	3,331

Beschreibung.

Software- und Datenintegritätsfehler beziehen sich auf Code und Infrastruktur, die keinen Schutz dagegen bieten, dass ungültiger oder nicht vertrauenswürdiger Code oder Daten als vertrauenswürdig und gültig behandelt werden. 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. Ein weiteres Beispiel ist eine CI/CD-Pipeline, die Code oder Artefakte aus nicht vertrauenswürdigen Quellen bezieht und/oder diese vor der Verwendung nicht überprüft (z. B. durch Prüfung der Signatur oder eines ähnlichen Mechanismus). 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. Angreifer:innen 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 Angreifer:innen 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, ausschließlich 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 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 von nicht vertrauenswürdigen Clients empfangen und anschließend ohne eine Form der Integritätsprüfung oder digitalen Signatur verwendet werden, um Manipulation oder ein erneutes Einspielen der serialisierten Daten zu erkennen.

Beispielhafte Angriffsszenarien.

Szenario Nr. 1 – Einbindung von Web-Funktionalität aus einer nicht vertrauenswürdigen Quelle: Ein Unternehmen nutzt einen externen Dienstleister für Support-Funktionalität. Der Bequemlichkeit halber wurde ein DNS-Mapping von myCompany.SupportProvider.com auf support.myCompany.com eingerichtet. Das bedeutet, dass alle Cookies – einschließlich Authentifizierungs-Cookies –, die für die Domain myCompany.com gesetzt wurden, nun an den Support-Anbieter gesendet werden. Jede Person mit Zugang zur Infrastruktur des Support-Anbieters kann die Cookies aller Nutzer:innen stehlen, die support.myCompany.com besucht haben, und einen Session-Hijacking-Angriff durchführen.

Szenario Nr. 2 – Update ohne Signierung: Viele Heimrouter, Set-Top-Boxen, Geräte-Firmware und andere Systeme überprüfen Updates nicht anhand signierter Firmware. Unsignierte Firmware wird zunehmend zum Angriffsziel und es ist davon auszugehen, dass sich dies weiter verschlechtern wird. Dies ist besonders problematisch, da es häufig keinen Mechanismus zur Behebung gibt, außer einen Fix in einer zukünftigen Version bereitzustellen und zu warten, bis ältere Versionen nicht mehr verwendet werden.

Szenario Nr. 3 – Verwendung eines Pakets aus einer nicht vertrauenswürdigen Quelle: Ein:e Entwickler:in hat Schwierigkeiten, die aktualisierte Version eines benötigten Pakets zu finden, und lädt es daher nicht vom regulären, vertrauenswürdigen Paketmanager herunter, sondern von einer Website im Internet. Das Paket ist nicht signiert, sodass keine Möglichkeit besteht, die Integrität sicherzustellen. Das Paket enthält bösartigen Code.

Szenario Nr. 4 – Unsichere Deserialisierung: Eine React-Anwendung ruft eine Reihe von Spring-Boot-Microservices auf. Als funktionale Programmierer:innen haben sie versucht, ihren Code unveränderlich zu gestalten. Die gewählte Lösung besteht darin, den Nutzerzustand zu serialisieren und mit jeder Anfrage hin- und herzuschicken. Ein:e Angreifer:in erkennt die Java-Objektsignatur „rO0" (in Base64) und nutzt den Java Deserialization Scanner, um Remote Code Execution auf dem Anwendungsserver zu erlangen.