A05:2021 – Sicherheitsrelevante Fehlkonfiguration

Beurteilungskriterien

Zugeordnete CWEs	Maximale Häufigkeit	Durchschn. Häufigkeit	Durchschn. Ausnutzbarkeit (gewichtet)	Durchschn. Auswirkungen (gewichtet)	Maximale Abdeckung	Durchschnittliche Abdeckung	Gesamtanzahl	CVEs insgesamt
20	19.84 %	4.51 %	8.12	6.56	89.58 %	44.84 %	208,387	789

Übersicht

Die Kategorie rückt auf von Platz 6 in der vorherigen Ausgabe: 90 % der Anwendungen wurden auf irgendeine Form von Fehlkonfiguration getestet, mit einer durchschnittlichen Inzidenzrate von 4 % und über 208.000 Vorkommen einer Common Weakness Enumeration (CWE) in dieser Risikokategorie. Angesichts der zunehmenden Verlagerung hin zu hoch konfigurierbarer Software ist es nicht verwunderlich, dass diese Kategorie aufsteigt. Bemerkenswerte enthaltene CWEs sind CWE-16 Configuration und CWE-611 Unproper Restriction of XML External Entity Reference.

Beschreibung

Die Anwendung besitzt möglicherweise Schwachstellen, wenn folgendes zutrifft:

Mangelhafte Sicherheitshärtung des Anwendungsstacks oder ungeeignet konfigurierte Berechtigungen auf Cloud-Diensten.
Nicht benötigte Features sind aktiviert oder installiert (z. B. unnötige Ports, Dienste, Seiten, Accounts oder Rechte).
Standardkonten und -passwörter sind aktiviert bzw. unverändert.
Die Fehlerbehandlung gibt Stack-Traces oder andere interne technische Fehlermeldungen an Anwendende preis.
Für aktualisierte Systeme sind die neuesten Sicherheitsfeatures deaktiviert oder nicht sicher konfiguriert.
Die Sicherheitseinstellungen in den Anwendungsservern und -frameworks (z. B. Struts, Spring, ASP.NET), Bibliotheken, Datenbanken etc. sind nicht auf sichere Werte gesetzt.
Der Server sendet keine Sicherheits-Header oder -Direktiven, bzw. diese sind nicht sicher konfiguriert.
Die Software ist veraltet oder verwundbar (siehe A06:2021-Unsichere oder veraltete Komponenten).

Ohne einen abgestimmten und reproduzierbaren Prozess zur sicheren Konfiguration sind Systeme einem höheren Risiko ausgesetzt!

Prävention und Gegenmaßnahmen

Es sollten sichere Installationsprozesse implementiert werden, darunter:

Ein wiederholbarer Härtungsprozess ermöglicht die schnelle und einfache Bereitstellung zusätzlicher Umgebungen, die entsprechend abgesichert sind. Entwicklungs-, Qualitätssicherungs- und Produktionsumgebungen sollten alle identisch konfiguriert sein, wobei in jeder Umgebung unterschiedliche Anmeldeinformationen verwendet werden sollten. Dieser Prozess sollte automatisiert werden, um den Aufwand für die Einrichtung einer neuen sicheren Umgebung zu minimieren.
Eine minimale Plattform ohne unnötige Funktionen, Komponenten, Dokumentation und Beispiele: Entfernen Sie Funktionen und Frameworks die Sie nicht verwenden oder installieren Sie diese erst gar nicht.
Überprüfen und Aktualisieren der Konfigurationen, die für alle Sicherheitshinweise, Updates und Patches im Rahmen des Patch-Verwaltungsprozesses geeignet sind (siehe A06:2021-Unsichere oder veraltete Komponenten). Überprüfen Sie die Cloud-Speicherberechtigungen (z. B. S3-Bucket-Berechtigungen).
Eine segmentierte Anwendungsarchitektur sorgt durch Segmentierung, Containerisierung oder Cloud-Sicherheitsgruppen (ACLs) für eine effektive und sichere Trennung zwischen Komponenten oder Mandanten.
Senden von Sicherheitsanweisungen an Clients, z. B. Sicherheits-Header.
Ein automatisierter Prozess zur Überprüfung der Wirksamkeit der Konfigurationen und Einstellungen in allen Umgebungen.

Beispielhafte Angriffsszenarien

Szenario Nr. 1: Der Anwendungsserver wird mit Beispielanwendungen geliefert, die nicht vom Produktionsserver entfernt wurden. Diese Beispielanwendungen weisen bekannte Sicherheitslücken auf, die Angreifende nutzen, um den Server zu gefährden. Angenommen, eine dieser Anwendungen ist die Admin-Konsole und die Standardkonten wurden nicht geändert. In diesem Fall meldet sich die angreifende Person mit Standardkennwörtern an und übernimmt die Kontrolle.

Szenario Nr. 2: Die Directory Listings wurden auf dem Server nicht deaktiviert. Angreifende entdecken, dass Verzeichnisse einfach aufgelistet werden können. Die angreifende Person findet die kompilierten Java-Klassen und lädt sie herunter, dekompiliert sie und betreibt Reverse Engineering, um den Code anzuzeigen. Dies ermöglicht das Findet eines schwerwiegenden Fehlers in der Zugriffskontrolle in der Anwendung.

Szenario Nr. 3: Die Konfiguration des Anwendungsservers ermöglicht die Rückgabe detaillierter Fehlermeldungen an Anwendende, z. B. Stack-Traces. Dadurch werden möglicherweise vertrauliche Informationen oder zugrunde liegende Fehler wie Komponentenversionen offengelegt, die bekanntermaßen anfällig sind.

Szenario Nr. 4: Ein Cloud-Dienstanbieter (CSP) enthält Standardfreigaben, die aus dem Internet für andere Cloud-Nutzende erreichbar sind und ermöglicht dadurch Zugriff auf sensitive Daten in der Cloud.