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 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.
In der Cybersicherheit sind wir oft wie Jäger. Unsere Augen sind fest auf den Horizont gerichtet, um nach der nächsten Sicherheitslücke zu suchen. Dieser vorausschauende Fokus kann jedoch den überraschenden Effekt haben, dass unser Sicherheitsbewusstsein insgesamt gedämpft wird.
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
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 unten stehenden Link und laden Sie die PDF-Datei dieser Ressource herunter.
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Bericht ansehenDemo 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.
Inhaltsübersicht
Vorstandsvorsitzender, Chairman und Mitbegründer
Secure Code Warrior ist für Ihr Unternehmen da, um Sie dabei zu unterstützen, Ihren Code über den gesamten Lebenszyklus der Softwareentwicklung hinweg zu sichern und eine Kultur zu schaffen, in der Cybersicherheit an erster Stelle steht. Ganz gleich, ob Sie AppSec-Manager, Entwickler, CISO oder ein anderer Sicherheitsverantwortlicher sind, wir können Ihrem Unternehmen helfen, die mit unsicherem Code verbundenen Risiken zu reduzieren.
Demo buchenHerunterladenRessourcen für den Einstieg
Sicher durch Design: Definition von Best Practices, Befähigung von Entwicklern und Benchmarking von präventiven Sicherheitsergebnissen
In diesem Forschungspapier werden die Mitbegründer von Secure Code Warrior , Pieter Danhieux und Dr. Matias Madou, Ph.D., zusammen mit den Experten Chris Inglis, ehemaliger US National Cyber Director (jetzt strategischer Berater der Paladin Capital Group), und Devin Lynch, Senior Director, Paladin Global Institute, die wichtigsten Erkenntnisse aus mehr als zwanzig ausführlichen Interviews mit Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, ein VP of Application Security und Software-Sicherheitsexperten, offenlegen.
Benchmarking von Sicherheitskompetenzen: Optimierung von Secure-by-Design im Unternehmen
Aussagekräftige Daten über den Erfolg von Secure-by-Design-Initiativen zu finden, ist bekanntermaßen schwierig. CISOs stehen oft vor der Herausforderung, den Return on Investment (ROI) und den Geschäftswert von Sicherheitsprogrammen sowohl auf Mitarbeiter- als auch auf Unternehmensebene nachzuweisen. Ganz zu schweigen davon, dass es für Unternehmen besonders schwierig ist, Erkenntnisse darüber zu gewinnen, wie ihre Organisation im Vergleich zu aktuellen Branchenstandards abschneidet. Die Nationale Cybersicherheitsstrategie des Präsidenten forderte die Beteiligten auf, "Sicherheit und Widerstandsfähigkeit durch Design" zu erreichen. Der Schlüssel zum Erfolg von Secure-by-Design-Initiativen liegt nicht nur darin, Entwicklern die nötigen Fähigkeiten zu vermitteln, um sicheren Code zu gewährleisten, sondern auch darin, den Aufsichtsbehörden zu versichern, dass diese Fähigkeiten vorhanden sind. In dieser Präsentation stellen wir eine Vielzahl von qualitativen und quantitativen Daten vor, die aus verschiedenen Primärquellen stammen, darunter interne Daten von über 250.000 Entwicklern, datengestützte Kundeneinblicke und öffentliche Studien. Auf der Grundlage dieser gesammelten Daten wollen wir eine Vision des aktuellen Stands von Secure-by-Design-Initiativen in verschiedenen Branchen vermitteln. Der Bericht zeigt auf, warum dieser Bereich derzeit nicht ausreichend genutzt wird, welche erheblichen Auswirkungen ein erfolgreiches Schulungsprogramm auf die Minderung von Cybersecurity-Risiken haben kann und welches Potenzial zur Beseitigung von Schwachstellen in einer Codebasis besteht.
Professionelle Dienstleistungen - Beschleunigen Sie mit Fachwissen
Das PSS-Team (Program Strategy Services) von Secure Code Warriorunterstützt Sie beim Aufbau, der Verbesserung und der Optimierung Ihres Programms für sichere Codierung. Ganz gleich, ob Sie neu anfangen oder Ihren Ansatz verfeinern möchten, unsere Experten bieten Ihnen maßgeschneiderte Beratung.
Themen und Inhalte der Schulung zu sicherem Code
Unsere branchenführenden Inhalte werden ständig weiterentwickelt, um sie an die sich ständig verändernde Softwareentwicklungslandschaft anzupassen und Ihre Rolle zu berücksichtigen. Die Themen reichen von KI bis XQuery Injection und werden für eine Vielzahl von Rollen angeboten, von Architekten und Ingenieuren bis hin zu Produktmanagern und QA. Verschaffen Sie sich einen kleinen Überblick über die Inhalte, die unser Katalog nach Thema und Rolle bietet.
Ressourcen für den Einstieg
Aufgedeckt: Wie die Cyber-Industrie "Secure by Design" definiert
In unserem neuesten Whitepaper haben sich unsere Mitbegründer Pieter Danhieux und Dr. Matias Madou, Ph.D., mit über zwanzig Sicherheitsverantwortlichen in Unternehmen, darunter CISOs, AppSec-Leiter und Sicherheitsexperten, zusammengesetzt, um die wichtigsten Teile dieses Puzzles herauszufinden und die Realität hinter der Secure by Design-Bewegung aufzudecken. Die Sicherheitsteams haben ein gemeinsames Ziel, aber kein gemeinsames Regelwerk.
Wird Vibe Coding Ihre Codebasis in eine Verbindungsparty verwandeln?
Vibe Coding ist wie eine College-Verbindungsparty, und AI ist das Herzstück aller Festivitäten, das Fass. Es macht eine Menge Spaß, sich auszutoben, kreativ zu werden und zu sehen, wohin die eigene Fantasie einen führen kann, aber nach ein paar Bierfässern ist das Trinken (oder die Verwendung von KI) in Maßen zweifellos die sicherere langfristige Lösung.
Entwicklergesteuerte Kodierung.
Sicher ist sicher.
Setzen Sie sich noch heute mit uns in Verbindung und machen Sie Softwaresicherheit zu einem festen Bestandteil Ihres Entwicklungsprozesses.
