DevSecOps：旧的安全漏洞仍在发挥新作用
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 sie es unbefugten Nutzern ermöglichen würde, Shells oder fast jede Art von Code auf vermeintlich sichere Systeme hochzuladen und auszuführen. Daraufhin wurde im Oktober eine Warnung vor der Sicherheitslücke mit der Bezeichnung CVE-2018-9206 veröffentlicht. Die Leichtigkeit, mit der die Schwachstelle von einem Sicherheitsforscher entdeckt wurde, deutet jedoch darauf hin, 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 Korrekturen, die daraufhin veröffentlicht wurden, kam es nur wenige Wochen später zu einem ä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.
在网络安全领域，我们通常就像猎人一样。我们的眼睛紧紧地注视着地平线，正在寻找下一个突破漏洞。但是，这种前瞻性的关注可能会产生令人惊讶的效果，削弱我们的整体安全意识。
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Demo buchen
Vorstandsvorsitzender, Chairman und Mitbegründer
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
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 sie es unbefugten Nutzern ermöglichen würde, Shells oder fast jede Art von Code auf vermeintlich sichere Systeme hochzuladen und auszuführen. Daraufhin wurde im Oktober eine Warnung vor der Sicherheitslücke mit der Bezeichnung CVE-2018-9206 veröffentlicht. Die Leichtigkeit, mit der die Schwachstelle von einem Sicherheitsforscher entdeckt wurde, deutet jedoch darauf hin, 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 Korrekturen, die daraufhin veröffentlicht wurden, kam es nur wenige Wochen später zu einem ä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.
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 sie es unbefugten Nutzern ermöglichen würde, Shells oder fast jede Art von Code auf vermeintlich sichere Systeme hochzuladen und auszuführen. Daraufhin wurde im Oktober eine Warnung vor der Sicherheitslücke mit der Bezeichnung CVE-2018-9206 veröffentlicht. Die Leichtigkeit, mit der die Schwachstelle von einem Sicherheitsforscher entdeckt wurde, deutet jedoch darauf hin, 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 Korrekturen, die daraufhin veröffentlicht wurden, kam es nur wenige Wochen später zu einem ä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.
Klicken Sie auf den folgenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Bericht anzeigenDemo buchen
Vorstandsvorsitzender, Chairman und Mitbegründer
Pieter Danhieux ist ein weltweit anerkannter Sicherheitsexperte mit mehr als 12 Jahren Erfahrung als Sicherheitsberater und 8 Jahren als Principal Instructor für SANS, wo er offensive Techniken lehrt, wie man Organisationen, Systeme und Einzelpersonen auf Sicherheitsschwächen hin untersucht und bewertet. Im Jahr 2016 wurde er als einer der "Coolest Tech People in Australia" (Business Insider) ausgezeichnet, erhielt die Auszeichnung "Cyber Security Professional of the Year" (AISA - Australian Information Security Association) und besitzt die Zertifizierungen GSE, CISSP, GCIH, GCFA, GSEC, GPEN, GWAPT, GCIA.
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 sie es unbefugten Nutzern ermöglichen würde, Shells oder fast jede Art von Code auf vermeintlich sichere Systeme hochzuladen und auszuführen. Daraufhin wurde im Oktober eine Warnung vor der Sicherheitslücke mit der Bezeichnung CVE-2018-9206 veröffentlicht. Die Leichtigkeit, mit der die Schwachstelle von einem Sicherheitsforscher entdeckt wurde, deutet jedoch darauf hin, 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 Korrekturen, die daraufhin veröffentlicht wurden, kam es nur wenige Wochen später zu einem ä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.
Verzeichnis
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior kann Ihrem Unternehmen dabei helfen, Code während des gesamten Softwareentwicklungszyklus zu schützen und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, Chief Information Security Officer oder in einem anderen sicherheitsrelevanten Bereich tätig sind – wir können Ihrem Unternehmen dabei helfen, die mit unsicherem Code verbundenen Risiken zu minimieren.
Demo buchen下载Ressourcen, die Ihnen den Einstieg erleichtern
Themen und Inhalte der Sicherheitsschulung
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sich an die sich wandelnde Softwareentwicklungslandschaft anzupassen und gleichzeitig Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis hin zu XQuery-Injection und sind für verschiedene Positionen geeignet, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA-Mitarbeitern. Verschaffen Sie sich einen ersten Überblick nach Themen und Rollen und erfahren Sie, was unser Inhaltsverzeichnis zu bieten hat.
Die Kamer van Koophandel setzt Maßstäbe für entwicklergesteuerte Sicherheit in großem Maßstab
Die Kamer van Koophandel berichtet, wie sie sicheres Codieren durch rollenbasierte Zertifizierungen, Trust Score-Benchmarking und eine Kultur der gemeinsamen Verantwortung für Sicherheit in die tägliche Entwicklungsarbeit integriert hat.
%20(1).avif)
.avif)
Bedrohungsmodellierung mit KI: So wird jeder Entwickler zum Bedrohungsmodellierer
Sie werden besser gerüstet sein, um Entwicklern dabei zu helfen, Ideen und Techniken zur Bedrohungsmodellierung mit den KI-Tools zu kombinieren, die sie bereits verwenden, um die Sicherheit zu erhöhen, die Zusammenarbeit zu verbessern und von Anfang an widerstandsfähigere Software zu entwickeln.
Ressourcen, die Ihnen den Einstieg erleichtern
Cybermon ist zurück: Die KI-Mission zum Besiegen des Bosses ist jetzt auf Abruf verfügbar.
Cybermon 2025: Der Kampf gegen den Boss hat nun in SCW ganzjährig begonnen. Der Kampf um die Sicherheit von KI/LLM auf Stammesebene, die Entwicklung von Sicherheits-KI wird durch groß angelegte Modelle verstärkt.
Auslegung des Gesetzes zur Netzresilienz: Was bedeutet es, durch die Entwicklung von Design-Software Sicherheit zu erreichen?
Verstehen Sie die Anforderungen des EU-Gesetzes zur Netzresilienz (CRA), für wen es gilt und wie sich Ingenieurteams durch Designpraktiken, Schwachstellenprävention und Kompetenzaufbau für Entwickler darauf vorbereiten können.
Treibende Faktoren 1: Klare und messbare Erfolgskriterien
Enabler 1 ist der Auftakt zu unserer 10-teiligen Reihe über Erfolgsfaktoren. Er zeigt, wie sichere Codierung mit Geschäftsergebnissen wie Risikominderung und schnellerer Reifung langfristiger Pläne in Verbindung gebracht werden kann.
