DevSecOps : les anciennes failles de sécurité continuent de poser des problèmes

Ursprünglich veröffentlicht am DevOps.com.

In der Cybersicherheit sind wir oft wie Jäger. Unsere Augen sind fest auf den Horizont gerichtet und suchen nach der nächsten Sicherheitslücke (zusammen mit den richtigen Designtools, Techniken und Taktiken, um sie zu verhindern). Diese vorausschauende Ausrichtung kann jedoch den überraschenden Effekt haben, dass sie unser allgemeines Sicherheitsbewusstsein dämpft und uns blind macht für tief sitzende Gefahren, die allgegenwärtig sind und die Angreifer nur allzu gerne ausnutzen.

Ich vergleiche moderne Cybersicherheit oft mit einer Kevlar-Rüstung. Die scheinbar ätherischen Eigenschaften von Kevlar können Geschosse mit hoher Geschwindigkeit und alle Arten moderner, mächtiger Waffen abwehren. Es kann sogar dazu führen, dass sich ein Träger einigermaßen unbesiegbar fühlt. Ein vergleichsweise altes Bogen- und Pfeilwaffensystem, das erstmals um 1000 v. Chr. hergestellt wurde, kann diesen Schutz jedoch oft durchdringen. Ein scharfes Messer, wahrscheinlich die zweitälteste Waffe der Welt hinter Steinen, kann Kevlar genauso leicht durchschneiden, als würde es ein Baumwoll-Sweatshirt zerfetzen. Und dann ist da noch das kleine Problem, dass Kevlar nicht in der Lage ist, jeden einzelnen Millimeter des menschlichen Körpers zu schützen. Wenn ein Angreifer eine Lücke findet, um ihm einen Schaden zuzufügen, wird er „wie kleine, ausnutzbare Bereiche in der Software“ vorgehen.

Im Bereich Cybersicherheit sind viele Unternehmen in ähnlicher Weise anfällig für Schwachstellen in Systemen, die acht oder zehn Jahre alt sind, was sie in modernen Computersystemen geradezu für eine Golduhr und eine Rente qualifiziert. Aber wenn Sie denken, dass Fehler in diesen älteren Systemen harmlos sind, dann haben Sie in Ihrer Zukunft wahrscheinlich den ein oder anderen blauen Bildschirm, auf dem Sie den Tod sehen werden.

Eine Sicherheitslücke 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 die Durchquerung und Manipulation von DOM-Bäumen bis hin zur Generierung von Animationen. Es ist ein ziemliches Arbeitstier und wird seit vielen Jahren verwendet. Die Leute gehen davon aus, dass die Bibliothek, weil sie zu diesem Zeitpunkt so etabliert ist, vollständig überprüft und alle Sicherheitslücken entfernt worden sein müssen.

Leider ist das nicht der Fall. Standardmäßig verwenden die meisten Anwendungen, die auf jQuery basieren, die Anweisungen der internen Bibliothek zur Authentifizierung. Bei Apache-Servern bedeutet dies beispielsweise, dass die .htaccess-Dateien überprüft werden. Nur wenige Entwickler, die Programme entwickeln, die Apache verwenden, dachten wahrscheinlich daran, zu überprüfen, ob die Apache-Serveraktualisierungen .htaccess enthielten. Warum sollte Apache schließlich diese kritische Komponente entfernen, die seit Jahren ein Grundpfeiler der Sicherheit ist?

So seltsam es auch scheinen mag, genau das hat Apache in Version 2.3.9 getan. Offenbar verlangsamte es die Dinge zu sehr, jedes Mal, wenn ein Programm ausgeführt werden musste, die Konfigurationsdateien von.htaccess überprüfen zu müssen. Es zu entfernen verbesserte die allgemeine Leistung von Apache, schuf aber auch eine Sicherheitslücke, von der die meisten Leute nichts wussten. Wenn sich Entwickler nicht die Mühe machen würden, zu überprüfen, ob ihre Apps die .htaccess-Dateien immer noch erreichen könnten, würden die meisten Anfragen einfach ohne Prüfung akzeptiert.

