DevSecOps: Die alten Sicherheitsprobleme zeigen immer noch neue Tricks

Ursprünglich veröffentlicht auf DevOps.de.

In der Cybersicherheit sind wir oft wie Jäger. Unsere Augen sind fest auf den Horizont gerichtet, auf der Suche nach der nächsten bahnbrechenden Schwachstelle (zusammen mit den richtigen Design-Tools, Techniken und Taktiken, um sie zu stoppen). Dieser vorausschauende Fokus kann jedoch den überraschenden Effekt haben, dass er unser gesamtes Sicherheitsbewusstsein dämpft und uns für tief sitzende Gefahren blind macht, die überall existieren und die Angreifer nur allzu gerne ausnutzen.

Ich vergleiche moderne Cybersicherheit oft mit einer Kevlar-Panzerung. Die scheinbar ätherischen Eigenschaften von Kevlar können Hochgeschwindigkeitsgeschosse und alle Arten von modernen, leistungsstarken Waffen blockieren. Der Träger fühlt sich vielleicht sogar irgendwie unbesiegbar. Doch ein vergleichsweise altes Waffensystem aus Pfeil und Bogen, das erstmals um 1000 v. Chr. hergestellt wurde, kann diesen Schutz oft durchdringen. Ein scharfes Messer, die wahrscheinlich zweitälteste Waffe der Welt nach Steinen, kann Kevlar so leicht durchschneiden, als würde es ein Baumwollsweatshirt zerfetzen. Hinzu kommt, dass Kevlar nicht jeden einzelnen Millimeter des menschlichen Körpers schützen kann. Wenn ein Angreifer irgendeine Lücke finden kann, um einen schädlichen Schlag auszuführen, wird er "ähnlich wie kleine, ausnutzbare Bereiche in Software.

In der Cybersicherheit sind viele Organisationen ähnlich anfällig für Fehler auf Systemen, die acht oder zehn Jahre alt sind, was sie nach modernen Computerstandards geradezu für eine goldene Uhr und eine Rente qualifiziert. Aber wenn Sie glauben, dass Fehler auf diesen älteren Systemen harmlos sind, dann haben Sie wahrscheinlich einen blauen Bildschirm des Todes oder zwei in Ihrer Zukunft.

Eine Schwachstelle für einen Veteranen

Eine der ältesten und meistgenutzten JavaScript-Bibliotheken ist jQuery, eine Open-Source-Ressource, die bei allem hilft, von der Ereignisbehandlung über das Traversieren und Manipulieren des DOM-Baums bis hin zur Erzeugung von Animationen. Es ist ein ziemliches Arbeitspferd und wird schon seit vielen Jahren verwendet. Die Leute gehen davon aus, dass, weil die Bibliothek an diesem Punkt so etabliert ist, dass sie vollständig überprüft worden sein muss, mit allen Schwachstellen entfernt.

Leider ist dies nicht der Fall. Standardmäßig verwenden die meisten Anwendungen, die sich auf jQuery verlassen, die Anweisungen der internen Bibliothek zur Authentifizierung. Bei Apache-Servern bedeutet dies zum Beispiel, dass die .htaccess-Dateien überprüft werden. Nur wenige Entwickler, die Programme entwerfen, die Apache verwenden, haben wahrscheinlich daran gedacht, zu überprüfen, ob Apache-Server-Updates die .htaccess-Datei enthalten. Denn warum sollte Apache diese kritische Komponente entfernen, die seit Jahren ein Grundpfeiler der Sicherheit ist?

So seltsam es klingen mag, genau das hat der Apache in Version 2.3.9 getan. Offensichtlich verlangsamte die Tatsache, dass die .htaccess-Konfigurationsdateien jedes Mal überprüft werden mussten, wenn ein Programm ausgeführt werden sollte, den Prozess zu sehr. Das Entfernen der Datei verbesserte zwar die Gesamtleistung des Apache, schuf aber auch eine Sicherheitslücke, von der die meisten Leute nichts wussten. Wenn Entwickler sich nicht die Mühe machten, zu überprüfen, ob ihre Anwendungen die .htaccess-Dateien noch erreichen konnten, wurden die meisten Anfragen einfach ohne Prüfung akzeptiert.

