Germany/Projekte/Top 10 fuer Entwickler-2013/A9-Benutzen von Komponenten mit bekannten Schwachstellen

Einige verwundbare Software-Komponenten (z.B. Bibliotheken von Frameworks) können von Tools erkannt und automatisch ausgenutzt werden. Dadurch steigt die Zahl der Bedrohungsquellen ins Unermessliche. Ein Angreifer erkennt Komponenten mit Schwachstellen mittels Scan, oder manueller Analyse. Er passt den Exploit an und führt den Angriff aus. Bei tief eingebetteten Komponenten ist dies schwieriger. So gut wie jede Anwendung ist von diesem Problem betroffen, da die meisten Entwicklungs-Teams wenig darauf achten, dass die benutzten Komponenten bzw. Bibliotheken aktuell sind. Häufig kennen sie nicht einmal alle Komponenten, oder machen sich keine Gedanken über deren Version. Die rekursive Abhängigkeit von weiteren Bibliotheken verschlechtert die Situation weiter. Die ganze Bandbreite von Schwachstellen ist möglich, inkl. Injection, Fehler in der Zugriffskontrolle, XSS usw. Die Auswirkungen können von minimal bis hin zur vollständigen Übernahme des Servers und der Daten reichen. Betrachten Sie was jede einzelne Lücke der Anwendung für Ihren Geschäftsbetrieb bedeuten kann. Es kann vollkommen harmlos bis hin zu existenzbedrohend sein.

Die durch Schwachstellen in Komponenten verursachten Lücken können von minimalen Risiken bis zu ausgeklügelter Malware führen, die für gerichtete Angriffe geeignet ist. Die Komponenten laufen meist mit allen Anwendungsrechten, wodurch ein Mangel in jeder Komponente schwerwiegend sein kann. Folgende verwundbare Komponenten wurden 22 Millionen Mal in 2011 heruntergeladen:


 * Apache CXF Authentication Bypass – Durch das Fehlen eines Identifikations-Tokens, konnten Angreifer beliebige Web-Services aufrufen (Apache CXF ist ein Web-Service-Framework, nicht zu verwechseln mit dem Apache Application Server).
 * Spring Remote Code Execution – Der Missbrauch der ‘Expression Language‘ in Spring ermöglichte Angreifern das Ausführen von beliebigem Code auf dem Server.

Jede Anwendung, die eine der beiden Bibliotheken benutzt, ist angreifbar, da sie beide direkt von Benutzern ansprechbar sind. Bei anderen Bibliotheken kann dies schwieriger sein.

Eine Option wäre, nur selbstgeschriebene Komponenten zu benutzen. Dies ist jedoch nicht sehr realistisch. Die meisten Framework-Projekte bringen keine Sicherheits-Patches für alte Versionen heraus. Meist werden die Lücken einfach in der nächsten Version behoben. Deshalb ist es sehr wichtig, diese neuen Versionen einzusetzen.

Software-Projekte sollten folgende Prozesse etabliert haben:
 * 1) Übersicht aller Komponenten und Versionen, die Sie direkt oder indirekt benutzen (z.B. Versions-Plugin).
 * 2) Laufendes Beobachten der Sicherheit dieser Komponenten mithilfe aktueller, frei zugänglichen Datenbanken, Mailing-Listen der Projekte und von Sicherheitsseiten.
 * 3) Entwickeln Sie Richtlinien zum Einsatz von Komponenten, für die Entwicklung von Software, das Durchführen von Sicherheitstests und akzeptable Lizenzbedingungen.
 * 4) Ggf. sollten Sie erwägen, Sicherheitsschichten einzuziehen, die Ihre Komponenten weiter härten (z.B. unbenutzte Funktionen sperren, oder Lücken schließen).

= JAVA =

Erkennen aller verwendeten Software-Komponenten
Verschaffen Sie sich einen Überblick über alle, vom Programm benutzten Software-Komponenten, deren Abhängigkeiten (rekursive Abfrage der benutzten Komponenten), sowie den Versionsständen. Beispiele für Tools, die Sie dabei unterstützen:
 * OWASP Dependency Check
 * Versions-Plugin für Maven
 * weitere kommerzielle Produkte: vgl Top10-Mail-Liste

Sicherheits-(CERT-)Meldungen für die verwendeten Versionen prüfen
Um herauszufinden, ob diese Versionen von Schwachstellen betroffen sind, ist es notwendig, die oben genannten Schwachstellen-Datenbanken regelmäßig, in kurzen Abständen zu durchsuchen, sowie sich mithilfe von Mailing-Listen und weiteren Meldungen zeitnah über mögliche Lücken zu informieren.

Am einfachsten geht dies mithilfe von Tools: Falls eine benutzte Komponente verwundbar ist, sollten Sie genau prüfen, ob Ihre Anwendung verwundbare Teile der Komponente nutzt und ob der Fehler Auswirkungen hat, um die Sie sich kümmern müssen. Verwenden des OWASP-Plugins im Maven-Build (pom.xml):
 * OWASP Dependency Check


 * org.owasp
 * dependency-check-maven
 * RELEASE
 * org.owasp
 * dependency-check-maven
 * RELEASE

Anmerkung: Theoretisch sollte es einfach sein, herauszufinden, ob die Anwendung verwundbare Komponenten, oder Bibliotheken benutzt. Leider enthalten Berichte über Sicherheitslücken kommerzieller oder von Open-Source-Software nicht immer automatisch auswertbare, exakte Versions-Angaben der verwundbaren Komponenten. Ferner benutzen nicht alle Bibliotheken ein verständliches Versionsnummerierungs-Schema. Darüber hinaus werden nicht alle Schwachstellen an zentrale Schwachstellen-Datenbanken, wie CVE und NVD gemeldet.

Entwickeln Sie Ihre Richtlinien zum Einsatz von Software-Komponenten
Um die Anzahl der, zu prüfenden Software-Komponenten und deren Versionen handhabbar zu halten, empfiehlt es sich, eine eigene Richtlinie dazu zu erstellen und durchzusetzen. Im Idealfall stellen Sie Ihren Entwicklern für bestimmte Aufgaben freigegebene Software-Komponenten (z.B. Bibliotheken) zur Verfügung.


 * OWASP Dependency Check
 * OWASP Good Component Practices Project


 * Versions-Plugin für Maven
 * The Unfortunate Reality of Insecure Libraries
 * Open Source Software Security
 * Addressing Security Concerns in Open Source Components
 * MITRE Common Vulnerabilities and Exposures
 * Beispiel einer 'Mass Assignment'-Schwachstelle, die inzwischen in ActiveRecord, ein 'Ruby on Rails-GEM', beboben wurde

= PHP =

Tbd
tbd '''tbd

Tbd
'''tbd
 * '''tbd
 * '''tbd

Tbd
'''tbd
 * '''tbd
 * '''tbd


 * tbd !!


 * tbd!!

= .NET =

Tbd
tbd '''tbd

Tbd
'''tbd
 * '''tbd
 * '''tbd

Tbd
'''tbd
 * '''tbd
 * '''tbd


 * OWASP SafeNuGet (für .NET Bibliotheken durch NuGet)
 * OWASP Dependency Check (für Java, ...)
 * OWASP Good Component Practices Project


 * Versions-Plugin für Maven
 * The Unfortunate Reality of Insecure Libraries
 * Open Source Software Security
 * Addressing Security Concerns in Open Source Components
 * MITRE Common Vulnerabilities and Exposures
 * Beispiel einer 'Mass Assignment'-Schwachstelle, die inzwischen in ActiveRecord, ein 'Ruby on Rails-GEM', beboben wurde