Vor Kurzem entdeckten Experten diesen Fehler und stellten fest, dass seine Verwendung 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 einer Schwachstellenwarnung mit der Bezeichnung CVE-2018-9206. Die Leichtigkeit, mit der die Sicherheitslücke von einem Sicherheitsforscher entdeckt wurde, deutet jedoch darauf hin, dass professionelle Hacker, deren einziges Ziel es ist, nach solchen Sicherheitslücken zu suchen, sie wahrscheinlich bereits entdeckt haben. Schließlich ereignete sich trotz der Öffentlichkeitsarbeit, der Patches und Fixes, die in der Folge veröffentlicht wurden, nur wenige Wochen später ein ähnlich starker Angriff, bei dem Bitcoin-diebende Malware wurde auf einer beliebten NPM-Lib veröffentlicht, die jede Woche von Millionen heruntergeladen wurde.

Der Butler hat es geschafft

Wie jQuery ist Jenkins ein Open-Source-Angebot und eines der beliebtesten seiner Art. Mit seinem hilfreichen Namen, der einem Diener ähnelt, macht es Sinn, dass Jenkins von Entwicklungsteams in vielen Branchen als Automatisierungsserver verwendet wird. Wenn Jenkins korrekt funktioniert, ist es ein äußerst hilfreiches Tool. Es wurden jedoch neu entdeckte Fehler und eine kürzlich aufgedeckte Krypto-Mining-Operation festgestellt das ist wirklich riesig im Maßstab, deutet darauf hin, dass Jenkins auch viel für die Bösewichte gearbeitet hat.

Eine der gefährlichsten Jenkins-Sicherheitslücken heißt Java-Deserialisierung. welches ist benannt als CVE-2017-1000353. Es ist ein komplexer Angriff, aber einer, den es schon eine Weile gibt. Ein Angreifer muss zwei Anfragen einreichen. 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 enthält, die der Angreifer wünscht, und verwendet das Skript payload.jar. Sobald die zweite Anfrage gesendet wurde, ist die Kommunikation auf ungepatchten Jenkins-Servern zulässig.

Selbst auf gepatchten Servern gibt es Exploits. Wenn Jenkins beispielsweise in einer Windows-Umgebung ausgeführt wird, verwendet es standardmäßig das Konto NT AUTHORITY\ SYSTEM, um Benutzer zu autorisieren. Dies ist gefährlich, da SYSTEM auf Windows-Servern volle Berechtigungen gewährt werden. Entwickler können das Autoritätskonto ändern, tun dies aber oft nicht. Ihre Logik, dies nicht zu tun, basiert auf der Tatsache, dass Jenkins schon immer da ist. Die Leute gehen also davon aus, dass alle Sicherheitslücken vor langer Zeit gepatcht wurden.

Zuletzt nutzte ein Hacker diese veralteten Jenkins-Sicherheitslücken, um mehrere Server zu kompromittieren. Das Ziel bestand darin, jeder anfälligen Jenkins-Instanz, die sie finden konnten, ein Crypto-Miner-Programm hinzuzufügen. Die Miner verbrauchten bei ihrer ständigen Suche nach Kryptowährung wertvolle Computerressourcen. Bisher haben sie gefunden haben ungefähr 10.800 Monero-Kryptomünzen mit einem Wert von fast 3,5 Millionen US-Dollar.

Was alt ist, ist wieder neu

In beiden Beispielen werden Sicherheitslücken von opportunistischen Angreifern auf Plattformen ausgenutzt, die viele Menschen für sicher halten. Auf der defensiven Seite ermöglicht das Fehlen sicherheitsbewusster Entwicklungen diesen Hackern, alten Tricks neues Leben einzuhauchen. Und trotz einer neuen Erfolgsrunde beim Ausnutzen veralteter Sicherheitslücken 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 schon seit Jahren gibt, heißt das nicht, dass sie absolut sicher sind (zum Beispiel widmet sich der neunte Eintrag in den aktuellen OWASP-Top-10 dem Umgang mit Verwendung von Komponenten mit bekannten Sicherheitslücken). Nur durch Fleiß und ständiges Sicherheitstraining können wir uns nicht nur vor gefährlichen Bedrohungen schützen, die sich am Horizont abzeichnen, sondern auch vor solchen, die sich bereits heimtückisch in unseren eigenen Hinterhöfen niedergelassen haben.