OWASP Top Ten 2017 (de)

A6:2017-Sicherheitsrelevante Fehlkonfiguration

 Languages: en [de]
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch		 Ausnutzbarkeit: 3 Verbreitung: 3 Auffindbarkeit: 3 technisch: 2 Geschäftl. ?
Angreifer versuchen oft, ungepatchte Schwachstellen, Standard-Konten, ungenutzte (Beispiel-)Seiten, ungeschützte Dateien etc. auszunutzen, um einen unerlaubten Zugriff oder Informationen über das System zu erlangen.
Sicherheitsrelevante Fehlkonfiguration kann auf jeder Ebene der Anwendung, einschließlich der Netzwerkdienste, Plattform, Web- und Anwendungsserver, Datenbank, Frameworks, Anwendungscode, vorinstallierte virtuelle Maschinen und Container oder Speicher vorkommen.
Automatisierte Scanner können oft Fehlkonfigurationen, Standard-Konten oder -Konfigurationen, nicht benötigte Dienste, Kompatibilitäten usw. erkennen.
Diese Fehler geben Angreifern häufig unautorisierten Zugriff auf Systemdaten oder -funktionalitäten. Manchmal führen sie zur kompletten Kompromittierung des Zielsystems.
Die Auswirkungen auf das Unternehmen hängen vom Schutzbedarf der Anwendung und ihrer Daten ab.
Ist die Anwendung verwundbar?
Die Anwendung könnte in folgenden Fällen verwundbar sein:
* Mangelhafte Sicherheitshärtung des Anwendungsstacks oder ungeeignet konfigurierte Berechtigungen von Clouddiensten.
* Nicht benötigte Features sind aktiviert oder installiert (z.B. unnötige Ports, Dienste, Seiten, Nutzer oder Rechte).
* Standardnutzer und -passwörter sind aktiviert, bzw. unverändert.
* Die Fehlerbehandlung gibt Stack-Traces oder andere interne technische Fehlermeldungen an den Nutzer 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 A9:2017-Nutzung von Komponenten mit bekannten Schwachstellen).
Ohne einen abgestimmten und reproduzierbaren Prozess sind Systeme einem höheren Risiko ausgesetzt!
Wie kann ich das verhindern?
Sichere Installationsprozesse sind zu implementieren:
* Ein wiederholbarer Härtungsprozess, der eine schnelle und einfache Verteilung einer neuen, abgesicherten Umgebung erlaubt. Entwicklungs-, QA- und Produktionsumgebungen sollten identisch konfiguriert sein, mit unterschiedlichen Passwörtern je Umgebung. Der Prozess sollte automatisiert sein, um den nötigen Aufwand bei Erstellung einer neuen, sicheren Umgebung zu minimieren.
* Eine Minimalplattform ohne unnötige Features, Komponenten, Dokumentation und Beispiele. Entferne, bzw. Vermeide die Installation nicht benötigter Features und Frameworks.
* Review und Update der Konfigurationen entsprechend aller Sicherheitshinweise, Updates und Patches als Teil des präventiven CERT-Prozesses (siehe A9:2017-Nutzung von Komponenten mit bekannten Schwachstellen). Überprüfen Sie auch die Cloudspeicher-Rechte (z.B. S3-Bucket-Rechte).
* Eine segmentierte Anwendungsarchitektur, die eine effektive, sichere Trennung zwischen Komponenten oder Mandanten, unter Nutzung von Segmentierung, Containerisierung oder Cloud-Sicherheitsgruppen, gewährleistet.
* An den Client Sicherheitsdirektiven, z.B. Security Header senden.
* Ein automatisierter Prozess zum Verifizieren der Effektivität der Konfigurationen und Einstellungen in allen Umgebungen.
Mögliche Angriffsszenarien
Szenario 1: Der Anwendungsserver wird in der Produktion mit Beispielanwendungen installiert. Diese enthalten bekannte Sicherheitslücken, die Angreifer ausnutzen könnten um den Server zu kompromittieren. Im Fall einer Adminkonsole könnten unveränderte Standardpasswörter zu einer Übernahme durch einen Angreifer führen.

Szenario 2: Directory Listings wurden auf dem Server nicht deaktiviert. Ein Angreifer findet in einer Verzeichnisliste die kompilierten Javaklassen und lädt diese herunter zur Dekompilierung und Reverse Engineering des Codes, um diesen lesen zu können. Der Angreifer findet ernste Schwachstellen in der Zugriffskontrolle der Anwendung.

Szenario 3: Die Konfiguration des Anwendungsserver ermöglicht detaillierte Fehlermeldungen, z.B. Stack-Traces an den Nutzer.
Dies enthüllt möglicherweise sensitive Informationen oder grundlegende Fehler wie verwundbare Versionen von Komponenten.

Szenario 4: Ein Cloud-Dienst enthält Standardfreigaben, die aus dem Internet für andere Cloud-Nutzer erreichbar sind und ermöglicht dadurch Zugriff auf sensitive Daten in der Cloud.
Referenzen