Kürzlich entdeckten Experten diese Schwachstelle und stellten fest, dass ihre Nutzung es unbefugten Benutzern ermöglichen würde, Shells oder fast jede Art von Code auf vermeintlich sichere Systeme hochzuladen und auszuführen. Dies führte im Oktober zur Erstellung einer Schwachstellenwarnung mit der Bezeichnung CVE-2018-9206. Doch die Leichtigkeit, mit der die Schwachstelle von einem Sicherheitsforscher entdeckt wurde, lässt vermuten, dass professionelle Hacker, deren einziges Ziel es ist, nach Schwachstellen wie dieser zu suchen, sie wahrscheinlich bereits entdeckt haben. Denn trotz der öffentlichen Aufmerksamkeit, der Patches und Fixes, die in der Folgezeit veröffentlicht wurden, gab es nur wenige Wochen später einen ähnlich folgenschweren Angriff, bei dem Bitcoin-diebische Malware auf eine beliebte NPM-Lib losgelassen wurde, die jede Woche von Millionen heruntergeladen wird.

Der Butler war's

Wie jQuery ist auch Jenkins ein Open-Source-Angebot und eines der beliebtesten seiner Art. Mit seinem hilfreichen, dienstbotenähnlichen Namen macht es Sinn, dass Jenkins als Automatisierungsserver von Entwicklungsteams in vielen Branchen eingesetzt wird. Wenn Jenkins korrekt funktioniert, ist es ein äußerst hilfreiches Tool. Neu entdeckte Schwachstellen und eine kürzlich aufgedeckte Krypto-Mining-Operation , die wirklich massive Ausmaße hat, lassen jedoch vermuten, dass Jenkins auch eine Menge Arbeit für die Bösewichte geleistet hat.

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

Selbst auf gepatchten Servern gibt es Sicherheitslücken. Wenn Jenkins beispielsweise in einer Windows-Umgebung ausgeführt wird, verwendet es standardmäßig das NT-Konto AUTHORITY\SYSTEM, um Benutzer zu autorisieren. Dies ist gefährlich, da SYSTEM auf Windows-Servern volle Berechtigungen erhält. Entwickler können das Autoritätskonto ändern, tun dies aber oft nicht. Die Logik, dies nicht zu tun, basiert auf der Tatsache, dass es Jenkins schon ewig gibt, so dass man davon ausgeht, dass etwaige Schwachstellen schon vor langer Zeit gepatcht worden sind.

Vor kurzem hat ein Hacker diese veralteten Jenkins-Schwachstellen genutzt, um mehrere Server zu kompromittieren. Das Ziel war das Hinzufügen eines Krypto-Miner-Programms auf jeder verwundbaren Jenkins-Instanz, die sie finden konnten. Die Miner beanspruchten wertvolle Rechenressourcen auf ihrer ständigen Suche nach Kryptowährung. Bisher haben sie etwa 10.800 Monero-Kryptomünzen gefunden, mit einem Wert von fast 3,5 Millionen US-Dollar.

Was alt ist, ist wieder neu

In beiden Beispielen werden Schwachstellen von opportunistischen Angreifern auf Plattformen ausgenutzt, die viele Menschen für sicher halten. Auf der defensiven Seite erlaubt der Mangel an sicherheitsbewusster Entwicklung diesen Hackern, alten Tricks neues Leben einzuhauchen. Und trotz einer neuen Runde von Erfolgen mit veralteten Schwachstellen haben viele Unternehmen keinen Plan, um diesen Teufelskreis zu stoppen.

Nur weil etwas alt ist, heißt das nicht, dass es harmlos ist. Und nur weil es gängige Bibliotheken und Ressourcen seit Jahren gibt, heißt das noch lange nicht, dass sie absolut sicher sind (der Eintrag Nr. 9 in der aktuellen OWASP-Top-10 widmet sich zum Beispiel dem Umgang mit " Using Components With Known Vulnerabilities"). Nur durch Fleiß und ständiges Sicherheitstraining können wir uns nicht nur vor gefährlichen Bedrohungen schützen, die über den Horizont kriechen, sondern auch vor solchen, die sich bereits heimtückisch in unseren eigenen Hinterhöfen eingenistet haben.