DevSecOps: Alte Sicherheitslücken mit neuen Tricks

Ursprünglich veröffentlicht auf DevOps.com.

In der Cybersicherheit sind wir oft wie Jäger. Unser Blick ist fest auf den Horizont gerichtet, immer auf der Suche nach der nächsten Sicherheitslücke (zusammen mit den richtigen Tools, Techniken und Taktiken, um sie zu schließen). Dieser zukunftsorientierte Fokus kann jedoch den überraschenden Effekt haben, dass unser allgemeines Sicherheitsbewusstsein schwindet und wir blind werden für tiefsitzende Gefahren, die überall lauern und die Angreifer nur allzu gerne ausnutzen.

Ich vergleiche moderne Cybersicherheit oft mit einer Kevlar-Weste. Die scheinbar ätherischen Eigenschaften von Kevlar können Hochgeschwindigkeitsgeschosse und alle Arten moderner, leistungsstarker Waffen abwehren. Das kann beim Träger ein Gefühl der Unverwundbarkeit erzeugen. Doch ein vergleichsweise uraltes Waffensystem wie Pfeil und Bogen, das erstmals um 1000 v. Chr. entwickelt wurde, kann diesen Schutz oft durchdringen. Ein scharfes Messer, wahrscheinlich die zweitälteste Waffe der Welt nach Steinen, kann Kevlar so leicht durchschneiden, als wäre es ein Baumwoll-Sweatshirt. Und dann ist da noch die Kleinigkeit, dass Kevlar nicht jeden einzelnen Millimeter des menschlichen Körpers schützen kann. Wenn ein Angreifer eine Lücke findet, um einen schädlichen Schlag zu versetzen, wird er das tun – genau wie bei kleinen, ausnutzbaren Bereichen in Software.

In der Cybersicherheit sind viele Unternehmen ähnlich anfällig für Fehler in Systemen, die acht oder zehn Jahre alt sind – was sie in der modernen Computerwelt fast schon für die Rente qualifiziert. Aber wenn Sie glauben, dass Fehler in diesen betagten Systemen harmlos sind, dann steht Ihnen wahrscheinlich der eine oder andere „Blue Screen of Death“ bevor.

Eine Schwachstelle für einen Veteranen

Eine der ältesten und am häufigsten verwendeten JavaScript-Bibliotheken ist jQuery, eine Open-Source-Ressource, die bei allem hilft – von der Ereignisbehandlung über das Durchlaufen und Manipulieren des DOM-Baums bis hin zur Erstellung von Animationen. Es ist ein echtes Arbeitstier, das seit vielen Jahren im Einsatz ist. Die Leute gehen davon aus, dass eine so etablierte Bibliothek gründlich geprüft wurde und alle Schwachstellen beseitigt sind.

Leider ist das nicht der Fall. Die meisten Anwendungen, die auf jQuery basieren, verwenden standardmäßig die Anweisungen der internen Bibliothek für die Authentifizierung. Bei Apache-Servern bedeutet dies beispielsweise die Überprüfung der .htaccess-Dateien. Nur wenige Entwickler, die Programme für Apache entwerfen, haben wahrscheinlich daran gedacht, sicherzustellen, dass Apache-Server-Updates .htaccess enthalten. Warum sollte Apache schließlich diese kritische Komponente entfernen, die seit Jahren ein Grundpfeiler der Sicherheit ist?

So seltsam es klingen mag, genau das hat Apache in Version 2.3.9 getan. Anscheinend verlangsamte die ständige Überprüfung der .htaccess-Konfigurationsdateien bei jedem Programmstart den Betrieb zu sehr. Das Entfernen verbesserte zwar die allgemeine Apache-Leistung, schuf aber auch eine Schwachstelle, von der die meisten nichts wussten. Wenn Entwickler nicht prüften, ob ihre Apps noch auf die .htaccess-Dateien zugreifen konnten, wurden die meisten Anfragen einfach ohne Prüfung akzeptiert.

