OWASP Top Ten 2017 (de)

A9:2017-Nutzung von Komponenten mit bekannten Schwachstellen.

 Languages: en [de]
Bedrohungsquellen / Angriffsvektoren Schwachstellen Auswirkungen
Anw.-
spezifisch		 Ausnutzbarkeit: 2 Verbreitung: 3 Auffindbarkeit: 2 technisch: 2 Geschäftl. ?
Für viele bekannte Schwachstellen ist es sehr einfach, existierende fertige Angriffe zu finden, für andere jedoch ist es erforderlich, unter gezieltem Aufwand einen maßgeschneiderten Angriffscode zu entwickeln.
Dieses Problem ist sehr weit verbreitet.
Komponentenlastige Entwicklungspattern können dazu führen, dass Entwicklerteams nicht einmal mehr verstehen, welche Komponenten sie in ihrer Applikation oder API benutzen, geschweige denn diese aktuell halten können.
Es existieren einige Scanner, wie zum Beispiel retire.js, die bei der Erkennung helfen. Das Ermitteln der Ausnutzbarkeit erfordert jedoch zusätzlichen Aufwand.
Während einige bekannte Schwachstellen zu geringen Auswirkungen führten, basieren einige der größten bisherigen Sicherheitsvorfälle auf dem Ausnutzen bekannter Schwachstellen in benutzen Komponenten.
Abhängig von den zu beschützenden Assets sollte dieses Risiko ggf. ganz oben auf der Liste stehen.
Ist die Anwendung verwundbar?
Die Anwendung ist wahrscheinlich verwundbar, wenn:
* keine Kenntnis über Versionen der in der Anwendung benutzten Komponenten (sowohl client- als auch serverseitig) besteht. Dies beinhaltet sowohl direkte als auch indirekte, verschachtelte Abhängigkeiten.
* verwendete Software verwundbar, nicht mehr unterstützt oder veraltet ist. Dies beinhaltet das Betriebssystem, den Web-/Applikationsserver, das Datenbankmanagementsystem (DBMS), Anwendungen, APIs und alle verwendeten Komponenten, Laufzeitumgebungen sowie Bibliotheken.
* Schwachstellenscans nicht regelmäßig durchgeführt werden und sicherheitsrelevante, die benutzten Komponenten betreffende Bulletins nicht abonniert sind.
* die zugrundeliegende Plattform, das Framework und die Abhängigkeiten nicht risikobasiert und rechtzeitig repariert oder geupgradet werden. Dies passiert in der Regel in Umgebungen in denen Patchen eine monatliche oder quartalsweise Tätigkeit und einer Änderungskontrolle unterliegt. Dies setzt die Organisation unnötigerweise über Tage oder Monate dem Risiko von bereits gepatchten Schwachstellen aus.
* Tests für Kompatibilität von geupdateter oder gepatchter Bibliotheken durch die Entwickler nicht durchgeführt werden.
* die Komponenten nicht sicher konfiguriert werden (siehe A6:2017-Sicherheitsrelevante Fehlkonfiguration).
Wie kann ich das verhindern?
Es sollte ein Patchmanagementprozess vorhanden sein:
* Entferne unbenutzte Abhängigkeiten sowie unnötige Funktionen, Komponenten, Dateien und Dokumentationen.
* Fortlaufendes Inventarisieren der Versionen aller client- und server-seitig benutzten Komponenten (z.B. Frameworks, Bibliotheken) sowie deren Abhängigkeiten unter Nutzung von Tools wie versions, DependencyCheck, retire.js, etc. Fortlaufendes Auswerten von Quellen für Schwachstellen in Komponenten wie CVE und NVD. Einsatz von Tools zur automatisieren Analyse der Softwarebestandteile. Bezug von CERT- und Herstellermeldungen über Schwachstellen der Komponenten.
* Komponenten sollten ausschließlich von offiziellen Quellen über sichere Verbindungen bezogen werden. Signierte Pakete sollten bevorzugt werden, um die Gefahr der Nutzung einer modifizierten bösartigen Komponente zu verringern.
* Überwachung zum Identifizieren von Bibliotheken und Komponenten, die nicht gewartet werden oder keine Sicherheitsupdates für ältere Versionen bereitstellen. Sollte Patchen nicht möglich sein, sollte geprüft werden, einen virtuellen Patch zu erstellen, um die gefundene Schwachstelle zu überwachen und um Angriffe zu entdecken und zu verhindern.
Jede Organisation muss sicherstellen, dass ein fortlaufender Plan zur Überwachung, Bewertung und Anwendung von Updates oder Konfigurationsänderungen für die gesamte Lebenszeit einer Applikation oder des Portfolios besteht.
Mögliche Angriffsszenarien
Szenario 1: Komponenten laufen typischerweise unter den selben Rechten wie die Anwendung selbst. Daher kann ein Fehler in einer beliebigen Komponente schwerwiegende Folgen haben. Solche Schwachstellen können sowohl durch ein Versehen (z.B. Programmierfehler) als auch vorsätzlich (z.B. Backdoor) in eine Komponente gelangen.
Einige gefundene und ausnutzbare Beispiele sind:
* CVE-2017-5638, eine Remote Code Execution Schwachstelle in Struts 2, die den Angreifer ermächtigt beliebigen Code auf dem Server auszuführen, wurde für einige erhebliche Sicherheitsvorfälle verantwortlich gemacht.
* Obwohl das Patchen von Geräten des internet of things (IoT)oft nur sehr schwierig oder unmöglich ist, kann dies sehr wichtig sein (z.B. biomedizinische Geräte).
Es existieren automatisierte Tools, die einem Angreifer helfen ungepatchte oder fehlkonfigurierte Systeme zu finden. Zum Beispiel kann die IoT-Suchmaschine Shodan benutzt werden, um Geräte zu finden, die immer noch für die im April 2014 gepatchte Heartbleed-Schwachstelle verwundbar sind.
Referenzen