Kürzlich entdeckten Experten diesen Fehler und stellten fest, dass er es unbefugten Benutzern ermöglichen würde, Shells oder fast jede Art von Code auf vermeintlich sicheren Systemen hochzuladen und auszuführen. Dies führte im Oktober zur Erstellung eines Schwachstellen-Alarms mit der Bezeichnung CVE-2018-9206. Doch die Leichtigkeit, mit der der Fehler von einem Sicherheitsforscher entdeckt wurde, deutet darauf hin, dass professionelle Hacker, deren einziges Ziel die Suche nach solchen Schwachstellen ist, ihn wahrscheinlich bereits entdeckt haben. Schließlich kam es trotz der Publicity, der Patches und Korrekturen nur wenige Wochen später zu einem ähnlichen Angriff mit großer Tragweite, bei dem Bitcoin-stehlende Malware auf eine beliebte NPM-Bibliothek losgelassen wurde, die wöchentlich millionenfach heruntergeladen wird.

Der Butler war's

Wie jQuery ist Jenkins ein Open-Source-Angebot und eines der beliebtesten seiner Art. Bei dem hilfreichen, dienerartigen Namen ist es nur logisch, dass Jenkins von Entwicklungsteams in vielen Branchen als Automatisierungsserver eingesetzt wird. Wenn Jenkins korrekt funktioniert, ist es ein äußerst hilfreiches Werkzeug. Neu entdeckte Schwachstellen und eine kürzlich aufgedeckte Krypto-Mining-Operation, die wirklich massiv ist, legen jedoch nahe, dass Jenkins auch viel Arbeit für die Bösewichte erledigte.

Eine der gefährlichsten Jenkins-Schwachstellen ist die Java-Deserialisierung, die als CVE-2017-1000353 bezeichnet wird. Es ist ein komplexer Angriff, der aber schon eine Weile existiert. Ein Angreifer muss zwei Anfragen senden. Die erste startet einen bidirektionalen Kanal zum Herunterladen, der vom Server zunächst abgelehnt wird. Die zweite Anfrage fügt jedoch einen Upload-Kanal hinzu, der eine Nutzlast mit den gewünschten Befehlen des Angreifers enthält und das Skript payload.jar verwendet. Sobald die zweite Anfrage gesendet wird, wird die Kommunikation auf ungepatchten Jenkins-Servern zugelassen.

Selbst auf gepatchten Servern existieren Exploits. Wenn Jenkins beispielsweise in einer Windows-Umgebung ausgeführt wird, verwendet es standardmäßig das Konto NT AUTHORITY\SYSTEM zur Autorisierung von Benutzern. Das ist gefährlich, da SYSTEM volle Berechtigungen auf Windows-Servern gewährt. Entwickler können das Berechtigungskonto ändern, tun dies aber oft nicht. Ihre Logik dahinter basiert auf der Tatsache, dass es Jenkins schon ewig gibt, weshalb man davon ausgeht, dass alle Schwachstellen längst gepatcht wurden.

Zuletzt nutzte ein Hacker diese alternden Jenkins-Schwachstellen, um mehrere Server zu kompromittieren. Das Ziel war es, auf jeder anfälligen Jenkins-Instanz, die sie finden konnten, ein Krypto-Mining-Programm zu installieren. Die Miner beanspruchten wertvolle Rechenressourcen für ihre ständige Suche nach Kryptowährung. Bisher haben sie etwa 10.800 Monero-Coins im Wert von fast 3,5 Millionen Dollar gefunden.

Was alt ist, ist wieder neu

In beiden Beispielen werden Schwachstellen von opportunistischen Angreifern auf Plattformen ausgenutzt, die viele für sicher halten. Auf der Verteidigungsseite führt der Mangel an sicherheitsbewusster Entwicklung dazu, dass diese Hacker alten Tricks neues Leben einhauchen. Und trotz einer neuen Erfolgswelle durch die Nutzung alternder Schwachstellen haben viele Unternehmen keinen Plan, um diesen Teufelskreis zu durchbrechen.

Nur weil etwas alt ist, heißt das nicht, dass es harmlos ist. Und nur weil gängige Bibliotheken und Ressourcen seit Jahren existieren, bedeutet das nicht, dass sie völlig sicher sind (zum Beispiel befasst sich der Punkt Nr. 9 in den aktuellen OWASP Top 10 mit der Verwendung von Komponenten mit bekannten Schwachstellen). Nur durch Sorgfalt und ständige Sicherheitsschulungen können wir uns nicht nur vor gefährlichen Bedrohungen schützen, die am Horizont auftauchen, sondern auch vor denen, die sich bereits heimtückisch in unserem eigenen Hinterhof eingenistet haben.