CERT.at - Blog

Bitlocker Recovery Keys in der Cloud

CERT.at — Mon, 26 Jan 2026 21:36:44 GMT+0100

Aktuell gehen reißerische Berichte durch die Medien, dass Microsoft regelmäßig Bitlocker Recovery Keys an Strafverfolgungsbehörden weitergibt.

Ich glaube, die Aufregung geht hier fast völlig an den wirklich spannenden Fragen vorbei, weil:

Wir reden hier von privaten Geräten, die nicht zentral verwaltet werden. Ist nämlich der Windows-PC in ein Active Directory eingebucht (Domain-Joined), dann wird der Recovery-Key dorthin gesichert.
Das Ganze ist klar dokumentiert und wird bei der Installation als eine der möglichen Wege zur Sicherung der Recovery-Keys angeboten.
Der Recovery-Key ist ohne die dazu passende Hardware völlig unnütz. Auch wenn Microsoft den Schlüssel an das FBI weitergibt, heißt das noch lang nicht, dass sie magischen Zugriff auf Rechner in Österreich haben.
Ich habe keine Zahlen, aber ich gehe davon aus, dass diese Cloudsicherung der Bitlocker Recovery-Keys ernsthaft viele Leute vor Datenverlust bewahrt hat. Ja, das Feature ist eine Gefahr für das C (confidentiality) in der CIA-Triade, aber das A (availability) ist gerade für Privatnutzer das eigentlich wichtigere Schutzziel.

Worüber man viel mehr reden sollte, sind zwei andere Punkte:

Wenn Microsoft die im Cloud-Account gespeicherten Keys rausgibt, dann wohl auch den Inhalt des OneDrive, des M365 Mail Accounts und all die Mail, bei beim „New Outlook“ über die Cloud geroutet wird. Und hier braucht die Polizei dann keine beschlagnahmte Hardware, um zu den Inhaltsdaten zu kommen.
Wenn das AD einer Organisation mit der Cloud Variante (früher Azure AD, jetzt Microsoft Entra ID) synchronisiert ist, werden dann die Bitlocker Recovery-Keys auch in die Cloud gesynct? Auf die hier gültigen Policies sollten CISOs ein Auge werfen.

Ein kurzer Blick auf das NISG 2026

CERT.at — Wed, 26 Nov 2025 19:15:28 GMT+0100

Wirklich viel hat sich zwischen dem abgelehnten Entwurf von 2024 und dem am 20. November eingebrachten Text nicht geändert. Ich will hier nur kurz zwei Punke ansprechen.

Recital 44

Dieser Erwägungsgrund aus der NIS2 Richtlinie hat es 1:1 in die Erläuternden Bemerkungen unseres Gesetzesentwurfes geschafft. Er lautet:

Die CSIRTs sollten in der Lage sein, auf Ersuchen einer wesentlichen oder wichtigen Einrichtung die mit dem Internet verbundenen Anlagen innerhalb und außerhalb der Geschäftsräume zu überwachen, um das organisatorische Gesamtrisiko der Einrichtung für neu ermittelte Sicherheitslücken in der Lieferkette oder kritische Schwachstellen zu ermitteln, zu verstehen und zu verwalten. Die Einrichtung sollte dazu angehalten werden, dem CSIRT mitzuteilen, ob es eine privilegierte Verwaltungsschnittstelle betreibt, da dies die Geschwindigkeit der Durchführung von Abhilfemaßnahmen beeinträchtigen könnte.

Wie schon im Sommer angemerkt, ist uns nicht klar, was der EU-Gesetzgeber uns damit sagen will. Ja, wir könnten das einfach ignorieren (EBs sind nicht verbindlich), aber so wirklich zufriedenstellend ist das nicht. Daher:

Woher kommt das und wie kann man das interpretieren?

Ich bin kein Experte in der EU-Gesetzgebung, aber nach meinen schnellen Recherchen finde ich das Recital nicht im initialen Vorschlag der Kommission, sondern es kommt aus dem Kompromissvorschlag des EU Parlaments.

Dort gibt es

Recitals

(25a) CSIRTs should have the ability to, upon an entity's request, continuously discover, manage, and monitor all internet-facing assets, both on premises and off premises, to understand their overall organisational risk to newly discovered supply chain compromises or critical vulnerabilities. The knowledge whether an entity runs a privileged management interface, affects the speed of undertaking mitigating actions

Das Parlament hatte noch weitere spannende Ideen für die CSIRTs:

1a. CSIRTs shall develop at least the following technical capabilities:

(a) the ability to conduct real-time or near-real-time monitoring of networks and information systems, and anomaly detection;

(b) the ability to support intrusion prevention and detection;

(c) the ability to collect and conduct complex forensic data analysis, and to reverse engineer cyber threats;

(d) the ability to filter malign traffic;

(e) the ability to enforce strong authentication and access privileges and controls; and

(f) the ability to analyse cyber threats.

Das hat es zum Glück nicht in den finalen Text geschafft, aber das dazugehörige Recital schon. Und damit hängt es in der Luft und passt zu keinem der Artikel.

Das hat ein Raten zu Folge, wo man das denn am ehesten sinnstiftend verlinken könnte.

Die EBs zum NISG2026 zitieren diesen Erwägungsgrund bei den Erklärungen zu „§8(1) Aufgaben der CSIRTs“ (wörtlich: „Zusätzlich nehmen CSIRTs noch weitere technische Aufgaben wahr (Abs. 1 Z 1 bis 5 und 8). Dazu gehören etwa […]“)

Gemeint sein könnte die Ziffer 1:

die Überwachung und die Analyse von Cyberbedrohungen, Schwachstellen und Cybersicherheitsvorfällen auf nationaler Ebene und gegebenenfalls die Unterstützung betroffener wesentlicher und wichtiger Einrichtungen hinsichtlich der Überwachung ihrer Netz- und Informationssysteme in Echtzeit oder nahezu in Echtzeit;

Das ist gefährlich, weil damit aus der „Unterstützung bei der Überwachung“, was man als „wir sollen den SOCs der Einrichtungen IOCs, CTI und andere Hinweise geben“ auslegen kann, ein „wir sollen die Einrichtungen unterstützen, indem wir auf Anfrage das SOC für sie betreiben“ wird. Das kann nicht funktionieren.

Man könnte das Recital aber auch auf der Ziffer 5 aufhängen. Diese lautet:

5. die Vornahme einer proaktiven Überprüfung der Netz- und Informationssysteme einer ersuchenden wesentlichen oder wichtigen Einrichtung im Hinblick auf Schwachstellen mit potenziell signifikanten Auswirkungen (Schwachstellenscan);

Das geht auch, und dort macht es viel mehr Sinn. Wir sollen auf Anfrage externe Scans machen, damit Attack Surface Monitoring, gepaart mit etwas Erkennung von Produkten, was man dann wieder gegen Schwachstellendatenbanken mappen könnte – damit ergibt sich der Verweis auf Lieferketten.

Zusammengefasst:

Das Recital kann man auf drei mögliche Arten bei uns im NISG2026 berücksichtigen:

Als Fehler im Trilog: die korrespondierenden Artikel wurden gestrichen, da hätte es eigentlich auch das Recital nicht in die finale Version schaffen sollen. Also am besten ignorieren und nicht in die EBs aufnehmen.
Es mit §8 Abs. 1 Z 5 verlinken. Ist nicht schön, aber dort tut es nicht wirklich weh.
Es mit §8 Abs. 1 Z 1 verlinken und Verwirrung stiften.

Eine kurze Umfrage im CSIRTs Network hat gezeigt, dass auch die anderen Teams an dieser Frage kiefeln.

Es wäre hilfreich, wenn die EBs bei uns klarstellen, dass nicht der §8 Abs. 1 Z 1 gemeint ist. Am besten wäre es, das Recital erst gar nicht in die EBs aufzunehmen.

Übergangsphase für CSIRTs

Das NISG 2026 ersetzt das alte NISG, damit werden alte Bescheide ungültig und das trifft auch die bescheidmäßigen Ermächtigungen laut §15 Abs 3, mit denen das Bundeskanzleramt das nationale und die sektorspezifischen Computer-Notfallteams anerkannt hat. Im Entwurf für das NISG 2026 findet sich die Ermächtigung von Sektoralen CSIRTs in §8. Im §51 werden die „Inkrafttretens-, Außerkrafttretens- und Übergangsbestimmungen“ geregelt, u.a.:

(2) Nach Ablauf von neun Monaten nach der Kundmachung dieses Bundesgesetzes mit dem nächstfolgenden Monatsersten treten […] die §§ 2 bis 45, […] in Kraft. Gleichzeitig treten […] die §§ 2 bis 31 NISG […] außer Kraft.

(3) Verordnungen auf Grund dieses Bundesgesetzes können bereits ab dem auf seine Kundmachung folgenden Tag erlassen werden. Sie dürfen jedoch frühestens mit Inkrafttreten dieses Bundesgesetzes in Kraft gesetzt werden.

(5) Bescheide, die gemäß § 15 Abs. 3, § 16 Abs. 1 und § 18 Abs. 1 NISG erlassen wurden, werden mit Inkrafttreten dieses Bundesgesetzes gegenstandslos, sofern nicht Abs. 6 oder Abs. 7 zur Anwendung gelangt.

(6) Das gemäß § 15 Abs. 3 NISG ermächtigte nationale CSIRT hat die Aufgaben gemäß § 8 Abs. 1 und 3 sowie § 11 bis zur Ermächtigung eines nationalen CSIRTs gemäß § 8 Abs. 2, längstens jedoch für einen Zeitraum von zwei Jahren ab Inkrafttreten dieses Bundesgesetzes, wahrzunehmen. § 8 Abs. 6 und § 10 gelten.

Was heißt das wirklich für die CSIRTs? Nehmen wir mal an, das Gesetz wird wirklich noch 2025 beschlossen und wir haben damit den 1. September als Stichtag für das volle Inkrafttreten. Ich lese das so:

Bis zum 1. September ändert sich mal in Sachen CSIRTs gar nichts.
Die sektorspezifischen CSIRTs verlieren mit 1. September ihre Ermächtigung
Das nationale CSIRT hat noch 2 Jahre Schonfrist (also Sept 2028), bis dahin muss eine neue Ermächtigung erfolgen
Der Absatz 3 ist gut, weil man damit Verordnungen vorab erlassen kann, die dann am Stichtag gültig werden: das gibt den Betroffenen Rechtssicherheit, was sie am 1. September erwartet
Aber: der Absatz 3 bezieht sich nur auf Verordnungen, nicht auf Bescheide. Ich bin kein Jurist, aber hier sehe ich eine Lücke. Es wäre sehr sinnvoll, wenn die Cybersicherheitsbehörde ein Bescheid für die erneute Ermächtigung eines sektorspezifischen CSIRTs während der 9 Monate Übergangsphase ausstellen kann, der mit 1. September in Kraft tritt.

Es wäre daher gut, wenn der Absatz 3 auf „Verordnungen und Bescheide“ erweitert wird.

Digitale Souveränität: Cloud Edition.

CERT.at — Wed, 03 Sep 2025 13:47:37 GMT+0100

Das erratische Verhalten der aktuellen US-Regierung hat die Sorgen um die Abhängigkeit Europas von den großen US-Cloudbetreibern verstärkt. In der EU haben sowohl die Kommission als auch das Parlament Dokumente zu diesem Thema vorgelegt, heuer hat die Kommission bereits um Ideen zu einem Cloud and AI Development Act gebeten. Auch in Deutschland macht man sich ernsthaft Gedanken zur Digitalen Souveränität.

Die großen Hyperscaler (Azure, Google, AWS, Oracle, IBM) haben alle Initiativen gestartet, die mittels einer „Sovereign Cloud“ diesen Bedenken gerecht werden sollen. Die Bewertung dieser Angebote ist nicht einfach, manches davon ist pures Marketing (das deutsche ZenDiS nennt das "Souveränitäts-Washing").

Folgende Aspekte sind relevant:

Geografisch nahe Standorte haben Vorteile, was die Ausfallssicherheit und Geschwindigkeit der Anbindung betrifft.
Was ist der Gerichtsstandort des Vertrages mit dem Anbieter?
Was sind die Durchgriffsmöglichkeit der US-Konzernmütter auf die Dienstleistungen ihrer Tochterfirmen in der EU?
Wie der Fall rund um die den ICC in Den Haag gezeigt hat, kann eine Sanktionierung per Executive Order weitreichende Folgen haben. Wie sehr kann eine Sovereign Cloud das wirklich abfangen?
Wird der Zugriff von US-Behörden auf die verarbeiteten und gespeicherten Daten nach dem US-CLOUD Act verhindert?
Datenschutz / GDPR: Für mache Anwendungen ist relevant, wo die Daten physische gespeichert werden. Achtung: Ob das EU–US Data Privacy Framework halten wird, ist fraglich.
Wie sehr ist man durch Vendor- oder Technologie-Lock-In gefangen?

Ewig ruft das Passwort

CERT.at — Tue, 26 Aug 2025 09:27:28 GMT+0100

Die Verwendung von Passwörtern hat eine lange Tradition in der IT. Und regelmäßig sind sich alle einig, dass wir sie eigentlich loswerden sollten. Das haben wir noch immer nicht geschafft, auch wenn Passkeys ein interessanter Ansatz sind. Daher sitzen wir alle auf großen Sammlungen von Passwörtern – die ca. 250 Einträge in meinem PW-Safe sind hoffentlich nicht repräsentativ – und im Internet tauchen in regelmäßigen Abständen immer absurd größere Passwort-Dumps auf. Es mehren sich auch Meldungen zu Datenlecks (aktuell PayPal), wo nicht klar ist, wo die Daten eigentlich abgeflossen sind. Solche Gerüchte können jede Organisation treffen, daher macht es Sinn, sich das Thema Passwörter in Ruhe anzuschauen.

Grundlagen

Dieser Blogpost schneidet das Thema nur kurz an, eine umfassende Behandlung des Themas Access Control liefert NIST SP800-63, in SP800-63B geht es im Detail um Passwörter. (Nebenbemerkung: die aktuelle Version enthält jetzt „Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically. However, verifiers SHALL force a change if there is evidence that the authenticator has been compromised.“)

Methoden zu Zugangskontrollen werden oft in drei Kategorien eingeteilt:

Das, was ich bin: Biometrie, Stimme, Aussehen
Das, was ich habe: Schlüssel, Token, Dienstausweis, Handy
Das, was ich weiß: Username + Passwort, PIN

Eine Passwortabfrage ist einfach zu implementieren (und daher auch eine beliebte Aufgabe für Schüler): das eingegebene Passwort wir mit dem gespeicherten verglichen und so wird entschieden, ob der Zugang gewährt wird. Allzu simple sollte man das aber doch nicht machen, weil man folgendes berücksichtigen sollte:

Die Übertragung von Passwörtern im Klartext ist gefährlich. Damals, im Zeitalter von offenen WLANs und vor dem breiten Einsatz von https war es ein beliebter Sport bei Konferenzen und Kaffeehäusern, die Passwörter anderer Leute aus dem Äther zu fischen.
Ein Challenge-Response Verfahren statt eines simplen Vergleiches vermeidet das Passwort im Klartext, das hat sich aber bei Webanwendungen nicht durchgesetzt.
Transport Layer Security (TLS) ist der übliche Weg, um neugierige Mithörer auszusperren.
Serverseitig sollten Passwörter nicht im Klartext gespeichert werden, sondern als nur als (gesalzener) Hash. Die Verifikation ist weiterhin leicht möglich (Salz aus der DB nehmen, eingegebenes Passwort neu hashen, dann Ergebnis vergleichen. Mit einem dafür entwickeltem Hash-Verfahren kann man gut verhindern, dass Auslesen der Datenbank am Server nicht gleich alle Passwörter preisgibt
Ist das Passwort aber zu einfach gewählt (geringe Komplexität oder häufiges Passwort in früheren Breaches), dann kann ein rohes Durchprobieren erfolgreich sein. Daher machen Vorgaben dazu (etwa eine Mindestlänge) und ein Check gegen Datenbanken bekannter Passwörter viel Sinn.
Serverseitig sollte dieses Passwortraten erkannt und unterbunden werden – aber ohne das Ganze zum Denial-Of-Service Angriff gegen den legitimen Benutzer werden zu lassen.
Optimal wären auch halbwegs zufällig Usernamen, in der Praxis werden bei den meisten Webseiten die Mailadressen der Nutzer als deren Username verwendet. Das erhöht die Wahrscheinlichkeit für erfolgreiche Credential-Stuffing Angriffe deutlich.

Wo gehen Passwörter verloren?

In der Praxis sind heute zwei Quellen für Passwort-Leaks relevant:

Serverseitig

Der Klassiker ist hier eine Schwachstelle in der Web-Applikation, die entweder direkt SQL Injection – und damit das Auslesen von Datenbanken – erlaubt, oder aber die Installation einer Webshell, was das Ausführen von beliebigem Code am Webserver ermöglicht. Natürlich ist auch ein anderer Weg als Einbruch in die Systeme denkbar, oder ganz etwas anderes wie unsachgemäße Entsorgung von alten Medien, Verlust von Laptops mit Kopien, böswilliges Handeln von Mitarbeitern oder Dienstleistern und was sonst noch alles die ISO 27k Norm im Risikokatalog dazu hat. Auch Einbrüche in veraltete Systeme, die eigentlich gar nicht mehr in Betrieb sind, aber trotzdem noch online waren, kamen schon mehrmals vor.

All das ermöglicht es Angreifern, die serverseitig zu Usern vorliegenden Daten komplett auszulesen. Solche Leaks haben meist folgende Eigenschaften:

Die Daten sind schön strukturiert und sauber.
Das Passwort ist hoffentlich nicht im Klartext enthalten – oft werden im Nachgang die einfach zu knackenden Hashes aufgelöst.
Es gehen die Informationen zu allen Benutzern in gleichem Maße verloren.

Daten aus diesen Lecks werden im Darknet oft zum Kauf angeboten, nach einer Zeit landen sie dann auf Plattformen wie DeHashed oder HIBP. Verkäufer teilen oft auch kleine Ausschnitte der gesamten Datenbasis, um prospektive Käufer anzulocken.

Clientseitig

Aber auch auf der Seite des Nutzers kann das Problem sein, etwa weil Malware a) gespeicherte Passwörter aus dem Browser ausliest, b) oder sie als Keylogger Passwörter bei ihrer Eingabe speichert, c) eine trojanisierte Browsererweiterung Zugangsdaten abfängt oder d), weil der webbasierte Passwort-Safe ein Sicherheitsproblem hat. Aber nicht nur technische Angriffe bedrohen die Seite des Nutzers: Auch Social Engineering Angriffe wie etwa Phishing Webseiten oder E-Mails können dazu führen, dass Zugangsdaten in falsche Hände geraten.

Auch die auf diese Weise gestohlenen Zugangsdaten werden oft in kriminellen Untergrundforen getauscht oder verkauft. Sie zeichnen sich aus durch:

Sie enthalten neben Username/Passwort auch oft die URL, zu der sie gespeichert wurden.
Das Passwort ist im Klartext enthalten.
Es trifft oft die Passwort-Sammlung eines Benutzers (viele verschiedene Webseiten), von einem Webshop sind aber nur einzelne User betroffen.
Die Daten – insb. von Keyloggern – sind nicht sehr sauber.

Mischformen

Bei Kreditkarten-Skimming gab es auch Fälle, wo der Einbrecher am Server die dort vorliegenden Daten gar nicht ausgelesen hat, sondern nur ein kleines Stück JavaScript in die Webseite eingebaut hat, dass bei der Eingabe der Zahlungsinformation im Browser des Users, diese client-seitig per Web-Request an einen Webserver unter der Kontrolle der Angreifer geschickt hat.

Was heißt das für mich als Organisation?

Frägt man CISOs nach ihren Albträumen, dann wird „Passwörter meiner Organisation sind im Web aufgetaucht!“ sicher oft genannt. Aber was kann hinter so einer Schlagzeile stecken?

Eigene Systeme

Der schlimmste Fall ist, wenn direkt auf dem eigenen Server die Userdatenbank einer Webanwendung ausgelesen wurde. Woran könnte man das erkennen?

Die Tätergruppe probiert eine Erpressung: „Zahlt mir was, oder ich veröffentliche die Daten!“
In den Untergrundforen taucht der Leak explizit mit Nennung der Quelle auf. „example.com – complete userdb incl. passwords“
Es trifft nicht nur einzelne meiner User, sondern alle.
Die Datenbasis ist zeitlich konsistent: es sollte nicht sein, dass längst gelöschte alte User neben brandneuen Accounts auftauchen.

Die Reaktion wird wohl umfassend sein:

Incident Response, um die Ursache zu ermitteln, zu beheben und sicherstellen, dass das Problem wirklich behoben ist - und sich auch nicht auswachsen könnte.
Meldepflichten: Datenschutz, NIS und potenziell sektorspezifische Regulierungen.
Information der Nutzer, Passwort-Änderungen.
Analyse, wie man das ganze Setup besser machen könnte.

Fremde Systeme

Das ist leider fast Tagesgeschäft. Auch wenn man Privatnutzung der dienstlichen E-Mailadresse untersagt hat, so werden auch bei rein beruflicher Nutzung die Adressen der eigenen Mitarbeiter in diversen Kundendatenbanken landen. Das kann eine Konferenzanmeldung sein, eine Fluglinie, ein Hotel, ein Catering-Service, ein Lieferant, ein Kunde, ein soziales Netzwerk (ja, es gibt genug Jobs, wo das zur Arbeitsplatzbeschreibung gehört), eine Kammer oder eine staatliche Stelle, bei der sich Mitarbeiter registrieren müssen.

Die meisten davon werden hoffentlich ihre Systeme im Griff haben, aber rein statistisch gesehen wird es immer wieder vorkommen, dass eine dieser Datenbanken Beine bekommt und im Dark Web auftaucht.

Sucht irgendwer nach der Domain einer Organisation in den Untergrundforen oder den legitimen Leak Sammlungen, so tauchen dann die E-Mail-Adressen aller betroffener Mitarbeiter auf. Das allein kann schon für reißerische Schlagzeilen sorgen.

Haben diese Mitarbeiter etwas falsch gemacht? Nicht notwendigerweise.

Besteht eine Gefahr für die Organisation? Typischerweise bemerkt die Quelle des Leaks relativ bald den Vorfall und mitigiert das Problem auf ihrer Seite. Die große Gefahr hier ist die mehrfache Verwendung von Passwörtern. Beispiel: max.mustermann@example.com taucht im Leak einer Konferenzwebseite auf, und hat das gleiche Passwort auch für seinen Account bei einem Social Network benutzt. Ein Käufer des Leaks probiert die Adresse/Passwort Paare bei verschiedenen populären Webseiten durch kann so in einen Account einsteigen und Unfug treiben.

Die üblichen Empfehlungen für diesen Bereich sind:

Die Nutzung der beruflichen E-Mail-Adresse für private Zwecke sollte nicht gestattet sein.
Klare Vorgaben, dass Passwörter nicht doppelt verwendet werden.
Dazu ist es nötig, dass Mitarbeitern entsprechende Werkzeuge (Passwortsafes) zur Verfügung gestellt werden.
Aktivierung von 2-Faktor Authentication auf möglichst allen externen Systemen.
Ein Zugriff von außen auf eigene Systeme muss durchgängig einen 2. Faktor verlangen.

Es kann sinnvoll sein, über Dienstleister das Auftauchen von eigenen Mailadressen in Untergrundforen und Leak-Seiten beobachten zu lassen, um möglichst proaktiv reagieren zu können.

Clientprobleme bei fremden Usern

Biete ich als Organisation eine Loginmöglichkeit für Kunden, Geschäftspartner oder Bürger an, so muss man leider davon ausgehen, dass diese ihre eigenen Systeme nicht zu 100% sicher betreiben und dass daher ein kleiner Teil davon ihre Zugangsdaten verlieren.

Je nach Applikation kann das harmlos oder gefährlich sein. Ein klassisches Beispiel ist das Online-Banking: hier haben Banken schon lange gelernt (und haben inzwischen auch harte staatliche Vorgaben), dass eine einfache Username/Passwort Kombination viel zu wenig Sicherheit bietet, um Geldgeschäfte abzuwickeln. Daher wurden hier schon früh TANs (Transaktionsnummern) eingeführt: zuerst auf Papier, dann SMS und jetzt über Apps.

Andersrum: wenn die Userdatenbank nur die Anmeldung zu einem Newsletter enthält, dann ist eine starke Absicherung schlicht unnötig, weil der mögliche Schaden nahe Null ist.

Aber eine PR-Tretmine ist das ganze allemal: Wenn ein Service eine signifikante Zahl an Nutzern hat, dann wird eine entsprechende Suche im Dark Web genug Treffer ergeben (jetzt in der URL-Spalte, und nicht mehr in der E-Mail-Spalte). Das kann bei genug Unwissenheit (oder Böswilligkeit) auch schon zu einem Skandal aufgeblasen werden.

Was kann man hier empfehlen?

Als erstes muss man sich klar werden, wie heikel die Daten überhaupt sind, die über diesen Account angesprochen werden. Welcher Level an Zugangsschutz ist nötig?
Kann die Authentifizierung outgesourced werden? Ein Passwort, das gar nicht vorhanden ist, kann nicht gestohlen werden.
- Für harmlose Services kann man das etwa über „Login via Google/Apple/Github/…“ oder eine simple E-Mail-Schleife lösen.
- Für heiklere Dienste bietet sich eine Anbindung an ID-Austria an.
Auch hier können Dienstleister, die das Dark Net zu Passwort Leaks beobachten, helfen, proaktiv zu agieren, statt im Nachhinein auf Presseanfragen reagieren zu müssen.

Clientprobleme bei eigenen Mitarbeitern

Wie man die Endgeräte seiner Mitarbeiter absichert, ist ein hartes Problem und soll hier nicht behandelt werden. Auch das Thema "Wie schule ich meine Mitarbeiter in der Erkennung von Social Engineering?" ist nicht trivial, wie ein aktuelle Studie belegt.

Zwei Empfehlungen von oben gelten hier jedenfalls auch:

Man muss davon ausgehen, dass Mitarbeiter Passwörter verlieren und die Sicherheitsarchitektur der eigenen IT entsprechend anlegen.
Ein Monitoring von Untergrundforen kann auch hier Sinn machen.

Zusammenfassung

Nicht alle „Password-Leaks“ sind gleich, und nicht für alle ist man selbst verantwortlich.

Zur eigenen Verantwortung zählt:

Sich der Gefahr (und sei es nur PR-Drama) bewusst sein
Fehler im eigenen Bereich so gut wie möglich ausschließen
- Datensparendes Arbeiten kann hier hilfreich sein
Die eigene Reaktion auf Fehler Dritter vorbereiten
Dafür sorgen, dass man nicht überrascht wird

NIS2 Umsetzung: heikle Punkte aus meiner Sicht

CERT.at — Fri, 13 Jun 2025 16:01:18 GMT+0100

Ich habe schon viel zu NIS2 geschrieben, von meinen Blogposts zum initialen Entwurf (Recitals, Haupttext), über ein Update 2021, bis hin zu unserer Stellungnahme zum NISG2024. Mit dem Übergang der Cyber-Agenden vom BKA zum BMI im Rahmen des Regierungswechsels ist auch ein neues Team für den Entwurf des Gesetzes verantwortlich. Für dieses will ich hier kurz zusammenfassen, wo man das Leben für uns als nationales CERT schwer, oder einfach und effektiv machen kann.

Die folgenden Punkte sind keine umfassende Wunschliste für das NIS2-Gesetz.

Scope

Laut Richtlinie sind die CSIRTs für die wesentlichen und wichtigen Einrichtungen zuständig, nicht aber für das ganze Land. Im aktuellen NISG haben wir das im §14 so gelöst:

(6) Computer-Notfallteams können die Aufgaben gemäß Abs. 2 Z 3 bis 5 auch gegenüber sonstigen Einrichtungen oder Personen wahrnehmen, sofern diese von einem Risiko oder einem Vorfall ihrer Netz- und Informationssysteme betroffen sind.

Warum ist das wichtig? Die Kollegen in den Niederlanden hatten das nicht in ihrem Gesetz und sind dann in folgendes Problem gelaufen: Sie bekamen von einem Partner Information zu kompromittierten Systemen, wo wahrscheinlich bald Ransomware aktiviert wird. Das betraf auch Firmen, die nicht unter NIS fallen, damit hatte das NCSC-NL keine Rechtsgrundlage zu Verarbeitung der entsprechenden Daten und durften daher die Warnungen nicht weitergeben.

Ähnliches gilt für das proaktive Scanning laut Artikel 11 NIS2-Richtlinie:

CSIRTs können eine proaktive nicht intrusive Überprüfung öffentlich zugänglicher Netz- und Informationssysteme wesentlicher und wichtiger Einrichtungen durchführen. Eine solche Überprüfung wird durchgeführt, um anfällige oder unsicher konfigurierte Netz- und Informationssysteme zu ermitteln und die betreffenden Einrichtungen zu unterrichten. Eine solche Überprüfung darf keinerlei nachteilige Auswirkung auf das Funktionieren der Dienste der Einrichtung haben.

Damit ich das als CSIRT genau so machen kann, brauche ich vollständige und aktuelle Daten zu den IP-Adressen und Domains von allen wesentlichen und wichtigen Einrichtungen. Ja, mindestens die IP-Adressen sollten laut Artikel 27(2)(f) eingemeldet sein, aber ich bin sehr skeptisch, dass das wirklich funktionieren wird.

Es macht unsere Arbeit daher einfacher, effizienter und sinnvoller, wenn die gesetzliche Freigabe bekommen, das ganze Land zu scannen – um mit den Ergebnissen auch dem ganzen Land zu helfen. Das ist nicht Gold-Plating, das tut keiner Firma in Österreich weh, und der potenzielle Mehraufwand bei uns ist durch die Vereinfachung der Arbeit abgedeckt – vom verbesserten Schutz für das ganze Land ganz abgesehen.

Aufgaben

Laut Artikel 11(3) gehört zu unseren Aufgaben:

a) Überwachung und Analyse von Cyberbedrohungen, Schwachstellen und Sicherheitsvorfällen auf nationaler Ebene und auf Anfrage Bereitstellung von Unterstützung für betreffende wesentliche und wichtige Einrichtungen hinsichtlich der Überwachung ihrer Netz- und Informationssysteme in Echtzeit oder nahezu in Echtzeit;

Ich lese das als „indem wir Warnungen herausgeben und Cyber Threat Intelligence weitergeben sollen wir Firmen dabei helfen, selber ihre Systeme zu überwachen“. Das ist sinnvoll und machbar. Im NISG2024 war das auch fast wörtlich so übernommen. In den Erläuterungen dazu stand aber:

Das klingt anders: das CSIRT selbst soll die IT von wesentlichen und wichtigen Einrichtungen überwachen, also als Security Operations Center (SOC) fungieren. Bei mehr als tausend Einrichtungen unter NIS2 bräuchte das mehrere hundert Mitarbeiter beim CSIRT, und es würde die kommerziellen MSSP-Anbieter komplett aus dem Markt drängen. Das kann wohl nicht gemeint sein.

Finanzierung

Aktuell bekommt CERT.at kein Geld vom Staat für den Betrieb des nationalen CERTs. Das muss sich mit NIS2 ändern, die Richtlinie sagt das nicht nur einmal:

Recital (41): Die Mitgliedstaaten sollten daher ein oder mehrere CSIRTs gemäß dieser Richtlinie benennen und sicherstellen, dass sie über angemessene Ressourcen und technische Kapazitäten verfügen.

Recital (46): Es ist von wesentlicher Bedeutung, dass angemessene Ressourcen bereitgestellt werden, um die Ziele dieser Richtlinie zu erreichen und es den zuständigen Behörden und den CSIRTs zu ermöglichen, die dort festgelegten Aufgaben zu erfüllen. […]

Artikel 10(2): Die Mitgliedstaaten gewährleisten, dass jedes CSIRT mit angemessenen Ressourcen ausgestattet ist, damit es seine in Artikel 11 Absatz 3 aufgeführten Aufgaben wirksam erfüllen kann.

Artikel 11(2): Die Mitgliedstaaten gewährleisten, dass ihre CSIRTs gemeinsam über die notwendigen technischen Fähigkeiten verfügen, damit sie ihre in Absatz 3 aufgeführten Aufgaben erfüllen können. Die Mitgliedstaaten stellen sicher, dass ihre CSIRTs mit ausreichenden Ressourcen ausgestattet sind, um für angemessene Personalausstattungen zu sorgen, damit die CSIRTs ihre technischen Fähigkeiten entwickeln können.

Wie das am besten mit der aktuellen Konstellation eines nationalen CSIRTs, das selber keine Behörde ist, legistisch umzusetzen ist, kann ich nicht beantworten.

Zusammenarbeit mit den Einrichtungen

Der oben zitierte Artikel 11(3)(a) hat Überlappungen mit den Aufgaben des Nationalen Cyber Hubs laut Cyber Solidarity Act. Das dort vorgesehene Netzwerk der nationalen SOCs passt auch gut zum Artikel 29 der NIS2 Richtlinie. Das ließe sich alles sehr gut verbinden. Meine Gedanken dazu habe ich in einem Whitepaper veröffentlicht.

DOGE, CISA, Mitre und CVE

CERT.at — Tue, 22 Apr 2025 14:25:39 GMT+0100

In der Cybersecurity Community herrschte letzte Woche helle Aufregung, weil die Einsparungstruppe von Trumps Gnaden die grandiose Idee hatte, das Funding für den Betrieb des CVE-Systems durch Mitre einzustellen. Wahrscheinlich aufgrund des starken Gegenwindes von der Seite der US-Industrie wurde eine Lösung gefunden und der Betrieb ist (angeblich) für die nächsten 11 Monate gesichert.

Ich will das zum Anlass nehmen, das System hinter den bekannten CVE-Nummern zu erklären und mögliche Entwicklungen aufzuzeigen.

Wozu das Ganze?

Schwachstellen Namen/Identifier zu geben, macht es für die IT-Abteilungen von Organisationen deutlich einfacher, ein systematisches Schwachstellenmanagement zu betreiben. Advisories von Herstellern, Ergebnisse von Scans, Patches und neue Softwareversionen nutzen diese Kennzeichen, um klar zu kommunizieren, um welche Schwachstellen es geht. Für Suchen im Web sind sie hilfreich und in internen Datenbanken werden sie zur Korrelation diverser Informationen genutzt. Sie sind vor allem lieferanten- und dienstleisterübergreifend einheitlich, was für die Interoperabilität extrem hilfreich ist.

Was genau einen solchen Identifier verdient, darüber kann man trefflich streiten, genauso wie man die Kritikalität und Ausnutzungswahrscheinlichkeit bewerten sollte.

One CVE to rule them all?

Das System rund um CVE (Common Vulnerabilities and Exposures), das von der Mitre Corporation im Auftrag der US-Regierung betrieben wird, ist bei weitem nicht das einzige derartige System. Zu erwähnen sind hier etwas das chinesische, das russische, das japanische, das von Github und das System für Cloud-Schwachstellen. Solange alle die dort vergebenen Identifier verschiedene Prefixe (etwa „CVE-“) nutzen, können diese problemlos nebeneinander existieren. Zwischen den Datenbanken wird es aber auch Überlappungen geben: dieselbe Schwachstelle kann in mehreren dieser Systeme einen Identifier bekommen haben, und es braucht ein Mapping dazwischen. Das ist ähnlich wie bei Malware oder Tätergruppen: auch hier existieren verschiedene Benennungssysteme nebeneinander. Das ist nicht schön, weil es Übersetzungstabellen braucht, aber es ist kein Weltuntergang.

Analogie DNS

Es bestehen gewisse Ähnlichkeiten zum Domain Name System (DNS): auch dieses muss sicherstellen, dass Identifier an einer Stelle nur einmal vergeben werden können. Und auch hier hat sich ein vergleichbares, komplexes Ökosystem aus verschiedenen Akteuren herausgebildet.

Initial war das CVE-System zentralistisch organisiert: CVE-Nummern wurden von genau einer Organisation vergeben, nachdem eine Schwachstelle an diese Stelle gemeldet wurde. Das skaliert nur begrenzt, daher wurde das Konzept von CVE Numbering Authorities (CNAs) eingeführt. Diese CNAs können dann in ihrem jeweiligen Bereich eigenständig CVE-Nummer vergeben – entweder aus einem vorher zugewiesenem Nummernpool oder eine, on-demand per API von Mitre abgeholte, freie Nummer.

Ähnliches ist im DNS passiert: war die Domainvergabe initial nur direkt bei der Registry möglich, so ist es heute üblich, dass ein Registrar die Kundeninteraktion übernimmt, und dass der Registrar dann über ein API die eigentliche Domainregistrierung bei der Registry vornimmt.

Rollen / Aufgaben

Registry / Vulnerability-DB

Um die Eindeutigkeit der Nummernzuordnung zu garantieren, wird von einer Organisation eine zentrale Datenbank betrieben (ja, das könnte man auch verteilt machen, aber das ist die Komplexität nicht wert). Diese hat eine natürliche Monopolstellung für den von ihr verwalteten Namensraum, daher macht es Sinn, ihre Aufgaben so eng wie möglich zu definieren.

Im Bereich des DNS gilt das für die meisten Registries: Sie betreiben die autoritative Datenbank der registrierten Domains, und interagieren möglichst wenig direkt mit den Domaininhabern.

Das gleiche gilt für Schwachstellenidentifierdatenbanken.

Registrare / CNAs

Im DNS übernehmen die Registrare die Kundebeziehung und nutzen die Registry nur per API um dann dort im Namen ihrer Kunden die Domain zu registrieren. Die CNAs haben die gleiche Aufgabe für Schwachstellen Die Verwaltung der Registrare/CNAs ist eine weitere Aufgabe der Registry bzw. der VDBs. (Das ICANN-System ist da natürlich speziell.)

Konfliktauflösung

Im DNS wird das selten gebraucht, und wenn, dann ist das entweder ein Thema für die Rechtsabteilung der Registry, von Gerichten oder die UDRP.

Es ist im CVE-System nicht so selten, dass das zu Unstimmigkeiten kommt: Es kann Duplikate geben, wenn eine Schwachstelle von mehreren CNAs eingebracht wird, oder es kann verschiedene Meinungen geben, ob die Meldung überhaupt die Kriterien für die Vergabe eines Identifiers erfüllt. Hier kommen die „Roots“ ins Spiel, die als Schiedsrichter fungieren und Ungereimtheiten auflösen sollen.

Direktvergabe

Manche Registries erlauben die Domainregistrierung auch direkt – oft aber zu prohibitiv hohen Preisen, weil sie sich nur als Fallback sehen, wenn das normale Registrar-System umgangen werden muss. Auch Mitre hat eine Direktvergabe von CVEs angeboten, aber davon abgeraten, diese zu nutzen; der Weg über die CNAs ist klar der präferierte.

Was drohte, wegzubrechen?

Mit der Meldung, dass die Finanzierung des CVE-Systems gestoppt wird, war die natürliche Reaktion: Welche dieser Funktionen ist dadurch betroffen? Falls es nur die Direktvergabe ist, tut das deutlich weniger weh, als wenn die zentrale Datenbank, ihre APIs für CNAs und die Webseite offline gehen würde.

Das Teure sind die manuellen Prozesse: dort, wo eine qualifizierte Fachkraft einlangende Berichte bewertet, wo zwischen verschiedenen Aussagen entschieden werden muss und bei der administrativen Interaktion mit den CNAs. Der technische Weiterbetrieb der IT-System ist im Vergleich dazu finanziell harmlos.

Zu dem, was wirklich gefährdet war, haben wir nur Gerüchte gehört, aber keine belastbaren Informationen bekommen.

Alternativen

In der Szene wurde schnell nach Möglichkeiten gesucht, das drohende Ende des CVE-Systems zu kompensieren. Das ist nicht trivial, denn ein über Jahre gewachsenes System mit einem ganzen Ökosystem an Playern kann man nicht innerhalb von 24h ersetzen. Nichtsdestotrotz gibt es Ansätze, das Thema Vulnerability Databases neu zu denken.

Die EU Vulnerability Database

In der NIS2-Richtlinie wird der ENISA die Aufgabe zugewiesen, eine Europäische Schwachstellendatenbank zu betreiben. Dazu gab es viele Konsultationen mit dem CSIRTs Network (insb. den Mitgliedern, die auch als CNA fungieren), und man war sich einig, dass man eigentlich nicht das CVE-System duplizieren will, sondern als Ergänzung dienen will. So etwa hat sich ENISA als CNA registrieren lassen und einen Prozess definiert, wie nationale CSIRTs über die ENISA CVE-Registrierungen vornehmen können.

Die EUVD selbst fungiert primär als Aggregation bestehender VDBs, umfasst daher neben den Daten aus dem CVE-System auch die von GHSA, GSD, PYSEC und anderen. Die EUVD vergibt beim Importieren aus anderen VDBs eigene Identifier, die mit EUVD- beginnen. Es war initial nicht daran gedacht, selbst neue Schwachstellen im System zu registrieren, sondern diese immer über das CVE-System zu spielen.

Die EUVD war im April 2025 im „Soft Launch“, also im eingeschränktem Testbetrieb. Durch die Vorgänge rund um die CVE-Finanzierung wurde sie mit dem Hinweis auf eine „beta phase“ live geschalten.

In der jetzigen Form kann die EUVD das von Mitre betriebene System nicht ersetzen. Es gibt nicht die APIs zu CNAs, diese sind nicht bei ENISA registriert, und bei der ENISA fehlt auch die Manpower, die manuellen Prozesse umzusetzen.

Das kann sich alles in den nächsten 11 Monaten ändern.

Mit der Umsetzung des Cyber Resilience Acts wird die EUVD weitere Use-Cases implementieren müssen.

Das Global CVE Allocation System

Die Kollegen von CIRCL, die für Open Source für die Cybersecurity-Community bekannt sind – und mit Vulnerability-Lookup auch ein spannendes Werkzeug zum Betrieb einer Schwachstellendatenbank geschrieben haben, haben mit GCVE eine Initiative gestartet, wie mit einem sehr dünnen Layer über mehrere Schwachstellendatenbanken ein einheitliches System gebaut werden kann.

Wieder in der DNS-Analogie gedacht: sie wollen eine schlanke root-Zone bauen, und einzelne TLDs (oder hier Identifier von VDBs) an Registries zu delegieren. Dort spielt dann die Musik, aber solange es einheitliche APIs gibt, ist das alles kein Problem für die Nutzer.

Während die normalen VDBs „thick registries“ implementieren (die Registrare übertragen alle Daten an die Registry), so ist GCVD mehr eine „thin registry“, in der Verweise auf die Datenbanken der Registrare gespeichert werden, bzw. in der Namensräume delegiert werden.

Die CVE Foundation

Mitre hat schon länger einen Beirat, der sie beim Betrieb des CVE-Systems beraten und beaufsichtigen soll. Aus dieser Gruppe von Personen heraus will sich jetzt eine gemeinnützige Stiftung („CVE Foundation“) gründen, die versuchen wird, das ganze System auf eine komplett neue rechtliche und finanzielle Basis zu stellen.

Zusammenfassung

Das Ökosystem der Schwachstellendatenbanken, von denen CVE die wichtigste ist, ist ein wichtiger Baustein in der globalen Sicherheitsarchitektur auf technischer und operativer Ebene. Es wird zwar nicht von einer Person in Nebraska betrieben, wie das im xkcd-Cartoon zu Software-Abhängigkeiten so schön beschrieben wird, aber manchmal ist die koordinierende Arbeit eines kleinen Teams sehr wohl eine tragende Säule, auf die man nicht spontan verzichten kann.

Ich hoffe wir schaffen es, aus dieser Episode zu lernen und das System auf eine tragfähigere Basis zu stellen.

Mehrere FortiGate-Modelle von Backdoor betroffen

CERT.at — Wed, 16 Apr 2025 10:34:52 GMT+0100

Hinweis: Der ursprüngliche Autor dieses Beitrages ist Kamil Mankowski. Alexander Riepl war nur an der Veröffentlichung und unterstützend an der Übersetzung beteiligt.

Am Freitag, den 10. April, veröffentlichte Fortinet Informationen über eine weltweite Kompromittierung von FortiGate-Geräten, die Angreifer:innen dauerhaften lesenden Zugriff ermöglichten. Die Angreifer:innen nutzten offenbar drei bekannte Schwachstellen in der SSL-VPN-Funktion, um sich Zugang zu den Geräten zu verschaffen, und eine Hintertür im Dateisystem zu platzieren um den illegalen Zugriff nachhaltig zu ermöglichen.

Hintergrund

FortiGate ist eine VPN-Lösung, die den Fernzugriff auf Unternehmenssysteme ermöglicht. Sie bietet als eine ihrer Optionen die Legacy-SSL-VPN-Lösung. Diese Funktion war zuvor durch die kritischen Schwachstellen CVE-2022-42475, CVE-2023-27997 und CVE-2024-21762 gefährdet. Jede dieser Sicherheitslücken ermöglichte es entfernten, nicht authentifizierten Angreifer:innen, über eine speziell gestaltete Anfrage Code auf dem Gerät auszuführen.

Angreifer:innen nutzten diese Schwachstellen, um Fortigate-Geräte zu kompromittieren und platzierten dann einen symbolischen Link in einem Ordner, der zur Bereitstellung von Sprachdateien verwendet wird. Auf diese Dateien kann ohne Authentifizierung zugegriffen werden, so dass jeder, der den Speicherort kennt, Lesezugriff auf das Dateisystem, einschließlich der vollständigen Gerätekonfiguration, erhalten kann. Die von Fortinet bereitgestellten Patches für die Schwachstelle entfernten den symbolischen Link nicht.

Die ShadowServer Foundation hat weltweit mehrere tausend gefährdete Geräte identifiziert. Unsere interne Analyse zeigt, dass in Österreich in der Spitze bis zu 840 Geräte betroffen sind, und die aktuelle Zahl ist etwas höher als die von ShadowServer für Österreich gemeldete Zahl.

Potentiell betroffene Systeme

Alle FortiGate-Geräte, physisch oder virtuell, die die SSL-VPN-Funktion aktiviert haben oder hatten und jemals für eine der genannten Schwachstellen anfällig waren (siehe betroffene FortiOS-Versionen in den Advisories - 1, 2, 3), sind potenziell gefährdet. Nach Angaben von CERT.nz könnten die Angriffe bereits im Jahr 2023 stattgefunden haben.

Obwohl die Details des Angriffs nicht veröffentlicht wurden, wurde CERT.at Anfang des Jahres von einer dritten Partei über diesen Vorfall informiert. Seither beobachten wir die Situation in Österreich genau und informieren seit Februar aktiv die Netzbetreiber.

Nach Angaben von Fortinet wurden ihre Kund:innen durch das Unternehmen kontaktiert.

Abhilfe

Wenn der Verdacht besteht, dass eines ihrer Systeme kompromittiert wurde, empfehlen wir Ihnen das betroffene System forensisch zu untersuchen und gegebenenfalls die im Rahmen Ihrer Sicherheitsrichtlinien definierten Prozesse einzuleten. Fortinet hat ebenfalls Abhilfemaßnahmen veröffentlicht, darunter:

AV/IPS Signature welche den bösartigen Symlink entdecken - bei Geräten mit aktivem IPS
FortiOS Versionen 7.6.2, 7.4.7, 7.2.11 & 7.0.17, 6.4.16 welche den Symlink entfernen

Fortinet hat außerdem Richtlinien zur Wiederherstellung kompromittierter Geräte veröffentlicht. Wenn Sie unsere Warnung vom Februar erhalten haben, beachten Sie bitte, dass Updates verfügbar sind, die das bösartige Artefakt entfernen.

Weitere Empfehlungen

Wir empfehlen Administrator:innen dringend sicherzustellen, dass ihre Firmware auf dem neuesten Stand ist. Für Unternehmen, die SSL VPN verwenden, empfehlen wir, eine Migration zu alternativen Fernzugriffsmethoden in Betracht zu ziehen, da es in der Vergangenheit immer wieder zu Sicherheitsproblemen kam. Fortinet bietet je nach Anwendungsfall Migrationsleitfäden zu IPSec oder Dial-up VPN an.

Start der Austria Cyber Security Challenge 2025

CERT.at — Wed, 19 Feb 2025 10:59:35 GMT+0100

Auch heuer unterstützt CERT.at die Austria Cyber Security Challenge, quasi die Österreichische Staatsmeisterschaft der Cybersicherheit.

Hier die wichtigsten Eckpunkte, alle Informationen gib es auf https://acsc.land/.

Am 1. März erfolgt der offizielle Startschuss zur Qualifikation für die Austria Cyber Security Challenge (ACSC 2025). Der Verein Cyber Security Austria sucht heuer bereits zum 13. Mal nach jungen IT-Security-Talenten, um die Elite der österreichischen NachwuchshackerInnen zu finden und zu fördern. Dieser prestigeträchtige Bewerb ist nicht nur ein spannender Wettkampf, sondern auch ein essenzieller Beitrag zur Stärkung der digitalen Sicherheitskompetenz in Österreichs – und als Grundlage für viele Europäische Modelle wichtige Voraussetzung für unsere digitale Souveränität.

Warum die ACSC unverzichtbar ist: Die Bedeutung der ACSC zeigt sich in der zunehmend alarmierenden Cyber-Bedrohungslage. Cyberkriminalität und Spionage nehmen weltweit rasant zu, während ein massiver Fachkräftemangel im Bereich Cybersicherheit herrscht. Studien zeigen, dass allein in Europa über 500.000 Fachkräfte in der Cybersicherheit fehlen.

Dieser Mangel hat gravierende Folgen: Kritische Infrastrukturen, wie Energieversorgung, Krankenhäuser oder Verkehrsnetze, sind zunehmend Angriffen ausgesetzt, während Unternehmen Milliarden durch Cyberangriffe verlieren. Die ACSC will an beiden Fronten Abhilfe schaffen: Sie macht auf die Dringlichkeit einer starken Cybersicherheitskultur aufmerksam und dient gleichzeitig als Plattform, um Talente frühzeitig zu entdecken, zu fördern und zu vernetzen. Denn: Ohne ausreichend geschulte Fachkräfte kann Österreichs digitale Zukunft nicht gesichert werden.

Joe Pichlmayr, Mitinitiator der ACSC, unterstreicht: „Die ACSC ist eine essenzielle Initiative, um den Nachwuchs zu stärken und unsere Gesellschaft vor den wachsenden Gefahren im Cyberspace zu schützen. Wir müssen junge Menschen frühzeitig für dieses Thema begeistern.“

So funktioniert die ACSC: Interessierte TeilnehmerInnen können sich ab sofort über die Website https://acsc.land/ anmelden und ihre Reise in die Welt der Cybersicherheit antreten. Die ACSC richtet sich sowohl an Neulinge als auch an erfahrene IT-Talente. Mit einer großen Bandbreite an Aufgaben und Schwierigkeitsgraden bietet der Bewerb jedem die Chance, sein Potenzial unter Beweis zu stellen.

Der Qualifikationsbewerb findet online statt und kann bequem von zu Hause, der Schule oder dem Büro aus absolviert werden. Die besten 20 SchülerInnen, 20 Studierenden und 18 teilnehmenden der offenen Klasse werden zum Finale eingeladen, das Mitte Juni traditionell im Rahmen der IKT-Sicherheitskonferenz des Österreichischen Bundesheers in Dornbirn, Vorarlberg, ausgetragen wird. Hier treten die FinalistInnen in Teams gegeneinander an, um den Titel des besten Nachwuchstalents in der IT-Security zu erringen.

Von der Challenge zur Karriere Die ACSC ist mehr als nur ein Wettbewerb: Sie ist eine Brücke in die professionelle Welt der Cybersicherheit. Die 25 besten Schülerinnen und Studierenden werden in das Center of Excellence eingeladen, wo sie von Mentorinnen unterstützt und weitergefördert werden. Hier entstehen Netzwerke zwischen Talenten, Profis und Unternehmen – ein entscheidender Vorteil für eine erfolgreiche Karriere.

Darüber hinaus qualifizieren sich die besten TeilnehmerInnen für das Training des Team Austria, das Österreich bei der European Cyber Security Challenge (ECSC 2025) vertritt. Wer also sein Talent unter Beweis stellt, hat die Chance, auf europäischer Ebene mitzuspielen und sich mit den Besten zu messen.

Der „Mozart“ unter den Hackern kommt natürlich aus Salzburg!

Zu den allerbesten der Welt zählt der erst 18 jährige Salzburger Matthias P. der im Vorjahr nicht nur alle drei Vorrunden und das Finale der prestigeträchtigen openECSC für sich entscheiden konnte, sondern auch als einziger der über 4.000 TeilnehmerInnen aus 142 Ländern der Welt alle gestellten Aufgaben der Vorrunde zu lösen vermochte.

„Für mich ist das immer eine großartige Gelegenheit coole Leute kennenzulernen und mich spannenden Challenges zu stellen. Was hauptsächlich mit Neugierde angefangen hat sich recht rasch zu einer größeren Leidenschaft entwickelt. Es macht richtig viel Spaß, Teil dieser Community zu sein“ so der junge Salzburger.

Matthias ist übrigens eine starke Stütze für unser Nationalteam das bei EM 2024 in Turin den tollen 5. Rang erreichen konnte.

Spaß, Wissen und langfristiger Nutzen Wie ACSC-Initiator Joe Pichlmayr betont, sollte die Challenge vor allem aber auch lehrreich sein und Spaß machen: „Unsere Top-SpielerInnen schaffen die Herausforderungen oft in wenigen Tagen, aber auch nur mit intensivem Einsatz. Für neue Teilnehmer*innen empfehlen wir, die Aufgaben in kleinen Schritten zu lösen und sich nicht entmutigen zu lassen. Der Weg ins Finale ist hart, aber er lohnt sich!“

Ausprobieren und üben kann übrigens jeder kostenlos auf https://acsc.land/de/resources/

Cybersicherheit für alle Selbst wenn die Aufgaben der ACSC zu anspruchsvoll erscheinen, gibt es keinen Grund, aufzugeben. Für Einsteiger bietet die Security Quizduell App einen spielerischen Einstieg in die Welt der Cybersicherheit. „Je früher wir Interesse wecken, Computer nicht nur zu bedienen, sondern auch zu verstehen, desto eher können wir Talente entdecken und fördern“, erklärt Pichlmayr.

Warum Cybersicherheit wichtig ist Daten sind das Rückgrat unserer modernen Gesellschaft. Von kritischen Infrastrukturen über sensible Gesundheitsdaten bis hin zur nationalen Sicherheit – die Verfügbarkeit und Integrität digitaler Systeme ist essenziell. Cybersicherheits-Expertise ist daher nicht nur ein gefragtes Berufsfeld, sondern ein Grundpfeiler für die Stabilität unserer digitalen Welt.

Im vergangenen Jahr wurden weltweit mehr als 21 Milliarden Datensätze gestohlen – ein Beleg dafür, wie dringend Cybersicherheit gebraucht wird.

Jetzt mitmachen und Teil der Zukunft werden! Anmeldung und weitere Informationen: https://verbotengut.at/anmeldung/

Risikobild 2025

CERT.at — Thu, 30 Jan 2025 15:33:45 GMT+0100

Das österreichische Verteidigungsministerium präsentierte am 27. Jänner das "Risikobild 2025". Wie nicht anders zu erwarten war, dominieren geopolitische Herausforderungen die Risikolandschaft. Der Ukraine-Krieg, die Spannungen zwischen China und den USA sowie der Nahe Osten sind auch die ersten Themen, die mir einfallen würden, wenn mich jemand nach aktuellen Risiken fragt. Wie ordnet sich das Thema Cybersecurity hier ein?

Laut dem Risikobericht sind Cyberangriffe vor allem ein Werkzeug, das in den genannten geopolitischen Konflikten eingesetzt wird. Danach müssen wir uns vor allem bei Russland, China und dem Iran darauf einstellen, dass sie Cyberangriffe als Teil ihres Arsenals sehen und auch einsetzen. Der Bogen spannt sich von der Nutzung in militärischen Operationen bis zur Sabotage, letztere vor allem als russisches Mittel zur Zielerreichung. So weit, so bekannt und nicht neu.

Gewundert hat mich beim Lesen und Hören der Präsentation des Risikobildes aber, wie oft Cyberangriffe mit Desinformation in einem Satz vorgekommen sind. Als Teil von hybriden Angriffen, hybriden Strategien, hybrider Kriegsführung werden parallel Cyberangriffe und Desinformationskampagnen durchgeführt. Beide gemeinsam gefährden laut dem Risikobild die Demokratie bzw. demokratische Prozesse. Dabei gibt es Überschneidungen zwischen beiden Risiken, auch wenn sie im Kern sehr unterschiedlich sind.

So kann man beispielsweise argumentieren, dass mittels der Werkzeuge der Cybersecurity verhindert bzw. entdeckt werden kann, ob ein Social Media Posting über einen gehackten Account verbreitet wurde. Oder ob ein Deepfake-Videocall nur deshalb möglich war, weil der Zugang zum Call über eine Schwachstelle im Call-Protokoll herstellbar war. Oder dass eine Website gefälscht und als Ersatz für eine echte Seite präsentiert wird, wie es beispielsweise bei der Doppelgänger-Kampagne der Fall war.

Aber der Kern von Desinformation, die Verbreitung von bewusst falschen Informationen, ist ein soziales Thema, ein politisches Thema bzw. ein Kommunikationsthema. Das Risikobild macht die beiden nicht zu einem, es wirft sie aber gemeinsam in einen Topf. Und hier könnte sich ein Problem für uns in der Cybersecurity-Welt anbahnen. Denn wie wir über die letzten Jahre gesehen haben, ist Cybersecurity schwer zu erklären, vor allem, wenn man es korrekt machen will. Desinformation hat zwar viele Aspekte, aber was eine bewusst falsche Information ist, versteht jede und jeder.

Für die Cybersecurity-Welt entsteht daher die Gefahr, dass die gleichen Experten zu beiden Themen befragt werden und dass das eine Thema, Desinformation, vorrangig besprochen wird, weil es einfacher zu verstehen ist und emotional aufgeladen werden kann. Es wird sich zeigen, ob ich mit meiner Befürchtung recht habe und wir in den kommenden Monaten öfter dazu aufgefordert bzw. eingeladen werden, zu Desinformation eine fachliche Beurteilung oder Meinung abzugeben. Gut wäre das vermutlich nicht, wie man beispielsweise in den USA sieht, wo die nationale Cyberbehörde CISA beschuldigt wurde, im Rahmen von Desinformations-Schwerpunktprojekten "vom Weg abgekommen zu sein" (Link zu Krebs on Security Bericht)

Ein anderer Aspekt aus dem Risikobild 2025 ist aber mindestens genauso spannend. Als Gegenmaßnahme zu Cyberangriffen nennt der Bericht einen gesamtheitlichen Ansatz aus Vernetzung, Infrastruktursicherheit und Bewusstseinsbildung. Das internationale Teilen von Informationen ist, so der Bericht, ein essentieller Bestandteil wirksamer Abwehr. Zitat aus dem Kapitel über aktuelle Cyberbedrohungen und österreichische Gegenmaßnahmen: "In Österreich wird diese Vernetzung durch die Nationale Koordinierungsstruktur für die Cybersicherheit aktiv gelebt."

CERT.at ist der gelebte ganzheitliche Ansatz nach dieser Definition. Wir verbringen unsere Tage und unsere Nächte mit Information, Vernetzung, Unterstützung beim Schutz von Infrastrukturen und mit Bewusstseinsbildung. Als Teil der nationalen Koordinierungsstruktur ist das nicht nur unsere Mission sondern auch unsere Pflicht. Es ist zwar schade, dass Österreich wenige andere Mittel hat, um Cyberangriffe nachhaltig zu verhindern, aber wenn Vernetzung und Informationsverteilung auch laut dem Risikobild die beste Option sind, die wir haben, dann machen wir das zumindest so gut, wie es irgendwie geht.

Link zum Risikobild 2025

E-Voting als Lösung?

CERT.at — Fri, 11 Oct 2024 15:27:48 GMT+0100

Weil letztens vom Gemeindebund das Thema Wahlen über das Internet aufgebracht wurde, will ich meine Gedanken dazu niederschreiben. Das ist jetzt kein vollumfängliche Behandlung des Themas, ich habe mich auch nicht in die Judikatur des VfGH eingelesen.

Problemdefinition

Was müssen Wahlen erreichen? Nach welchem Maßstab müssen wir messen, ob sie ihr Ziel erreicht haben?

Meiner Meinung nach gibt es hier zwei große Ziele, wobei das zweite gerne übersehen wird:

Ermittlung des Wahlsiegers
Die Verliererpartei dazu zu bringen, dass sie das Ergebnis anerkennt. Wir wollen keine österreichische Version des 6. Jänner 2021 erleben.

Für den zweiten Punkt ist es daher nicht nur nötig, dass die Wahl mathematisch beweisbar korrekt abgelaufen ist, sondern dass der Vorgang für jeden Bürger verständlich und nachvollziehbar ist. Jeder Beisitzer kann die Stimmzettel mitzählen und das Aufsummieren der Ergebnisse vom Sprengel bis rauf zum Staat braucht nicht mehr als Volksschulmathematik. Wie das Wahlgeheimnis gewährleistet wird, ist auch einfach und anschaulich erklärbar.

Ja, in der Theorie kann e-Voting auch geheimes Wählen umsetzen, aber die Erklärbarkeit und Transparenz für Jedermann ist einfach nicht auf dem gleichen Level.

Aufwand durch die Briefwahl

Es wird schon wahr sein, dass der Prozess für die Gemeinden aufwändig ist, aber was genau ist die Lösung? Dazu muss erstmal klar sein, was eigentlich das Problem ist:

Das Ausstellen und Versenden der Briefwahl-Unterlagen?
Das Berücksichtigen dieser Möglichkeit in den Wählerlisten, damit nicht doppelt gewählt werden kann?
Die Verarbeitung der eingelangten Briefstimmen in den Gemeinden?
Die Zuordnung der Stimmen zu den Heimatgemeinden?

Ich kenne die aktuellen Details nicht, aber eine Sache könnte das ganze etwas entspannen: warum müssen die Briefwahlstimmen getrennt und nach den normalen Wahlzetteln ausgezählt werden? Warum werden diese nicht in Ruhe vor oder während der Wahl aus dem äußeren Kuvert genommen und in die normale Urne dazu gegeben? Ja, dazu müssten die Briefwahlbriefe auf Sprengelebene behandelt werden, und die Deadline für deren Eintreffen müsste vorverlegt werden. Dafür könnte man sich das Tracken der ausgegebenen Briefwahl-Stimmzettel fast sparen, denn das Eintreffen eines Briefes läuft dann 1:1 wie das Wählen vor Ort. Das Gegenargument ist, dass dann die Übermittlung der Briefstimmen in die Sprengel überwacht werden muss. Ob ein Wähler in Person in das Wahllokal kommt, oder ob seine Briefstimme im Wahllokal verifiziert und eingeworfen wird, sollte vom Aufwand her sehr ähnlich sein. Damit skaliert das bis zu einem beliebig hohen Briefwahlanteil - und erhält das Wahlgeheimnis auch bei nur einer einzigen Briefwahlstimme.

Ein Wählen am Wahltag in einem anderen Wahllokal ist damit natürlich nicht mehr möglich.

Anders formuliert: wir haben den Wahlkarten- bzw. Briefwahlprozess unter der Annahme entworfen, dass er die Ausnahme ist. Das stimmt nicht mehr, daher gibt es vielleicht eine andere Herangehensweise, die auch bei über 40% Briefwahlstimmen noch gut funktioniert?

Was machen wir bei Unwettern?

Bei der NRW 2024 hatten wir Glück: ein Wahltermin zwei Wochen früher, und die Wahlen wären in manchen Bezirken schlicht nicht durchführbar gewesen. Das mag in 5 Jahren anders sein, oder eine andere Wahl treffen.

Wir brauchen dazu einen vorab vereinbarten Prozess. Das ist ein nicht triviales Problem, denn eine Wahl kann ich nicht so einfach verschieben wie ein Fußballspiel. Da besteht das Potenzial für Missbrauch.

Da ist erstmal die Entscheidung, dass die Wahl am geplanten Tag nicht regulär durchführbar ist. Wer darf das, mit welchen Safeguards, entscheiden?

Und was dann? Eine spontane Verlegung eines Wahllokals (die Schule steht unter Wasser, wir weichen ins Wirtshaus aus) lässt sich noch machen, aber was, wenn der halbe Ort am Sandsäcke Schaufeln ist, und der Rest panisch Wertsachen in die oberen Stockwerke bringt? Kann verschoben werden? Auf welcher Ebene?

Ein spontanes Ausweichen auf E-Voting hilft hier nicht. Wenn die Bevölkerung gerade am Retten von Leben und Besitz ist, dann wird Wählen sicher keine Priorität haben. Funktioniert es überhaupt noch technisch? Gibt es Connectivity? Kabel/DSL oder Mobil? Und falls ja, dann sind Fähigkeiten, das auch wirklich zu machen, in manchen Bevölkerungsschichten konzentriert. Damit verschiebt sich aber zwangsläufig das Wahlergebnis in Richtung der Parteien, die tendenziell eher die jüngeren und technikaffineren Wähler ansprechen.

Zusammenfassung

Es macht durchaus Sinn, darüber nachzudenken, wie wir Wahlen mit einem hohen Anteil an Briefstimmen effizient abwickeln können, und wie wir gut auf spontane Notfälle reagieren können. E-Voting ist hier aber sicher nicht die Lösung.

Geoblocking als einfache DDoS-Abwehr

CERT.at — Fri, 27 Sep 2024 13:08:42 GMT+0100

Distributed Denial of Service (DDoS) Angriffe gibt es in diversen Varianten, das reicht von reflected UDP mit hoher Bandbreite über Tricksereien auf Layer 4 (etwa TCP-SYN Flooding, oder auch nur Überlastung der State-Tabellen in Firewalls) bis hin zu Layer 7 Angriffen mit vielen teuren http Anfragen.

Aktuell sehen wir gerade letztere, dazu wollen wir ein paar Hinweise geben:

Es geht hier nicht um hohe Bandbreiten, sondern um viele Anfragen an den Webserver. Der Engpass ist daher selten die Internetanbindung, sondern die Last auf Firewall, Load-Balancer, Webserver und dahinterliegenden Datenbanken.
Daher hat der ISP nur eine sehr beschränkte Rolle in der Verteidigung: er muss keine Gbit/s an Störverkehr ausfiltern, und er hat wegen TLS nur sehr wenig Sichtbarkeit auf Layer 7.
Um echte http Anfragen abzusetzen, muss eine TCP-Session etabliert werden, was einen vollen 3-way Handshake voraussetzt. Das funktioniert mit gefälschten IP Source Adressen nicht, d.h. der Angreifer kann seinen Ursprung maximal mit einem VPN oder sonstigen Proxys verschleiern.
In diesen Fällen kann es daher eine einfache Erstmaßnahme sein, von der globalen Erreichbarkeit der Webseite abzurücken. Wenn über 95 % der legitimen Besucher aus dem eigenen Land oder der D-A-CH Region kommen, dann ist es besser, diese zu bedienen und den Rest der Welt auszusperren, als dass der Server für alle potenziellen Nutzer nicht erreichbar ist.
Dieses Geo-Blocking kann als Allow (etwa: „AT, DE, CH dürfen, aber der Rest der Welt ist ausgesperrt“) oder als Deny („Von XX kommt nur Schrott, die blockiere ich“) implementiert werden.
Am wirksamsten ist das Geo-Blocking möglichst weit draußen: Natürlich kann man das direkt im Webserver auf Applikationslevel (Apache/nginx/…) machen, aber das hilft nichts, wenn der Loadbalancer davor schon wegen überlaufender Session-Tables eingeknickt ist.
Kommerzielle Firewalls und Loadbalancer haben typischerweise Geo-Blocking als Feature implementiert, die genauen Details sind von Hersteller zu Hersteller verschieden.
Mit Linux Bordmitteln ist das auch leicht machbar, dazu will ich im Weiteren ein paar Tipps geben.

Händisch sich die Listen von Netzblöcken zusammenzusuchen und diese dann direkt in Firewall-Regeln zu konvertieren, skaliert gar nicht. Das ist zum Glück aber auch nicht nötig.

Der Linux-Kernel kennt „ipsets“, damit wird das Testen, ob eine IP-Adresse in einer langen Liste von Prefixen enthalten ist, deutlich effizienter als ein sequenzielles Durchgehen. Damit lässt sich das Problem „Geo-Blocking unter Linux“ in zwei Schritte unterteilen:

Konfiguration / Aktualisierung von ipsets zu all den Staaten, die man speziell behandeln will.
Einrichten einer Firewallregel, die die gewünschte Allow oder Deny Policy mit Verweisen auf die ipsets umsetzt.

Ersteres lässt sich etwa mit einem einfachen Perl-Script umsetzen, dass die Daten von RIPEstat nimmt. Andere Datenquellen dafür sind u.a. ip2location.com oder ipdeny.com - es mag ein bisschen sed Scripting nötig sein, um daraus fertige ipsets im Kernel zu bauen.

Zweiteres ist von der gewünschten Policy und dem konkreten Setup abhängig: steht diese Firewall vor dem Webserver oder betreibe ich den Filter direkt am Webserver? Bei der Konfiguration der Firewall mittels iptables ist die Option „-m set“ die relevante, die Dokumentation dazu gibt es in der Manpage iptables-extensions. Ein Allow-Listing könnte damit so implementiert werden:

iptables -I FORWARD 3 -m set ! --match-set ipv4_AT src --destination WEBIP -m tcp -p tcp --dport 443 -j DROP

Auf Deutsch: Beim Weiterleiten filtere die Pakete weg, die:

nicht aus Österreich kommen (! --match-set ipv4_AT src), und
zum Webserver am TCP port 443 gehen sollen

Im Netz findet man leicht viele weitere Beispiele, wie das alles umgesetzt werden kann.

Addendum 2024-09-29:

Will man gezielter blocken, so kann man das etwa mit folgenden Schritten machen:

1. Messen, welche IP-Adressen beim Angriff mitmachen: Das hängt vom konkreten Setup ab, man muss nur aufpassen, dass man keine legitimen, aber hochfrequenten Zugriffe mitnimmt.

2. Aggregation in Netzblöcke: Die aktuelle Tätergruppe nutzt vor allem VPNs, da sind dann viele der Adressen nahe beisammen. Auf Ebene BGP Prefixe kann diese etwa so aggregieren:

(echo "begin"; echo "verbose"; cat ips.txt ; echo "end") | netcat whois.cymru.com 43 | fgrep '|' | awk '{print $5}' | sort | uniq -c | sort -rn

Damit hat man dann eine Liste von Prefixen mit der Zahl der Angreifer-IP-Adressen, die jeweils drinnen sind. Mit den ersten paar Einträgen kann man einen Großteils des Verkehrs abblocken.

Heute am Wahltag komm ich damit auf folgende Top 10:

    119 155.94.240.0/20
    103 104.223.96.0/20
     41 204.44.112.0/20
     39 87.249.132.0/24
     32 107.161.86.0/23
     30 198.96.94.0/23
     29 69.12.94.0/23
     23 192.161.188.0/22
     18 81.92.200.0/22
     18 149.36.50.0/24

3. Diese Netzblöcke auf BGP Ebene zu blocken, ist wahrscheinlich Overkill, aber als Filter vor dem eigenen Webserver ist das sehr brauchbar.

YubiKeys klonen?

CERT.at — Wed, 04 Sep 2024 15:21:38 GMT+0100

Dass Passwörter allein zum Anmelden im Netz nicht der Weisheit letzter Schluss sind, wissen wir schon lange. Ein vielversprechender Ansatz, das alles viel besser zu machen ist FIDO2 / Webauthn / Passkeys.

Die populärste Implementation dieses Standards in der Form eines USB-Sticks kommt von Yubico, die YubiKeys. Heute gab es dazu eine reißerische Meldung: diese lassen sich klonen. Nachzulesen bei Ars Technica, Heise oder direkt bei NinjaLab, die die Schwachstelle gefunden haben.

Das ist mal klarerweise nicht gut.

Aber wie so oft bei Schlagzeilen dieser Art lohnt es sich, genauer zu lesen, was eigentlich passiert ist, und wie realistisch die Angriffe wirklich sind.

Hier ist meine Einschätzung

Das Ganze ist kein Fehler von Yubico, sondern von Infineon. Deren proprietäre Software für ihre Sicherheitschips, die die mathematischen Basisoperationen implementiert, auf denen Kryptographie basiert, hat ein Problem: Aus der Laufzeit einer Operation kann man Rückschlüsse auf den verarbeiteten Schlüssel ziehen.
Es trifft daher nicht nur YubiKeys, sondern noch andere Produkte. Die YubiKeys waren nur aufgrund ihrer Verbreitung das Testobjekt von NinjaLab. Da werden noch einige spannende Fälle dazukommen.
Neuere YubiKeys verwenden eine andere Library, der beschriebene Angriff funktioniert ab Firmwareversion 5.7 nicht mehr. Ein Update der Firmware ist bei YubiKeys nicht vorgesehen. Ob die neue fehlerfrei ist, oder bloß andere Probleme hat, kann man nicht wissen.
Der Angriff braucht den physischen Zugriff auf den YubiKey, und ermöglicht, einen Klon herzustellen, mit dem man sich dann auch anmelden kann. Es ist kein Angriff über das Internet (oder USB oder NFC), es gibt keine Möglichkeit, alle YubiKeys da draußen mit irgendwelchen Scans, Würmern, Malware oder sonstiger böse klingender Software anzugreifen.
Für den Fall, dass der YubiKey einfach nur gestohlen (oder verloren) wird, bringt die Schwachstelle keine weitere Angriffsfläche.
Das Szenario eines erfolgreichen Angriffs ist daher das „Ausleihen“ des Sticks. Der Angreifer verschafft sich temporär Zugang zum YuibKey, macht seine schwarze Magie und gibt den Stick zurück, damit der Eigentümer keinen Verdacht schöpft.
Das Problem mit dem Zurückgeben ist, dass es für den Angriff nötig ist, den Sicherheitschip freizulegen. Das ist schon mal nicht ganz einfach, zusätzlich müssen vor der Rückgabe die entstandenen Spuren verwischt werden, was auch nicht trivial ist.
Der YubiKey ist meist nur der 2. Faktor, der erst nach Username/Passwort zum Tragen kommt.

Damit ergibt sich für mich, dass ich keine Hemmungen habe, meinen privaten YubiKey mit Firmware 5.2.7 weiter zu nutzen.

Lessons (re-)learned

Der Schritt von mathematischer sicherer Kryptographie zu einer sicheren Implementation dieser Algorithmen in echten physikalischen Systemen ist ein langer und schwieriger. Es gibt hier jede Menge Fallstricke.
Der beschriebene Angriff über einen laufzeitbasierten Seitenkanal ist nicht neu. Es ist erschreckend, dass Infineon Software verkauft, die das nicht berücksichtigt.
Sicherheitszertifizierungen haben nur beschränkten Wert. NinjaLabs schreibt:

This vulnerability – that went unnoticed for 14 years and about 80 highest-level Common Criteria certification evaluations – is due to a non constant-time modular inversion.

Das ist ernsthaft enttäuschend. Man beachte dazu den Artikel 28 der NIS2 Richtlinie.

Ein paar Gedanken zur „Überwachung verschlüsselter Nachrichten“

CERT.at — Tue, 03 Sep 2024 14:47:59 GMT+0100

Vor 7 Jahren habe ich schon einmal einen längeren Blogpost zu Gesetzesentwürfen geschrieben, mit denen damals die Möglichkeit einer Einbringung von Überwachungssoftware für polizeiliche Zwecke ermöglicht hätte werden sollen.

Jetzt sind wir wieder so weit, die ÖVP hat das Thema im Wahlkampf aufgegriffen und meint, dass aktuelle Vorfälle die Notwendigkeit hinreichend untermauern. Ich will hier jetzt keine Brandrede gegen jegliche Überwachungsideen halten, sondern ein paar Fakten klarstellen, die gerne übersehen werden.

Details zum aktuellen Gesetzesentwurf („Entwurf eines Bundesgesetzes, mit dem das Staatsschutz- und Nachrichtendienstgesetz geändert wird“ - 350/ME XXVII. GP) sind auf der Parlamentswebseite abrufbar. Mein Kollege Alexander Riepl hat dazu auch schon einen Blogpost geschrieben.

Dieses Dokument geht bewusst nicht auf alle Aspekte des Entwurfes ein.

Die Telefonüberwachung als Vorbild ist falsch

Dass der Staat gerne Einblicke in die Kommunikation seiner Bürger hätte, hat eine lange Tradition, die bis in die Habsburgerzeit (Metternich ist da nur das bekannteste Gesicht davon) zurück reicht. Zuerst ging es um Briefe, später auch um das Telefon. So eine Überwachung brauchte keinen direkten Zugang zum Überwachten, ein Eingriff im Postamt bzw. der Telefonvermittlung reichte aus, um einen Zugriff auf die Kommunikation zu erlangen.

Wie so oft in der Menschheitsgeschichte hat es eine Zeit gedauert, bis sich ein Konsens zu den rechtlichen Rahmenbedingungen dafür gebildet hat. Nach überschießender Überwachung kam die Aufnahme des Brief- und Fernmeldegeheimnisses in das Staatsgrundgesetz (Artikel 10, 10a), wo ein enger Rahmen für zulässige Eingriffe gesetzt wird.

Nach den Snowden-Enthüllungen wurde das Schützen der Vertraulichkeit von digitaler Kommunikation durch den Einsatz von Kryptografie umfassend umgesetzt. Ein Mitlauschen bzw. Mitlesen rein durch das Ausleiten der übertragenen Datenpakete durch den ISP an die Polizei ist damit nicht mehr möglich.

Eine Analogie dazu in der alten Telefoniewelt wäre der Einsatz einer Sprache, die von den Mithörern nicht verstanden wird. Daher kam es zu Episoden, in denen der Staat die zu verwendende Sprache bei Telefongesprächen vorgeschrieben hat. Im militärischen Bereich ist der Einsatz von den Navajo Codespeakern im 2. Weltkrieg ein sehr erfolgreiches Beispiel von „analoger Verschlüsselung“.

Ein Gedankenexperiment dazu: Hätte eine kriminelle Vereinigung in den 60er Jahren sich ein paar Codespeaker geleistet, dann wäre die Polizei damals bei der Telefonüberwachung genau dort angestanden, wo sie jetzt das große Problem hat: Die Kommunikation wird verschlüsselt bevor sie übertragen wird, daher kann ein Mitlauschen keinen Klartext mehr liefern. Die Analogie zur „Quellen-TKÜ“ wäre hier ein Mitlauschen der Kommunikation zwischen dem Kriminellen und seinem Codespeaker, etwa mit einer Wanze nahe am Telefon. Eine Aussage der Art „macht euch keine Sorge, die Wanze wird nur aktiv sein, wenn auch wirklich gerade telefoniert wird, zu allen anderen Zeitpunkten wird der überwachende Beamte weghören“ hätte auch damals schon unglaubwürdig geklungen.

Hier kommen wir aber mit dem Artikel 9 des Staatsgrundgesetzes in Konflikt, das lautet: „Das Hausrecht ist unverletzlich.“

Handy als Wohnung

Vor 10 Jahren gab es schon die ersten Urteile, die den Umfang der persönlichen Daten in Smartphones für derartig groß ansehen, dass eine Durchsuchung des Handys einer Wohnungsdurchsuchung gleichkommt. Inzwischen hat uns allen der Ibiza-Skandal und die folgenden Durchsuchungen von Handys klargemacht, wie sensitiv die Daten sind, die wir alle auf unseren Geräten mit uns führen. Das reicht vom Kommunikationsarchiv, Bildarchiv, Adressbuch, Gesundheitsdaten, Social Media Streams, Lesehistorie (was etwa sexuelle Orientierung und Religionsbekenntnis verraten kann), Finanzdaten bis hin zum zweiten Faktor unserer digitalen Identitäten wie etwa ID-Austria.

Rechtlich ist daher der Zugriff des Staates auf die Mobiltelefone seiner Bürger extrem heikel. Was etwa mit einem beschlagnahmten Telefon alles gemacht werden darf, und wer kontrolliert, wie die so gewonnen Informationen genutzt werden, wird gerade auch wieder kontroversiell diskutiert.

Wenn wir aber das Handy als genauso schützenswert sehen wie eine Wohnung, dann ist der virtuelle Einbruch dort zwecks Installation der Überwachungssoftware mit einem verdeckten Einstieg in eine Wohnung zum Einbringen einer Wanze gleichzusetzen.

Dass das Thema Hausrecht für sie schwierig ist, greifen auch die Autoren des vorliegenden Entwurfes auf, denn sie schreiben klar in den EBs: „Ein Eindringen in vom Hausrecht geschützte Räume oder Durchsuchen von Behältnissen zwecks Installation des Programms ist nicht zulässig.“ Ein Blick zu unseren deutschen Nachbarn zeigt, dass man dort schon weiter ist: Die Ministerin will genau dieses erlaubt sehen. Ein österreichisches „wir werden das nicht brauchen“ halte ich daher nicht für dauerhaft gültig.

Handys haben weiters die Eigenschaft, dass wir sie laufend mit uns mitführen. Die korrekte Analogie zur Wanze neben dem alten Analogtelefon zuhause ist daher folgendes: Das BMI will eine Drohne laufend dem Überwachungssubjekt um den Kopf schwirren lassen, diese darf aber nur dann filmen und Tonaufnahmen machen, wenn derjenige gerade chattet oder telefoniert.

Einschränkung auf Kommunikationsüberwachung

Die ganze Fiktion des „wir machen nur Kommunikationsüberwachung“ in dem Gesetzesentwurf basiert darauf, dass es technisch machbar ist, die Fähigkeiten der Software so einzuschränken, dass wirklich nur genau das geht, was auch explizit vom Gesetz erlaubt wird.

Aus technischer Sicht ist das nicht haltbar.

Vor 30 Jahren war das noch denkbar: die ersten GSM-Telefone konnten telefonieren und nutzten das SMS als Medium für schriftliche Nachrichten. Ein aktuelles Smartphone ist ein äußerst komplexer Computer, der nebenbei auch noch telefonieren kann. Heute dominieren Over-the-top (OTT) Dienste: der Mobilfunkanbieter stellt nur die IP-Connectivity bereit (wenn das Handy nicht gerade per WLAN online ist), die eigentliche Kommunikationsdienstleistung wird von Dritten bereitgestellt. Bekannte Beispiele sind iMessage, WhatsApp, Telegram, Signal, Slack, Skype, Discord, Teams, Zoom, WebEx oder Threema. Manche fokussieren auf Privatnutzer, andere auf Firmen und bieten Chat, Telefonie und auch Videokonferenzen; alles sowohl zwischen zwei Teilnehmern als auch in Gruppen. Neben diesen Dienstleistern gibt es auch eine Vielzahl an Software, die es sehr einfach macht, solche Services selbst zu betreiben. Bekannt sind hier etwa Mattermost, NextCloud, RocketChat, Jabber, IRC, BigBlueButton und jede Menge an Software für Webforen. Dazu kommen noch Social Media Apps wie Facebook, Twitter/X, Instagram, SnapChat, BlueSky und Mastodon, die auch in vielen Fällen Chat und Video-Conferencing eingebaut haben. Multiplayer Online-Spiele inkludieren auch meistens einen Chat. Zu vielen dieser Dienste gibt es dedizierte Apps, aber fast alle davon sind auch über den Webbrowser nutzbar.

Es mag noch denkbar sein, dass die Überwachungssoftware es schafft, die Telegram-App laut Wunsch des Gesetzgebers korrekt zu überwachen und sich auch bei der Exfiltration der Chat-Historie an das Timeboxing des Gerichtsbeschlusses zu halten. Aber die Fülle an Anwendungen inklusive der Nutzung des Browsers? Das ist völlig unrealistisch.

Die korrekte Analogie

Das Festhalten am „wir wollen nur das Mittel der Telefonüberwachung retten“ kann aus all diesen Gründen nicht funktionieren.

Die korrekte Analogie für Überwachungssoftware am Handy ist eine laufende, verdeckte Hausdurchsuchung inklusive der Installation von Wanzen und Kameras plus einem Live-Tracking des Standortes des Überwachungszieles.

Das ist die Ultima Ratio der Ermittlungsmöglichkeiten. Wenn der Gesetzesentwurf ehrlich wäre, dann würde er genau das klar kommunizieren: wir brauchen den großen Lauschangriff nicht nur in physischen Wohnungen, sondern auch in ihren virtuellen Äquivalenten, den Computern und Handys.

Ich würde diese Möglichkeit nicht kategorisch ausschließen, insbesondere nicht für die Nachrichtendienste. Das darf keinesfalls zur Routinemaßnahme werden, und braucht eine starke, unabhängige Aufsicht.

Ultimative Macht ist gefährlich

Die Überwachungssoftware für Handys, zum Beispiel Pegasus von der NSO Group, ist ein extrem mächtiges Instrument: man braucht nur eine Telefonnummer, und hat damit dann Vollzugriff auf das Handy, kann es orten, kann es als Wanze verwenden, kann den Bildschirm spiegeln und das komplette Kommunikationsarchiv einsehen. Das ist quasi der ultimative Telefon-Joker, den die Polizei ziehen kann, wenn sie bei Ermittlungen ansteht.

Es ist daher menschlich verständlich, und so auch schon in anderen Staaten passiert, dass die Verlockung der einfachen Lösung dazu führt, dass dieser Joker auch bei Fällen gezogen wird, bei denen das eigentlich nicht vorgesehen gewesen wäre. Pegasus & co sind wie ein Cheat-Code bei Computerspielen: immer, wenn es schwierig wird, kann man darauf zurückgreifen und damit kann auch ein harter Gegner im Spiel leicht bezwungen werden.

Und dann ist der Schritt nicht weit, dieses Werkzeug auch für politische Zwecke einzusetzen. Und da reden wir nicht nur von den Diktaturen in Südamerika, Afrika und Asien, bei denen wir nichts anderes erwarten, sondern auch innerhalb der EU wurden mehrere Missbrauchsfälle aufgedeckt.

Im EU-Parlament selber wurden schon Fälle gefunden, und in einem Untersuchungsausschuss wurde der Einsatz solcher Software bei einigen Mitgliedsstaaten untersucht. Der Endbericht führt im Detail an, wo in der EU Spionagesoftware gegen politische Gegner, Journalisten und die Zivilgesellschaft eingesetzt wurde. Konkret werden die Missbrauchsfälle durch Polen, Ungarn, Griechenland, Zypern und Spanien dokumentiert, sowie einige Fälle, in denen Akteure außerhalb der EU politische Ziele in der EU angegriffen haben.

In der Zusammenfassung finden sich folgende Aussagen:

Der Missbrauch von Spähsoftware verletzt nicht nur das Recht auf Privatsphäre natürlicher Personen. Er untergräbt auch heimlich die Demokratie und die demokratischen Institutionen. Er schaltet die Opposition und Kritiker stumm, verhindert Überprüfungen und hat eine abschreckende Wirkung auf die freie Presse und die Zivilgesellschaft. Er dient auch dazu, Wahlen zu manipulieren. Der Begriff „Söldner-Spähsoftware“ beschreibt sehr gut den Charakter des Produkts und der Industrie. Sogar gescheiterte Versuche, ein Smartphone mit Spähsoftware zu infizieren, haben politische Auswirkungen und können sowohl dem Einzelnen als auch der Demokratie Schaden zufügen. Die Teilnahme am öffentlichen Leben wird unmöglich, wenn die Gewissheit fehlt, frei und unbeobachtet zu sein.

Der Spähsoftware-Skandal ist keine Folge isolierter nationaler Missbrauchsfälle, sondern eine ausgewachsene europäische Angelegenheit. Regierungen von EU-Mitgliedstaaten haben Spähsoftware genutzt, um ihre Bürger zu politischen Zwecken auszuspionieren und Korruption und kriminelle Aktivitäten zu vertuschen. Einige gingen sogar noch weiter und haben Spähsoftware in ein System eingebaut, das gezielt für autoritäre Regierungsstrukturen entwickelt wurde. Regierungen anderer Mitgliedstaaten haben zwar keinen Missbrauch von Spähsoftware begangen, aber den verborgenen Handel mit Spähsoftware erleichtert. Europa ist zu einem attraktiven Ort für Söldner-Spähsoftware geworden. Es war Drehscheibe für Exporte in Diktaturen und Unterdrückungsregime wie Libyen, Ägypten und Bangladesch, wo die Spähsoftware gegen Menschenrechtsaktivisten, Journalisten und Regierungskritiker eingesetzt wurde.

Der Missbrauch von Spähsoftware bedeutet eine schwere Verletzung aller Werte der Europäischen Union und stellt die Widerstandsfähigkeit der Demokratie und Rechtsstaatlichkeit in Europa auf die Probe. In den letzten Jahren hat die EU ihre Kapazität zur Reaktion auf externe Bedrohungen unserer Demokratie, sei es Krieg, Desinformationskampagnen oder politische Einmischung, sehr schnell ausgebaut. Im Gegensatz dazu bleibt die Fähigkeit, auf interne Bedrohungen der Demokratie zu reagieren, bedauerlicherweise schwach.

Das Missbrauchspotential solcher Software ist daher klar dokumentiert. Bei der Einschätzung der Gefahr für einen gesetzeswidrigen Einsatz in Österreich darf man nicht nur von den aktuell handelnden Personen im BMI und der DSN ausgehen, man muss immer im Auge behalten, dass sich die Besetzungen nach den Wahlen ändern können.

Wir sollten das Risiko nicht eingehen, dass wir uns in zehn Jahren wundern müssen, was alles in Sachen Überwachungssoftware geht.

Um nochmal ein Bild dafür zu bringen: Diese Überwachungssoftware ist ein bisschen wie der „Ring der Macht“ aus Tolkiens „Herr der Ringe“. Dort lehnen auch starke, positive Figuren seinen Einsatz ab, weil sie um die korrumpierende Macht dieses Artefakts wissen.

Interessenskonflikt zu Schwachstellen

Bei der Debatte zur NIS2-Umsetzung im Parlament wurde auch der Interessenskonflikt innerhalb des BMI angesprochen: Einerseits wollen wir, dass das Handy eines Politikers, einer Geschäftsführerin, eines Anwaltes oder einer Journalistin so sicher sind, wie nur irgendwie möglich. Das inkludiert „Evil Maid“ Angriffe, d.h. auch der physische Zugriff auf das Handy sollte nicht das Auslesen der darauf gespeicherten Daten ermöglichen, und erst recht nicht die Installation von Überwachungssoftware.

Aber gleich neben den dafür zuständigen Aufgabenbereichen „Spionageabwehr“, „Cybersicherheit“, und „Schutz kritischer Infrastruktur“ soll es in der DSN die Bereiche geben, wo genau die gleichen Schwachstellen dafür genutzt werden, um Überwachungssoftware auf die Handys verdächtiger Personen einzubringen.

Aus technischer Sicht besteht kein Unterschied zwischen der Vorgehensweise der „Guten“ und der der „Bösen“, und wir haben schon oft genug erlebt, dass die Schwachstellen, die initial von westlichen Diensten für ihre Zwecke genutzt wurden, auch in andere Hände fallen und dort dann für eindeutig kriminelle Zwecke benutzt werden. Die großen Hersteller haben sich inzwischen klar dafür entschieden, alle Schwachstellen zu schließen, auch wenn das hier und da negative Seiteneffekte haben könnte.

Ein bekanntes Beispiel dafür ist der EternalBlue Exploit der NSA, der mit WannaCry, NotPetya and BadRabbit Schäden in der Milliardenhöhe verursacht hat. Aktuell meldet Google, dass russische APT-Akteure die gleichen Exploits nutzen, die sie von Anbietern von Spionagesoftware kennen.

Mit diesem Gesetzesentwurf setzt die Politik die DSN in eine Zwickmühle. Was soll sie priorisieren? Das Schließen von Schwachstellen, um unsere kritischen Systeme zu schützen, oder das Offenhalten von Schwachstellen, damit sie ihre Überwachungssoftware platzieren kann?

Meiner Meinung nach kann das nur in Richtung CVD – der koordinierten Offenlegung von Schwachstellen – gehen.

Zusammenfassung

Die Fiktion, dass wir mit dem aktuellen Gesetzesentwurf einfach nur die Telefonüberwachung fortschreiben, ist nicht haltbar. Wir lügen uns damit nur selbst an.
Aktuelle Überwachungssoftware ist sehr mächtig und verleitet dadurch zu Missbrauch. Diese Gefahr ist nicht theoretisch, diese Fälle sind auch in der EU schon mehrfach dokumentiert. Der Bericht des EU-Parlament spricht hier sehr klare, warnende Worte.
Der Interessenskonflikt im BMI ist real: Schützen wir die kritische Infrastruktur, die Politik, die Verwaltung und die Zivilgesellschaft vor Spionage, oder wollen wir die Instrumente der Angreifer auch selbst nutzen?

Wie entsteht unser Lagebild?

CERT.at — Wed, 21 Aug 2024 16:58:23 GMT+0100

Ich habe letztens hier schon über das Thema Lagebilder geschrieben, und den Aspekt Lagebildumfragen beleuchtet. In der IT-Security Koordinierungsstruktur des Bundes, dem IKDOK, wird einmal im Monat ein Lagebild erstellt, das irgendwo zwischen strategischer und operativer Ebene angesiedelt ist. Dieses wird dann an diverse Zielgruppen verteilt.

Einmal im Monat werden wir gebeten, einen Beitrag für dieses Lagebild zu liefern. Das ist immer eine spannende Frage, weil der Monatstakt es oft sinnlos macht, auf ganz akute Probleme einzugehen. Der Prozess vom Schreiben und Einwerfen unseres Beitrags, Aggregation dieses mit den anderen, Lagebildsitzung, Endredaktion, Freigabe und Verteilung dauert in Summe etwa eine Woche. Viele der wirklich spannenden Sachen sind bis dahin gegessen, und es macht keinen Sinn mehr, sie im Lagebild noch drinnen zu haben. Dafür gibt es unsere Warnungen.

Daher versuche ich immer, eine Abstraktionsebene höher zu gehen, einen konkreten Vorfall in den richtigen Kontext zu setzen, dahinter liegende Muster aufzuzeigen und Lösungsstrategien anzubieten, die nicht nur auf den Anlassfall passen.

Das ist nicht immer einfach.

Ich will diesen Prozess anhand eines aktuellen Beispiels erläutern:

Ausgangslage

Der Vorfall am 19. Juli mit den EDR von CrowdStrike war eine große Sache: es gab echte Auswirkungen auf die Bevölkerung und ein entsprechendes Medienecho. Auch wir waren involviert, es gab von uns ein Aktuelles und einen Blogpost.

Der Inhalt des ersteren ist für das Lagebild unbrauchbar, denn die Hinweise zur Behebung braucht ein Monat nach dem Vorfall keiner mehr. Der Blogpost schon eher, das war meine Vorbereitung für ein Interview, wo es auch schon um Lektionen aus dem Vorfall gehen könnte.

Überlegungen

Die erste Entscheidung war, welche der vier Lektionen aus dem Blogpost ich im Lagebild betonen will: idealerweise die, zu welchen ich Trends und Hintergründe angeben kann. Meine Wahl war „Abhängigkeiten“, zuvor muss ich aber noch den Anlass kurz umreißen und auch erklären, warum das ganze passiert ist.

Das Thema „Updates (incl. AV-Definitionen) auf kritischen Systemen“ ist überhaupt nicht neu, vor allem im Bereich der Gesundheitstechnik ist das ein Dauerbrenner, da an vielen Stellen nur zertifizierte Systeme eingesetzt werden dürfen. Da schon ein Windows Patchday, oder auch nur ein Pattern-Update der AV-Software die Zertifizierung aufheben kann, steht man dort immer schon in der Zwickmühle zwischen Security-Updates und Safety-Zertifizierung.

Abstrakt betrachtet sind die Systeme, die diese Definitionsupdates liefern, Teil der kritischen Informationsinfrastruktur. Fallen diese aus, oder (meistens schlimmer) liefern sie fehlerhafte Daten, dann kann das sehr direkte Auswirkungen auf die Verfügbarkeit haben. Das kann man aus dem Kontext NIS2 betrachten, und diese Systeme in die Risikobewertung miteinschließen. Wobei hier die Unterscheidung zwischen Lieferantenmanagement (verkauft mir der Hersteller eine vernünftige Lösung) und einem Outsourcing (etwa: liefert mir mein AV-Vendor jeden Tag gute Signatur-Updates) nicht trivial ist. Weil das viele noch nicht am Radar haben, ist hier auch ein Verweis auf den Cyber Resilience Act angebracht, der hier die Produkthaftung neu definiert.

Durch die Abhängigkeit von Cloud-Komponenten können auch signifikante Klumpenrisiken entstehen, die Steuerung von Solaranlagen ist dafür ein gefährliches Beispiel.

Wir hatte vor einiger Zeit einen Vorfall in einer kritischen Infrastruktur, bei dem ein Tausch einer Beschleunigungskarte in einer Firewall durch den Lizenzserver des Herstellers mit einem „Du darfst das nicht nutzen“ quittiert wurde, worauf es zu massiven Ausfällen kam. In dem Fall war das schlicht ein Prozessfehler, ich will aber nicht drüber nachdenken, was ein böswilliger Akteur mit Zugriff auf Lizenzserver eines großen Anbieters an globalen Disruptionen anrichten könnte.

Neben dem Aspekt „liefert die Cloud die richtigen Daten“ wird auch immer mehr „laufen meine Systeme überhaupt noch an, wenn ich keine Netzverbindung habe“ relevant. Die Klassiker dafür sind das DNS und externe Abhängigkeiten von internen Webanwendungen. Es kann sein, dass in manchen Bereichen zirkuläre Abhängigkeiten entstanden sind, die einen Neustart nach komplettem Shutdown sehr schwierig machen.

Da ich nur wenig Platz im Lagebild habe, wurde aus all diesen Überlegungen der folgende Text:

Lagebildbeitrag

Externe Abhängigkeiten

Am 19. Juli wurde durch ein Signaturupdate ein Bug im CrowdStrike Falcon EDR getriggert, was global zu weitreichenden IT-Störungen führte. Dazu ist festzuhalten:

Damit AV/EDR Produkte ihre volle Funktionalität entfalten können, müssen sie unter Windows im Kernelmodus laufen. Dadurch führte der Bug zu einem Komplettausfall der betroffenen Systeme.
Noch mehr als bei normalen Software-Updates muss bei den laufenden Aktualisierungen von Sicherheitskomponenten eine Balance zwischen schneller Wirksamkeit und sorgfältigem Testen gefunden werden. Bei kritischen Systemen müssen nicht nur neue Softwareversionen, sondern auch Konfigurationsupdates (incl. AV-Definitionen) auf Staging-Systemen getestet werden.
Dieser Vorfall hat gezeigt, dass die Grenze zwischen einem Produkt und einer Dienstleistung verschwimmen kann. Der kommenden EU Cyber Resilience Act geht darauf ein, in dem er „remote data processing solutions“ („Datenfernverarbeitungslösungen“) als integralen Teil eines „Produkt mit digitalen Elementen“ definiert.
Betroffene Produkte reichen von harmlos (Staubsaugeroboter für Zuhause) über heikel (fernsteuerbare Türschlösser) bis hin zu kritisch (Steuerung von Solaranlagen).
Auch die zunehmende Online-Lizenzierung von Software bis hin zu Netzwerkkomponenten stellt eine Gefahr für die Verfügbarkeit dar. Ein Vorfall, oder auch nur ein Fehler, in einem Lizenzserver kann signifikante Folgen haben.
Was bei Kraftwerken die „Schwarzstartfähigkeit“ ist, also die Möglichkeit ohne externe Stromquelle hochzufahren, könnte in Zukunft auch in der IT relevant werden: die Fähigkeit, auch ohne Netzzugang und Cloud-Komponenten den Betrieb aufnehmen zu können.

Alle Jahre wieder: Bundestrojaner und Messengerüberwachung

CERT.at — Tue, 20 Aug 2024 10:10:09 GMT+0100

Note: The following blog post is also available in English here.

Nicht nur die Jahreszeiten oder meine Versuche doch mal in einem anderen Outfit als löchrigen Konferenzshirts, Shorts und Birkenstockschlapfen im Büro zu erscheinen sind zyklisch. Auch der Wunsch der Politik nach einem Bundestrojaner oder einer Messengerüberwachung folgt einem scheinbar gleichbleibenden Rhythmus - und anscheinend ist es wieder einmal so weit: Bundeskanzler Karl Nehammer macht die Messengerüberwachung zur festen Bedingung einer zukünftigen politischen Koalition.

Und auch der Bundestrojaner war gerade erst wieder Thema. Die Vorstellungen der Politik ließen sich in einem medial kursierenden Gesetzesentwurf gut erkennen. Angeblich sollte dieser Gesetzesentwurf den durch den Verfassungsgerichthof bereits 2019 klar gesetzten Einschränkungen angepasst sein. Obwohl dieser schlussendlich (glücklicherweise) abgelehnt wurde möchte ich trotzdem darauf eingehen. Vor allem weil ich davon ausgehe, dass wir diese Unterhaltung in einigen Monaten wieder führen werden.

Konkret ging es in dem aktuellen Entwurf um die Überwachung von Nachrichten welche "verschlüsselt gesendet, übermittelt oder empfangen werden", durch "Einbringen eines Programms in ein Computersystem des Betroffenen". Besonders interessant finde ich die gegebene Notwendigkeit "technisch sicherzustellen, dass ausschließlich Nachrichten überwacht werden können, die innerhalb eines betstimmten Bewilligungszeitraums gesendet oder empfangen wurden".

Laut der Einschätzungen von Jurist:innen wäre so eine verfassungskonforme Überwachung möglich, weil die auf dem Markt erhältliche Überwachungssoftware bereits "viel zugespitzter auf Chatnachrichten" sei, und nicht mehr "auf das gesamte Mobiltelefon anwendbar". Was auch immer das heißen soll.

Ich würde mir persönlich wünschen, dass bei dem Thema nicht nur Jurist:innen befragt werden würden, sondern auch Sicherheitsexpert:innen und Techniker:innen einen Beitrag leisten dürften. Jurist:innen technische Urteile fällen zu lassen ist wie mich juristische Einschätzungen treffen zu lassen - suboptimal.

Denn als Techniker muss ich den Jurist:innen hier ganz klar widersprechen. Die gängigen Lösungen verschiedenster Anbieter kommerzieller Spyware (auf die wohl zurückgegriffen werden würde, ich gehe nicht davon aus, dass die verantwortlichen Stellen in Österreich eigene Lösungen entwickeln würden) sind allesamt nicht dafür ausgelegt nur bestimmte Applikationen zu überwachen. Es gibt, meines Wissens, keine Spyware, die (beispielsweise) nur Telegram oder nur Viber überwacht.

Natürlich wäre es für den Anbieter möglich sein System so zu konfigurieren, dass den Kund:innen nur Nachrichten aus (beispielsweise) Telegram oder Viber angezeigt werden. Das ist aber dann eine organisatorische Sicherstellung, keine technische Garantie dafür, dass nur relevante Nachrichten überwacht werden. Selbiges gilt für die Anforderung, dass nur Nachrichten innerhalb eines in einer Anordnung festgesetzten Beobachtungszeitraumes in's Visier genommen werden dürfen.

Die Kompromittierung eines Endgerätes mit kommerzieller Spyware bedeutet immer, dass die Privatsphäre der betroffenen Personen vollständig kompromittiert ist. Stichwort kompromittiert: Ich gehe davon aus, dass mit "Einbringen eines Programms in ein Computersystem des Betroffenen" nicht gemeint ist, dass die Betroffenen bei ihrer örtlichen Polizeiinspektion vorstellig werden, dort ihr Mobiltelefon oder ihren Computer (inklusive der notwendigen Zugangsdaten) abgeben und um die Ecke einen Kaffee trinken gehen, während die Beamt:innen das "Programm" "einbringen". Zumindest hoffe ich, dass das nicht gemeint ist.

Nein, wovon hier verklausuliert gesprochen wird ist, dass Sicherheitslücken ausgenutzt werden um Schadsoftware auf den Geräten zu installieren. Damit Sicherheitslücken ausgenutzt werden können müssen die Schwachstellen ungepatcht bleiben. Das bedeutet gleichzeitig aber auch, dass ein System im weitesten Sinne unsicher bleibt. Und auch andere Akteure mit (je nach Betrachtungsweise "noch") böseren Absichten diese missbrauchen können.

Diese Tatsache sorgt dafür, auch in Anbetracht der Anforderungen der NIS-2-Richtlinie, dass der Staat sich hier selbst in ein Dilemma befördert:

Der Staat möchte, dass IT-Systeme so sicher sind, dass Bürger:innen, Organisationen, Unternehmen und Behörden mit diesen vertraulich kommunizieren und sicher Daten austauschen können. Dies setzt unter anderem voraus, dass die Systeme nach dem besten Stand der Technik geschützt werden. Wenn es Schwachstellen gibt so müssen diese schnellstmöglich gepatcht oder dem Hersteller gemeldet werden, damit dieser Patches zur Verfügung stellen kann.
Der Staat möchte, zur Verhinderung und / oder Aufklärung von Verbrechen, Terrorismus oder Spionage Einblicke in die Kommunikation und die Daten von Verdächtigen bekommen. Dies setzt unter anderem voraus, dass die von den Verdächtigen eingesetzten Systeme Schwachstellen aufweisen die ausgenutzt werden können um Software auf den Geräten der Verdächtigen zu platzieren mittels derer die Einblicke ermöglicht werden.

Beide Ansprüche vollständig zu erfüllen wird nicht möglich sein. Auf diese Tatsache hat mein Kollege Otmar Lendl bereits vor sieben Jahren in einem Beitrag zu einem sehr ähnlichen Thema hingewiesen.

Grundsätzlich verstehe ich den Wunsch der Behörden Einblick in die Kommunikation von Verdächtigen zu bekommen (das FBI hat den Wunsch sogar so stark verspürt, dass sie den Kriminellen kurzerhand einfach gleich selbst den Messenger zur Verfügung gestellt hat). Aber so, wie sich das die Politik vorstellt - sauber, klar definiert, sicher, die Grundrechte wahrend - ist das schlichtweg nicht möglich. Auch wenn man es sich noch so oft wünscht.

Auch wenn ich kein Kriminalist, Ermittler oder Experte für Terrorismus bin, so fallen mir aus dem Stegreif Maßnahmen ein, die mit sehr hoher Wahrscheinlichkeit erfolgsversprechender sind und sich noch dazu deutlich einfacher mit dem Verfassungsrecht in Einklang bringen lassen.

Ich weiß von Kolleg:innen im Bundesdienst, die aufgrund veralteter Prozesse und den elendig langsam mahlenden Mühlen der Bürokratie mehrere Monate warten mussten um für die Arbeit notwendige Peripheriegeräte für ihre Dienstcomputer zu bekommen. Oder von Fällen, in denen eine Abteilung in der Menge der anfallenden Arbeit beinahe untergeht während sich ein anderes Team mit gleicher fachlicher Kompetenz in's "Boreout" langweilt, aus welchen Gründen auch immer aber nicht unterstützend tätig werden darf.

Im Kontakt mit CSIRTs und Strafverfolgungsbehörden aus anderen Ländern hören wir immer wieder, dass die Zusammenarbeit mit Institutionen aus Österreich super funktioniert - wenn sie denn mal zustande kommt, weil mit erschreckender Regelmäßigkeit motivierte Leute frustriert das Handtuch werfen. Wenn ich mit Bekannten sprechen, die in der Sozialarbeit und Bewährungshilfe tätig sind ist die massive Unterversorgung mit Ressourcen ein regelmäßiges Thema. Ich lehne mich aus dem Fenster und behaupte, dass man mit all den Ressourcen, mit all der Zeit und Energie (und sicherlich auch zu einem gewissen Maß Budget) die in die Thematik Messengerüberwachung und Bundestrojaner geflossen ist, viele andere Dinge verbessern hätte können, die einen nachhaltigeren positiven Effekt auf unsere Sicherheit gehabt hätten.

Um mit einem ganz aktuellen Beispiel zu schließen: Obwohl zeitliche Korrelation natürlich keinen Kausalzusammenhang bedingt kann ich mich des Verdachtes nicht erwehren, dass das Aufkochen des Themas in Zusammenhang mit den vereitelten Anschlagsversuchen rund um die Konzerte von Taylor Swift in Wien in Zusammenhang steht.

In meinen (noch) jüngeren Jahren habe ich einige Zeit als Sicherheitsmitarbeiter für Großveranstaltungen gearbeitet. Und schon damals war es so, dass die einzige Voraussetzung für eine Anstellung eine vorhandene Bereitschaft für Nachtdienste im strömenden Regen für 6,50€ pro Stunde war.

Was dazu geführt hat, dass ich den Hintereingang einer namhaften Kulturinstitution mit zwei Kollegen bewacht habe, von denen einer in seiner Freizeit im Kontext eines Wiener Fußballvereins Mannschaftskickboxen auf Feldwegen trainiert hat während mein zweiter Kollege zur Dienstversehung einige seiner Tätowierungen abkleben musste um nicht mit diversen Paragraphen des VbtG in Konflikt zu geraten. Das kam mir damals schon seltsam vor.

Noch mehr haben sich meine Augen vor einigen Jahren gehoben als bekannt wurde, dass während des Untersuchungsausschusses zur BVT-Affäre ein Sicherheitsmitarbeiter mit engen Verbindungen zu einem seit Jahrzehnten amtsbekannten Rechtsextremisten seinen Dienst im Parlament getan hat. Anscheinend war auch in diesem Fall nicht wirklich überprüft worden, wen man für (hoffentlich der Inflation angepasste) 6,50€ pro Stunde anstellte.

Immerhin hat dies dazu geführt, dass im türkis-grünen Regierungsprogramm aus dem Jahr 2020 "klare und verbindliche Sicherheitsstandards" für Sicherheitsunternehmen geschaffen werden sollten. Im Rahmen der Ermittlungen nach den Absagen der Konzerte von Taylor Swift in Wien vor einigen Wochen stellte sich heraus, dass acht bei den Konzerten eingesetzte Mitarbeiter des Sicherheitsdienstes bereits wegen Jihadismus aufgefallen waren. Scheint bisher nicht so ganz zu klappen, das mit den Sicherheitsstandards.

Der Punkt auf den ich hinaus möchte ist: Der Bundestrojaner ist nicht die Lösung. Er ist nicht einmal ein Lösungsansatz von mehreren, wie die in den vergangenen Absätzen von mir genannten Beispiele. Der Bundestrojaner ist ein Problem.

Die gezielte Überwachung einzelner Unterhaltungen oder nur bestimmter Chat-Applikationen bei gleichzeitiger Vermeidung eines übermäßigen Eingriffes in die Privatsphäre und Gewährleistung der technischen Sicherheit von überwachten Geräten ist so, wie sich das die Entscheidungsträger:innen das vorstellen nicht möglich. Ich wünschte, dass dies nicht alle paar Jahre auf's Neue erklärt werden müsste.

Notizen zum CrowdStrike Vorfall

CERT.at — Fri, 19 Jul 2024 16:36:05 GMT+0100

Wir hatten heute viel Spaß mit den Problemen rund um den CrowdStrike EDR.

Am Nachmittag hat sich der ORF bei mir gemeldet, sie hätten gerne für die ZiB 1 ein Interview mit mir. Das lief dann soweit gut, ich will hier meine "Speaking Notes" offenlegen, weil sicher nicht alles, was ich gesagt habe, in den kurzen O-Ton Beiträgen im Fernsehen zu sehen sein wird.

Das sind nur die Stichworte, die ich für mich selber geschrieben habe, und nicht voll ausformulierte Argumente.

Was ist passiert?

Fehler in einem Automatischen Update einer Sicherheitssoftware, nicht bei Microsoft selber
- Das kam schon bei vielen Anbietern vor
Diese ist tief im System verankert, damit sie ihre Arbeit machen kann
Ein schweres Problem dort -> Computer ist als Ganzes ist nicht mehr brauchbar
Damit konnten auch die Korrekturen nicht mehr automatisch übernommen werden
Es ging rein um die Verfügbarkeit
- Keine Auswirkungen auf Datenschutz / Geheimnisse / Spionage
- Keine Manipulation von Daten

Ursache / Grund

Automatische Update der Einstellungen einer Sicherheitssoftware:
- Nötig, um schnell auf neue Gefahren reagieren zu können
- Kein ausführliches Testen beim Kunden machbar
Warum das passiert ist, wissen wir noch nicht. Das kann man nach 12 Stunden auch noch nicht erwarten. Spekulationen sind sinnlos.

Effekte

Die Gesellschaft hängt an vielen Stellen vom Funktionieren der Computer ab
Ausfälle dort treffen rasch das normale Leben
Die betreffende Software wird gerade bei wichtigen Firmen eingesetzt, daher waren auch die Auswirkungen global signifikant

Reparaturzeit

Das Problem wurde sehr schnell identifiziert
Lösungswege sind vorhanden
- Manchmal einfach
- In einigen Fällen braucht es Handarbeit
Heute Stress bei den Betriebsteams (Hoffentlich hab ich noch die Fähigkeiten im eigenen Haus, wenn alle das auf ein paar Dienstleister outgesourced haben, ist dort schnell ein Riesenengpass an Manpower)
Sicher noch einiges an Überstunden am Wochenende
Nächste Woche noch aufräumen: Laptops im Homeoffice oder Dienstreise

Lektionen

Vorbereitung auf Ausfall der Computer und Datennetze
- Wie reagieren wir? Was geht noch?
- Es ist nicht immer nur das Blackout
Sicherheitssysteme kommen immer mit Nebenwirkungen
- Wie bei Medizin: Was hilft es, welche Probleme handle ich mir ein?
- Beispiel Alarmanlagen: Wie ist da das Verhältnis von Fehlalarmen zu echten?
Eine gute Risikobewertung ist nötig
- Risiko, eine Unterwanderung des Netzes nicht zu erkennen
- vs. Risiko, dass die Sicherheitslösung im Betrieb Probleme macht.
Globale Abhängigkeiten
- Ein Fehler einer Firma in Amerika kann direkte Auswirkungen in Österreich haben
- Lizenzen (was mach ich, wenn ein Lizenzserver für Router/Firewall/Virtualisierungslösung/... falsch antwortet)
- Cloud (Ausfälle schlagen bei Software as a Service sofort auf alle Kunden durch)

Gleichbleibend Unangenehm

CERT.at — Wed, 17 Jul 2024 15:25:27 GMT+0100

Drei Ebenen

Es gibt strategische Lagebilder für das Top-Management: da geht es um high-level Trends und Themen, die in den nächsten Monaten oder Jahren akut werden. Daher muss dieses Lagebild auch nicht täglich aktualisiert werden. Manche NCSC publizieren solche Berichte, in Österreich geht am ehesten der Bericht Cybersicherheit in diese Richtung.

Das Security Management Team rund um den CISO braucht auch operative Informationen, was die aktuelle Bedrohungslage ist und wohin sie ihr Augenmerk legen sollen. Die Taktung ist hier kürzer, wir reden hier von Tagen bis Wochen. Es darf auch schon deutlich technischer werden. In Österreich erstellt die IKDOK/OpKoord ein monatliches Lagebild, das ich primär als operatives Lagebild einstufe.

In den Schützengräben der IT-Security, wo IT-Betriebsteams und SOC Analysten möglichst schnell und effektiv auf neue Bedrohungen reagieren, braucht man die Bedrohungsinformationen quasi in Echtzeit. Hier sind wir endgültig auf der rein technischen Ebene, da geht es um akute Schwachstellen und ihre Workarounds/Patches, neueste IOCs für die Erkennung von Problemen und was es sonst noch an Neuigkeiten gibt. Neben den Lagebildern für die Menschen, wie es etwa unsere Tageszusammenfassungen sind, spielt hier auch die Machine-to-Machine Kommunikation eine Rolle, diverse technische Systeme (AV, SIEMs, Proxies, …) bekommen von ihren Herstellern oder auch von Dienstleisten das aktuelle Bedrohungsbild eingespielt.

Quellen

Ich sehe drei prinzipielle Möglichkeiten, zu einem Lagebild zu kommen:

OSINT / Threat Feeds: ich kann mich umschauen, was andere zu diesem Thema publizieren. Das reicht von Softwareherstellern, Forschern, Medien, Betroffenen, spezialisierten Firmen bis hin zu meinen Partner-CERTs.
Ich habe Sensorik im Einsatz, die messen, was wirklich im Internet passiert. Das kann passiv sein, wo meine Sensoren nur beobachten, welche Angriffe gerade gefahren werden, oder aktiv, indem ich selbst per Scans nachschaue, was die Lage ist. Etwa, wie stark ein System verbreitet ist, zu dem gerade eine Schwachstelle publiziert wurde.
Und ich kann Fragen stellen: Ich kann aktiv auf meine Constituency zugehen und per Interviews oder Umfragen erheben, wie die Stimmung ist und was sie gerade beschäftigt.

In vielen Fällen wird das finale Lagebild eine Mischung dieser drei Informationsquellen sein.

Lagebildumfragen

Sowohl im Bereich des Austrian Energy CERTs, als auch im GovCERT haben wir 2019 begonnen, aktiv nach der Lageeinschätzung unserer Kundenkreise zu fragen. Das kann man natürlich nach allen Regeln der Statistik machen, und damit versuchen, möglichst korrekte und belastbare Zahlen zu bekommen. Wir haben uns bewusst dagegen entschieden:

Mit dem Anspruch setze ich auch die Befragten unter Druck, ein fundiertes lokales Lagebild zu erstellen. Auf was soll das basieren? Incident-Statistiken? Dashboards von Firewalls, AV-Lösungen, EDRs und sonstigen Sicherheitslösungen? Ausgaben für die Abwehr?
Ich brauche dann auch genau eine Antwort pro Organisation. Damit zwinge ich diese zu einer internen Abstimmung, was den Aufwand dort weiter erhöht.
Und wenn das Organisationen schaffen, wie vergleichbar sind dann die Antworten zwischen diesen? Messen alle das Gleiche, oder sind die Blickwinkel so verschieden, dass wir Äpfel und Birnen zusammenzählen würden?
Sollte ich die ersten beiden Hürden überwunden haben, wie aggregiere ich dann die Zahlen? Einfach pro Organisation rechnen, oder sollte ich nach deren Größe gewichten? Schließlich erwarte ich Antworten von kleinen Firmen bis hin zu Organisationen wie der Stadt Wien.
Die erwartete Zahl der Antworten ist für eine genaue statistische Aussage schlicht zu klein, insb. wenn ich auf Sektorebene auswerte. Wir haben nicht viele Schienennetzbetreiber in Österreich.

Was ist die Alternative dazu? Wir fragen einfach nach einem Stimmungsbild. Anfang 2021, in meiner Mail an die Mitglieder des Austrian Trust Circle, habe ich das so formuliert:

Ich verteile seit einiger Zeit hier die Lagebilder, die im Rahmen der IKDOK (der Koordinierungsstruktur laut NISG) in monatlichem Takt erstellt wird. Dort fließen ein:

Jede Menge OSINT (offene Quellen, primär von uns und dem HNaA)

Erkenntnisse aus Meldungen an CERT.at, GovCERT und Energy CERT, informell und via NIS Formular

Statistiken aus der Arbeit der Polizei (.BK / C4)

Aktuelle Vorfälle / Tätigkeiten (CERTs, CSC, AbwA)

Die NIS-Meldungen sind aktuell noch deutlich zu selten und auch zwangsläufig einseitig. Niemand wird "Bei uns ist aktuell alles ruhig" per NIS Formular melden.

Daher haben das BKA und wir uns schon letztes Jahr überlegt, wie wir zu einem Bild kommen könnten, wie es wirklich um die IT Security im Land gerade bestellt ist. Uns war schnell klar, dass wir mit quantitativen Fragen nicht weit kommen werden, weil die Zahlen schwer zu bekommen und noch schwerer zu vergleichen sind. Daher haben wir uns dazu entschlossen, mehr in Richtung "Einschätzungen und Bauchgefühl" zu fragen, damit der Fragebogen kurz bleibt, und er auch ohne aufwändigen Recherchen schnell zu beantworten ist.

Wir haben das 2020 im Bereich des GovCERTs gemacht, 2021 wollen wir jetzt breiter fragen, daher diese Mail an alle ATC Listen.

Es würde mich freuen, wenn wir hier viele Antworten bekommen.

Wir erfassen nicht, wer geantwortet hat. Es ist auch nicht wichtig, dass genau einer aus einer Organisation antwortet. Das Ergebnis ist ein Stimmungsbarometer, und erhebt nicht den Anspruch, eine repräsentative Umfrage zu sein.

Die Umfrage selbst haben wir mit EUSurvey implementiert. Vor den eigentlichen Fragen stand der folgende Text:

Diese Umfrage dient dazu, ein schnelles und qualitatives Bild der aktuellen IT Security Lage zu erheben.

Es geht hier nicht um exakte Zahlen, sondern darum, die aktuelle Stimmungslage innerhalb eines Sektors abzufragen. Es ist daher explizit nicht notwendig, lange interne Nachforschungen anzustellen, was diverse technische Systeme melden, sondern mehr um das „Bauchgefühl“ der IT Security Verantwortlichen im jeweiligen Sektor zu erfassen.

Die Umfrage lässt sich daher bewusst in wenigen Minuten beantworten.

Diese Umfrage geht auf folgende sechs Themenbereiche ein:

Betrugsversuche/Erpressungsversuch

Schadsoftwarefunde

Allgemeiner Unsicherheitszustand

Verletzung der Vertraulichkeit von Daten

Denial of Service

Widerrechtlicher Zugriff auf Accounts/Daten

Zu diesen Themenbereichen werden jeweils zwei Einschätzungen abgefragt:

Relevanz: Wie sehr ist dieses Thema zum aktuellen Zeitpunkt ein Problem für Ihre Organisation?

Skala: Irrelevant – Unangenehm – Problematisch – Kritisch

Tendenz: Sehen Sie eine Veränderung zur jüngeren Vergangenheit?

Skala: Stark fallend – Fallend – Gleichbleibend – Steigend – Stark steigend

Die sechs Themenbereiche lassen sich nicht exakt voneinander abgrenzen. Beispielsweise werden sich manche Vorfälle in mehreren Themengebieten wiederfinden. Im Folgenden werden exemplarische Beispiele zu den einzelnen Themenbereichen angeführt, welche bei den beiden Einschätzungen (Relevanz, Tendenz) berücksichtigt werden sollen.

Themenbereich 1: Betrugsversuche/Erpressungsversuche

In diese Kategorie fallen beispielsweise Themen wie Phishing, allgemeine Fraud Versuche, Scams/Betrugsversuche, CEO Fraud, Fake Anrufe (z.B. "Microsoft Support calls"), Sextortion aber auch Ransomware.

Themenbereich 2: Schadsoftwarefunde

Hier geht es nicht notwendigerweise um bereits aktiv gewordene Schadsoftware, sondern um erkannte Versuche, diese zu platzieren. Die Datenquellen dazu sind etwa AV Alarme (in Mailserver, auf Proxies, am Client, ...), IOC Funde (z.B. IDS Hits), MalSPAM Rate, Ransomware-Vorfälle, ...

Themenbereich 3: Allgemeiner Unsicherheitszustand

In diesem Thema soll bewertet werden, wie die Verwundbarkeit der IT Systeme subjektiv eingeschätzt wird. Kriterien, die bei der Einschätzung helfen, sind beispielsweise: • Anzahl/Anteil nicht gepatchter Systeme • Fehlbedienungen • Fehlkonfigurationen • Gefundene Schwachstellen • Ausfälle • Vorfälle

Themenbereich 4: Verletzung der Vertraulichkeit von Daten

Diese Kategorie behandelt Punkten wie Leaks, DSGVO Verstöße, Spionage, erfolgreiches Phishing, etc.

Themenbereich 5: Denial of Service

Hier geht es um die Verfügbarkeit von IT Systemen. Diese könnte etwa durch netzwerkbasierte DDoS-Angriffe, Mailbomben oder anderen gezielte Störaktionen gestört worden sein.

Themenbereich 6: Widerrechtlicher Zugriff auf Accounts/Daten

Darunter fallen Manipulationen, Hacking, Social Media Hijacks, ...

Bei den Sektoren standen die folgenden zur Auswahl (Mehrfachnennung möglich): Energie, Verkehr, Bankwesen, Finanzmarktinfrastrukturen, Gesundheitswesen, Trinkwasserversorgung, Digitale Infrastruktur, Anbieter digitaler Dienste, Einrichtungen der öffentlichen Verwaltung, Sonstige

Wir haben drei Jahre lang jedes Quartal eine Umfrage gemacht.

Ergebnisse

Wir bekamen zwischen 40 und 100 Antworten pro Quartalumfrage, in der letzten waren das damit 2 bis 11 Antworten pro Sektor, was seriöse Aussagen pro Sektor nicht erlauben.

Ein erster Weg, das Ergebnis zu visualisieren ist eine Heatmap in der Einschätzung/Tendenz-Matrix. Damit kommen wir etwa für Q1 2024 auf folgendes Bild:

Man kann gut erkennen, dass die häufigsten Antworten „gleichbleibend Unangenehm“ sind.

Über die Laufzeit des Projektes haben sich die Bewertungen folgendermaßen entwickelt:

Ein gewisses Rauschen ist bei der geringen Zahl an Rückmeldungen immer zu erwarten, es ist daher nicht seriös, aus einzelnen Abweichungen gesicherte Schlussfolgerungen zu ziehen. Zwei Punkte sind aber trotzdem erwähnenswert:

Der Bereich Denial of Service ist klar weniger relevant als die anderen. Dazu nachher noch mehr.
Im Q1 2022 gab es einen Sprung nach oben bei der Relevanz des „Allgemeinen Unsicherheitszustandes“. Das könnte man auf Start des russischen Angriffskrieges in der Ukraine zurückführen. Da war es eine Zeit lange nicht klar, was das für Seiteneffekte auf die Cybersecurity in der EU haben wird.

Die Frage nach der Tendenz hätten wir uns sparen können, hier kann man fast gar nichts herauslesen.

Natürlich sind nicht alle Bedrohungsmuster für alle Sektoren gleich relevant, aber das aus den wenigen Antworten pro Quartal mit Sicherheit herauslesen zu wollen, ist eine Überinterpretation der Daten. Ich habe daher alle 598 Antworten der 16 Quartale zusammengeworfen, und mir dann die Sektorverteilung angesehen. Da verliere ich zwangsläufig die zeitliche Auflösung, aber dafür habe ich eine brauchbare Datenbasis für die Unterschiede zwischen den Sektoren (bis auf „Trinkwasser“, dort waren es trotzdem noch zu wenige Antworten).

Hier stechen ein paar Werte heraus:

Denial of Service Angriffe sind für die Sektoren, die ihre Dienstleistungen (auch) über das Internet anbieten, klar relevanter als für solche, die das nicht tun (Energie, Verkehr)
Spitzenwerte in Bezug auf Vertraulichkeit und Accountsicherheit gibt es im Bereich Gesundheit und Banken.
Das Umgekehrte gilt für Energie und Verkehr: Die Stromrechnung ist doch weniger heikel als der Befund des Arztes.

Abschluss des Projektes

Da sich die Antworten von Quartal zu Quartal kaum unterschieden, wurde ich immer wieder gefragt, ob dieses Projekt noch Sinn macht. Da sich der Aufwand in Grenzen hielt, und erst mit einer langen Baseline Trends sichtbar werden könnten, habe ich das drei Jahre lang durchgezogen. Als ich dann Q4 2023 verpasst hatte, war das ein Anlass, in der Community nachzufragen, ob die Zahlen jemandem abgehen würden. Die Antwort war nein, daher haben wir mit Q1 2024 das Projekt beendet.

Schlussfolgerungen

In den drei Jahren gab es abseits von geopolitischen Entwicklungen auch immer wieder relevante Ereignisse in der IT Security Branche. Diese haben sich kaum in den Antworten wiedergefunden, ein etwaiges Signal ging schnell im statistischen Rauschen unter.

Meine Theorie dazu ist, dass sich die Branche in einem Gleichgewicht aus Bedrohungslage und Risikomanagementmaßnahmen befindet. Taucht eine neue Gefahr auf, so kann das zwar zwischenzeitlich Angst auslösen, aber das System findet eine Lösung und investiert so viel in Abwehrmechanismen, bis das Gleichgewicht wiederhergestellt ist.

Kurzfristig kann es Störungen geben, etwa wenn eine Welle an 0-days die Branche erschüttert, oder Tätergruppen signifikant effektivere Techniken neu entwickeln und einsetzen. Aber dann fängt das Immunsystem der Branche an zu arbeiten, entwickelt neue Antikörper und damit sollte neben einem kurzfristigen Fieber nichts Gröberes passiert sein.

Man könnte auch die Theorie aufstellen, dass ein signifikantes Nachlassen der Bedrohungslage auch eine Reduktion der IT-Sicherheitsbudgets bewirken würde, worauf die Zahl der Vorfälle wieder auf die Level von vorher steigen würde.

Das alles ist zwar nicht exakt die Definition des „Regression to the mean“, aber wir sind nahe dran. Was unsere Umfragen gezeigt haben ist, dass der Grundzustand der IT Sicherheit am besten mit „gleichbleibend unangenehm“ zu beschreiben ist.

Neue Absenderadresse für unsere täglichen Mails an Netzbetreiber

CERT.at — Mon, 15 Jul 2024 14:32:56 GMT+0100

Wir versenden jeden Tag zwischen 150 und 250 Mails an unsere Kontakte bei Netzbetreibern in Österreich, um diese über Probleme in ihren Netzen zu informieren, die wir (bzw. unsere Datenquellen) dort gefunden haben. All das hat Kamil letztens in einem Blogpost ausführlich beschrieben.

Rückfragen waren immer schon willkommen: das ist auch einer der Gründe, warum wir diese Mails aus unserem Ticketsystem heraus verschicken. Nur leider hat das (trotz gesetztem „Precedence: bulk“ – Header) dazu geführt, dass wir ob der vielen automatischen Antworten (von „Ich bin auf Urlaub“ bis zu „Danke für ihre Anfrage“) immer wieder echte Rückfragen übersehen.

Lange haben wir versucht, mit Filtern in der Verarbeitungskette zu arbeiten, was einen laufenden Aufwand für das Nachjustieren generiert hat. Jetzt haben wir uns dazu entschlossen, den gleichen Weg zu nehmen, den schon viele andere Firmen beschritten haben: Wir senden ab sofort diese Mails nicht mehr von team@cert.at als Absender, sondern von noreply@cert.at aus. Diese Adresse lehnt eingehende Mails mit einer sinnvollen Fehlermeldung direkt im SMTP-Dialog ab.

Echte Rückfragen sollten weiterhin an team@cert.at gerichtet werden. Bitte lassen Sie das Subject aber unverändert, insbesondere die Ticketnummer ("[CERT.at #1234567]") hilft uns wirklich bei der Zuordnung der Frage zu unserer Aussendung. Meistens enthalten unsere Mails Informationen zu mehreren IP-Adressen, zu welcher davon es Fragen gibt, ist auch wichtig zu erwähnen.

Falls Sie unsere Mail automatisch verarbeiten, kann es also sein, dass Sie entsprechende Anpassungen auf Ihrer Seite vornehmen müssen.

"Ich hab doch nur g'schaut .. (bis sich eine bessere Gelegenheit bietet)!"

CERT.at — Tue, 09 Jul 2024 10:21:13 GMT+0100

Angriffe mit (vermeintlich) hacktivistischer Motivation sind inzwischen ein fester Bestandteil des digitalen Hintergrundrauschens. Das ist nicht erst seit Beginn des russischen Angriffskrieges auf die Ukraine der Fall, jedoch hat die Zahl von Attacken durch Bedrohungsakteure, welche im Sinne ihrer "Sache" für eine der Seiten innerhalb des Konfliktes aktiv werden, merklich zugenommen.

Gerade DDoS-Angriffe sind ein beliebtes Mittel der Wahl, da die vergleichsweise niedrige technische Hürde zur Mittäter:innenschaft es einer potentiell größeren Anzahl an Unterstützer:innen ermöglicht, sich an der - in den eigenen Augen - gerechten Sache zu beteiligen. Dazu kommt auch, dass sich durch DDoS im Vergleich zur Komplexität der Angriffe und dem dafür notwendigen Aufwand überproportional viel öffentliche Aufmerksamkeit generieren lässt. Oder, wie es in einem bekannten xkcd gut zusammengefasst wird:

Diese Art von Angriffen (welche sich alle paar Monate auch gegen österreichische Ziele richten) sind jedoch nicht das einzige Werkzeug im Repertoire von (vermeintlich) hacktivistisch motivierten Bedrohungsakteuren. Die Kriminellen sind nicht wählerisch. Wenn sich eine Gelegenheit ergibt Schaden anzurichten, so wird diese in den allermeisten Fällen ergriffen.

Ein gutes Beispiel dafür war vor kurzer Zeit in einer Telegram-Gruppe zu sehen, welche einem prorussischen Bedrohungsakteur zugerechnet wird. Dort wurden Bildschirmfotos des Benutzer:inneninterfaces einer Industriesteuerungsanlage geteilt, auf welche die Angreifer:innen vermeintlich Zugriff hatten.

Wie genau es dem Bedrohungsakteur gelungen ist diesen Zugriff zu erlangen ist nicht mit abschließender Sicherheit geklärt. Untersuchungen legen jedoch Nahe, dass sich jemand aus dem Umfeld der Gruppierung die Mühe gemacht hat, eine Vielzahl von Adressranges nach offenen, ohne Authentifizierung zugänglichen VNC-Servern auf Port 5900 zu scannen. Zumindest in einem Fall wurde der / die Täter:in fündig und hat die Screenshots - dem den Bildern beigefügten Text nach zu schließen mit Begeisterung - sofort geteilt.

Auch wenn in dem konkreten Fall vielleicht keine Bedrohung vorgelegen ist, weil es sich bei dem betroffenen System um ein reines Monitoring-Interface ohne Kontrollfunktion gehandelt haben könnte - im Gegensatz zu uns werden Kriminelle in ihren Aktivitäten nicht von solchen Kleinigkeiten wie dem Konzept von "Wahrheit" beeinträchtigt. Bereits in der Vergangenheit gab es Fälle, bei denen Bedrohungsakteure gegenüber Journalist:innen und Medienorganisationen vorgegeben haben, Zugang zu Steuerungsanlagen oder sonstigen kritischen OT-Systemen erlangt zu haben, ohne dass dies tatsächlich der Fall gewesen wäre.

Die möglichen Auswirkungen, wenn es (vermeintlich) hacktivistisch motivierten Angreifer:innen gelingen sollte Zugriff auf industrielle Steuerungen zu erlangen, möchte man sich im Detail gar nicht zu genau ausmalen. Entsprechende "Defacements" mit der Verbreitung von Propaganda wären hier wohl mit Abstand das geringste Übel.

Ich habe in den einleitenden Worten dieses Beitrages vom "digitalen Hintergrundrauschen" gesprochen. In gewisser Weise ist dieser Beitrag ein wortreicher Zusatz zum bestehenden "Hintergrundrauschen unserer CERT-Arbeit". Wir weisen bereits seit langer Zeit (auf verschiedenen Ebenen und über unterschiedliche Wege) darauf hin, dass ungesicherte, uneingeschränkt erreichbare VNC-Server im österreichischen Internet weiterhin ein viel zu großes Problem sind. Nicht nur, aber insbesondere auch bei Systemen mit denen direkter Einfluss auf die analoge Welt genommen werden kann.

Das Thema "Remote Access" ist jedoch generell ein Dauerbrenner mit verschiedenen Baustellen. Mal abgesehen von der leider immer noch nicht flächendeckenden Absicherung von Fernzugriffen mittels Zweifaktor-Authentifizierung (2FA) gibt es auch immer wieder Probleme mit unternehmensinternen Wildwüchsen von Fernwartungssoftware.

Diese erleichtern Administrator:innen zwar die Arbeit, weil sie oftmals mehr Komfort bieten als systemeigene Lösungen, gleichzeitig freuen sich aber auch Bedrohungsakteure über deren Anwesenheit auf Systemen. Der noch nicht abschließend geklärte Sicherheitsvorfall bei dem deutschen Unternehmen "TeamViewer" zeigt, dass die Hersteller solcher Produkte ein beliebtes Ziel von Angreifer:innen waren, sind und wohl auch zukünftig bleiben werden. Und dass es wichtig ist den Einsatz solcher Lösungen nicht nur sorgfältig zu planen und im Rahmen des eigenen Risikomanagement zu beurteilen, sondern auch gut zu dokumentieren.

Ja, das mehr oder weniger schnell näher kommende Inkrafttreten von NIS2 ist sicher ein guter Motivator dafür, das eigene Asset-Management auf Vordermann zu bringen (was bei allen Beteiligten meiner Erfahrung nach mehr als nur einmal zu Ausrufen der Sorte ".. bitte warum ist das aus dem Internet erreichbar?!" führt) und sich näher mit den eigenen Regelungen zu den Themen Authentifizierung und Fernzugriff zu beschäftigen.

Aber selbst wenn es noch eine Weile dauern sollte, bis NIS2 tatsächlich schlagend wird, so ist der Schutz vor Sicherheitsvorfällen alleine wohl schon ein ausreichender Grund, sich der hier beschriebenen Problematik eingehend anzunehmen. Zumindest hoffe ich das.

NIS2 - Implementing Acts

CERT.at — Fri, 28 Jun 2024 17:10:14 GMT+0100

Es liegen endlich Entwürfe für die Implementing Acts zur NIS 2 Richtline vor, die Umsetzungsdetails regeln werden.

Genauer gesagt: es geht um

Kriterien, wann ein Vorfall meldepflichtig wird
Maßnahmen zum Risikomanagement

Seitens der EU gibt es ein öffentliches Konsultationsverfahren dazu, das bis zum 25. Juli offen ist. Die Entwürfe sind auch über diese Webseite abrufbar.

NISG 2024 im Innenausschuss

CERT.at — Tue, 25 Jun 2024 14:47:33 GMT+0100

Ich wurde eingeladen, am 19. Juni im Innenausschuss des Parlaments als Experte in einem Hearing zum NISG 2024 aufzutreten. Das war keine Vorladung zu einem Untersuchungsausschuss, die man kaum ausschlagen kann, sondern ein wirklich freiwilliger Termin. Ich war schon öfters beruflich im Parlament, aber bisher immer auf Einladung der Parlamentsdirektion: das hier war der erste Termin mit Mandataren. Die Illusion, mit diesem Auftritt irgendwas bewirken zu können, hatte ich nie. Zwei Tage nach dem Koalitionsstreit um die Renaturierungsverordnung und schon fast im heißen Wahlkampf: Da zählen politische Argumente sicher mehr als fachliche.

In diesem Blogpost will ich kurz erklären, was ich kommunizieren wollte:

Eingangsstatement

Brauchen wir das Thema NIS?

Ja, weil die Verfügbarkeit unserer IT inzwischen gesellschaftlich relevant ist. Wir kommen nicht drum rum, das Thema ernsthaft anzugehen. Das ist analog zu Brandschutz, Verkehrssicherheit, Standards beim Bau, Arbeitnehmerschutz, …

Dadurch, dass durch die IT auch immer mehr physische Systeme gesteuert werden, ist ihre korrektes Funktionieren zunehmend wichtig für die (körperliche) Sicherheit der Menschen.

Es geht nicht nur um böswillige Akteure, sondern NIS behandelt umfassend den sicheren Betrieb von Computern und Netzwerken.

Wir haben mit NIS1 ein gutes Fundament – insb. was die interministerielle Zusammenarbeit und die Kooperation Staat / Wirtschaft betrifft.

Sind die Maßnahmen für die Betroffenen machbar?

Für viele:

Sie müssen dokumentieren, dass sie ihre Hausaufgaben gemacht haben
Das sind großteils Sachen, von denen man schon lange weiß, dass man sie eigentlich machen sollte
Für den CISO ist das ein aufgelegter Judo-Move, mit dem Gesetz im Rücken endlich die Sachen umsetzen zu können, die schon lange auf der ToDo-Liste sind

Für manche:

Für die ist viel Neues dabei, weil das Thema bis jetzt noch nicht systematisch angegangen wurde
Das sollten einen echten Schub für den Reifegrad vieler Organisationen bewirken

Für wenige:

Sie sind leider regulatorischer Beifang wegen Denkfehlern im Richtlinientext

Für alle:

Risikoanalyse: jede Organisation muss sich dokumentiert Gedanken machen, was ihre IT-Risiken sind
Das ist allemal sinnvoll.

Qualität der Richtlinien Umsetzung

Die Richtlinie ist sehr spezifisch – in vielen Bereichen war kaum Spielraum vorhanden. Daher konnten nicht alle sinnvollen Stellungnahmen aus der Begutachtung aufgenommen werden.

Die Richtlinie ist in einigen Bereichen schlecht formuliert. Hier wäre es sinnvoll gewesen, im Gesetz vom RL-Text abzuweichen, um bessere Formulierung zu finden.

Mehr Mut wäre gut gewesen

Klare Fehler in der RL sollten wir vielleicht doch nicht umsetzen. Die Kollegen aus CZ trauen sich da mehr. Siehe etwa Punkt 14.6. in ihrer Scope-Definition.
Wir sollten deutlicher formulieren, was man ermöglichen will
- z.B. im Datenschutz beim Informationsaustausch
- Kein „der Satz im §x plus §y in Verbindung mit dem Nebensatz im §z ermöglicht uns das eh“

Eine frühere Einbindung der Stakeholder hätte geholfen. Wir haben die Cyber Security Platform (CSP), nutzen wir sie doch bitte nicht nur für die Risikomanagement-Maßnahmen, sondern auch für eine offene Diskussion zu Implementierungsmodellen einer Cybersicherheitsbehörde.

Cybersecurity Architektur des NISG 2024

Es gibt keinen EU-Standard, wo das Thema Cybersecurity in der Verwaltung aufgehängt wird. Man findet in anderen EU-Mitgliedstaaten Platzierungen unter dem Premierminister, dem Innenresort, dem Finanzministerium, der National Security Authority, im Militärnachrichtendienst und unter dem Ministerium für Wirtschaft oder Digitalisierung. Manchmal ist das Thema direkt im Ministerium, andere haben dafür eine Agency/Amt, es gibt auch ausgegliederte Lösungen. Mache Staaten geben alles in ein „National Cyber Security Center“, andere haben einen sektoralen Ansatz und wiederum andere Trennen das Thema Regulierung stark vom Thema Hilfe.

Unser Entwurf für das NISG 2024 konzentriert alles, außer Notfallteams (CSIRTs), im BMI. Dazu gibt es viel Pro und Kontra. Aufpassen müssen wir bei:

Zielkonflikt: Schwachstellen schließen vs. Ermittlungsmöglichkeiten für die Polizei
Aufsicht vs. Hilfestellung
Überlappungen der Aufgaben der CSIRTs (§12 Abs. 1) und des BMI (§4 Abs. 1). Das läuft aktuell noch gut, hier müssen wir uns in Zukunft sehr gut abstimmen.

IKT-Systeme zur Früherkennung

Im §17 werden „IKT Systeme zur Früherkennung von Risiken, Cyberbedrohungen oder Cybersicherheitsvorfällen“ gefordert. Wie schon die Stellungnahmen gezeigt haben, ist das nicht unumstritten. Ich sehe das so:

Ja, wir brauchen eine gemeinsame Datenbasis zwischen allen Stakeholdern (CSIRTs, BMI, Militär, privaten SOCs) zu Bedrohungen (Cyber Threat Intelligence)
Siehe auch EU Cyber Solidarity Act
Erkennung von Vorfällen braucht 2024 aber
- Interne Netzwerksensoren
- Analyse von Logfiles
- Software (EDR – Endpoint Detection and Response) auf allen Systemen
Daher sollte die Vorfallserkennung am besten von der Einrichtung selber, bzw. ihrem selber ausgesuchten Dienstleister, gemacht werden
Der Staat kann IOCs einbringen und die Zusammenarbeit fördern und holt sich über diese Plattform Erkenntnisse aus dem Feld

Fragerunde

Nach unseren Eingangsstatements gab es eine Fragerunde; ich kann mich nicht mehr an alle erinnern.

Wie schätzen sie die Änderungen nach der öffentlichen Begutachtung ein?

Der aktuelle Stand im Initiativantrag ist deutlich besser als die Version von Anfang April. Es wurden viele Punkt verbessert, die bei Stellungnahmen angemahnt wurden. Wie vorhin gesagt: es mussten die Änderungen aber im Rahmen der Richtlinie bleiben.

Wurde hier „Gold Plating“ gemacht?

Nein, die Anforderungen an die Normunterworfenen und deren Auswahl kommt direkt aus der Richtlinie. Eigene Ideen betreffen rein die Behörden, die das Gesetz vollziehen müssen.

Ist NIS überschießend?

Die meisten Risikomanagement-Maßnahmen, die Firmen laut NIS implementieren müssen, sind Stand der Technik für gute IT-Betriebsführung. Wir müssen nur aufpassen, dass wir beim Vollzug auch tolerieren, dass bei der Risikoanalyse mancher Organisationen herauskommen kann, das einzelne Kapitel für diese schlicht nicht relevant sind, und diese dort daher auch nicht umgesetzt werden müssen.

Nach alle der Kritik, würden sie dem Gesetz zustimmen?

Ja, der Gesetzestext ist nicht perfekt, einiges könnte besser umgesetzt werden. Aber das Thema jetzt auf die lange Bank zu schieben, ist um nichts besser. Einige Firmen sind im Ausland schon von NIS2 betroffen, eine Nichtumsetzung bei uns führt nur zu noch mehr Verwirrung und noch weniger Planungssicherheit.

Im Rückblick

Am 3. Juli wurde dann das NISG 2024 in der 270. Plenarsitzung des Nationalrates behandelt, und erreichte nicht die qualifizierte Mehrheit. Ich hab mir die Debatte zuhause per Videostream angesehen und es war spannend zu beobachten, wie oft sich die Abgeordneten auf die Aussagen der beiden "Experten", also Sebastian Kneidinger von Epicenter.works und mich berufen haben. Manchmal durchaus korrekt, aber auch immer wieder falsch - so etwa hat keiner von uns gesagt, dass im Letztentwurf nicht auf das Feedback aus der Begutachtung eingegangen wurde.

Das Ganze hat mich sehr daran erinnert, wie es mir öfters geht, wenn ich mit Journalisten spreche: was man sagt, und was dann in der Zeitung steht, ist nicht immer das gleiche. Man kann oft froh sein, wenn der Artikel der eigenen Aussage nicht komplett widerspricht, sondern sie nur verkürzt, vereinfacht oder zugespitzt wiedergibt.

Ich hab bei meiner Stellungnahme im Innenausschuss versucht, eine differenzierte Einschätzung des Gesetzesentwurfes abzugeben. Das war vielleicht für diese Zielgruppe nicht die richtige Entscheidung. So kurz vor der Wahl ist in der Politik ist anscheinend nicht viel Platz für Graustufen, sondern alles wird nur noch in Schwarz/Weiß gesehen.

CVD - Notizen zur Pressekonferenz

CERT.at — Tue, 30 Apr 2024 17:50:52 GMT+0100

Ich wurde eingeladen, heute bei einer Pressekonferenz von Epicenter.works am Podium zu sitzen. Es ging um einen Fall, bei dem es im Zuge einer klassischen verantwortungsvollen Offenlegung einer Schwachstelle (Responsible Disclosure, bzw Coordinated Vulnerability Disclosure [CVD]) zu einer Anzeige gekommen ist. Nachzulesen ist der Fall auf der Epicenter Webseite.

Ich will hier kurz meine Notizen / Speaking Notes zusammenfassen.

Solche Klagen/Anzeigen gibt es nicht nur in Österreich, in Deutschland gab es etwa letztens auch ähnliche Fälle. Es gibt aber auch schon gute Gegenbeispiele wie etwa die Niederlande – dort bekommen Melder ein T-Shirt und keine Anzeige. Die Stadt Den Haag organisiert sogar "Hack the Hague"-Partys. Seitens der EU gibt es daher in der NIS2 Richtlinie Vorgaben an die EU-Mitgliedstaaten, dieses Thema zu adressieren. Das sind:

Es muss eine nationalen CVD-Policy entwickelt werden (Artikel 7(2)c)
Es muss eines der CSIRTs als CVD-Anlaufstelle festgelegt werden (Artikel 12)

Die NIS-Kooperationsgruppe, welche die Aufgabe hat, die NIS-Implementationen in den Mitgliedstaaten zu harmonisieren, hat ein Dokument veröffentlicht, das hierzu Empfehlungen ausspricht. Von der ENISA gibt es auch eine Studie zu diesem Thema.

Der Entwurf für das NISG-2024 regelt das Thema CVD in § 11 sehr knapp und greift nicht alle Punkte auf, die laut den EU-Empfehlungen geregelt gehören. Dazu gehören:

Strafrecht: Wie schützt man verantwortungsvolle Schwachstellenfinder:innen vor Anzeigen – also genau der Anlassfall in Österreich.
Zivilrecht: An was müssen sich Forscher:innen halten, damit klar ist, dass sie nicht auf Geschäftsschädigung bzw. Schadensersatz geklagt werden können.
Datenschutz: Um zu beweisen, dass Datenlecks bestehen, muss man Beispieldaten hernehmen. Was sind hier die Spielregeln?
Wie soll der CVD-Prozess genau funktionieren und welche Zeitlimits gelten bei den Schritten.

Vor allem sollte das Ziel des CVD-Prozesses klar definiert sein: Es muss darum gehen, dass die Schwachstelle möglichst schnell, umfassend und ohne Ausnutzung durch Dritte behoben wird. Der CVD-Prozess ist für die Verteidiger da – sie sollen durch die erstellen Datenbanken (etwa bei der ENISA) und Verständigungen in die Lage versetzt werden, sich zu schützen. Es geht ganz klar nicht darum, dass der Staat Exploits sammeln will.

Es braucht hier eine gefühlvolle Abwägung zwischen dem Schutz vor rücksichtslosem Penetration-Testing versus dem Recht, online links und rechts zu schauen und gefundene Probleme ohne Furcht vor negativen Folgen melden zu können. Damit das garantiert werden kann, schreibt die EU-Richtlinie vor, dass diese Meldungen auch anonym erfolgen können.

Nach allem, was ich aus dem BMI gehört habe, wird das Thema bald angegangen, ich wünsche mir, dass es hier zu einer Einbeziehung der Zivilgesellschaft und den Universitäten kommt.

Genauso wie der Staat Österreich sich eine nationale CVD-Policy geben sollte, so sollten auch alle Organisationen klar bekanntgeben, wie sie auf Meldungen zu Problemen in ihren Netzen reagieren, und wo man diese melden kann. Eine Option dafür ist der security.txt Standard.

Wir von CERT.at werden wohl die Rolle des CSIRTs bekommen, das sich um die gemeldeten Schwachstellen in Österreich kümmern wird. Wir machen das gewissermaßen schon seit Anbeginn: wir geben jeden Tag hunderte Meldungen zu Sicherheitsproblemen im österreichischen Internet an die jeweiligen Betreiber weiter, damit diese ihre Systeme absichern. Hier ist durchaus noch Luft nach oben, insbesondere was die Mitarbeit mancher ISPs angeht.

NIS2 – Richtlinie: Ein zweiter Blick auf den Text

CERT.at — Fri, 26 Apr 2024 12:41:11 GMT+0100

Beim Schreiben unserer Stellungnahmen zum Entwurf des NISG 2024 habe ich mir die Paragrafen, die uns betreffen, genauer angesehen. Diesmal nicht mit dem Blickwinkel „macht das Sinn“, sondern mit Fokus auf die Formulierungen. Das erinnert mich ein bisschen an die Zeit, als ich bei der Erstellung von RFCs mitgearbeitet habe und da auch bei Reviews jedes Wort genau auf mögliche Fehldeutungen abgeklopft habe.

Ich hatte beim Lesen drei Dokumente offen: den Gesetzesentwurf, die Richtlinie in der deutschen Version und auch die englische Fassung. Und viele der schlechten Formulierungen waren keine Erfindungen aus Wien, sondern wurden schon in Brüssel erfunden. Ich will das hier dokumentieren:

Domain vs. Domäne

Der Zug ist bei Gesetzestexten wahrscheinlich schon abgefahren, aber englische Begriff „domain“ im Kontext des DNS wird normalerweise nicht eingedeutscht, sondern als „Domain“ verwendet (Siehe Webseiten der Registries [at, de, ch] oder Webhostern [1, 2, 3]), während das Wort „Domäne“ primär im Kontext von Windows und Active Directory verwendet wird.

DNS-Diensteanbieter

§ 3 Z 12 definiert sie als

"Einrichtung, die b) autoritative Dienste zur Auflösung von Domänennamen zur Nutzung durch Dritte, mit Ausnahme von Root-Namenservern, anbietet";

„Dritte“ ist hier nicht eindeutig, das könnte sich auf Domaininhaber beziehen, die ihre Domains auf den autoritative Nameservern eines DNS-Diensteanbieter hosten lassen, oder auf die Personen, die Anfragen an diese Nameserver stellen. Die erstere Deutung ist hoffentlich die gewünschte, wenn man „Dritte“ durch „Domaininhaber“ ersetzt, ist das eindeutig. Das Original „authoritative domain name resolution services for third-party use“ hat das gleiche Problem.

Definition von „Einrichtung, die Domänennamen-Registrierungsdienste erbringt“

Hier ist schon in der deutschen Version der Richtlinie ein Fehler drinnen, indem „Anbieter“ und „Wiederverkäufer“ vertauscht wurden.

Aus dem englischen „(22) ‘entity providing domain name registration services’ means a registrar or an agent acting on behalf of registrars, such as a privacy or proxy registration service provider or reseller;“ wurde in in der deutschen Version „Einrichtung, die Domänennamen-Registrierungsdienste erbringt“ ein Registrar oder eine Stelle, die im Namen von Registraren tätig ist, wie etwa ein Anbieter oder Wiederverkäufer von Datenschutz- oder Proxy-Registrierungsdiensten;".

Korrekt wäre aber

„Einrichtung, die Domänennamen-Registrierungsdienste erbringt“ ein Registrar oder eine Stelle, die im Namen von Registraren tätig ist, wie etwa ein Anbieter von Datenschutz- oder Proxy-Registrierungsdiensten oder Wiederverkäufer;“,

oder (besser)

„Einrichtung, die Domänennamen-Registrierungsdienste erbringt“ ein Registrar oder eine Stelle, die im Namen von Registraren tätig ist, wie etwa Wiederverkäufer oder Anbieter von Datenschutz- oder Proxy-Registrierungsdiensten;"

Aufgaben der CSIRTs

Der erste Absatz lautet hier

§8 (1) 1. die Überwachung und die Analyse von Cyberbedrohungen, Schwachstellen und Cybersicherheitsvorfällen auf nationaler Ebene und gegebenenfalls die Unterstützung betreffender wesentlicher und wichtiger Einrichtungen hinsichtlich der Überwachung ihrer Netz- und Informationssysteme in Echtzeit oder nahezu in Echtzeit;

Ja, das ist fast 1:1 der Text aus der Direktive, in dem wurde das schon holprige englische „concerned“ als „betreffende“ übersetzt. Was das Wort im Gesetzestext aussagen soll, erschließt sich mir nicht. Besser wäre „betroffener“: damit ist klar die Einrichtungen gemeint, die von den Bedrohungen, Schwachstellen und Vorfällen betroffen sind. Da viele Cyberbedrohungen aber generisch sind, und daher eine gezielte Hilfe nicht immer machbar ist, oder die Hilfe proaktiv ist, könnte man auch das Wort „betreffender“ einfach weglassen.

Domaininhberinformationen

§30 (1) Die TLD-Namenregister und die Einrichtungen, die Domänennamen-Registrierungsdienste erbringen, haben in einer eigenen Datenbank genaue und vollständige Domänennamen-Registrierungsdaten zu sammeln

In der englischen Direktive steht hier „accurate and complete“, was besser mit „korrekt und vollständig“ zu übersetzen wäre. Das Wort „genau“ hat zwei Bedeutungen: es kann „exakt richtig“ meinen, aber auch nur dass die Angabe sehr spezifisch – aber nicht notwendigerweise korrekt – ist. Da mit dem zweiten Adjektiv „vollständig“ klar ist, dass etwa nur die Angabe des Nachnamens nicht reicht, ist bei „genau“ die Bedeutung „korrekt“ die relevante, worauf es mehr Sinn macht, gleich dieses Wort zu verwenden.

Meldepflichten bei lang anhaltenden Vorfällen

§34 (2) 5. im Falle eines andauernden Cybersicherheitsvorfalls zum Zeitpunkt der Vorlage des Abschlussberichts gemäß Z 4 haben die betreffenden Einrichtungen zu diesem Zeitpunkt einen Fortschrittsbericht und einen Abschlussbericht innerhalb eines Monats nach Behandlung des Cybersicherheitsvorfalls zu übermitteln.

Auch hier ist schon die Textvorlage der Direktive nicht verständlich formuliert („Behandlung des Cybersicherheitsvorfalls“ ist kein Zeitpunkt, sondern ein lange dauernder Vorgang). Eine bessere Formulierung wäre etwa

Falls der Cybersicherheitsvorfalls zum Zeitpunkt der Fälligkeit der Vorlage des Abschlussberichts gemäß Z 4 noch andauert, haben die betreffenden Einrichtungen bis zu diesem Zeitpunkt einen Fortschrittsbericht zu übermitteln. Der Abschlussbericht muss bis maximal ein Monat nach Beendigung der Vorfallsbehandlung übermittelt werden.

Oder aber (ganz verstehen wir die Intention hinter der Formulierung in der Direktive nicht):

Falls der Cybersicherheitsvorfalls zum Zeitpunkt der Fälligkeit der Vorlage des Abschlussberichts gemäß Z 4 noch andauert, haben die betreffenden Einrichtungen bis zu diesem Zeitpunkt einen Fortschrittsbericht zu übermitteln, wodurch sich die Frist für die Vorlage des Abschlussberichts um ein Monat nach hinten verschiebt.

Stellungnahme von CERT.at zum NISG 2024

CERT.at — Thu, 18 Apr 2024 15:16:02 GMT+0100

Die EU hat noch Ende 2022 die NIS2-Richtlinie angenommen, was den EU Mitgliedstaaten eine Frist bis Herbst 2024 einräumt, diese in nationales Recht zu gießen.

Jetzt liegt ein Entwurf für dieses Gesetz vor und wir haben uns genau angesehen, wie die Punkte umgesetzt sind, die uns als nationales CSIRT betreffen. Dabei sind uns einige Stellen aufgefallen, wo wir klares und einfaches Verbesserungspotential sehen. Das sind insbesondere:

Begriffsbestimmungen: in einem Fall ist schon bei der Übersetzung der Richtlinie von Englisch auf Deutsch ein Fehler passiert.
Strukturen: Die Definition des SPOCs enthält Kommunikationswege, die die Richtlinie nicht vorsehen. Im Bezug auf die Vertrauenswürdigkeit der CSIRT-Mitarbeiter ist der Text in zwei Punkten unklar bzw. überschießend.
CVD: Der Paragraph zur Koordinierten Offenlegung von Schwachstellen ist ein guter Anfang, aber er behandelt das Thema nicht umfassend, da wird es Nacharbeiten geben müssen.
Meldewege: Der Prozess für Pflichtmeldungen enthält unklare Formulierungen und vermisst die Freigabe für die Übermittlung von PII Daten; die Festlegungen zu den freiwilligen Meldungen könnte man deutlich vereinfachen.
Informationaustausch: Der §36 ist eine 1:1 Übernahme aus der Richtlinie, mit einer kleinen Erweiterung könnte man das deutlich sinnvoller gestalten.
Verwendung von zertifizierten Produkten: auch hier ist die Sprache unklar

Details kann man unserer vollständigen Stellungnahme entnehmen.

Staatlich gesponserte "Entwicklung" quelloffener Software

CERT.at — Mon, 01 Apr 2024 14:17:39 GMT+0100

TL;DR: Wer auf der Suche nach einer kurzen Zusammenfassung der Geschehnisse rund um die (höchstwahrscheinliche) Backdoor in xz, CVE-2024-3094, ist, möge einen Blick auf diese durch den Sicherheitsforscher Thomas Roccia erstellte Grafik werfen. Darin sind die wichtigsten Details zusammengefasst, die in den folgenden Absätze wesentlich ausführlicher beleuchtet werden.

Alternativ hätte dieser Blogpost auch einen deutlich knackigeren Titel haben können - "CVE-2024-3094", um jene geht es in diesem Beitrag nämlich. Diese Sicherheitslücke in einer populären Implementation des "xz"-Dateiformates, welche mit an Sicherheit grenzender Wahrscheinlichkeit keine einfache Schwachstelle, sondern eine bewusst platzierte Hintertür ist, hat in den vergangenen Tagen durchaus für Aufregung gesorgt.

Diese Hektik und Nervosität war berechtigt, wenngleich die IT-Sicherheitsgemeinschaft in der initialen Erregung meiner Meinung nach einen wirklich besorgniserregenden Aspekt der ganzen Sache ziemlich ignoriert hat. Aber der Reihe nach ..

Was ist passiert?

Der Entwickler Andreas Freud entdeckte am 29.03.2024 beinahe zufällig eine schwerwiegende Sicherheitslücke in liblzma, einem Teil von xz. Während einiger lokaler Benchmarks im Rahmen anderer Arbeit fielen ihm einige Merkwürdigkeiten in Zusammenhang mit dem auf seinem System installierten SSH-Daemon auf, welcher ungewöhnlich viel CPU-Leistung verbrauchte. Weitere Untersuchungen deuteten darauf hin, dass liblzma der Ursprung der Leistungsprobleme sei, und führten - aufgrund einer sehr glücklichen Verkettung einer Vielzahl von Zufällen - schlussendlich zur Entdeckung der Schwachstelle.

Bereits nach kurzer Zeit stellte sich heraus, dass die Sicherheitslücke sehr wahrscheinlich nicht durch unbeabsichtigte Fehler von Entwickler:innen verursacht wurde, sondern dass es sich um eine durch bösartige Akteure bewusst platzierte Hintertür handelte.

Auffällig, und besonders beunruhigend, ist die Tatsache, dass es aktuell nicht danach aussieht, als wären die Systeme einer Person mit Zugriffsrechten auf die Versionskontrolle des xz-Projekts kompromittiert worden. Stattdessen scheint es sich hier um einen von langer Hand vorbereiteten Angriff handeln, bei dem die Angreifer:innen in der Lage waren, sich unter Vortäuschung falscher Tatsachen Commit-Rechte zu erschleichen. Eine detaillierte Ausführung dieses Aspektes des Angriffes würde den Rahmen dieser Veröffentlichung sprengen; der Entwickler Evan Boehs hat eine gute, vorläufige Zeitleiste auf seiner Webseite veröffentlicht.

Die durch den Bedrohungsakteur platzierte Hintertür ist technisch beeindruckend, und das nicht nur, weil ich selbst kein Entwickler bin und mein Kopf während des Lesens der verschiedenen Analysen zu rauchen begonnen hat. Aber die Tatsache, dass es mehrere Stufen gibt, sie auf eine Art und Weise geschrieben wurde, die es nahezu unmöglich macht, effektiv danach zu scannen, und dass die Analyse trotz der enormen Aufmerksamkeit von allen Seiten der Community noch nicht komplett ist, spricht für mich eine eindeutige Sprache.

Der oder die Verantwortliche/n hat signifikanten Aufwand betrieben, um sein Ziel zu erreichen, unabhängig davon, ob es um zeitliche oder monetäre Ressourcen geht. Wir reden hier von einem Bedrohungsakteur, der über mehrere Jahre hinweg im Einzelnen unauffällige Änderungen an verschiedenen, quelloffenen Softwareprojekten erreicht oder durchgeführt hat, um schlussendlich eine technisch hochkomplexe Hintertür in xz einbauen zu können, die ihm unter Umständen unauffälligen Fernzugriff auf hunderttausende Systeme auf der ganzen Welt ermöglicht hätte.

Wir wissen aktuell nicht, wer dahintersteckt. Aber die Kombination aus der technischen Komplexität und der operativen Disziplin, bzw. dem operativen Aufwand über Jahre hinweg, sind für mich Indizien, die in Richtung eines staatlich gesteuerten, oder zumindest staatlich unterstützten, Bedrohungsakteurs deuten. Mit der Annahme stehe ich nicht gänzlich alleine auf weiter Flur, auch Leute mit deutlich mehr Ahnung als ich sehen das ähnlich.

Die Situation hat sich rasch entwickelt, und seit dem ersten Kommentar von Andreas Freud letzten Freitag wurden viele Informationen zusammengetragen. Trotzdem sind die Untersuchungen noch lange nicht abgeschlossen, und es ist nicht auszuschliessen, dass in den nächsten Tagen noch weitere Erkenntnisse folgen.

Was bedeutet das für mich?

Benutzer:innen, auf deren Systemen Debian Testing, Debian Sid und Debian Experimental, Fedora 41 (und 40, unter bestimmten Umständen), Fedora Rawhide, Kali Linux und Arch Linux (unter bestimmten Umständen), openSUSE Tumbleweed oder openSUSE MicroOS eingesetzt wird, sind dringend dazu angehalten, bereits zur Verfügung stehende Sicherheitsaktualisierungen einzuspielen.

Die genannten Distributionen bzw. Versionen sind diejenigen, deren Versionen von xz gesichert von der Schwachstelle betroffen sind. Es gibt jedoch einige andere Distributionen bzw. Versionen, die aufgrund ihrer Release-Politik von der Sicherheitslücke betroffen sein könnten, bzw. die in den nächsten Tagen noch davon betroffen werden könnten.

Auf repology.org findet sich eine Auflistung, welche Distribution aktuell welche Version von xz in den Paketquellen hat. Nachdem auch in den Repositories des Paketmanagers Nix zeitweise eine verwundbare Version beinhaltet war ist nicht auszuschliessen, dass nicht auch macOS-Installationen betroffen sein könnten.

Ich habe hier bewusst Benutzer:innen angesprochen, und nicht Unternehmen oder Organisationen. Jene unter diesen, die (in der breiten Masse, im produktiven Einsatz) auf "Bleeding Edge" setzen .. mutig. Deutlich mutiger als ich, und ihr wisst hoffentlich, was ihr da tut, und wie ihr die Situation handhabt.

Bisher gibt es keine Anzeichen dafür, dass die Sicherheitslücke breitflächig ausgenutzt worden wäre. Laut einem Blogpost des Sicherheitsunternehmens Wiz (welches Cloud Security-Dienstleistungen anbietet) finden sich verwundbare Versionen von xz nur auf ungefähr 2% der Systeme in ihrem Zuständigkeitsbereich. Auch wenn sich diese Zahl natürlich nicht 1:1 auf das gesamte Internet übertragen lässt, so dient sie zumindest als ein Indikator dafür, dass eine Verwundbarkeit kein absolutes Massenphänomen ist.

Diese These wird auch von den ersten Resultaten der Analyse der Sicherheitslücke unterstützt. Diese legen nahe, dass sich die Schwachstelle, bzw. deren Ausnutzung, primär gegen bestimmte Distributionen (Debian, Red Hat und etwaige Derivate) richten sollte, und auch hier nur gegen Systeme, die gewisse Kriterien erfüllen.

Soll heissen: Aus praktischer Sicht ist in den allermeisten Fällen kein Grund zur Panik gegeben, und die Schwachstelle kann mit den üblichen Prozessen abgehandelt werden, die auch bei der Handhabung anderer Sicherheitslücken zum Einsatz kommen. Für Nutzer:innen bedeutet das also, schnellstmöglich den Updatemechanismus des installierten Betriebssystems bedienen.

Was bedeutet das?

Dennoch: Nur, weil bisher keine Informationen über etwaige Ausnutzung(en) der Schwachstelle an die Öffentlichkeit gelangt sind heisst das nicht notwendigerweise, dass das nicht passiert ist. Das ist aber nicht der eigentliche, wichtige Punkt an der ganzen Angelegenheit.

Auch wenn eine kritische Sicherheitslücke, die eine so verbreitete Implementierung eines grundlegenden Protokolls des modernen Internets, bzw. eine so verbreitete Programmbibliothek, betrifft, natürlich eine hässliche Sache ist, so wäre das alleine noch kein Grund dafür, dass meine Kolleg:innen Teile des Osterwochenendes im Dienst verbringen durften. Oder Auslöser dafür, dass ich hier in die Tasten hauen würde. Man schaue sich einfach unsere Warnungen der letzten Monate an.

Der eigentliche Punkt, das wirklich besorgniserregende an der Situation ist, dass wir es hier mit einem Supply Chain-Angriff zu tun haben, der von einem kompetenten, über in jeder Hinsicht signifikante Ressourcen verfügenden bösartigen Akteur durchgeführt worden ist.

Auch wenn das abschliessende Urteil noch aussteht, und noch nicht mit hundertprozentiger Sicherheit erwiesen ist, so sieht es für den Moment dennoch sehr stark danach aus, als wäre das einer der komplexesten, besten Angriffe auf Lieferketten, den wir in langer Zeit gesehen haben. Und der, wie in einem der ersten Absätze erwähnt, hauptsächlich durch Zufall entdeckt worden ist.

Plus: Der dafür verantwortliche Bedrohungsakteur hat einen, zumindest wenn man die Supply Chain-Angriffe betrachtet, die medial bekannt geworden sind, ungewöhnlichen Weg gewählt. Er hat sich nicht dafür entschieden, mittels offensiver Computermittel sein Ziel zu erreichen. Sondern hat analoge Mittel und Wege für digitale Erfolge genutzt.

Angreifer:innen haben bereits vor längerer Zeit verstanden, dass Sicherheitsexpert:innen ein lukratives Ziel sind. Einerseits aus offensichtlichen Gründen - das System eine:r Mitarbeiter:in eines SOC zu kompromittieren erlaubt unter Umständen weitreichenden Zugriff, ein Einbruch in den Computer einer Sicherheitsforscher:in kann gegebenenfalls wertvolle Informationen liefern, mit der sich die eigene OPSEC der Kriminellen stärken lässt, und so weiter.

Aber: Sicherheitsexpert:innen selbst anzugreifen kann für Täter:innen ebenfalls lohnend sein. Dass IT-Sicherheit ein stressiges Berufsfeld ist muss ich der Leserschaft dieses Blogs wohl nicht erklären. Zu viele Aufgaben, zu wenige Ressourcen, und in sehr vielen Fällen ist man gezwungen, reaktiv zu agieren, weil proaktive Schritte Unterstützung aus dem Management benötigt hätte.

Wenn man bereits gestresst ist, und dann noch durch Angreifer:innen belästigt wird, man selbst oder die Liebsten durch die Kriminellen bedroht werden, dann kann dies eine massive, zusätzliche Belastung sein.

Meiner (sehr persönlichen, subjektiven) Meinung nach haben sich die Angreifer:innen im aktuellen Fall von xz ebenfalls Stress und psychologische Last zu Nutze gemacht, allerdings auf eine heimlichere, perfidere Art und Weise.

Der Hauptentwickler hinter xz, Lasse Collin (dessen Statement zu der aktuellen Causa sich hier finden lässt) war lange Zeit der einzige Entwickler dieser Software, die ein fundamental wichtiger Bestandteil der meisten modernen, verbreiteten Linux-Distributionen ist. Ein sich fast schon aufdrängendes Beispiel für den Wahrheitsgehalt eines sehr bekannten XKCD.

Die Geschwindigkeit, mit der Entwicklungsfortschritte erzielt wurden, waren dementsprechend gering. Insbesondere auch, weil Lasse Collin durch Probleme mit seiner mentalen Gesundheit und anderen privaten Einflüssen stellenweise signifikant eingeschränkt war - etwas, das er auf projektbezogenen Mailinglisten offen angesprochen hat:

I haven't lost interest but my ability to care has been fairly limited mostly due to longterm mental health issues but also due to some other things. Recently I've worked off-list a bit with Jia Tan on XZ Utils and perhaps he will have a bigger role in the future, we'll see.

Besagter Jia Tan hatte sich einige Monate zuvor das erste Mal auf der Mailingliste des Projektes zu Wort gemeldet, mit einem Patch für xz - ein Patch, dessen Inkludierung rasch von einer weiteren, bisher ebenfalls unbekannten Person, gefordert wurde. Eine Forderung, die im Monatstakt wiederholt wurde.

Zumindest ein weiterer, bisher ebenso nicht in Erscheinung getretener, Teilnehmer auf der Mailingliste bekräftigte den Wunsch nach Akzeptanz des Patches. Die Forderungen gingen irgendwann dazu über, dass der ursprüngliche Entwickler aufgefordert wurde, einen weiteren Maintainer zu ernennen, während ihm im selben Atemzug vorgeworfen wurde, sich nicht mehr für das Projekt zu interessieren. Ein Vorwurf, der jemanden, der bereits mit psychischen Problemen zu kämpfen hat, sicherlich hart treffen würde.

Relativ kurze Zeit nach diesen Nachrichten liefert Jia Tan seinen ersten direkten Beitrag zu xz, und steuert in den darauffolgenden Monaten regelmässig Patches bei. Ab Jänner 2023 scheint es besagter Person gelungen zu sein, das vollständige Vertrauen von Lasse Collin zu erlangen, da ab diesem Zeitpunkt nicht nur Patches beigesteuert werden, sondern diese auch direkt in die Codebasis eingepflegt werden.

Dem Bedrohungsakteur ist es gelungen, einen Angriffsvektor auszunutzen, für den vorrangig quelloffene Projekte anfällig sind. Die Bedingungen, unter denen die Entwickler:innen bzw. Verantwortlichen solcher Projekte agieren sind ideal um auszubrennen. Was es Kriminellen ermöglicht, sich in eine Position zu bringen, in der es vergleichsweise einfach ist, sich als der "Retter in der Not" zu präsentieren. Und diese damit, in weiterer Folge, die Möglichkeit bekommen, heimlich still und leise in vermeintlich vertrauenswürdiger Software Schadcode zu platzieren. Wieder einmal beisst uns die verbreitete Unwilligkeit von Unternehmen, quelloffene Software adäquat zu unterstützen, in das metaphorische Hinterteil.

Der österreichische Journalist Andreas Proschofsky hat es in einem Artikel zu der Thematik besser zusammengefasst, als ich es je könnte:

Doch diese Freude dürfte von kurzer Dauer sein, wirft die Episode doch einige unerfreuliche Fragen auf. Etwa, wie es im Jahr 2024 noch immer sein kann, dass auf vielen Millionen Rechnern eingesetzte Komponenten bis heute von schwer überarbeiteten Hobby-Entwicklern gewartet werden. Obwohl durchaus bekannt ist, dass genau solche Projekte zu einem immer größeren Ziel für Angreifer werden.

Auf jeder Konferenz, bei der es auch nur am Rande um IT-Sicherheit geht wird die Thematik der Sicherheit digitaler Lieferketten breitgetreten, es gibt eine Vielzahl von (in ihrem Nutzen fragwürdigen) Workshops zu dem Thema, in Diskussionen zu Cybersicherheitsgesetzen wird Supply Chain-Sicherheit angesprochen.

Dennoch ändert sich nichts daran, dass kritische Teile unserer digitalen Infrastruktur von überarbeiteten Freiwilligen entwickelt und gewartet werden, die ausser Beschwerden und Druck herzlich wenig willkommen.

Deswegen gehe ich mit dem Blickwinkel, dass die Entdeckung der und der Umgang mit der Schwachstelle ein Erfolg war, nicht d'accord. Eine Mischung aus Zufall, Glück und intensivem persönlichem Einsatz waren der Grund dafür, dass es Angreifer:innen nicht gelungen ist, eine Hintertür in einer enorm wichtigen Softwarepaket zu verstecken. Wir können und dürfen uns nicht darauf verlassen, dass uns das beim nächsten Mal wieder gelingt.

Dieser Angriff hat gezeigt, dass die bestehenden Mechanismen, mit denen wir uns vor Angriffen auf Lieferketten im Open Source-Bereich schützen wollen, nicht (oder nicht gut genug) funktionieren. Wir müssen hier besser werden, sonst haben wir in der nahesten Zukunft noch mehr Probleme, als wir jetzt bereits haben.

Die Verantwortung für diese notwendige Verbesserung darf allerdings nicht alleine auf den Schultern der Entwickler:innen liegen. Die enorme mentale Belastung selbiger war für die Durchführung des Angriffes gegen xz ein wichtiger Faktor, den Zuständigen jetzt noch mehr Verantwortung und Stress aufzuhalsen wird nicht zielführend sein.

Ablauf einer Schwachstellen-Information durch CERT.at am Beispiel Ivanti Connect Secure VPN (CVE-2024-21887, CVE-2023-46805)

CERT.at — Thu, 25 Jan 2024 15:06:07 GMT+0100

Am Mittwoch 10.01.24 17:48 veröffentlichte Ivanti die Information bezüglich der Schwachstellen CVE-2024-21887 und CVE-2023-46805 in ihrem Produkt Connect Secure VPN (früher Pulse Connect VPN) [1].

Dies kam für uns zwar nicht ganz, aber doch überraschend, da wir zwar über das europäische CSIRT Netzwerk erfahren hatten, dass mit etwas zu rechnen ist, aber erst mit Donnerstag 11.01.24.
Es könnte damit in Verbindung stehen, dass der bekannte Sicherheitsforscher Kevin Beaumont auf Mastodon bereits Mittwoch 10.01.24 17:18 über Schwachstellen in diesem Produkt postete [2] . Diese Verhaltensweise ist, wenn auch interessant, nicht unbedingt optimal, weil sie eine koordinierte Schwachstellen-Kommunikation eher erschwert und im schlimmsten Fall dazu führt, dass Schadakteure ihre Spuren verwischen bevor Beweise gesammelt werden konnten.
Dies ist besonders relevant, wenn die Schwachstellen, wie in diesem Fall, bereits vor Veröffentlichung, also als 0-day, für die Kompromittierung von Geräten benutzt wurden.
Laut Berichten von Veloxity [3] und Mandiant [4] war dies seit etwa Dezember 2023 für ausgewählte Ziele bereits der Fall.

Nach der Veröffentlichung begann nun der normale Prozess für CERTs weltweit, ebenso natürlich für CERT.at ... die Verbreitung der Information über die Schwachstellen vorzubreiten beziehungsweise zu finalisieren. Die CERTs veröffentlichten und sendeten ihre Warnung aus. Unsere Warnung, die laufend aktualisiert wird, wurde Donnerstag 11.01.24 gegen Mittag ins Netz gestellt, über den freien RSS-Feed für Abonnenten zugänglich gemacht und ausgesandt [5]. Gleichzeitig wurden Besitzer im Österreichischen IP-Raum identifizierter Geräte über uns bekannte Kontakte direkt per E-Mail benachrichtigt. Letzteres kann herausfordernd sein, da bei vielen IPs ausschließlich die Kontakte der verantwortlichen Internet Service Provider (ISP) hinterlegt sind und hier die ISPs gefordert sind, die Information entsprechend weiterzuleiten, was außerhalb unseres direkten Einflussbreichs liegt. Die Zusammenarbeit mit ISPs ist sehr gut, aber man kann natürlich immer etwas verbessern.

Nachdem ab Freitag 12.01.24 immer mehr Details zur Art und Weise der Kompromittierungen und zu den Schwachstellen bekannt wurden, konnten spezifischer Geräte ausgemacht werden, die betroffen sind oder noch nicht abgesichert wurden. CERT.at hat die Besitzer beziehungsweise bekannten Kontakte laufend über unsere automatisierte Lösung IntelMQ kontaktiert.
Eine Schattenseite von immer detailreicheren Informationen bezüglich Schwachstellen, ist die folgende Entwicklung von öffentlich verfügbaren Exploits, also Ausnutzungsmöglichkeiten. Im konkreten Fall wurde am Montag 15.01.24 ein Modul für eine bekannte Penetrationtesting-Lösung Metasploit veröffentlicht [6]. Dies erlaubte nun eine breite Ausnutzung der Schwachstellen.

Nach weiterer Beobachtung der Lage beschlossen wir am Freitag 19.01.24 erneut an Betreiber von Geräten die ab Montag 15.01.24 ihre Geräte noch nicht abgesichert hatten, direkt Informationen über die Gefährdungslage auszusenden und Besitzer kompromittierter Geräte telefonisch zu kontaktieren.

Mit Montag 22.01.24 haben wir nachgefasst und die Besitzer noch verbleibender verwundbarer Systeme direkt telefonisch kontaktiert. Dies ist natürlich mit Recherche-Aufwand verbunden und führt oft nicht direkt zu relevanten Ansprechpersonen.

Der weiterführende Informationsverteilungs-Prozess könnte erheblich erleichtert werden, wenn Organisationen und Unternehmen vermehrt auf RFC 9116 setzen würden und die damit verbundene security.txt [7] mit relevanten Kontaktinformationen, wie die bereits lange benutzte robots.txt, auf ihren Internet-Seiten pflegen. Die in der security.txt enthaltenen Kontaktdaten würden den manuellen Rechercheaufwand für die telefonische und anderweitige direkte Kontaktaufnahmen stark verkürzen und bei breiter Anwendung potentiell eine Automatisierung erlauben.

Wir beobachten die Lage weiter genau und sind in intensivem Austausch mit dem europäischen CSIRT Netzwerk und unseren internationalen Partnern.

Sie hören von uns. ;)

Timeline:

Di. 09.01. Erste Infos das etwas kommt werden bekannt
Mi. 10.01. Ivanti veröffentlicht Advisory einen Tag früher als geplant [11.01.] (abends) (Mastodon Leak Kevin Beaumont)
Mi. 10.01. Volexity veröffentlicht Blog mit Webshell Details
Mi. 10.01. CISA fügt Schwachstellen zu KEV hinzu
Do. 11.01. CERT.at veröffentlicht diesbezüglich ein Warning (mittags)
Do. 11.01. 15:40 CERT.at Oneshot ausgesendet (Geräte identifiziert [potentiell verwundbare]) (86 IPs)
Fr. 12.01. Mandiant veröffentlicht Blog mit Webshell Details
Mo. 15.01. Metasploit-Modul wird veröffentlicht (breitere Ausnutzuing [Coinminer, CredentialStealer])
Mo. 15.01. Externe Partner scannen nach noch verwundbaren Systemen (18 IPs)
Di. 16.01. Externe Partner scannen nach kompromittierten Systemen (Webshells) (0 IPs)
Di. 16.01. Volexity veröffentlich Blog zu breiter Ausnutzung der Schwachstellen
Di. 16.01. CERT.at Automatisierte Aussendung über IntelMQ an weiterhin verwundbare Systeme (14 IPs)
Do. 18.01. Kompromittierung durch externen Partner detektiert (1 IP)
Do. 18.01. Eskalation der Schwachstellen im europäischen CSIRT Netzwerk
Do. 18.01. Unbekannte Webshell (WIREFIRE-Variante) durch CSIRT Netzwerk an externe Partner gemeldet
Fr. 19.01. CERT.at eskaliert Schwachstellen
Fr. 19.01. WIREFIRE-Variante wird durch externe Partner gescannt
Fr. 19.01. Anfrage anderer externer Partner auf weitere Kompromittierung in Österreich (16.01. 1 IP) - bereits mitigiert
Fr. 19.01. Direkte telefonische Kontaktaufnahme mit Besitzer weiterhin kompromittiertem System
Fr. 19.01. 15:38 Oneshot (potentiell kompromittiert, noch verwundbar ab 15.01.)
Fr. 19.01. CERT.at Update Warning
Fr. 19.01. CERT.at Automatisierte Aussendung über IntelMQ an neue verwundbare Systeme (1 IP)
Mo. 22.01. CSIRT Netzwerk Meeting bezüglich Schwachstellen
Mo. 22.01. CERT.at beginnt telefonisch Besitzer von Geräten auf IPs, die ab 15.01. und noch verwundbar waren, zu kontaktieren.
Mo. 22.01. QUOINTELLIGENCE veröffentlich Blog-Post zu WIREFIRE-Variante
Mo. 22.01. CERT.at Automatisierte Aussendung über IntelMQ an neue verwundbare Systeme (2 IP)
Di. 23.01. Weitere Beobachtung Informations-Kanäle
Di. 23.01. CERT.at Automatisierte Aussendung über IntelMQ an neue verwundbare Systeme (1 IP)
Mi. 24.01. Keine kompromittierten Geräte in Scans von externen Partner mehr in Österreich
Mi. 24.01. CERT.at Warning erneut wegen negativem Einfluss eines automatischen Konfiguration-Push auf Mitigation aktualisiert
Do. 25.01. CERT.at finalisiert Blog-Beitrag zu diesem Thema.
Do. 25.01. Verwundbare Geräte im österreichischen IP-Raum noch vorhanden. (8 IPs)

[1] https://forums.ivanti.com/s/article/KB-CVE-2023-46805-Authentication-Bypass-CVE-2024-21887-Command-Injection-for-Ivanti-Connect-Secure-and-Ivanti-Policy-Secure-Gateways?language=en_US
[2] https://cyberplace.social/@GossiTheDog/111732557100241084
[3] https://www.volexity.com/blog/2024/01/10/active-exploitation-of-two-zero-day-vulnerabilities-in-ivanti-connect-secure-vpn/
[4] https://www.mandiant.com/resources/blog/suspected-apt-targets-ivanti-zero-day
[5] https://cert.at/de/warnungen/2024/1/kritische-sicherheitslucken-in-ivanti-connect-secure-und-ivanti-policy-secure-aktiv-ausgenutzt
[6] https://github.com/rapid7/metasploit-framework/pull/18708/commits/4060e069ed73927066b8a242e02d794f19251e9c
[7] https://securitytxt.org/

Es cyberwar't wieder. Oder so.

CERT.at — Thu, 19 Oct 2023 14:09:19 GMT+0100

Wichtiger Disclaimer vorweg: Die Beiträge in unserem Blog werden von Mitarbeiter:innen von CERT.at verfasst, und spiegeln deren Meinung(en) wieder, nicht "offizielle" Meinungen und Ansichten des nationalen Computernotfallsteams.

Ich habe mir größtmögliche Mühe gegeben, mich auf vorhandene Fakten zu konzentrieren, technische Informationen in den Vordergrund zu stellen und auch sprachlich neutral zu bleiben. Dennoch kann ich nicht ausschließen, dass mir Formulierungen durchgerutscht sind, die in irgendeiner Weise politisch gefärbt sind. Wo dies der Fall ist, handelt es sich um einen Fehler des persönlichen Lektorats und keine bewusste Meinungsäusserung - nicht von mir, und insbesondere nicht von CERT.at

Wie schon zu Beginn des Krieges in der Ukraine vor inzwischen eineinhalb Jahren, kam es auch kurz nach den Ereignissen, die am 07.10.2023 Israel erschüttert haben, relativ schnell zu Berichten über die mögliche Rolle von Cyberangriffen in diesem Konflikt.

Neben den Beiträgen von Journalist:innen und Nachrichtenportalen wurden soziale Netzwerke geradezu überschwemmt mit Berichten über Angriffe, zu vermeintlichen Leaks sensibler Daten und zu angeblichen Kompromittierungen kritischer Infrastruktur.

Nach mehreren Jahren in dieser Branche hebe ich - und wahrscheinlich auch die meisten Expert:innen - in solchen Situationen bei Defacements von Webseiten aller Art schon nicht einmal mehr eine Augenbraue. Auch die unzähligen, meist kurzlebigen DDoS-Angriffe sorgen (ausser bei überarbeiteten, unterbezahlten Systemadministrator:innen kleiner Unternehmen) für keine übermäßigen Schweissausbrüche mehr.

Das war den Angreifer:innen anscheinend bewusst, also wurden Gerüchte über einen angeblichen Hack des israelischen Raketenabwehrsystems "Iron Dome" verbreitet, aus dem dann schnell "Angriffe gegen kritische Punkte des Iron Dome" wurden. Auch israelische Unternehmen wurden Opfer - unter anderem wurden ganze Produktionsfirmen gehackt - und sogar kritische Infrastruktur in Form eines Kraftwerkes wurde kompromittiert. Zum darüberstreuen wurden israelische Energie-, Telekommunikations- und Rüstungsunternehmen dann auch noch von einem der Hamas zugerechneten Bedrohungsakteur ins Visier genommen.

Im ersten Moment, vor allem vor dem Hintergrund der analogen Geschehnisse, wirkt das wie eine Menge an erschreckenden und effektiven Angriffen auf teilweise vitale Ziele einer modernen Gesellschaft. Wenn man jedoch genauer hinschaut, dann fällt die Fassade der effizienten, effektiven, und vermeintlich vor nichts Halt machenden Hacker relativ schnell in sich zusammen.

Welche "kritischen Punkte des Iron Dome" von den Kriminellen nun tatsächlich angegriffen wurden, ließ sich nicht in Erfahrung bringen, sonderlich effektiv scheinen die Angriffe jedoch nicht gewesen zu sein. Der Hack einer Produktionsfirma stellte sich am Ende als ein Defacement der Webseite des Unternehmens hervor. Einer Webseite, deren Relevanz ich anzuzweifeln wage, nachdem sie mehr als eine Woche später immer noch mit dem "digitalen Graffiti" der Angreifer:innen verziert ist.

Und was das angeblich durch die Täter:innen übernommene Kraftwerk betrifft, so treffen die Berichte in der Tat zu. Unter der Voraussetzung, dass man die Bedeutung des Wortes "übernehmen" so neu definiert, dass man damit die Wiederaufbereitung Jahre alter Leaks meint.

Der als Letztes genannte Versuch eines der Hamas zugerechneten Bedrohungsakteurs, israelische Unternehmen zu kompromittieren hat wirklich stattgefunden - zu Beginn des Jahres, wie der Bericht von Microsoft, auf den sich die Autor:innen von "The Hacker News" beziehen, auch sehr deutlich sagt. Dieses meiner Meinung nach gezielte In-die-Irre-führen hinterlässt, gerade in Anbetracht der Situation, einen mehr als bitteren Beigeschmack.

Was einer Gruppe Angreifer:innen tatsächlich gelungen ist: Eine in Israel verbreitete mobile Applikation zur Warnung vor Raketenangriffen beinhaltete eine Sicherheitslücke, die es dem Bedrohungsakteur "AnonGhost" ermöglichte, mehrere gefälschte Warnungen (inkl. vor einem vermeintlichen Nuklearschlag gegen Israel) an mehrere tausend Nutzer:innen zu verschicken. Diesen Vorfall will ich nicht verschweigen, verbuche ihn aber offen gestanden unter "ein blindes Huhn findet auch mal ein Korn". Ein statistischer Ausreisser, wenn man so will.

All das, was ich hier gerade aufgelistet und beschrieben habe deutet für mich darauf hin, dass sich die Geschichte wiederholt. Lautstark auftretende hacktivistische Gruppierungen (oder Personen, die vorgeben eine solche zu sein), die Defacements, DDoS-Angriffe und Behauptungen über angeblich gestohlene Daten oder kompromittierte Systeme nutzen um Aufmerksamkeit zu erregen und damit einer Konfliktpartei - oder - wie im Fall der DDoS-Wellen, die auch Österreich getroffen haben - peripher mit den Konfliktparteien verbundenen Entitäten zu schaden. Ohne dabei eigentlich Einfluss auf das eigentliche Konfliktgeschehen zu haben und ohne die Angriffe länger als einige Wochen durchzuhalten.

Der vielleicht entscheidendste Unterschied zu den Vorgängen zu Beginn des Krieges in der Ukraine ist, dass die Angriffe in weiten Teilen einseitig waren. Während Anfang 2022 sowohl russische als auch ukrainische Akteure digitale Infrastruktur der jeweils anderen Kriegspartei unter Beschuss nahmen, so war die überwältigende Mehrheit der Angriffe seit dem Überfall der Hamas gegen israelische Ziele gerichtet.

Ein weiterer Unterschied ist auch, dass aktuell so gut wie noch keine öffentlichen Informationen über Aktivitäten staatlich unterstützter oder kontrollierter Bedrohungsakteure vorliegen. Einzig die als "Predatory Sparrow" bekannte Gruppierung (welche von manchen Journalist:innen und Sicherheitsexpert:innen als Tarnidentität für Cyberangriffe durch israelische Geheimdienste gesehen wird) hat auf Telegram die Wiederaufnahme ihrer Aktivitäten bekannt gegeben aber keine weiteren Informationen über etwaige Angriffe veröffentlicht.

Das heißt natürlich nicht, dass es hier keine Angriffe gibt; diese Art von Attacken wird im Regelfall durch die Angreifer:innen nicht laut in die Welt hinausposaunt. Aber wenn man bedenkt, wie schnell im Februar 2022 und teilweise auch davor und wie viel öffentlich über Angriffe von Gruppen wie Sandworm oder APT28 berichtet wurde, so bin ich geneigt davon auszugehen, dass die vergleichsweise Abwesenheit solcher Berichte zu dem aktuellen Konflikt zu mindest ein Indiz dafür ist, dass eine geringere Anzahl solcher Operationen stattfindet.

Einige Gruppierungen (darunter Killnet und Anonymous Sudan), denen man mit einer gewissen Sicherheit zumindest die Nähe zu Staaten beziehungsweise Nachrichtendiensten nachsagen kann, haben sich zwar zu Wort gemeldet und mit der palästinensischen Seiten solidarisch gezeigt - von diesen kam jedoch in der Vergangenheit ausser DDoS und viel heißer Luft nichts, dementsprechend bin ich nicht willens, sie im Kontext staatlicher Bedrohungsakteure auch nur im Ansatz ernst zu nehmen. Falls die Webseite von CERT.at in den nächsten Tagen nicht erreichbar sein sollte, werte ich das als Erfolg. Sogar die Bösewichte der Welt lesen, was wir schreiben. Ich fühle mich geehrt.

Trotz dieser genannten Unterschiede, eine große Gemeinsamkeit bleibt: Hauptsächlich sind die bisher bekannten Angriffe als ein Ausdruck der Solidarität zu sehen, mit so gut wie keinen relevanten Auswirkungen und ohne jeden auch nur im Ansatz bedeutsamen Beitrag zu der Situation in der "echten Welt". Letzterer wird, auf teilweise schreckliche Art und Weise, andernorts und anderweitig geleistet.

Ich bin - wie ich in meinem letzten Beitrag zu Cyberangriffen im Rahmen des Krieges in der Ukraine bereits angemerkt habe - Security Analyst, kein Militärexperte. Aber für den Moment bleibe ich bei dem Fazit, welches ich damals bereits gezogen habe: Cyberangriffe verlieren rapide an taktischer und operativer Bedeutung wenn alternative, kinetische Möglichkeiten zur Verfügung stehen. Und ich sehe aktuell keinen Grund, warum sich das in absehbarer Zeit ändern sollte.

Abschließend sei gesagt: Auch wenn sich aktuell keine konkrete Gefährdung für österreichische Ziele abzeichnet, verfolgen wir die Situation aufmerksam. Wir stehen in laufendem Kontakt und Austausch mit unseren internationalen CERT-/CSIRT-Kollegen und den nationalen Koordinierungsstrukturen um gegebenenfalls rechtzeitig handeln zu können.

Unsere generelle Empfehlungen, die wir in jeder unserer Warnung aussprechen, sind auch hier anwendbar: Nutzen Sie, wo möglich, die "automatisches Update"-Features von Software, halten Sie Firewalls und sonstige Schutzmaßnahmen aktiv, und vor allem die Ohren steif. Oh, und tragen Sie bitte Sorge dafür, dass keine Management-Interfaces irgendwelcher Appliances direkt aus dem Internet erreichbar sind.

Letzteres hat nichts mit dem aktuellen Konfliktgeschehen zu tun, das ist einfach generell eine verdammt gute Idee.

GNOME what I'm sayin'? - GNOME libcue 0-click vulnerability

CERT.at — Fri, 13 Oct 2023 11:22:10 GMT+0100

Vorab die gute Nachricht: Es gibt keinen Grund sich im Rübenkeller zu verschanzen und das Ende der Zivilisation bei 2 Dosen Bohnen mit Speck auszusitzen. Alles ist gut. Aber fangen wir am Anfang an.

CVE-2023-43641

Die genauen technischen Details, aufbereitet von Menschen, die sich damit besser auskennen als ich, gibt es hier.

Die Schwachstelle existiert in libcue, einer Bibliothek zum Parsen von cuesheets. Was sind cuesheets? Das sind Dateien (.cue), die das Track-Layout auf einer (Audio-)CD beschreiben. Was ist eine CD? Nun, sowas Ähnliches wie eine Schallplatte aber mit mehr Hexenwerk. Was ist eine Schall...ach, lassen wir das.

GNOME indiziert Dateien für die Suche, unter anderem eben auch eventuell vorhandene cuesheets. Das geschieht automatisch wenn man Dateien in bestimmten Sub-Directories (in diesem Fall ~/Downloads) hinzufügt oder ändert. Wieso der rotbemützte Unruhestifter dazu die komplette Datei parsen muss, kann ich nicht sagen, ich bin mit der Mechanik dahinter nicht vertraut aber in der dazu verwendeten libcue Bibliothek existiert kein Check, ob beim Parsen der Track-Offsets in der Datei ein Integer-Überlauf stattfindet und der Index deswegen negativ ist. Dieser negative Index erlaubt, außerhalb des Adressbereichs des Arrays zu schreiben und wenn man dem Programm auf diese Weise Shellcode unterjubelt, können wundersame Dinge passieren - vom langweiligen Segmentation Fault bis zur RCE.

Nun wurde ja in den Medien so einiges geschrieben, von einer "ernsthaften Bedrohung" war die Rede und der eingangs erwähnte Rübenkeller sah nicht gänzlich unattraktiv aus. Wie gefährlich ist der aufmüpfige Gartenzwerg aber tatsächlich?

Das Bedrohungsszenario

Ja, die Schwachstelle ist nicht schön, vor allem da das Betriebssystem die Indizierung übernimmt und eventuell vorhandene AV-Lösungen das möglicherweise selig ignorieren. Steht uns eine Riesenwelle von Kompromittierungen bevor? Nein, ich glaube nicht und zwar aus folgenden Gründen:

Die Anzahl der Linux-Systeme, die libcue in einer verwundbaren Konstellation einsetzen ist vergleichsweise gering. Den größten Anteil daran haben wohl Client-Systeme. Die Server die ich bis jetzt gesehen habe sind zum allergrößten Teil headless, der Anteil mit GUI (also möglicher GNOME-Installation) vernachlässigbar.
Client-Systeme bekommen eher mal ein Update als ein Server, der monatelang traurig in einer Ecke vor sich hinvegetiert. Viele Clients haben automatische Updates aktiviert.
Der Großteil der Firmen die aus mehr als 2 Leuten bestehen, verwenden eine Windows-Umgebung für ihre Clients.
Es gibt bereits Patches, die Installation dauert wenige Sekunden (weil ihr ja alle immer brav eure Updates macht und nicht 1400 packages updaten müsst, oder? ODER?!)

Wir halten fest: Die Attack-Surface ist schon mal nicht so groß, dass man den Weltuntergang heraufbeschwören müsste und ein Upgrade auf eine gefixte Version ist hinreichend trivial.

Das heißt aber noch nicht, dass es nicht möglich ist, die Schwachstelle auszunutzen. Findige Nerds werden mit ziemlicher Sicherheit den PoC-Exploit aufgreifen, die Offsets (die übrigens innerhalb einer Linux-Distro konsistent bleiben) herausfinden und das Ganze in einen einsatzfähigen Exploit verwandeln. Ich habe ein wenig mit dem Testfile und Ubuntu 2023.4 experimentiert. Die Datei wird klaglos heruntergeladen, wenn man von einer unscheinbaren Website per JS darauf weiterleitet, es handelt sich also tatsächlich theoretisch um einen 0-click Exploit (allerdings müssen die Offsets in der .cue Datei zu der jeweiligen Distro passen).

Sollte der Exploit in Zukunft wirklich weaponized werden, fällt mir als plausible Einsatzmöglichkeit auf die Schnelle eigentlich nur das Browser Exploitation Framework (BeEF) ein, da man über einen hooked Browser zumindest ein paar Infos zum Betriebssystem des unseligen Opfers erhält.

Im Bereich Social Engineering sehe ich nicht wirklich die große Gefahr; es gibt meiner Meinung nach in dem Szenario zuviele Variablen, was den Empfänger betrifft (benutzt dieser überhaupt Linux bzw. eine verwundbare Distro, wenn ja welche, wie müssen die Offsets dafür aussehen, etc.).

Watering-hole attacks könnte ich mir vorstellen, allerdings hielte sich der Impact da wohl in engen Grenzen. Die Website, auf der ich per XSS den Drive-By-Download einschleuse muss entsprechend unsicher sein, das Opfer muss eine verwundbare Linux-Distro verwenden, ich als Angreifer müsste den Callback zeitnah mitbekommen usw. IMHO rein opportunistisches Script-Kiddie-Stuff.

Fazit: Alles halb so wild, einen funktionierenden Exploit würde ich definitiv in mein Arsenal aufnehmen aber hauptsächlich deswegen, weil "haben" besser ist als "brauchen". Das heißt nicht, dass man die Schwachstelle ignorieren sollte. Just patch and move on.

Dabei ist zu beachten, eine Linux-Distro zu verwenden, die noch aktiv supported (kein EOL) ist. Ja, ich weiß, ist naheliegend aber wir wissen alle, dass das durchaus vorkommt.

Über Packages, für die ein Upgrade verfügbar ist kann man sich auf Debian-Derivaten mit apticron per Mail informieren lassen oder diese einfach mit unattended-upgrades automatisch aktuell halten und sich auf die (proverbiale) faule Haut legen.

Und weil Ubuntu + GNOME eine der meistverbreitetsten verwundbaren Distros ist, gibt es das Kommando zum updaten quasi als kleines Dankeschön, dass ihr euch mein Geschwurbel bis zum bitteren Ende angetan habt:

sudo apt update && sudo apt upgrade

PS: Wo wir die Schwachstelle sicher sehen werden, wird in den einschlägigen CTFs sein und darauf freue ich mich schon.

Well, this SOCKS - curl SOCKS 5 Heap Buffer Overflow (CVE-2023-38545)

CERT.at — Thu, 12 Oct 2023 06:15:26 GMT+0100

Nachdem letzte Woche ein Advisory zu "der schlimmsten Schwachstelle in curl seit Langem" angekündigt wurde, konnten verängstigte, verschlafene und chronisch unterkoffeinierte Admins und Security-Spezialisten nach der gestrigen Veröffentlichung den Schaden begutachten. Die gute Nachricht: Die Apokalypse ist an uns vorüber gegangen. Die schlechte Nachricht: Mit dem CVSS(v2) Score lässt sich die Schwere einer Schwachstelle nicht immer ausreichend abbilden.

Nachfolgend ein (sehr) kurzer Blick auf die Schwachstelle selbst und warum trotz eines CVSS-Scores von 7.8 kein Grund besteht, eine Notwasserung der Beinkleider zu veranlassen.

Die Schwachstelle

Ich werde diese Sektion kurz halten, die schmutzigen technischen Details kann man hier nachlesen. Die Schwachstelle resultiert daraus, dass libcurl unter bestimmten Voraussetzungen einen sehr langen Hostnamen anstatt der aufgelösten Adresse an eine Variable übergibt und per memcopy() den Heap-Buffer sprengt und eventuell RCE erlaubt. So weit, so ungustiös. Die Voraussetzungen dafür sind jedoch alles andere als gängige Praxis, man muss schon ein wenig Arbeit investieren um diese zu schaffen:

Ein entsprechend langer Hostname muss an curl übergeben werden. Eine wirksame Input-Validation verhindert das schon mal.
curl muss sich mit einem SOCKS 5 Proxy verbinden um den Bug zu triggern. Diese Konstellation hab ich tatsächlich in einer Produktionsumgebung noch nie gesehen. Das heißt nicht, dass es sie nicht gibt, aber sieht für mich nach wildem Flickwerk aus und ist offensichtlich auch nicht die allerbeste Idee.

Ich erlaube mir an dieser Stelle, die Zusammenfassung vom SANS ISC abzukupfern schamlos zu stehlen:

This is only a valid exploit if you take unvalidated data and create an HTTP request via a SOCKS5 proxy to a hostname created from the unvalidated data. My recommendation is to upgrade without haste.

Schrecken, Angst und Panik

Jaja, ich weiß, CVSSv2-Score 7.8 (lt. Tenable). An dieser Stelle möchte ich den Maintainer von curl - Daniel "Badger" Stenberg - zitieren:

The severity level is a blunt tool. This is a HIGH severity problem but there is still going to be a large chunk of users who will not be affected by these problems.

"Blunt tool" trifft es ziemlich genau. Der CVSS-Score ist nicht der Weisheit letzter Schluss, es ist ein Hilfsmittel um die Einschätzung zu erleichtern und in keinster Weise granular (oder auch nur eindeutig) genug um jede Schwachstelle ausreichend einschätzen zu können. In Wahrheit werden zwei verschiedene Personen vermutlich unterschiedliche Scores berechnen. Nachfolgend zeige ich das am Beispiel dieser Schwachstelle.

Sehen wir uns einmal den Vektor an:

AV:N/AC:L/Au:N/C:N/I:N/A:C

Access Vektor: N, Network - Also kurz: über das public Internet ausnutzbar. OK.
Access Complexity: L, Low

Specialized access conditions do not exist. [...] The affected configuration is default or ubiquituous.

Nein, eher nicht. Ändern wir das mal auf M, Medium (The affected configuration is non-default and is not commonly configured).

Authentication: N, None - OK
Confidentiality: N, None - Damit bin ich nicht einverstanden, wenn der Angriff erfolgreich ist, gehe ich aufgrund einer RCE mit zumindest User-Rechten von einem teilweisen Impact auf die Confidentiality aus. Ändern wir das auf P, Partial.
Integrity: N, None - Hier ebenso, mit einer RCE mit User-Rechten sehe ich die Integrity zumindest teilweise kompromittiert. - Ebenfalls P, Partial.
Availability: C, Complete - Sollte der Bug ausgelöst werden, wird das curl-Kommando vermutlich abschmieren, inwiefern der darüberliegende Dienst komplett den Geist aufgeben soll, erschließt sich mir nicht. Nehmen wir in dem Fall mal eine teilweise Beeinträchtigung der Availability an - P, Partial.

Und damit haben wir unseren neuen CVSSv2-Vektor

AV:N/AC:M/Au:N/C:P/I:P/A:P

und einen neuen Score von 6.8 und damit nur noch Medium. Sollte man das weiterspielen wollen und den Impact auf die Availability als None einstufen, landen wir bei 5.8, also im mittleren Medium-Feld. Der Definition für Access Complexity folgend, könnte man diese sogar auf High setzen, denn da heißt es:

The vulnerable configuration is seen very rarely in practice.

Und plötzlich sind wir bei einem CVSSv2-Score von 4.0 und das ist gerade mal am untersten Ende von Medium.

Abschließend möchte ich anmerken, dass Daniel Stenberg den Vorfall vorbildlich behandelt hat, durch die initiale Einstufung als High ist auch niemandem ein Schaden entstanden, eher im Gegenteil - es wurde entsprechend Aufmerksamkeit geschaffen und patchen sollte man das ja schon. Es besteht aber auch kein Grund zur Panik, es sei denn man hat wirklich ein Faible für obskure Konfigurationen, wild zusammengehackte Shell-Scripts und lebt gerne gefährlich.

In diesem Sinne: Gut is gangen, nix is gschehen.

Das European Cyber Shield

CERT.at — Tue, 12 Sep 2023 10:23:21 GMT+0100

Die EU will im Rahmen vom "Digital Europe Programme" mit Förderungen für die Vernetzung von SOCs die Sicherheit der EU stärken und das System über einen neuen "Cyber Solidarity Act" dauerhaft einrichten.

Ich hab dazu im Rahmen des CSIRTs Network Meetings im Juni einen Vortrag gehalten, dessen Inhalt ich jetzt auf ein ausformuliertes Paper (auf Englisch) erweitert habe.

Executive Summary

The proposed Cyber Shield (Chapter 2 Cyber Solidarity Act) contains valid ideas: supporting SOCs by fostering national and cross-border collaboration is worth doing.
An unfortunate choice of terminology is prone to confuse readers of the Act. A change would be welcomed.
The relationship between the proposed structures and the tasks of the CSIRTs and the CSIRTs network (as stipulated in the NIS2 Directive) is not entirely clear. Defining this relationship and integrating the proposed roles with the existing structures would be useful.
EU funding for multiple consortia with the aim of building closer, technical collaborations in cross-border structures is a sound investment.

Das ganze Paper gibt es zum Download direkt hier oder über unsere Download/Papers Seite.

Post-Quantum Cryptography

CERT.at — Thu, 07 Sep 2023 15:05:19 GMT+0100

Das Aufkommen von fähigen Quantencomputern hat massive Seiteneffekte auf die Sicherheit diverser kryptografischer Grundoperationen. Diese sind in den letzten Jahren zu essentiellen Bausteinen unserer IT Architektur – insbesondere in vernetzten Systemen – geworden. Noch funktioniert alles, aber wenn wir nicht bald anfangen, uns auf die diese kommende Gefahr vorzubereiten, dann wird die Transition zu „post-quantum cryptography“ schmerzhafter als nötig werden.

Konkret geht es darum, dass der Aufwand für die Operationen „Faktorisierung ganzer Zahlen“, „Diskreter Logarithmus ganzer Zahlen“ und „Diskreter Logarithmus auf elliptischen Kurven“ nicht mehr deutlich überproportional mit der Zahlengröße steigt. Damit ist die Sicherheit von RSA, ECC, DH & co nicht mehr gegeben.

Ich darf nächste Woche bei einer Veranstaltung dazu am Podium sitzen. Und wenn ich mich schon darauf vorbereite, dann teile ich doch gleich meine Quellen und Schlussfolgerungen. Dieser Blogpost erhebt keinen Anspruch auf Vollständigkeit.

Thesen

These 1: Das Problem ist nicht neu

Auf Sicherheitskonferenzen wird seit Jahren thematisiert, dass Quantencomputer (QC) in Verbindung mit dem Algorithmus von Schor die Eckpfeiler der aktuell verwendeten Public-Key Kryptografie aushebeln. Es wird daher schon länger nach alternativen Lösungen gesucht. Es gibt schon eine Menge Vorschläge, und auch die ersten Standardisierungen, aber es ist noch nicht ganz klar, wo der Zug hinführen wird.

These 2: Es wird trotzdem überraschend kommen

Wir Menschen sind oft sehr gut im Ignorieren von Warnungen. Klimawandel, die nächste Covid Welle, Y2K, und so weiter. „Es wird schon nicht so schlimm kommen.“ „Irgendwer wird uns schon die magische Lösung präsentieren.“ „Sollen doch mal die anderen Vorausarbeiten, ich komm dann nach, wenn alles ausgereift ist.“

Und dann wird uns das Thema treffen wie jedes Jahr die Autofahrer der erste Schnee des Winters in Wien.

Die Four Stage Strategy wird nicht funktionieren.

These 3: Manches muss man früh angehen

Eines der bösen Probleme bei dem Thema ist „jetzt aufzeichnen – später entschlüsseln“. Wenn Daten übertragen oder gelagert werden, die langfristig geheim gehalten werden müssen, dann reicht es nicht, sich gegen aktuelle Angriffe zu schützen, man muss auch bedenken, dass ein Angreifer jetzt die Daten abfangen könnte, sie gut archiviert, und dann, wenn die Quantencomputer da sind, diese entschlüsselt. Auch bei digitalen Signaturen muss man mitdenken, was es z.B. für einen digital unterschriebenen Vertrag heißen könnte, wenn in der Zukunft der private Schlüssel einer eID errechnet werden kann, und damit alte Unterschriften gefälscht werden können.

These 4: Der Umstieg wird zu lange dauern

Die Umstellungen, die uns durch Quantencomputer aufgezwungen sind nicht die ersten dieser Art. Immer wieder gab er Erkenntnisse, dass alte Protokolle und Algorithmen nicht mehr zeitgerecht sind. Alleine die Abkehr von MD5 als Hashing-Algorithmus in Zertifikaten war ein Drama und ich bin mir nicht ganz sicher, ob wir da wirklich schon komplett durch sind. SSL, SSLv2, TLS 1.0 und TLS 1.1 sind alle nicht mehr als sicher einzustufen. Sind wir sie los? Naja. Microsoft verspricht, hier bald ernst zu machen. Wir haben ähnliche Ankündigungen schon oft gehört, und oft genug wird im Sinne der Rückwärtskompatibilität etwas weiterbetrieben, was schon längst auf den Misthaufen der Protokollgeschichte gehört. NTLM? SMBv1? Die Liste ist lang.

These 5: Es geht nicht nur um Verschlüsselung

Die kryptografischen Primitiven wie RSA oder ECC werden bei weitem nicht nur zum Austausch von Schlüsseln verwendet, um dann etwa mit AES einen Kommunikationskanal abzusichern. Ja, das ist auch ein Teil des TLS Handshakes, aber es wird auch überprüft, ob die Gegenstelle wirklich die ist, mit der ich sprechen will. Hier kommt die nach X.509 standardisierte Public Key Infrastruktur ins Spiel. Diese basiert auf den gleichen Algorithmen. Moderne Konzepte im Internet wie Single-Sign On, Zero Trust, Fido2/Webauthn (von Blockchain und Web 3.0 will ich besser nicht reden) bauen auch darauf auf. Aber nicht nur online ist das ein Thema: RFID in Reisepässen, Kartenzahlungen, Zugangsysteme, digitale Unterschriften und die Integritätsprüfung von Software (Stichwort Secure Boot) hängen davon ab.

These 6: Die Verschlüsselung ist unser kleinstes Problem

OIDC, SAML2, SSO, JWT und wie die Techniken sonst noch abgekürzt werden: Bei Authentication und Autorisation schlagen gebrochene Schlüssel viel direkter und spürbarer durch.

Empfehlungen

Informieren

Es gibt inzwischen von vielen Seiten wirklich gute Dokumente zu diesem Thema, etwa von den großen Sicherheitsagenturen:

BSI
- Artikel im BSI Magazin 2023/01
- Kryptografie quantensicher gestalten
CISA
- Quantum-Readiness: Migration to Post-Quantum Cryptography
- Sogar einen Gesetzesentwurf gibt es schon in den Staaten

Aber auch die großen Internetfirmen arbeiten schon an Lösungen und bieten sowohl Erklärungen, Software und Produkte dazu an. Etwa:

Inventur machen

Wo hat man selber Kryptografie eingebaut? Ist man dort hinreichend agil, was die eingesetzten Algorithmen angeht?

Welche eingekauften/installieren Lösungen nutzen Kryptografie?

Das ist ein bisschen analog zum Y2K Problem: da war oft ein etwaiges Problem schnell gelöst, aber der wirklich große Aufwand floss in das Nachschauen, wo man betroffen sein könnte.

Offenheit für neue Lösungen

Einfach nur die kryptografischen Primitive auszutauschen ist natürlich verlockend. Ich würde die Gelegenheit aber auch nutzen, manche Grundannahmen zu überdenken. Wo brauche ich welche Sicherheit? Habe ich eine Form von „Defense in Depth“ was meinen Einsatz von Kryptografie angeht? Treten wir uns mit dem Umstieg auf neue Algorithmen neue Angriffsflächen ein?

Und könnte ich nicht auch die Quantentechnik defensiv nutzen?

Ein Deepdive in die ESXiArgs Ransomware Kampagne

CERT.at — Wed, 09 Aug 2023 15:37:11 GMT+0100

Es war ein schöner Tag dieser Freitag, der 03. Februar 2023, aber wie es Freitage im Cybersicherheits-Umfeld leider so an sich haben, sollte sich das schnell ändern.

Da dieser Vorfall inzwischen schon etwas weiter in der Vergangenheit liegt, ist Ruhe um ihn eingekehrt. Allerdings gibt es doch so manch interessanten Aspekt, der - zumindest mir bekannt - so noch nicht berichtet wurde.

Was mehr oder weniger allgemein bekannt ist …

Nach ersten Meldungen auf Twitter, dass hier etwas ganz und gar nicht Normales mit VMware ESXi Servern passiert, trafen in einem öffentlich zugänglichen Support-Forum [1] fast zeitgleich erste detailliertere Berichte über die Vorgänge von besorgten, hilfesuchenden System-Administratoren ein.

Quelle: https://twitter.com/mmarcha/status/1621481244922941440

Quelle: https://twitter.com/f2rv/status/1621483813523128322

Es war kein Zugriff auf die Server mehr möglich und die Systemverwalter wurden anstatt der gewohnten Nachricht auf der Login-Seite von einem Erpresserschreiben begrüßt. Die Systeme seien verschlüsselt und nur durch Bezahlung einer nicht unerheblichen Summe in Bitcoin an die Erpresser wieder in Betrieb zu nehmen.

Soweit nicht ungewöhnlich für solch geartete Vorfälle, auch wenn das Ausmaß der - über eine auch bis jetzt weiterhin nicht geklärte Schwachstelle (vermutet wird CVE-2021-21974 [2]) - kompromittierten Systeme noch nicht voll ersichtlich war. Da es sich bei ESXi-Servern um Virtualisierungs-Hosts handelt, auf denen teilweise zig Server- und Client-Systeme gleichzeitig laufen, konnte ein erheblicher Schaden vermutet werden.

Eine Suche auf Censys.io ergab ungefähr 3.800 betroffene Host-Systeme [3]. Wobei hier zu bedenken ist, dass diese Zahl auf den damals auffindbaren Hosts mit öffentlicher HTTP(S)-Schnittstelle und damit erkennbarer Erpressungsmeldung basiert.

Da die verwendete Webshell, die bereits im Dezember 2022 in einem Artikel von Juniper beschrieben wurde [4], auch Reverse-Shell-Eigenschaften (aktive Verbindung vom Host nach außen) hat, ist es möglich, dass hier weitaus mehr Systeme betroffen waren.

Die Verschlüsselung passierte in zwei (vielleicht sogar drei und einer vierten sehr frühen - mehr dazu später) Wellen, da im ersten Anlauf bekannt wurde, dass der verwendete Verschlüsselungsalgorithmus eine Schwachstelle besitzt und somit erlaubte, auch ohne Bezahlung der Erpresser, die Daten zu entschlüsseln.

Viele der Erpressten konnten die Webshell auf ihren Systemen nicht mehr auffinden, da das Verschlüsselungsscript diese nach erfolgreicher Ausführung gelöscht hatte, um Spuren zu verwischen. Allerdings wurde die Webshell weiter im Arbeitsspeicher ausgeführt - auch auf Systemen, wo sie durch den Administrator proaktiv gelöscht, aber kein Neustart durchgeführt beziehungsweise der Prozess nicht aktiv beendet wurde. Ein eingespielter Patch für CVE-2021-21974 [2] brachte bei bereits vorhandener Webshell ebenso keine Abhilfe, genauso wie ein Blockieren des Service Location Protocol (SLP) Ports für Zugriffe von außen. Die zweite Welle (rund um den 09. Februar 2023) mit nicht verwundbarem Verschlüsslungsmechanismus und Erpresserschreiben ohne Bitcoin-Adresse (zur schlechteren Verfolgbarkeit der Erpresser) konnte, während Administratoren bereits versuchten ihre Systeme wiederherzustellen, fast ungehindert ihren Lauf nehmen.

Info: Erpresserschreiben 03. Februar 2023 (mit Bitcoin-Adresse)

Info: Erpresserschreiben 09. Februar 2023 (ohne Bitcoin-Adresse)

Basierend auf Daten von Shodan.io dürfte es noch eine kleinere dritte Welle um den 15. Februar gegeben haben.

Die meisten weiteren bekannten Details sind in den Artikeln von BleepingComputer [5][6] und deren Support-Forum [1] ersichtlich.

Was nicht allgemein bekannt ist …

Wie sich zeigen sollte, war die Kompromittierung schon Monate beziehungsweise vielleicht Jahre zuvor geschehen und die ersten Opfer im Oktober 2022 (eines davon bereits im April 2021) hatten potentiell politische Relevanz.

Es ist weiter ungeklärt, wann genau die Webshell auf Systeme eingebracht wurde, da die Akteure bedacht darauf waren, die Zeitstempel der von ihnen erzeugten Dateien zu fälschen (Timestomping) und diese nach Abschluss der Verschlüsselung zu löschen. Bei der Untersuchung eines im Februar 2023 betroffenen Hosts konnten schwache Hinweise darauf gefunden werden, dass eine Kompromittierung bereits im Juli 2022 stattgefunden hat. Dies basiert auf einer Crash-Dump Datei des betroffenen rhttpproxy Services, welcher benutzt wurde, um über endpoints.conf am betroffenen System den Zugriffspunkt für die Webshell zu konfigurieren.

Da auf diesem Host das Verschlüsselungsscript fehlerhaft beendet wurde, blieben wertvolle Informationen erhalten.

Der Zugriff auf die Webshell erfolgte in diesem Fall von den IP-Adressen:

139[.]99[.]69[.]73
84[.]22[.]102[.]83

Von den zehn im Oktober 2022 betroffenen Hosts konnte mittels Censys.io, Shodan.io, Zoomeye.org und passive DNS festgestellt werden, dass zumindest acht davon im betroffenen Zeitraum eine ukrainische Top-Level-Domain inne hatten und damit eine politische Motivation potentiell ableitbar ist.

Quelle: https://trends.shodan.io/search?query=title%3A"How+to+Restore+Your+Files"#facet/ip

51[.]83[.]141[.]52 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)
54[.]36[.]48[.]148 - esxi04.dentsuaegis.com[.]ua - OVH SAS
51[.]83[.]140[.]71 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)
159[.]69[.]163[.]148 - dc2.vites.kiev[.]ua - Hetzner Online GmbH
51[.]77[.]43[.]28 - vdc.npint.com[.]ua - OVH SAS
51[.]83[.]237[.]4 - vdc.npint.com[.]ua - OVH SAS
136[.]243[.]76[.]47 - sb91.binco.com[.]ua - Hetzner Online GmbH
176[.]31[.]238[.]112 - ns342609.ip-176-31-238[.]eu - OVH SAS
51[.]83[.]184[.]96 - novaposhtaglobal[.]ua - OVH SAS (SSL DC=vdc)
95[.]217[.]75[.]225 - static.225.75.217.95.clients.your-server[.]de - Hetzner Online GmbH

Einer dieser zehn Hosts mit ukrainischer Top-Level-Domain (51[.]83[.]141[.]52) zeigte bereits im April 2021 ein entsprechendes Erpresserschreiben und wurde sogar viermal Opfer “dieser” Kampagne im April 2021, Oktober 2022, 03. Februar 2023 und 09. Februar 2023.

Eine erste Kompromittierung im April 2021 passt auch gut zur potentiell ausgenutzten Schwachstelle CVE-2021-21974 [2], die am 23. Februar 2021 in einem Advisory durch VMware [7] beschrieben und in einem Artikel der Zero Day Initiative [8] am 02. März 2021 detailliert erklärt wurde. Auch wenn der erste Proof-of-Concept Exploit [9] erst am 24. Mai veröffentlicht wurde.

Ableitbare Maßnahmen …

Schnelles Patchen alleine reicht nicht. Eine weiterführende Untersuchung der Systeme ist gegebenenfalls notwendig.
Management-Schnittstellen haben im öffentlichen Internet nichts verloren. Diese sollten ausschließlich über VPN oder ähnliche Lösungen erreichbar sein.
Eingesetzte Endpoint Detection and Response (EDR) Lösungen sollten auch “Nischenprodukte” abdecken können.
Aktives Suchen - “Hunting” - nach Unregelmäßigkeiten in allen im Unternehmen verwendeten Technologien.

[1] https://www.bleepingcomputer.com/forums/t/782193/esxi-ransomware-help-and-support-topic-esxiargs-args-extension/
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-21974
[3] https://gist.github.com/cablej/bdc2ee2c84915d0b68eec9d4d4747e19
[4] https://blogs.juniper.net/en-us/threat-research/a-custom-python-backdoor-for-vmware-esxi-servers
[5] https://www.bleepingcomputer.com/news/security/massive-esxiargs-ransomware-attack-targets-vmware-esxi-servers-worldwide/
[6] https://www.bleepingcomputer.com/news/security/new-esxiargs-ransomware-version-prevents-vmware-esxi-recovery/
[7] https://www.vmware.com/security/advisories/VMSA-2021-0002.html
[8] https://www.zerodayinitiative.com/blog/2021/3/1/cve-2020-3992-amp-cve-2021-21974-pre-auth-remote-code-execution-in-vmware-esxi
[9] https://straightblast.medium.com/my-poc-walkthrough-for-cve-2021-21974-a266bcad14b9

Eine Attribuierung zu bekannten Gruppen oder staatlichen Akteuren ist mit den vorhandenen Indicator of Compromise (IOCs) und Tacticts, Techniques und Procedure (TTPs) nicht durchführbar und liegt auch nicht im Interesse und direktem Aufgabenbereich von CERT.at.

Cyber ist effektiv, Explosionen sind effektiver

CERT.at — Wed, 28 Jun 2023 17:39:04 GMT+0100

Die Veröffentlichung von Dokumenten, welche vermeintlich die Arbeit eines russischen IT-Unternehmens im Auftrag russischer Nachrichtendienste beschreiben, hat durch verschiedene journalistische Publikationen Ende März dieses Jahres für einiges an Aufsehen gesorgt.

Die "Vulkan Leaks" beinhalteten unter anderem auch Informationen zu einem Projekt, welches unter dem Namen "Kristal-2V" geführt wurde. In den Dokumenten zu eben jenem fanden sich massenhaft Verweise zu Angriffen gegen OT-Systeme und die effektive Durchführung von Informationsoperationen unter Einbeziehung dieser Angriffe.

Was aber gerade in der initialen Berichterstattung, aus welchen Gründen auch immer, oft nicht erwähnt wurde: Es handelt sich bei Kristal-2V um eine, soweit es sich beurteilen ließ, reine Trainingsplattform. Ja, die Plattform erlaubte sowohl defensive als auch offensive Simulationen und ja, es ist davon auszugehen, dass russische Nachrichtendienste Interesse daran haben Kapazitäten zu besitzen, die zuverlässig physische Zerstörung durch Cyberangriffe ermöglichen.

Das sind aber allesamt keine überraschenden, unerwarteten Details. Der Angriff von "BlackEnergy" auf die Stromversorgung in der Ukraine liegt nahezu ein Jahrzehnt in der Vergangenheit, der zerstörerische Einsatz von Stuxnet in den Anreicherungsanlagen von Natanz und Bushehr noch länger - und der "Aurora Generator Test" hat inzwischen fast schon die Volljährigkeit erreicht.

Dennoch, diese Revelationen haben dafür gesorgt, dass das Thema Cyberangriffe mit physischen Auswirkungen auch abseits der Vulkan Leaks wieder vermehrt in's Rampenlicht gezogen wurden.

Insbesondere die Überschriften und Schlagzeilen rund um einen potentiell möglichen, in ganz Europa geführten Cyberkrieg mit katastrophalen Auswirkungen auf die Stabilität, im metaphorischen und wortwörtlichen Sinn, unserer Gesellschaft entbehrten in Anbetracht der gegenwärtigen sicherheitspolitischen Lage in Europa nicht einer gewissen Ironie.

Seit Februar 2022, der Beginn der russischen Invasion der Ukraine, sind wir hierzulande Zeuge eines "klassischen" Krieges, eines konventionellen militärischen Konfliktes zwischen zwei Nationalstaaten - dem ersten dieser Art seit dem Ende des zweiten Weltkrieges vor fast 80 Jahren.

Dies bedeutet auch, dass wir zum ersten Mal einen Krieg erleben, bei dem die involvierten Parteien nicht komplett asymmetrisch sind, wie es beispielsweise im syrischen Bürgerkrieg der Fall war. Und dementsprechend wäre dies auch der erste Krieg, bei dem destruktive Cyberangriffe Teil der kombinierten Kriegsführung hätte sein können (einzelne Vorfälle in der Vergangenheit, wie beispielsweise die israelische "Operation Outside the Box", ignoriere ich ob des limitierten Maßstabes unauffällig). Insbesondere vor den russischen Kapazitäten in diesem Bereich wurde insbesondere in den Monaten vor Beginn des Krieges immer wieder gewarnt. Wodurch sich für mich an einem Punkt im Kriegsverlauf die Frage ergeben hat: Was ist eigentlich an diesen Befürchtungen dran gewesen?

Um diese Frage zu beantworten habe ich versucht, in spärlichen Mengen verfügbaren öffentlichen Informationen zusammen zu tragen und herauszufinden ob, und wenn ja in welchem Ausmaß, destruktive Cyberangriffe durch russische Bedrohungsakteure direkten Einfluss auf das Kampfgeschehen in der Ukraine genommen haben - und in welchem Verhältnis deren Effektivität im Vergleich zu kinetischen Angriffen steht.

Einige kleine, aber wichtige Details vorweg: Ich habe mir nahezu ausschließlich Daten und Informationen zu destruktiven Angriffen angesehen; Angriffe, deren Ziel die Gewinnung von Informationen war wurden weitestgehend außen vor gelassen.

All das war ein rein empirisches Unterfangen. Auch wenn ich mich um Objektivität und Sachlichkeit bemüht habe, wissenschaftlichen Standards wurde an keiner Stelle genüge getan. Die Datenlage, was öffentliche Quellen betrifft, ist höchst dürftig und es ist nicht auszuschließen, dass in den nächsten Wochen, Monaten und Jahren Details an's Licht kommen, die meine Schlussfolgerungen vollumfänglich widerlegen. Oder, um es in den Worten eines Piraten zu sagen: Ye be warned!

Bevor ich in weiter ausführe, die wichtigsten Eckpunkte vorweg zusammengefasst:

Betrachtet man den gesamten bisherigen Konfliktverlauf, so waren destruktive Cyberangriffe aus militärischer Sicht nahezu vollständig wirkungslos, und auch in Hinblick auf Schäden an ziviler Infrastruktur nutzlos. Die Lahmlegung von VIASAT zu Beginn des Konfliktes hatte unter Umständen einen positiven Einfluss auf russische Militäroperationen, auch das lässt sich aber in keinster Weise belegen.
Insbesondere im direkten Vergleich zu "klassischen" kinetischen Angriffen war der Schaden, welcher durch Cyberangriffe angerichtet wurde, vernachlässigbar.
Ähnlich der initialen russischen militärischen Taktik, welche von massiven Defiziten in der Koordination zwischen den verschiedenen Truppenteilen geplagt war, wurden Cyberangriffe in den meisten Fällen sehr "stumpfsinning" eingesetzt; keine der spezifischen Vorteile von Cyberangriffen wurden genutzt.

Militärische Sicht

Die massenhafte Zerstörung von Modems des Unternehmens Viasat, welches einen temporären, vollständigen Ausfall des dem Unternehmen gehörenden Kommunikationsnetzwerkes KA-SAT zur Folge hatte, wurde medial als der "digitale Startschuss" der russischen Invasion gehandelt. Ersten Meldungen zu Folge hatten diese Angriffe massiven Einfluss auf die Fähigkeit der ukrainischen Streitkräfte, Verteidigungshandlungen effektiv zu koordinieren.

Dies wurde jedoch mehrfach von ukrainischen Kommandeuren, die zu Beginn des Überfalls rund um die ukrainische Hauptstadt Kyiv im Einsatz waren, bestritten. Laut deren Aussagen waren die Auswirkungen des Ausfalles von KA-SAT vernachlässigbar, da eine Verwendung selbst bei voller Funktionsfähigkeit des Netzwerkes nicht möglich gewesen wäre. Sämtliche elektronische Kommunikation wurde durch Mittel der elektronischen Kriegsführung von Einheiten der russischen Streitkräfte gestört.

Welcher Faktor nun tatsächlich ausschlaggebend für initiale Kommunikationsprobleme der ukrainischen Streitkräfte war, wurde in den von mir gesichteten Artikeln und Meinungen intensiv debattiert. Auch zwei andere ukrainische Internet Service Provider, Ukrtelecom und Triolan wurden relativ knapp nach Kriegsbeginn Opfer von Cyberangriffen, die zu zeitweisen Problemen bei der Verfügbarkeit führten - jedoch nach Aussage ukrainischer Regierungsvertreter sowie den betroffenen Unternehmen selbst zu keiner Zeit militärische Auswirkungen hatten.

Auch wenn keinerlei Beweise dafür vorgelegt wurden, so decken sich die Aussagen mit anderen Berichten zu Erfahrungen von ukrainischen Einheiten zu Beginn des Krieges. In den meisten davon werden (oft erfolgreiche) Versuche der funkelektronischen Störung durch entsprechende russische Einheiten (zu welchen es eine ausgezeichnete Analyse durch das Institute of Electrical and Electronic Engineers gibt) beschrieben. Probleme, denen ein Ausfall der Service Provider zugrunde liegt, werden an keiner Stelle erwähnt.

Auch was den militärischen Nachschub betrifft, sowohl auf operativer, taktischer Ebene als auch in Bezug auf die Zuführung von Militärhilfe durch westliche Länder, gibt es keine öffentlich verfügbaren Informationen darüber (oder auch nur Hinweise darauf), dass dieser von Cyberangriffen beeinträchtigt wurde.

Während behördliche und zivile Einrichtungen zu Beginn des Krieges massiv durch den Einsatz von Wipern getroffen wurden (dazu später mehr), scheinen militärische Systeme weitestgehend verschont geblieben zu sein. Selbiges gilt für den direkten Verlust von Material und Menschenleben, welcher durch die Aktivitäten russischer Bedrohungsakteure ausgelöst wurde.

Der einzige mir bekannte Fall, bei dem ein russischer Cyberangriff im Krieg in der Ukraine zu direkten militärischen Verlusten geführt haben könnte ist die angebliche Kompromittierung einer ukrainischen App zur Kalibration von älteren Haubitzen durch APT28, welcher dem russischen Militärgeheimdienst GRU zugerechnet wird.

Das Sicherheitsunternehmen Crowdstrike beschreibt in einem im Dezember 2016 veröffentlichten Bericht, wie der Bedrohungsakteur die Endgeräte des Entwicklers der App kompromittiert hatte, um dann den Quellcode der App selbst zu modifizieren, um so Standortinformationen sammeln zu können, die in weiterer Folge für den gezielten Beschuss ukrainischer Artilleriestellungen genutzt werden konnten. Laut dem Unternehmen führte dieser Cyberangriff in weiterer Folge zu signifikanten Verlusten auf Seiten der Ukraine - bis zu 80% besagter Haubitzen.

Ich verwende hier deswegen den Konjunktiv, weil Crowdstrike in seiner Analyse und Attribuierung zwar sehr überzeugt aufgetreten ist, allerdings sowohl der angeblich betroffene Entwickler als auch das ukrainische Verteidigungsministerium den Bericht in Frage stellen.

Aber selbst, wenn wir davon ausgehen, dass der Bericht korrekt ist und der erfolgreiche Angriff katastrophale Folgen hatte, so handelt es sich um einen einzelnen Angriff, welcher 2016, also vor Beginn der offenen russischen Invasion im Februar letzten Jahres erfolgt ist.

Dem gegenüber stehen tausende Verluste auf Seiten der ukrainischen Streitkräfte (und der ukrainischen Zivilbevölkerung) welche durch den Einsatz konventioneller Waffen verursacht wurde. Auch wenn die genauen Zahlen nicht bekannt sind, und aktuell nur ungefähre Schätzungen vorliegen, so ist das Verhältnis mehr als eindeutig.

Zivile Sicht

Crowdstrike bezeichnete das Jahr 2022 in einem Bericht als "das bisher aktivste Jahr für Wiper". Ukrainische Netzwerke, sowohl von behördlichen Stellen als auch Institutionen der Zivilgesellschaft und kommerzieller Unternehmen, wurden bis zum Sommer letzten Jahres von insgesamt fast 50 unterschiedlichen Wipern heimgesucht (die genaue Zahl schwankt, eine Analyse des Center for Strategic & International Studies gibt mit 37 die niedrigste Zahl an, auf die ich im Zuge meiner Recherche gestoßen bin).

Wie schon bei dem Angriff gegen VIASAT scheiden sich hier die Geister, wie hoch der effektive Schaden dieser Angriffe tatsächlich war. Während dieser von ukrainischer Seite als "nicht vorhanden" bezeichnet wurde, spricht Microsoft von einer "permanenten Zerstörung von Daten auf hunderten von Systemen von Dutzenden Organisationen in der gesamten Ukraine" - nennt die tatsächlichen Auswirkungen auf die Verfügbarkeit von Services aber "limitiert".

Selbst wenn die Auswirkungen dieser Angriffe in Wirklichkeit stärker waren als von Microsoft angenommen, sie waren nur von sehr kurzer Dauer. Wie in einer Grafik des CyperPeace Institute ersichtlich erreichte die Zahl der angegriffenen ukrainischen Systeme und Netzwerke ungefähr vier Wochen nach dem Beginn der Invasion ihren Höhepunkt; danach flachte die Kurve rasant und nachhaltig ab.

Zwar dauert der Krieg nun bereits deutlich länger als die in der Grafik als Endpunkt verwendete Woche 35 des Jahres 2022, aber wenn man davon ausgeht, dass die in Artikeln und Beiträgen auf sozialen Medien geteilten Informationen ein halbwegs akkurates Bild russischer Cyberangriffe in der Ukraine darstellen, dann hat sich seit letztem Jahr nichts grundlegendes geändert - selbst für das wohl "interessanteste" Ziel für Angreifer:innen.

Das ukrainische Stromnetz war in den Vergangenen Jahren immer wieder Ziel von Cyberangriffen, die weltweit für Aufmerksamkeit gesorgt haben. Beispielhaft seien hier stundenlange, durch Schadsoftware ausgelöste Stromausfälle im Dezember 2015 genannt. Vor Beginn des Krieges sind viele Expert:innen davon ausgegangen, dass diese Art von destruktiven Angriffen eine wichtige Rolle im Fall einer russischen Invasion spielen würden.

Auch in unseren Analysen als CERT sind wir davon ausgegangen, dass es diese Angriffe geben würde. Auch wenn wir versucht haben, den allgemeinen Überblick über mögliche Auswirkungen eines russischen Angriffes auf die Ukraine zu berücksichtigen hat uns die Frage, ob es im Fall solcher Cyberangriffe potentiell Kollateralschäden für österreichische Energieunternehmen geben könnte, besonders beschäftigt. Diese Fragen und Bedenken haben auch andere CERTs beschäftigt.

Um so überraschter waren wir, als es zu Beginn des Überfalls nicht zu sofortigen, massiven, und vor allem effektiven Angriffen gegen die ukrainische Stromversorgung kam. Dies hat sich bis heute nicht geändert, öffentlich bekannt wurden seit Februar 2022 nur zwei erfolglos gebliebene Angriffsversuche.

Dem gegenüber stehen, vor allem in den Wintermonaten am Ende des Jahres 2022, periodische Stromausfälle, die teilweise das ganze Land betrafen. Ausgelöst durch gezielte Luft-, Drohnen- und Raketenangriffe gegen alle Teile des ukrainischen Stromnetzes waren [zeitweise hunderttausende Menschen für mehrere Tage ohne Strom].

Zeitgleich neben den beschriebenen koordinierten Angriffen, und auch nach deren Abflauen, gab es ebenfalls immer wieder einzelne Defacements und kleinere Datenleaks, sowie konzertierte DDoS-Angriffe von vorgeblich pro-russischen Hacktivisten (wer in den letzten Monaten einmal Nachrichten mit Bezug auf IT-Security gelesen hat wird den Namen "Killnet" zumindest einmal gehört haben). Um die Wirkung in den (aus dem Kontext gerissenen) Worten eines Mitarbeiters des BMLV zu beschreiben: "Die Javelin hat sicher Angst, weil die Webseite der Regionalbank Kherson offline ist.".

Wie auch schon bei der Betrachtung aus militärischer Sicht zeichnet sich hier ein sehr deutliches Bild - der durch kinetische Angriffe angerichtete Schaden, und das damit einhergehende Leid für die Zivilbevölkerung, ist um ein vielfaches höher als der durch Cyberangriffe verursachte Schaden und die dadurch entstehenden Auswirkungen.

Einige wenige, begrenzte Ausfälle der nationalen Konnektivität durch die Aktivitäten russischer Bedrohungsakteure sind nicht einmal im Ansatz gleichzusetzen mit den massiven Ausfällen die durch zerstörte Netzwerkinfrastruktur verursacht wurde, oder der intensiven Bombardierungen der kritischen Infrastruktur (insbesondere der Stromversorgung) des Landes - welche mit fortschreitender Dauer des Krieges militärisch kaum mehr zu rechtfertigen waren.

Bis auf eine handvoll von zeitlich und örtlich sehr spezifischen Ausnahmen, mehrheitlich zu Beginn der Invasion, sind zerstörerische Angriffe russischer Akteure aller Couleur in ihrer Wirkung weit hinter den Erwartungen (und theoretischen Möglichkeiten) zurückgeblieben & können nach aktuellem Stand in ihrer Gesamtheit als gescheitert betrachtet werden.

Ich bin glücklicherweise in der Position für eine Organisation zu arbeiten, die sich mit der fachlichen Analyse dieser Angriffe auf technischer Ebene beschäftigt. Detaillierte militärische Einschätzungen sowie eine Abschätzung, was die Geschehnisse im "militärischen Cyberraum" für verteidigungspolitische Entwicklungen der nächsten Jahre bedeutet liegen nicht in meiner Verantwortung (und sind auf Basis einer solchen rudimentären Analyse wie der obigen wahrscheinlich auch nicht seriös möglich).

Dennoch möchte ich kurz einen Blick darauf werfen, was die Gründe für dieses scheinbare Versagen, beziehungsweise die Nichtigkeit dieser Cyberangriffe im "großen Ganzen", sein könnte.

Was ist der Grund dafür?

Die Liste an Gründen für das vergleichsweise Fehlen von Erfolg, oder zumindest Effektivität, ist wahrscheinlich lange und komplex. Einige besondere Faktoren sind meines Erachtens nach herausstechend.

Russische Bedrohungsakteure sind seit mehr als einem Jahrzehnt in der öffentlichen Berichterstattung zu Cyberangriffen präsent, und haben diese mehr als einmal dominiert. Das könnte unter Umständen fälschlicherweise den Eindruck erwecken, dass russische Nachrichtendienste über ein riesiges Heer aus bestens ausgebildeten Spezialisten verfügen, welches sich beliebig vergrössern lässt und das nur darauf wartet, auf den digitalen Feind losgelassen zu werden.

Es gibt keine öffentlichen Zahlen zu den personellen Kapazitäten, aber es ist wohl keine gänzlich absurde Schätzung wenn man (unter Einbeziehung von russischen Staatsbürgern, die in kriminelle Aktivitäten digitaler Natur verwickelt sind und ihre Expertise aus patriotischem Enthusiasmus, der nichts mit mehr oder weniger subtil angedrohten Zwangsmassnahmen zu tun hat, zur Verfügung stellen) von einer geringen vierstelligen Zahl an zumindest grundlegend für offensive Operationen geeigneten Personen ausgeht.

Das ist nicht unbedingt viel, insbesondere wenn man bedenkt, dass trotz der Wichtigkeit des Krieges die Ukraine nicht der einzige Schauplatz für Aktivitäten russischer Bedrohungsakteure ist.

Und genau diese personelle Limitierung ist eines der Probleme, die die Effektivität russischer Cyberangriffe im Rahmen der Unterstützung militärischer Angriffe gemindert haben beziehungsweise dazu beigetragen haben, dass der Fokus weniger auf destruktiven Angriffen liegt, als vor Beginn des Krieges angenommen wurde.

Als Beispiel: Um eine handvoll Kraftwerke physisch einzunehmen benötigt es (rein vom personellen Aufwand her, etwaigen Widerstand außen vor gelassen) einige geschulte Unteroffiziere und zwei oder drei Kompanien Infanteristen, deren Ausbildung zur Befolgung von Befehlen ausreicht.

(Falls jemand mit militärischer Ausbildung sich gerade an den Kopf greift und ob meiner Milchmädchenrechnung verzweifelt, ich bitte um Nachsicht um der Argumentation willen. Bei mir hat es nicht einmal für den Zivildienst gereicht.)

Um dieselbe Anzahl an Kraftwerken erfolgreich zu kompromittieren und die Stromversorgung negativ zu beeinträchtigen braucht es, sofern dies zeitnah geschehen soll, eine Gruppe ausgebildeter und erfahrenes Fachpersonal.

Davon gibt es eine schnell enden wollende Menge, und diese Menge zu erhöhen ist auch nicht trivial möglich. Insbesondere dann, wenn der Pool an potentiellen Kandidaten aufgrund des durch den Krieg ausgelösten Abfluss von jungen, gebildeten Menschen stetig schrumpft. Ohne Einblick in die Kapazitäten anderer Staaten zu haben gehe ich davon aus, dass dieses Problem auf die meisten staatlichen Bedrohungsakteure zutrifft. Cyberangriffe skalieren nur sehr limitiert.

Weiters waren russische Bedrohungsakteure über weite Teile nicht in der Lage, die typischen Vorteile von Cyberangriffen auszunutzen. Oder, um es etwas besser auszudrücken: Russland hatte es nicht notwendig, diese auszunutzen.

Wenn man bereits dabei ist, in ein Land einzumarschieren, dann sind Dinge wie Kosteneffektivität, glaubhafte Bestreitbarkeit und die Möglichkeit, Kollateralschäden zu vermeiden nicht mehr wirklich nützlich. Die metaphorische feine, unter Umständen getarnte Klinge, ist nicht mehr notwendig, wenn man stattdessen ohne Probleme auf die wörtliche Granate zurückgreifen kann.

Dort, wo es zu Angriffen auf ukrainische IT-Netzwerke kam, trafen die Angreifer:innen auf einen Gegner, der die letzten Jahre damit verbracht hat seine Systeme zu härten und gemachte Erfahrungen aus erfolgreichen Angriffen in die Praxis umzusetzen.

Ich hatte die Chance, mich letztes Jahr auf einer Konferenz ausführlich mit dem Sicherheitsverantwortlichen einer ukrainischen Regierungsbehörde zu unterhalten. Eine Aussage, die mir (sinngemäss) im Gedächtnis geblieben ist, war: "Wir wehren pro Monat mehr Angriffe ab als die meisten Unternehmen in mehreren Jahren mitbekommen".

Unabhängig davon, wie extrem die Diskrepanz nun tatsächlich ist, die Ukraine ist insbesondere seit 2014 und den Ereignissen auf der Krim und im Osten des Landes verstärkt Ziel russischer Cyberangriffe. Gerade zu Beginn waren die Angreifer:innen ob der veralteten und desolaten IT-Landschaft des Landes, sowohl bei staatlichen Institutionen als auch bei privaten Unternehmen, enorm erfolgreich. Im Lauf der letzten Jahre hat sich dies massiv geändert, und viele österreichische Unternehmen könnten sich vom Sicherheitsstand bei manchen ukrainischen Unternehmen einiges abschauen.

Neben diesen jahrelangen Erfahrungswerten darf die Unterstützung durch westliche Partner, sowohl durch diverse Nachrichtendienste als auch eine Vielzahl von kommerziellen Unternehmen, nicht außer Acht gelassen werden.

Das Übertragen von kritischen Daten der ukrainischen Behörden, die flächendeckende Bereitstellung von Endpoint Protection für ukrainische Systeme, eine vermutlich gigantische Menge an Informationen und generell intensiver Informationsaustausch und Kooperation haben sicherlich einen massiven Beitrag zur Stärkung der Resilienz ukrainischer Systeme geleistet.

Was genau von nachrichtendienstlicher Seite beigetragen wurde kann ich nicht sagen, aber ich bin mir relativ sicher, dass deren Bedrohungsinformationen das Gegenteil von nutzlos waren. Und wenn wir schon beim Stichwort Nachrichtendienste sind ..

Spionage?

Ich habe zu Beginn dieses Beitrages gesagt, dass ich digitale Spionage mehr oder weniger ignoriert habe. Auch wenn ich das Thema persönlich sehr spannend finde, unsere Aufgabe als nationales CERT ist die IT-Sicherheit, und darauf liegt auch unser Fokus.

Dazu kommt, dass die Informationslage (was öffentliche Quellen betrifft) sehr dürftig ist, und viel Spekulation erfordern würde. Auch was destruktive Angriffe betrifft ist die Vollständigkeit der zur Verfügung stehenden Informationen mehr als fraglich, aufgrund der ausgezeichneten Arbeit von Sicherheitsunternehmen, unabhängigen Forscher:innen und Expert:innen sowie einigen Veröffentlichungen von Regierungsbehörden zumindest etwas besser.

Dennoch möchte ich kurz auf Informationsgewinnung durch Cyberangriffe eingehen, damit hier nicht der falsche Eindruck entsteht, dass russische Aktivitäten hier erfolgreich waren, eben weil destruktive Angriffe es nicht waren. Ich bin mir sicher, dass es im Rahmen des Krieges zu ungezählten Fällen von Cyberspionage gekommen ist, ich zweifle aber durchaus an, dass diese in militärischer Hinsicht wirksamer waren als destruktive Angriffe.

Es gibt einige wenige Hinweise, dass bei Cyberangriffen Informationen beschafft wurden, die in weiterer Folge zur Koordination von Angriffen verwendet wurden. Microsoft spricht beispielsweise in einem Bericht von Angriffen im Frühjahr 2022 gegen die Verwaltung der Stadt Vinnytsia, deren Flughafen zwei Tage später von mehreren Mittelstreckenraketen getroffen wurde.

Derselbe Vorfall wird in einem zweiten Bericht ebenfalls erwähnt, wobei Microsoft in jenem selbst davon spricht, dass es sich hier um eine zeitliche Korrelation handelt, und nicht notwendigerweise um einen Kausalzusammenhang.

Natürlich ist es denkbar, dass militärische relevante Daten im Zuge von Angriffen gegen IT-Systeme im Einsatzgebiet erbeutet wurden. Für die Kommandeurin einer Militäreinheit wäre es allerdings deutlich einfacher und wahrscheinlich schneller zielführend, eine billige Drohne einzusetzen und die gegnerischen Stellungen auszukundschaften anstatt zu warten, bis zufällig auf einem gegnerischen Computer eine Karte aller Stellungen gefunden wird.

Alternativ kann ein Unteroffizier vielleicht auf Satellitenbilder, mobile Radareinheiten, akustische Anti-Artillerie-Geräte und sonstige Technik zurückgreifen - oder einfach die aus dem Nachbarort radelnde Pensionistin fragen, ob sie am Hauptplatz zufällig Panzer gesehen hat.

Dazu kommt, dass durch alle Beteiligten auf allen Seiten - Soldat:innen, Journalist:innen, Zivilist:innen - eine Menge an audiovisuellen Inhalten generiert und in den sozialen Netzwerken geteilt wurde. Auch daraus lassen sich, unter Umständen schneller, billiger und einfacher, operative Informationen gewinnen.

Abgesehen davon, dass man mit einer gewissen Sicherheit davon ausgehen kann, dass digitale Spionageoperationen unter denselben Problemen und Limitierungen gelitten haben, wie destruktive Angriffe, sind Cyberangriffe auf operativer Ebene, im Feld, wohl nicht das Mittel der Wahl.

Was heißt das alles für uns als Verteidiger?

Mein Vorgesetzter hat diese seltsame, fixe Vorstellung, dass ich auf Basis unvollständiger Informationen Aussagen über vergangene und zukünftige Entwicklungen treffe. Er nennt das "Analyse" und behauptet, dass ich dafür bezahlt werde. Woher auch immer er das wieder hat.

Das Gros der "lessons learned" ist für die meisten Unternehmen wahrscheinlich von geringerer Bedeutung als für militärische Planer. Der bisherige Verlauf des Krieges in der Ukraine hat gezeigt, dass es eine gigantische Herausforderung ist, kontinuierlich Cyberangriffe durchzuführen, die zielgerichtet, zweckdienlich und effektiv sind. Diese dann auch noch so zu gestalten, dass sie die kinetischen Operationen der eigenen Truppen unterstützen ist unter Umständen sogar noch eine grössere Herausforderung.

Dennoch gibt es auch für den zivilen Bereich, für den Unternehmensalltag, einige (auch von uns seit langem beschworene) Dinge, die sich im Rahmen des Ukrainekrieges erneut als wahr herausgestellt haben.

Sorgfältige Vorbereitungsarbeit und kontinuierliche Verbesserung der Sicherheit der eigenen Netzwerke funktioniert. Investitionen in diesem Bereich mögen zwar eine Kostenstelle sein, sind aber langfristig kritisch für die Gewährleistung des regulären Betriebes des eigenen Unternehmens.

Der Fokus dieser Investitionen, sowohl monetärer als auch personeller Natur, sollte auf den Grundlagen liegen. In den seltensten Fällen kommt es bei Cyberangriffen zum Einsatz von fundamental neuen Angriffsmethoden, in den meisten Fällen wird auf altbewährte Taktiken und Techniken zurückgegriffen. Dies gilt auch in Extremfällen, wie das ukrainische SSSCIP in einer Analyse zu der Dimension russischer Cyberangriffe festgestellt hat.

Threat Hunting zu betreiben, ein hypermodernes SOC zu haben oder "Artificial Intelligence" einzusetzen ist alles schön und gut, hilft aber wenig, wenn es ein einziges lokales Adminpasswort für alle Systeme gibt oder das Buchhaltungsprogramm auf Windows XP (ohne Service Pack) angewiesen ist.

Gleichzeitig kennen Cyberangriffe keine Regeln, sie halten sich an keine sozialen Konventionen oder internationalen Normen. Kriminelle interessieren sich in keinster Weise für ISO-Zertifizierungen (es sei denn, sie machen sich auf ihren Leak-Seiten explizit darüber lustig), und in den seltensten Fällen haben Gesetze irgendeine Relevanz für die Täter:innen.

Jedes Unternehmen, jede Institution, jede Organisation ist ein legitimes Ziel, solange es für die Angreifer:innen - auf welche Art und Weise auch immer - gewinnbringend ist. Selbst wenn Bedrohungsakteure vorgeben, gewisse Gruppen von Zielen nicht anzugreifen (wie dies zuletzt bei Angriffen der Clop Ransomwaregang der Fall war) heißt das noch lange nicht, dass dem dann im Endeffekt auch wirklich so ist.

Was sich allerdings in der Zeit seit dem Beginn des Krieges in der Ukraine geändert hat, jedoch nicht notwendigerweise im Kausalzusammenhang steht: In der Vergangenheit waren Informationsoperationen nahezu ausschließlich die Domäne von Nationalstaaten, oder organisierten Gruppierungen (beispielsweise Unternehmen oder politische Parteien), und in den meisten Fällen war die Zielsetzung eine Form von politischer Einflussnahme.

In den letzten Monaten zeigt sich vor allem bei finanziell motivierten Cyberangriffen eine Bereitschaft der Täter, den Verhandlungs- und Zahlungsdruck durch gezieltes Ansprechen von Medien, vor allem soziale Medien aber auch "traditionelle" Nachrichtenorganisationen, und die schrittweise Veröffentlichung von angeblich gestohlenen Informationen, zu erhöhen.

Dies steht im Gegensatz zu der fast schon kommentarlosen Veröffentlichung von betroffenen Unternehmen auf den jeweiligen Leakseiten. Es ist dementsprechend durchaus ratsam, die eigene Kommunikationsabteilung frühzeitig in den Incident Response-Prozess einzubeziehen und eine Kommunikationsstrategie in der Hinterhand zu haben. Nach einem Sicherheitsvorfall transparent und ehrlich mit Betroffenen, Kunden und der breiteren Öffentlichkeit zu kommunizieren ist unschätzbar wertvoll, und interessanterweise etwas, was gerade große Unternehmen so überhaupt nicht auf die Reihe kriegen.

Auch wenn meine Einschätzung sich mit weiten Teilen der Community deckt - ich empfehle an dieser Stelle das ausgezeichnete Paper das Jon Bateman im Rahmen seiner Arbeit für das Carnegie Endowment for International Peace geschrieben hat, welches sich mit sehr ähnlichen Fragen beschäftigt (und dabei deutlich detaillierter und qualitativer ist) - sei fairerweise erwähnt, dass es Expert:innen gibt, die das anders sehen.

Der Leiter des britischen GCHQ bezeichnet die Verneinung des Einflusses russischer Cyberangriffe als "Irrtum". Und auch aus den Reihen der NATO kommen Stimmen, die Cyberangriffe als den grössten militärischen Erfolg Russlands seit Beginn des Krieges betrachten - der Sicherheitsexperte Dmitri Alperovitch sieht dies, bezogen auf den Angriff gegen KA-SAT zu Beginn des Krieges, gleich. Auch wenn ich natürlich gerne die absolute Wahrheit für mich gepachtet hätte, wahrscheinlich liegt genau jene in irgendeinem der vielen Grautöne zwischen den binären Beurteilungen.

Abschließend sei gesagt: Ich will in keinster Weise in Abrede stellen, dass russische Nachrichtendienste kontinuierlich in ihre offensiven Kapazitäten investieren und eine Bedrohung für österreichische Ziele darstellen (selbiges gilt natürlich auch für andere Bedrohungsakteure, mit deren gesteigerter Aktivität sich mehr als ein eigener Beitrag füllen ließe ..), dass Cyberangriffe gegen kritische Infrastruktur eine ernst zunehmende Bedrohung sind, oder dass OT-Systeme ein immer lohnenderes Ziel für Angriffe werden. All dies steht hoffentlich nicht zur Debatte.

Aber gerade um den Schutz dieser kritischen Systeme bestmöglich zu gewährleisten ist es in meinen Augen wichtig, einem objektiven, rationalen Ansatz zur Einschätzung der Bedrohungen und Risiken zu verfolgen - und nicht in Hyperbeln zu verfallen oder diesen zu folgen.

3CX - Operation erfolgreich, Patient ignoriert

CERT.at — Thu, 13 Apr 2023 18:45:52 GMT+0100

3CX hat nun erste Informationen veröffentlicht, welche durch Mandiant im Rahmen einer forensischen Untersuchung der Systeme des Unternehmens gefunden wurden. Diese Informationen unterstützen Aussagen in Berichten von anderen Sicherheitsunternehmen (wie beispielsweise Kaspersky), die den Angriff gegen 3CX beziehungsweise den dafür verantwortlichen Bedrohungsakteur staatlichen Stellen in Nordkorea zurechnen.

Inzwischen gibt es auch eine vergleichsweise brauchbare Liste an Artefakten und technischen Indikatoren, mithilfe derer sich eine Infektion im eigenen Netzwerk relativ zuverlässig erkennen lässt. Links zu dem Gros dieser Indikatoren finden sich in unserer letzten Veröffentlichung zum Thema 3CX.

Nach anscheinender anfänglicher Schockstarre hat das Unternehmen auch seine Krisenkommunikation inzwischen halbwegs im Griff, neben "offiziellen" Pressemeldungen hat sich auch der Geschäftsführer von 3CX bereits mehrfach persönlich zu der Causa zur Sache gemeldet. Dies unter anderem in einem Posting im firmeneigenen Forum. Folgender Teil dieses Beitrages sticht dabei hervor:

We only have a handful of cases reported to us where malware has actually been triggered. And these reports still require verification. Furthermore after removal of the infected files using anti virus software no further malicious outbound traffic has been observed. Of course this may change but this is the status as of today.

Mal ganz abgesehen davon, dass diese Aussage im Widerspruch zu dem steht, was in weiterer Folge von Kund:innen in eben jenem Forenthread berichtet wird, und auch elegant ausblendet, dass die kompromittierte Version der 3CX Desktop-App per Definition auch Malware ist - hier wird ein ganz wesentlicher Punkt ignoriert. Ein Punkt, den auch Teile der Security-Community zu ignorieren scheinen.

Ja, nach allem was wir bisher wissen handelt es sich bei den Angreifer:innen tatsächlich um einen staatlichen Bedrohungsakteur dem es zumindest aktuell nicht darum gehen dürfte, weitreichend zerstörerische Schadsoftware auszurollen - auch wenn nordkoreanische Angreifer:innen in der Vergangenheit auch destruktiv unterwegs waren, so waren in den letzten Jahren Spionage und der Diebstahl von Kryptowährungen doch eher im Fokus der Aktivitäten.

Und ja, eben jene Theorie, dass die Angreifer:innen als aktuelles Primärziel das Eindringen in einen Finanzdienstleister, einen Exchange oder ein sonstiges Unternehmen im Finanzbereich hatten ist absolut plausibel. Das heisst aber noch lange nicht, dass dies das einzige Ziel ist oder war, dieser durch die Kompromittierung von 3CX erstandene weitreichende Zugriff kann durch den Bedrohungsakteur vielfältig genutzt werden. Es wäre fast schon nachlässig verschwenderisch, aus Sicht der Angreifer:innen, wenn diese das nicht auch entsprechend tun würden.

Selbst wenn das Unternehmen ein vermeintlich "sauberes" Update nachgeliefert hat, und Mandiant anscheinend mit Hochdruck dabei ist, forensische Untersuchungen durchzuführen, ist es in meinen Augen beinahe fahrlässig, diesen Sicherheitsvorfall als beendet anzusehen und zur digitalen Tagesordnung zurückzukehren. Insbesondere in Anbetracht der Tatsache, dass bisherige technische Analysen (wie beispielsweise die sehr empfehlenswerte der kompromittierten macOS-Variante der 3CX Desktop App) deutliche Hinweise darauf liefern, dass eben jene vielfältige Nutzung zumindest in der Theorie angedacht war oder ist:

That’s up to say, the [supply-chain] attacker gets thousands of victims, collects everything they need for future compromises, profiles their haul, and decides how to maximize that access.

Wir haben in unserer Rolle als nationales CERT von Partnerorganisationen Informationen über ungefähre Infektionszahlen bekommen. Diese Zahlen dürfen wir leider nicht veröffentlichen, und sie beziehen sich auch nicht speziell auf Österreich, sondern auf weltweite Infektionen, ohne detailliertere Aufschlüsselungen zu beinhalten. Aber, um irgendwo den Spagat zwischen Wahrung der Informationsklassifikation und dem Wunsch nach der Weitergabe relevanter Informationen zu bewerkstelligen, es ist eine Zahl, die deutlich über dem Eurobeitrag liegt, den mir mein Arbeitgeber am Ende jeden Monats auf mein Konto überweist.

Daher die eindringliche Bitte: Auch wenn es verlockend ist, weil wir allesamt genug zu tun haben, wenn die 3CX Desktop App in Ihrem Unternehmen im Einsatz ist, oder innerhalb der letzten Monate im Einsatz war, überprüfen Sie Ihre Risikoabschätzung, versuchen Sie sicher zu stellen, dass Sie nicht von einer Infektion betroffen waren, oder zumindest von Seiten der Angreifer:innen keine weiteren missbräuchlichen Schritte gesetzt wurden. Ja, das ist eine Investition von Zeit und Arbeitskraft - aus eigener Erfahrung weiss ich aber, dass die Aufarbeitung einer mehrere Monate lang unentdeckt gebliebenen Kompromittierung deutlich mehr kostet. In jeder Hinsicht.

Und ganz allgemein auch noch der Appell: Wenn Ihr Unternehmen bei solchen Vorfällen Opfer wird, oder der Verdacht besteht, dass es zu einer Infektion oder Kompromittierung gekommen ist, bitte sprechen Sie mit uns - in vielen Fällen haben wir die Möglichkeit, ihre Incident Response zumindest mit technischen Detailinformationen zu unterstützen. Und selbst in Situationen wo uns dies nicht möglich ist erlaubt uns das Wissen über den Vorfall eine bessere Abschätzung der aktuellen Situation in Österreich. Sie wissen schon, dieses medial gerne ausgeschlachtete "Cyberlagebild".

(Gepatchte aber dennoch) üble Sicherheitslücke in (einer optionalen Komponente von) Microsoft Windows

CERT.at — Wed, 12 Apr 2023 18:10:55 GMT+0100

Es entbehrt nicht einer gewissen Ironie, dass die meisten Blogeinträge, welche sich in den letzten Monaten mit Sicherheitslücken in Produkten von Microsoft beschäftigt haben, von dem Mitarbeiter des CERT stammen, dessen Kenntnisse rund um Windows, Office und den ganzen Rest wohl mit Abstand am schwächsten sind - und damit herzlich willkommen zu einem weiteren Beitrag, welcher diese Kriterien vollständig erfüllt.

Dass die monatlichen Patchdays für das Gros der Unternehmen in den meisten Fällen unter "business as usual" fallen habe ich bereits im Dezember letzten Jahres angemerkt. In der damals angesprochenen Zwickmühle sind wir jedoch leider auch dieses Monat wieder gelandet, dank CVE-2023-21554. Dabei handelt es sich um eine Remote Code Execution im "Windows message queuing service", einer optionalen Komponente von Windows.

Wie das Wort "optional" andeutet ist diese zwar nicht standardmäßig aktiviert, jedoch laut Microsoft in jeder Version von Windows, inklusive Windows 11 und Windows Server 2022, inkludiert. Wenn der Service aktiv ist lauscht er auf Port 1801/TCP auf neue Verbindungen, was geneigte Angreifer:innen dank dieser Sicherheitslücke sehr freut, weil es folgendes ermöglicht:

To exploit this vulnerability, an attacker would need to send a specially crafted malicious MSMQ packet to a MSMQ server. This could result in remote code execution on the server side.

Autsch. Ich habe im Lauf meiner professionellen Laufbahn schon öfter gewitzelt, Systeme seien "so unsicher, dass man sie nur anhusten müsse, damit sie in sich zusammenbrechen". Auch wenn die genauen technischen Details (zumindest mir) noch nicht bekannt sind, so kommt CVE-2023-21554 dem von mir humoristisch gezeichneten Szenario doch sehr, sehr nahe.

Die Sicherheitsforscher:innen von Checkpoint sprechen in einem Blogpost von weltweit rund 360.000 öffentlich erreichbaren IP-Adressen, bei denen sich hinter einem offenen Port 1801/TCP ein laufender MSMQ-Service verbirgt. Diese massiven Zahlen konnte ich auf die Schnelle nicht verifizieren, aber es gibt definitiv einen Haufen potentiell betroffener Systeme da draussen. Und auch wenn ich (leider/zum Glück) keinen Einblick in die Denkweise der diversen aktuell aktiven Bedrohungsakteure habe, so würde es mich sehr wundern, wenn sich Angreifer:innen die Ausführung von Code über einen simpel abzusetzenden Request lange entgehen lassen würden.

Neben der offensichtlichen Lösung für das Problem - das Einspielen des zur Verfügung stehenden Patches - sei Administratoren dringend geraten zu prüfen, ob der betroffene Service (laut Microsoft ist er unter dem Namen "Message Queuing" / "mqsvc.exe" zu finden) auf einem der eigenen Systeme aktiv ist.

Und selbst wenn beim Lesen dieser Zeilen der Gedanke "Ha! Sowas würde ich doch nie aktivieren!" kommen sollte, so wäre ich doch vorsichtig. Anscheinend wird MSMQ als Middleware in diversen populären Anwendungen eingesetzt, was dazu führen kann, dass der Service aktiviert wird, ohne dass Benutzer:innen oder Administrator:innen sich dessen bewusst sind.

Doch selbst wenn man im eigenen Unternehmen nicht durch Dritte sabotiert wird, so ist Microsoft unter Umständen zur Stelle und schiesst einem motiviert in's Bein:

For example, CPR saw that when installing the official Microsoft Exchange Server, the setup wizard app would enable the MSMQ service in the background if the user selects the “Automatically install Windows Server roles and features that are required to install Exchange” option, which is recommended by Microsoft.

Sollte nichts der genannten Dinge zutreffen und MSMQ trotzdem aktiviert sein .. nun, ich will hier nicht die Ansicht vertreten, dass Protokolle, Software oder Systeme, die lange keine Aktualisierung mehr erfahren haben deswegen schlecht, veraltet oder gar unsicher sind. Dass die offizielle Dokumentation zu MSMQ anscheinend das letzte Mal vor weit mehr als fünf Jahren geändert wurde, und bereits 2020 davon gesprochen wurde, dass MSMQ wohl tot sei, hinterlässt aber zugegebenerweise einen etwas bitteren Beigeschmack.

Vielleicht übersehe ich hier ob meiner mangelnden intimen Bekanntschaft mit Windows ein Szenario, in der MSMQ systemrelevant ist, aber unter Umständen sollte man diese Schwachstelle zum Anlass nehmen, den Service in den wohlverdienten Ruhestand zu schicken und zu deaktivieren. Oder zumindest firewall-seitig sicherstellen, dass Port 1801/TCP nicht für Gott und die Welt offen erreichbar ist.

In eigener Sache: CERT.at sucht Verstärkung

CERT.at — Tue, 28 Mar 2023 18:44:29 GMT+0100

Für unsere täglichen Routineaufgaben suchen wir derzeit 1 Berufsein- oder -umsteiger:in mit ausgeprägtem Interesse an IT-Security, welche:r uns bei den täglich anfallenden Standard-Aufgaben unterstützt. Details finden sich auf unserer Jobs-Seite.

CVE-2023-23397 - der (interessante) Teufel steckt im Detail

CERT.at — Wed, 15 Mar 2023 17:05:18 GMT+0100

Im Regelfall veröffentlichen wir zu Sicherheitslücken, die durch den Hersteller im Rahmen eines regulären Patchzyklus behoben werden, keine Warnung. Die Motivation dahinter ist, dass wir unsere Warnungen als Werkzeug betrachten, Informationen über kritische Schwachstellen mit entsprechender Urgenz an die jeweiligen Adressat:innen bringen wollen. Dementsprechend entscheiden wir relativ konservativ, wovor oder worüber wir warnen, um die Wirkung selbiger nicht zu verwässern.

Aber, wie so oft, bestätigen Ausnahmen die Regel - der im Rahmen des diesmonatigen Patchday von Microsoft veröffentlichte Fix für CVE-2023-23397 ist genau so ein Fall. Die weite Verbreitung von Microsoft Outlook, kombiniert mit der vergleichsweise trivialen Ausnutzbarkeit sowie des laut dem Unternehmen bereits erfolgten Missbrauches der Schwachstelle bei Angriffen ist ein ausreichender Motivator um mit absolutem Nachdruck zu sagen: Aktualisierung einspielen. Jetzt.

Um, zumindest zu einem gewissen Grad, sicherstellen zu können, dass man nicht bereits Opfer einer Ausnutzung wurde, lässt sich das Script verwenden, welches das Unternehmen aus Redmond im selben Atemzug mit dem Patch veröffentlicht hat. Damit lassen sich Exchange-Server auf Spuren einer Kompromittierung von Zugangsdaten untersuchen - indem Mails und Kalendereinträge auf darin vorhandene UNC-Pfade durchleutet werden.

Neben technischen Informationen zu CVE-2023-23397 enhält das Advisory zu der Sicherheitslücke diversen Metriken, sowie Empfehlungen zur Risikominimierung und noch einige andere Informationen. Wo sich Microsoft aber in einen Mantel des Schweigens hüllt sind Details zu der berichteten bereits erfolgten Ausnutzung - Information, die nicht unwichtig ist.

Für die eigene Risikobewertung ist es durchaus von Relevanz, ob die Schwachstelle durch finanziell motivierte Bedrohungsakteure ausgenutzt wurde, oder ob sie bei nachrichten-/geheimdienstlich gesteuerten Spionagekampagnen missbraucht wurde.

Ein Indikator findet sich in der Danksagung:

CERT-UA, Microsoft Incident Response, Microsoft Threat Intelligence (MSTI)

Deutlichere Worte findet das Unternehmen in einem Blogpost:

Through joint efforts, Microsoft is aware of limited targeted attacks using this vulnerability and initiated communication with the affected customers. Microsoft Threat Intelligence assesses that a Russia-based threat actor used the exploit patched in CVE-2023-23397 in targeted attacks against a limited number of organizations in government, transportation, energy, and military sectors in Europe.

Ich lehne mich mal vorsichtig aus dem Fenster und deduziere, dass die Entdeckung der Schwachstelle im Rahmen einer forensischen Untersuchung der ukrainischen CERT-Kollegen erfolgt ist und in weiterer Folge Microsoft gemeldet wurde - was an und für sich gesprochen schon erfreulich ist. Nicht nur, weil die Kooperation zwischen staatlichen Stellen und Herstellern wohl nicht immer einfach ist, und die Beeinträchtigungen, die die Arbeit in einem aktiven Kriegsgebiet mit sich bringt. Sondern auch, weil es eine meiner (von mir gerne salopp als Tatsache deklarierte) Theorien unterstützt.

Ich höre auf Konferenzen und in Gesprächen mit Kolleg:innen aus der Branche immer wieder die Aussage, dass sich Angreifer:innen gar nicht bemühen müssten, weil die trivialen Techniken und billigen Tricks ausreichen würden.

Aber auch Witze und Gelächter über russische Bedrohungsakteure und ihre Aktivitäten seit Beginn des russischen Angriffskrieges gegen die Ukraine sind keine Seltenheit - insbesondere, weil deren Performance im Rahmen offensiver Computer-Netzwerk-Operationen in der öffentlichen Wahrnehmung ähnlich bescheiden ist, wie die der russischen Streitkräfte gerade zu Beginn der seit über einem Jahr andauernden dreitägigen Spezialoperation.

Die Geschehnisse rund um die Entdeckung von CVE-2023-23397 zeigt für mich, dass Beides fälschliche Annahmen sind. Natürlich freuen sich Angreifer:innen, wenn die Kompromittierung ihrer Ziele ohne großen Aufwand möglich ist. Aber sie scheuen ganz sicher nicht davor zurück zu komplexen Angriffsmethoden oder zur "Verbrennung" bisher unbekannter Schwachstellen zu greifen, wenn die einfachen Methoden nicht funktionieren oder nicht im erwünschten Ausmaß erfolgversprechend sind. Alles ist erlaubt, solange es die Erreichung der Ziele unterstützt.

Ja, die von einer Vielzahl von "Expert:innen" angekündigte "digitale Zerstörungswelle" gegen europäische Netzwerke und Computersysteme ist ausgeblieben. Und ja, manche der enttarnten (oder, im Fall diverser pseudo-hacktivistischer Gruppierungen, öffentlich angekündigten) Angriffsversuche Russland zugerechnteter Bedrohungsakteure waren schon fast lachhaft tollpatschig. Aber in jedem Konflikt gilt, dass es niemals eine gute Idee ist, seine Widersacher zu unterschätzen - das wusste schon Sunzi .. oder Carl von Clausewitz. Auf jeden Fall bin ich sicher nicht der Erste, der das propagiert.

Oh, und weil's eine billige Gelegenheit ist: Diese Schwachstelle ist ein erneutes, eindrucksvolles Beispiel, warum sowohl "Defense in Depth" als auch 2FA wichtige Komponenten der eigenen Sicherheitsstrategie sind. Es gab, bis zu der Veröffentlichung des Patches, relativ wenig, was man gegen einen Missbrauch der Schwachstelle hätte tun können. Aber auch der coolste gestohlene Net-NTLMv2-Hash hilft Angreifer:innen wenig, wenn der dazugehörige zweite Faktor sicher verwahrt auf einem Hardwaretoken in der Hosentasche der eigenen Mitarbeiter:innen ist.

ProxyNotShell Mitigations K.O.

CERT.at — Thu, 05 Jan 2023 12:40:27 GMT+0100

Warum ist ProxyNotShell noch ein Thema? Die Schwachstellen wurden doch von Microsoft Anfang November geschlossen?

Kurz gesagt, weil sich viele auf die letzte Mitigation von Microsoft verlassen haben, anstatt auf den November-Patch. Der Exchange Patch vom November hatte es einigermaßen in sich. Zuerst war er heiß erwartet, dann gab es vereinzelt doch Probleme beim Einspielen und hat so manchen Admin mehrere Anläufe gekostet. Zum Glück hat Microsoft Übergangslösungen für die ProxyNotShell-Sicherheitslücke veröffentlicht … Naja.

Ende September 2022 bekam die Schwachstellenkette (CVE-2022-41040 und CVE-2022-41082) ihren Namen ProxyNotShell, hier unsere Warnung dazu. Was folgte war ein Katz- und Maus-Spiel, in dem Microsoft eine Mitigation nach der anderen veröffentlichte, die meist kurze Zeit danach wieder umgangen werden konnte. Die letzte Mitigation vom 8. Oktober blieb dann erst einmal standhaft und das sogar bis über den November-Patch hinaus. Diese Mitigation wurde aber dann Mitte Dezember wieder erfolgreich umgangen was ungepatchte Exchange-On-Premise-Server wieder angreifbar machte. Das hat zur Folge, dass Shadowserver in Österreich zum jetzigen Zeitpunkt rund 1600 vulnerable Systeme erkennt. „Fatality“

Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen. Regelmäßige Neustarts stellen sicher, dass diese auch zeitnah aktiviert werden.

Warum ich keine Cloud-basierten Passwort-Manager nutze:

CERT.at — Thu, 29 Dec 2022 16:00:29 GMT+0100

Eingangs ein paar seichte Witze über die Cloud. Wie Sie hiesigen Medienberichten [1, 2, 3, 4] unter Umständen entnommen haben, bekamen LastPass-BenutzerInnen für ihr Vertrauen heuer ein Weihnachtsgeschenk der unerfreulichen Art.

Was ist passiert?

Am 22. Dezember veröffentlichte LastPass das nun dritte Update zu einem Security-Advisory, der zugehörige Incident begann irgendwann Anfang August in einer Entwicklungsumgebung.

Damals wurden mithilfe eines kompromittierten Entwicklerkontos sowohl Quellcode als auch interne Infrastrukturdetails entwendet. Dieser Vorfall ist natürlich unangenehm, jedoch relativ gut eingrenzbar (meinte LastPass am 25. August):

While our investigation is ongoing, we have achieved a state of containment, implemented additional enhanced security measures, and see no further evidence of unauthorized activity.

Rund 4 Monate später dürfte die Situation etwas eskaliert sein, LastPass schreibt nun, dass neben grundlegenden Benutzerdaten wie Name, Rechnungsadresse, E-Mail auch noch weitaus sensiblere Daten gestohlen wurden:

The threat actor was also able to copy a backup of customer vault data from the encrypted storage container which is stored in a proprietary binary format that contains both unencrypted data, such as website URLs, as well as fully-encrypted sensitive fields such as website usernames and passwords, secure notes, and form-filled data.

Ein proprietäres Format, welches unverschlüsselte Felder enthält und durch Backups zu einem Drittanbieter hochgeladen wurde - viel kann da ohnehin nicht mehr falsch gelaufen sein.

Glaubt man dem Twitter-Thread eines ehemaligen LastPass-Mitarbeiters lief dort zumindest in der Vergangenheit einiges nicht ideal. Es gab Ambitionen, Verbesserungen zu erzielen - die Umsetzung ebendieser gestaltete sich jedoch vor allem bei langjährigen Nutzern schwierig.

Lots of vault entries may be encrypted with ECB mode AES-256. [4]

Das ist schlecht. Sehr schlecht. Denn dadurch kann auch ohne Entschlüsselung eine Wiederbenutzung von Passwörtern innerhalb eines Vaults erkannt werden. Die technischen Details erspare ich den LeserInnen an dieser Stelle (hier, und hier).

If you had a legacy 5000 rounds or 10000 rounds, the # of rounds can't just be increased server side. [5]

Das National Institute of Standards and Technology (NIST) hat im Juni 2017 in ihren "Digital Identity Guidelines" bezüglich der Rundenanzahl "so viel möglich" empfohlen, aber die Empfehlung mit "typischer mindestens 10.000" beendet.

Dass das URL-Feld im eigenen Vault nicht verschlüsselt wird, dürfte bereits länger bekannt sein - das ist also kaum erwähnenswert.

Was jedoch erwähnenswert ist:

Warum ich keine Cloud-basierten Passwort-Manager nutze

Grundsätzlich gibt es verschiedene Gründe, warum ich manche Leute die Nutzung eines Cloud-basierten Passwort-Managers ablehnen. Die Gründe dafür sind einfach:

Sicherheit: Ich möchte meine Passwörter nicht online speichern. Zugegeben: Mein Heimnetzwerk ist wohl ähnlich schlecht abgesichert wie das einiger Cloud-Anbieter - aber es ist meines!
Privatsphäre: Dadurch, dass mein Vault nicht online ist, sind meine unverschlüsselten URL-Felder vor fremden Augen geschützt. Und da geht es noch gar nicht um die Möglichkeit der Auswertung oder des Verkaufs meiner Daten.
Abhängigkeit: Einerseits von der Verfügbarkeit des Anbieters, andererseits vom "Internet".
Kontrolle: Mit einem Offline-Passwortmanager habe ich vollständige Kontrolle über meine Passwortdatenbank. Die Datenbank landet lediglich auf meinen Geräten und ich muss mich diesbezüglich nicht auf einen Drittanbieter verlassen.

Disclaimer:

Es ist wichtig zu beachten, dass sowohl offlinebasierte als auch cloudbasierte Passwortmanager ihre eigenen Vor- und Nachteile haben. Welche Art für Ihre Bedürfnisse am besten geeignet ist, müssen Sie selbst entscheiden.
Ich benutze KeePassXC, eine Implementierung des quell-offenen KeePass-Frameworks (sollte ich im neuen Jahr Zeit finden werde ich mir KeeWeb in Kombination mit Caddy und Client-Certificate-Authentication anschauen).

Patch Tuesday: (zur Abwechslung) Augen auf!

CERT.at — Wed, 14 Dec 2022 20:38:51 GMT+0100

An und für sich ist der monatliche "Patch Tuesday" nichts besonderes, und fällt in den meisten Unternehmen wohl sehr eindeutig in die Kategorie "Business as Usual" Auch wir haben uns bereits vor längerer Zeit entschlossen, im Regelfall zu Sicherheitslücken, die im Rahmen dieser Anlässe gefixt werden, keine Warnings zu veröffentlichen. Ausnahmen sind hier relativ selten, zuletzt war dies im Juli 2021 der Fall, als im Druckerdienst von Windows (zum wiederholten mal) das große Sicherheitschaos ausgebrochen war.

Manchmal gelangen wir jedoch in die verzwickte Lage, dass sich in den Patchnotes Updates für Schwachstellen verbergen, aufgrund derer wir zwar keine Warnung veröffentlichen, aber auf die wir dennoch explizit hinweisen wollen. Diesen Monat ist es wieder einmal soweit.

Konkret geht es um CVE-2022-41076 sowie CVE-2022-41080. Dabei handelt es sich eine Remote Code Execution in Powershell sowie eine Elevation of Privilege in mehreren Versionen von Microsoft Exchange. Sind die beiden Sicherheitslücken für sich alleine zwar unschön, aber kein Weltuntergang, ermöglichen sie in Doppelpack potentiell eine Codeausführung auf On-Prem Exchange-Servern. Insbesondere wenn man einen ungeschützten Exchange-Server im Netz hat ist hier Eile beim Aktualisieren angebracht (.. aber wer hat das schon, richtig?).

Auch für ein rasches Einspielen des Patches für CVE-2022-44698 geben wir eine nachdrückliche Empfehlung ab, da diese Lücke bereits aktiv durch Bedrohungsakteure ausgenutzt wird.

Der CVSS-Score von 5.4 ist (in meinen unbedarften Augen) etwas irreführend. Wenn unter Windows eine Datei aus dem Internet heruntergeladen wird, versieht Windows diese Datei mit einem speziellen NTFS-Stream, dem sogenannten "Mark of the Web" - dieser wiederum sorgt dafür, dass manche hauseigenen Applikationen die Datei etwas vorsichtiger behandeln.

Beispielsweise führt Windows SmartScreen, sobald besagte Datei geöffnet wird, basierend auf der Präsenz dieses NTFS-Streams, eine Reputationsprüfung durch. Und genau diese Prüfung kann durch Angreifer:innen, unter Ausnutzung von CVE-2022-44698, umgangen werden. Sich nicht mit Windows SmartScreen herumschlagen zu müssen erleichtert eine initiale Infektion enorm.

Wir können unser eigenes Mantra nicht oft genug betonen:

Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen. Regelmäßige Neustarts stellen sicher, dass diese auch zeitnah aktiviert werden.

(Hinter den Gerüchten, dass dieser Paragraph auf den T-Shirts einiger CERT-Mitarbeiter:innen prangt, steckt selbstverständlich kein Körnchen Wahrheit. Nicht ein Einziges.)

OpenSSL wünscht (vielleicht) "Happy Shelloween"

CERT.at — Mon, 31 Oct 2022 14:35:27 GMT+0100

Das OpenSSL-Projekt hat für morgen, den 01.11.2022, die Veröffentlichung von Sicherheitsaktualisierungen angekündigt. Diese sollen zwischen 13:00 und 17:00 (UTC) erscheinen und beheben laut der Ankündigung mehrere Sicherheitslücken, darunter eine als "CRITICAL" eingestufte Schwachstelle. Diese Einstufung erfolgte zuletzt 2014, für CVE-2014-0160 - besser bekannt als "Heartbleed".

Aufgrund des verhängten Embargos gibt es bisher weder eine öffentlich bekannte CVE-Nummer, noch sonderlich viele bestätigte Informationen und / oder technische Details. Das macht eine akkurate Einschätzung der Gefährdungslage herausfordernd, um es diplomatisch zu formulieren.

Was jedoch bekannt ist: Betroffen ist OpenSSL in den Versionen 3.0.0 bis 3.0.6, die morgen veröffentlichte Version 3.0.7 enthält die Behebung der Schwachstelle. Und die Information hilft zumindest dabei das Ausmaß der betroffenen Systeme besser einschätzen zu können.

Im Gegensatz zu OpenSSL in den Versionen 1.x.x ist Version 3.x.x deutlich weniger verbreitet. Viele Linuxdistributionen (darunter Systeme, die aufgrund ihrer langen Supportzeiträume im Serverbereich zum Einsatz kommen) setzen noch auf ältere Versionen der Bibliothek. Das sollte die Menge an verwundbaren Systemen drastisch einschränken. Die ersten Untersuchungen, die durch Mitarbeiter:innen eines IT-Dienstleisters vorgenommen wurden, bestätigen diese Vermutung:

To assess the potential impact of the vulnerability, we analyzed hundreds of cloud environments from all major CSPs (AWS, GCP, Azure, OCI, and Alibaba Cloud) that contained millions of workloads. We found that over 75% of organizations have at least one impacted instance in their environment. Fortunately, only 1.5% of OpenSSL instances are impacted versions, whereas 98.5% are older, unaffected versions.

Dennoch, davon ausgehend, dass die Entwickler:innen von OpenSSL sich nicht zum Spaß für diese Einschätzung entschieden haben: Für Systeme die auf eine verwundbare Version setzen werden die Auswirkungen wohl ernst sein.

Mir ist klar, dass "Habt Angst!" nicht unbedingt ein idealer Ratschlag ist. Das ist auch nicht die Botschaft, die diese Zeilen vermitteln sollen. Aufgrund der Informationspolitik der Entwickler:innen ist es aktuell leider nicht wirklich möglich zu sagen, wie sich die Situation entwickeln wird. Dennoch macht es Sinn die Schwachstelle ernst zu nehmen und Vorbereitungen zu treffen, damit die Sicherheitsaktualisierungen möglichst schnell eingespielt werden können.

Betroffene Systeme identifizieren

Mittels sudo lsof -n | grep libssl.so.3 lässt sich auf den meisten Linux-Systemen herausfinden, welche laufenden Programme verwundbar sind. Unter Windows ist das Pendant zu diesem Befehl dir /b/s libssl*.dll. Von dort lässt sich dann feststellen welcher Service beziehungsweise welches darunterliegende Paket betroffen ist.

Betroffene Systeme priorisieren

Verwundbare Systeme, die direkt aus dem Internet erreichbar sind, sollten als Erstes aktualisiert werden. Die weitere Priorisierung hängt von den eigenen operativen Bedürfnissen ab, aber für den Betrieb unabdingliche Systemen sollten kurz danach folgen. Auch wenn bisher nicht bekannt ist, ob es sich um eine Schwachstelle handelt, die Clients oder Server betrifft, wäre ich geneigt dem Aktualisieren von Servern / Services im Zweifelsfall die höhere Priorität einzuräumen.

Abwarten, präferiertes Heißgetränk trinken - Ruhe bewahren!

Es könnte durchaus sein, dass der morgige Tag relativ hektisch wird was Medienberichterstattung und Filterblasen in den sozialen Medien betrifft. Auch wenn die Schwachstelle sich als katastrophal herausstellen sollte: Ruhe bewahren. Alle Anderen sind genauso verwundbar wie man selbst, alle Anderen sind genauso an der Grenze zur Panik und die Angreifer:innen kochen ebenfalls nur mit Wasser. Auch dieser Sturm wird vorbeigehen, egal ob er nun im (digitalen) Ozean oder Wasserglas entsteht.

CVE-2022-42889 - das Gute, das Schlechte

CERT.at — Wed, 19 Oct 2022 13:04:12 GMT+0100

Einen passenden Titel für diesen Beitrag zu finden war eine unerwartete Herausforderung, weil es mehrere interessante Aspekte gibt, die bei der Betrachtung von CVE-2022-42889 in's Auge stechen.

Das Wichtigste jedoch vorweg, hinter der CVE-Nummer versteckt sich folgende Sicherheitslücke:

Apache Commons Text performs variable interpolation, allowing properties to be dynamically evaluated and expanded. The standard format for interpolation is "${prefix:name}", where "prefix" is used to locate an instance of org.apache.commons.text.lookup.StringLookup that performs the interpolation. Starting with version 1.5 and continuing through 1.9, the set of default Lookup instances included interpolators that could result in arbitrary code execution or contact with remote servers.

Falls die Details dieser Schwachstelle jemandem bekannt vorkommen sollten: Zurecht, eine starke Ähnlichkeit zu CVE-2022-33980 besteht (was auch in den sozialen Medien nicht unbemerkt geblieben ist).

Apache Commons Configuration performs variable interpolation, allowing properties to be dynamically evaluated and expanded. The standard format for interpolation is "${prefix:name}", where "prefix" is used to locate an instance of org.apache.commons.configuration2.interpol.Lookup that performs the interpolation.

Somit reiht sich diese Sicherheitslücke nahtlos ein in die Serie an Verwundbarkeiten in verschiedensten Java-Applikationen und Frameworks, die mit dem letztjährigen "Vergnügen" (im Nachhinein betrachtet bin ich sehr froh, dass ich erst mit Jänner meinen Weg - zurück - zum CERT gefunden habe) rund um die Probleme mit Log4j begonnen hat.

Die erste wirklich öffentliche Erwähnung fand CVE-2022-42889 letzte Woche auf der Mailingliste des Apache Projektes, bevor die Schwachstelle dann diesen Montag auf Twitter und Konsorten rasch massiv an Aufmerksamkeit gewonnen hat, auch weil ein PoC bereits öffentlich verfügbar war und ist.

Initial war das Bekanntwerden der Sicherheitslücke durchaus besorgniserregend, "Remote Code Execution durch willkürlichen Input in einer verbreiteten Java-Bibliothek" ist gerne ein Rezept für schlaflose Nächte. Vergleiche zu Log4Shell wurden rasch gezogen, und vor allem initial gerne unreflektiert akzeptiert und verbreitet.

Glücklicherweise hat die Community inzwischen leider (.. eine wunderbare Verkettung von Worten) durchaus etwas Erfahrung mit dieser Art von Schwachstellen, weswegen schnell Stimmen laut wurden, welche die Vergleiche in Frage gestellt haben.

Ein Blogpost des Unternehmens Rapid7, den Entwicklern von Metasploit, fasst die Situation relativ gut zusammen. Kurz gesagt ist es, im Gegensatz zu Log4j, vergleichsweise unwahrscheinlich, dass Projekte die verwundbare Komponente nutzen um ungefilterte, potentiell bösartige Daten zu verarbeiten. Die Autoren dieses Posts ziehen Vergleiche zu CVE-2022-22965, einer weiteren ähnlichen Schwachstelle in einem Java-Framework aus diesem Jahr: Die Ausnutzung ist nicht so trivial, wie sie auf den ersten Blick erscheinen mag, in der Praxis gibt es hier einiges an Einschränkungen.

Ein weiterer bitterer, aber dennoch relevanter Einwand aus der Community war, dass die Sicherheitslücke erst 2018 im Code entstanden sei, und die meisten Projekte wohl sowieso nicht auf so eine aktuelle Version setzen würden.

Meine auf Webserver-Logs basierende Telemetrie ist geographisch auf Europa und die USA limitiert, und es ist nicht immer leicht herauszufiltern, welche Schwachstelle mit seltsam anmutenden HTTP-Requests nun ausgenutzt werden soll. Aber es wirkt auf mich auch nicht so, als hätte die Veröffentlichung der Informationen zu dieser Lücke nicht zu einem merklichen Anstieg an Scans oder automatisierten Angriffsversuchen geführt. Anscheinend wird die Welt noch nicht untergehen. Zumindest nicht aufgrund von CVE-2022-42889.

Schlussendlich gibt es in meinen Augen zwei "lessons identified":

Auch wenn eine gewisse Effekthascherei wohl ihren Platz haben kann, wir täten alle gut daran, reisserische Berichte über neue Sicherheitslücken mit potentiell gravierenden Auswirkungen kritisch zu betrachten.
Auch wenn die praktischen Auswirkungen diesmal nicht ganz so katastrophal waren, der Strom an Schwachstellen, welche "Log4" ähneln, reisst nicht ab. Das ist ein Indiz dafür, dass wir hier ein grundlegendes, strukturelles Problem haben. Ich kann nicht sagen, was genau das Problem ist. Es könnten Designprobleme sein, es könnten Qualitätsprobleme im Code sein, es könnte mangelnde Qualitätssicherung sein - oder etwas gänzlich Anderes. Aber die Tatsache, dass wir uns bei kritischen Komponenten moderner Computernetzwerke oftmals auf motivierte Einzelpersonen verlassen um Sicherheitslücken zu finden (anstatt, beispielsweise, konzertierter Maßnahmen durch Projekte oder Hersteller selbst), kann langfristig nichts Gutes verheissen.

Beschäftigen wird uns diese Schwachstelle, auch wenn es nicht zu massenhafter Ausnutzung kommen sollte, wohl dennoch noch eine Weile. Laut den Kollegen vom DFN-CERT ist Apache Commons Text eine Abhängigkeit für über 20.000 Repositories auf Github, was für meine Kollegen in der Medienbeobachtung wohl eine Vielzahl von Advisories mit sich bringen dürfte.

Oh, und natürlich gilt das obligatorische Mantra von CERT.at auch im Fall dieser Sicherheitslücke:

Generell empfiehlt CERT.at, sämtliche Software aktuell zu halten und dabei insbesondere auf automatische Updates zu setzen.

Schlaflose Patchnächte sind aber nicht notwendig. Nachdem sich das Jahresende nähert hoffe ich doch, dass es Budgetfragen sind, die dem geneigten Leser den Schlaf rauben - so wie sich das für diese Jahreszeit gehört.

Shodan Verified Vulnerabilities – Statistiken zu Schwachstellen in Österreich (Updated)

CERT.at — Tue, 22 Sep 2020 12:27:52 GMT+0100

Wir verarbeiten bereits seit einiger Zeit den Stream der Suchmaschine shodan.io, der sämtliche Daten Shodans für Österreich enthält. Dieser hat sich schon bei vielen unserer Aussendungen als extrem hilfreich erwiesen, um Schwachstellen zu identifizieren und Betroffene möglichst zeitnah zu informieren.

Seit einiger Zeit zeigt Shodan auch eine Liste von Schwachstellen an, für die die gescannten Geräte verwundbar sind. Einige davon werden aufgrund von Metadaten wie gefundenen Versionsnummern ermittelt, andere durch sicherere Methoden (Details finden sich z.B. in diesem Twitter-Thread). Wir haben dementsprechend ein kleines Script gebastelt, dass uns eine Zusammenfassung der "Verified Vulnerabilities" erstellt und diese in eine Grafik im SVG-Format umwandelt. Mit Stand 2020-09-22 sieht das Ergebnis folgendermaßen aus:

Das ist aktuell noch Work-in-Progress, geplant ist folgendes:

Monatliche Updates unter https://cert.at/de/meldungen/aktuelles/ (done.)
Jeweils kurze Vergleiche mit dem Vormonat und ggf. Referenzen zu Artikeln, die uns in der Medienbeobachtung dazu aufgefallen sind (done.)
Potentiell: Erweiterung der Grafiken sodass die Schwachstellenbezeichnungen darin zu Links werden, um schnell zu einer Beschreibung des Problems zu kommen

Über Feedback zu diesem Plan würden wir uns freuen, wie immer an team@cert.at.

Liste der Schwachstellen (wird bei "Neuzugängen" aktualisiert)

CVE-2013-1899	Argument Injection Schwachstelle in PostgreSQL 9.2.x < 9.2.4, 9.1.x < 9.1.9 und 9.0.x < 9.0.13	NIST NVD, PostgreSQL Advisory
CVE-2014-0160	Heartbleed Schwachstelle in OpenSSL 1.0.1 vor 1.0.1g	NIST NVD, CERT.at Warnung, CISA Alert TA14-098A
CVE-2015-0204	FREAK Schwachstelle in OpenSSL vor 0.9.8zd, 1.0.0 vor 1.0.0p und 1.0.1 vor 1.0.1k	NIST NVD, CERT.at Blog, Shadowserver Feed
CVE-2015-1635	Potentielle RCE Schwachstelle in Microsoft Windows 7 SP1, Windows Server 2008 R2 SP1, Windows 8, Windows 8.1 und Windows Server 2012 Gold und R2	NIST NVD, Microsoft Advisory
CVE-2015-2080	Auslesen potentiell sensitiver Informationen in Eclipse Jetty before 9.2.9.v20150224 über das Netzwerk und ohne Authentifizierung	NIST NVD, Eclipse Mail-Thread
CVE-2015-4000	Logjam Schwachstelle in TLS <= 1.2 wenn eine DHE_EXPORT Ciphersuite am Server aber nicht am Client aktiviert ist	NIST NVD, CERT.at Blogpost, OpenSSL Advisory
CVE-2016-9244	Potentielles Auslesen sensitiver Daten im BIG-IP Virtual Server	NIST NVD, F5 Advisory
CVE-2017-7269	Remote Code Execution in Microsoft IIS 6.0 in Microsoft Windows Server 2003 R2	NIST NVD
CVE-2019-0708	Remote Code Execution in RDP	NIST NVD, CERT.at Warnung, Microsoft Advisory
CVE-2019-11510	Auslesen beliebiger Dateien über das Netzwerk und ohne Authentifizierung in Pulse Secure Pulse Connect Secure (PCS) 8.2 vor 8.2R12.1, 8.3 vor 8.3R7.1 und 9.0 vor 9.0R3.4	NIST NVD, Pulse Secure Advisory
CVE-2019-1652	Authenticated RCE auf Cisco Small Business RV320 und RV325 Dual Gigabit WAN VPN Routern	NIST NVD, Cisco Advisory
CVE-2019-1653	Auslesen sensitiver Informationen aus Cisco Small Business RV320 und RV325 Dual Gigabit WAN VPN Routern	NIST NVD, Cisco Advisory
CVE-2019-19781	"Shitrix", eine Schwachstelle in Citrix Application Delivery Controller (ADC) und Gateway 10.5, 11.1, 12.0, 12.1, und 13.0, die die vollständige Übernahme des Geräts ermöglicht	NIST NVD, CERT.at Blogpost, Citrix Advisory
CVE-2020-5902	Eine unauthenticated RCE im Traffic Management User Interface von F5s BIG IP Produkten	NIST NVD, F5 Advisory
CVE-2020-0796	Remote Code Execution durch eine Schwachstelle in Microsoft Server Message Block 3.1.1 (SMBv3)	NIST NVD, CERT.at Warnung, Microsoft Advisory
CVE-2020-11651	Fehlerhafte Überprüfung von Methoden-Aufrufen im SaltStack, was potentiell das Auslesen von Account-Tokens vom Salt Master bzw. RCE ohne Authentifizierung auf Salt Minions ermöglicht.	NIST NVD, SaltStack Advisory
CVE-2020-11652	Fehlerhafte Pfad-Bereinigung, die authentifizierten NutzerInnen ermöglicht, auf beliebige Dateien zuzugreifen.	NIST NVD, SaltStack Advisory
CVE-2021-26855	Microsoft Exchange Server Remote Code Execution Vulnerability	NIST NVD, Microsoft Advisory
CVE-2021-26857	Microsoft Exchange Server Remote Code Execution Vulnerability	NIST NVD, Microsoft Advisory
CVE-2021-26858	Microsoft Exchange Server Remote Code Execution Vulnerability	NIST NVD, Microsoft Advisory
CVE-2021-27065	Microsoft Exchange Server Remote Code Execution Vulnerability	NIST NVD, Microsoft Advisory
CVE-2021-31206	Microsoft Exchange Server Remote Code Execution Vulnerability	NIST NVD, Microsoft Advisory, ZDI Advisory
CVE-2021-31207	Microsoft Exchange Server pre-auth path confusion (Teil von ProxyShell)	NIST NVD, Microsoft Advisory, ZDI Blogpost
CVE-2021-34473	Microsoft Exchange Server Privilegieneskalation im PowerShell Backend (Teil von ProxyShell)	NIST NVD, Microsoft Advisory, ZDI Blogpost
CVE-2021-34523	Microsoft Exchange Server Erstellung beliebiger Dateien (Teil von ProxyShell)	NIST NVD, Microsoft Advisory, ZDI Blogpost
CVE-2021-43798	Grafana Path Traversal Vulnerability	NIST NVD, Grafana Blogpost
CVE-2022-32548	DrayTek Authentication Bypass Vulnerability	NIST NVD, DrayTek Advisory
CVE-2022-36804	Command Injection Schwachstelle in Atlassian Bitbucket Server und Data Center	NIST NVD, Atlassian Advisory
MS15-034	Gleiches Microsoft Advisory wie für CVE-2015-1635	Microsoft Advisory
MS17-010	"Eternal Blue", eine Schwachstelle in Microsoft Server Message Block 1.0 (SMBv1) Server, die u.a. bei WannaCry ausgenutzt wurde	Microsoft Advisory, CERT.at Warnung zu WannaCry

Ein guter Tag für Freund:innen von Adobe Software und gepflegtem Patchen

CERT.at — Wed, 12 Oct 2022 10:30:09 GMT+0100

Da kann man sich nicht beschweren: nicht nur eine kritische Lücke in Adobe Commerce und Magento Open Source (CVSS 10.0 - Highscore-verdächtig), sondern auch gleich deren mehrere in Adobe ColdFusion (unter Anderem 4x mit CVSS 9.8 und 1x mit 8.1).

Nutzer:innen von Adobe Acrobat/Acrobat Reader kommen ebenfalls nicht zu kurz, auch wenn man dort dank Auto-Updates vielleicht nicht selbst so viel Spass mit dem Patchen hat.

Und auch wenn ich nicht weiß, was (eine) Adobe Dimension ist: Admins haben dort 4x CVSS 7.8 - Freude.

Aber Adobe ist hier nicht allein, Microsoft matcht den CVSS von 10.0 direkt mit einem Bug in Azure Arc-enabled Kubernetes Cluster und schiebt auch noch gleich 1x CVSS 7.8 mit Privilege Elevation in Windows COM+ Event System Service nach, während Admins von Microsoft Exchange weiter Wetten abschliessen wie lange die letzte Mitigation für die aktuellen Probleme diesmal hält - mit einem CVSS von 8.8 ist man da jedenfalls halbwegs weit vorne dabei.

Und auch sonst ist der Patch Tuesday nicht langweilig.

Und täglich grüßt die Microsoft Exchange On-Prem Schwachstelle

CERT.at — Mon, 03 Oct 2022 13:02:57 GMT+0100

Letztes Jahr schon führten diverse Microsoft Exchange 0-day Schwachstellen - ProxyLogon, ProxyOracle und ProxyShell (CVE-2021-34473, CVE-2021-34523, CVE-2021-31207) - zu einigermaßen chaotischen Zuständen. Dies kann zum Teil auf die späte Reaktion des Herstellers beziehungsweise die verwirrenden, zum Teil falschen Anleitungen für eine erfolgreiche Mitigation der Schwachstelle zurückgeführt werden. Zum Zeitpunkt der Veröffentlichung des Patches waren 2021 bereits eine große Anzahl an Exchange-Server weltweit kompromittiert.
Ende letzter Woche wurde nun eine neue 0-day Schwachstelle - ProxyNotShell (CVE-2022-40140, CVE-2022-41082) getauft - in Exchange bekannt, die zwar im Gegensatz zu ProxyShell - laut offiziellen Informationen - nur authentifiziert eine Remote-Code-Execution (RCE) zulässt, aber dennoch nicht zu unterschätzen ist, da bereits ein Standardbenutzer reicht, um das komplette System zu übernehmen. Diese Schwachstelle wird auch bereits - wenn auch, laut Microsoft nur begrenzt - aktiv ausgenutzt.
Nach Veröffentlichung des initialen Blog-Beitrags zur Schwachstelle und der Meldung an die Zero Day Initiative, hat der Hersteller dieses Mal zwar flott mit Anleitungen für eine Mitigation reagiert, jedoch hat sich gezeigt, dass diese wieder zum Teil falsch beziehungsweise unzureichend sind.

Ohne hier jetzt genau ins Detail zu gehen und die Anzahl der vielleicht in naher Zukunft kompromittierten Systeme zu kennen, soll hier und jetzt die Zeit sein, erneut auf folgendes hinzuweisen ...

Ein On-Prem Exchange-Server ist nur dann ein sicherer oder zumindest halbwegs sicherer Exchange-Server, wenn seine Webinterfaces (Outlook Web Access, Exchange Web Services, etc) ausschließlich über private, gesicherte Verbindungen (zum Beispiel VPN) erreichbar sind.

MOTW (Mark of the Web) - Retter in der Not?

CERT.at — Wed, 24 Aug 2022 16:54:08 GMT+0100

Einführung - Die Mutter aller Probleme

In vielen Fällen sind infizierte Computer auf Dateien zurückzuführen, die ursprünglich aus dem Internet stammen und per Webbrowser oder E-Mail Client durch bewusstes Herunterladen/Speichern ihren Weg auf Erstere gefunden haben. Dies gilt gleichermaßen für ausführbare Dateien (Portable Executables oder Scripts) als auch normale Dateien wie Dokumente (.doc, .pdf, ...). Letztere sind zwar nicht direkt ausführbar, können aber als Einfädler für maliziöse Aktivitäten missbraucht werden.

Um diesem Szenario entsprechend Rechnung zu tragen und Computer dagegen besser schützen zu können, bräuchte es als Grundlage eine Art Markierung für jene aus dem Internet stammende Dateien, so dass diese in weiterer Folge vom Betriebssystem und von Applikationen automatisch mit größerer Vorsicht behandelt werden könnten. So die Theorie.

Umsetzung - Die Geburt von MOTW

Die Umsetzung dieses logischen, einfach nachzuvollziehenden Ansatzes, stellt jedoch ein relativ komplexes Problem dar. Zum einen müssen die besagten Dateien jene Markierung erhalten, müssen aber auch gleichermaßen voll funktionstüchtig, also inhaltlich unangetastet, bleiben. Darüber hinaus muss die Markierung der Dateien kopier- und verschiebeoperationsresistent sein.

Dieser einem Spagat gleichenden Aufgabenstellung hat sich vor vielen Jahren Microsoft angenommen und die Technologie MOTW, ein Akronym für "Mark of the Web", entwickelt. Grundlage deren Lösungsansatzes ist es, die Fähigkeit des Windows Standard-Filesystems NTFS, neben dem Hauptdatenstrom einer Datei auch beliebig viele Nebenströme (Alternative Datenströme, ADS genannt) zu dieser speichern/führen zu können, für die besagte Markierung zu nützen. Dadurch bleibt der originale Inhalt der Datei, also der Hauptdatenstrom, zum Einen unangetastet, und zum Anderen wird der Alternative Datenstrom, das MOTW, bei Fileoperationen mitberücksichtigt. Das heißt, wird die betreffende Datei kopiert oder verschoben, so wird das MOTW mitkopiert, beziehungsweise mitverschoben.

Die Markierung, die damit technisch zufriedenstellend umsetzbar war, musste aber auch noch von Jemandem oder Etwas gesetzt werden. Für Microsoft war damals der Internet Explorer die logische Wahl und so wurde dieser entsprechend um die Funktionalität, den (alternativen) MOTW Datenstrom an Downloads automatisch anzuhängen, erweitert.

Damit war die Basis für die gewünschte Sonderbehandlungsmöglichkeit für aus dem Internet heruntergeladene Dateien gelegt. Die damalige Implementierung abschließend, und um derartige Dateien auch noch verarbeiten zu können, wurde in Windows eine Sicherheitshürde in Form einer Warnung/Freigabeabfrage bei der Ausführung solcher Dateien eingeführt.

MOTW - Eine Frage der Disziplin

MOTW ist ein technisch durchdachter, konsistenter und funktioneller Ansatz, jedoch ist auch bei diesem wieder die Disziplin aller Beteiligten gefragt. Letzten Endes liegt es am Anwender zu entscheiden, ob die beim Öffnen/Ausführen einer betreffenden Datei angezeigte Warnung übergangen wird oder nicht. Und in den meisten Fällen wird Ersteres wohl auch legitim sein.

Disziplin ist aber in dieser Sache nicht nur vom Anwender gefragt - auch die Entwickler der (anderen) Webbrowser (und E-Mail Clients) sowie der, die markierten Dateien verarbeitenden Applikationen, müssen dieses Lösungskonzept entsprechend mittragen.

MOTW - Status Quo

Heutzutage wird das Schreiben der MOTW Markierung von den gängigsten Web Browsern unterstützt. Was E-Mail Clients anbelangt, gibt es diesbezüglich aber leider Nachholbedarf. In allen Fällen gilt aber, dass der Support von MOTW von der jeweiligen Version der Software/Applikation abhängig ist. Ist man sich unsicher bezüglich der selbst genutzten Software, und die Recherche im Internet ist diesbezüglich in den meisten Fällen wenig aussagekräftig/fruchtbringend, empfiehlt sich, es einfach auszuprobieren, also, eine Datei runterzuladen bzw. ein Attachment zu speichern. Danach muss man nur noch die Dateien auf die MOTW Markierung überprüfen.

MOTW, zeig Dich!

Will man herausfinden, ob eine Datei MOTW-markiert ist, so gibt es mehrere Methoden - hier eine Auswahl der einfachsten:

Die Eigenschaften (Allgemeiner Reiter) der betreffenden Datei im Windows Explorer (erreichbar durch dessen Kontextmenü) enthalten einen sich mit der Abbildung deckenden oder vergleichbaren Spezialbereich.
Über ein Konsolen-Fenster (cmd.exe) kann man über den Befehl dir /r die alternativen Datenströme der im aktuellen Verzeichnis enthaltenen Dateien anzeigen lassen, und damit auch die MOTW Markierung derer ... siehe Abbildung.

MOTW - Status Quo, die 2te

Abseits der MOTW-schreibenden Software ist jene, die das MOTW verarbeiten und interpretieren kann, natürlich mindestens genauso wichtig. Hier zeigt sich aber, dass das diesbezügliche Feld ein sehr durchwachsenes ist. Und das fängt schon bei Windows selbst an. Während der Start einer MOTW-markierten ausführbaren Datei über den Windows Explorer über mehrere Schritte im Hintergrund verifiziert und durch einen Dialog blockiert wird (siehe weiter unten), lässt sich selbige Datei über ein Konsolen-Fenster (cmd.exe) ohne Einschränkung starten. Für allgemeine Anwendungssoftware/-applikationen verhält es sich ähnlich wie weiter oben schon erwähnt: Recherche im Internet ist diesbezüglich in den meisten Fällen wenig aussagekräftig/fruchtbringend, eine (erschöpfende) Liste an unterstützenden Applikationen ein Wunschtraum. Es empfiehlt sich demnach auch an dieser Stelle, es einfach auszuprobieren, also, MOTW-markierte Dateien unterschiedlicher Formate/Extensions mit den präferierten Applikationen zu öffnen und auf deren Verhalten zu achten.

Vorzeigeschüler Windows Explorer

Wird eine MOTW-markierte ausführbare Datei im Windows Explorer gestartet (Doppelklick, Enter-Taste), passieren folgende Schritte:

Überprüfung durch SmartScreen Application Reputation (Win8+) sowie aller installierter Antiviren Scanner
Überprüfung der digitalen Signatur der Datei
Warnung und Bestätigungsanforderung an den Benutzer durch Dialog (siehe Abbildung)

Corner Cases als potentielle Schlupflöcher und Fallstricke

Abseits der teils fehlenden Disziplin und Verlässlichkeit oder generellen Unterstützungsbereitschaft der einzelnen (potentiellen) Teilnehmer im MOTW Rollenspiel, zeigt sich leider auch ein hohes Potential an Bypass-Szenarien. So kann es durchaus sein, dass eine MOTW Markierung versehentlich verloren geht.

Dies gilt insbesondere für den Umgang mit komprimierten Archiven. Je nach verwendeter Software, nimmt diese auf die Vererbung einer etwaig gesetzten MOTW Markierung beim Entpacken eines Archives Rücksicht oder nicht. Die Windows on-board ZIP Implementierung macht es richtig, und die ausgepackten Dateien erhalten die MOTW Markierung des ursprünglichen Archives. Das allseits beliebte 7-zip hingegen hat bis zum letzten Versionsupdate im Mai/Juni 2022 (siehe auch obig erwähnte Versionsabhängigkeit) MOTW komplett ignoriert.

Aber auch das Windows-eigene ZIP kommt schnell an seine Grenzen. Geht man den umgekehrten Weg und packt die gerade entpackten, mit der vom ursprünglichen Archiv geerbten MOTW Markierung versehenen, Dateien in ein neues Archiv, so gehen die Markierungen dabei verloren und das resultierende Archiv ist ebenfalls nicht markiert.

Ähnliches passiert, wenn eine MOTW-markierte Datei auf/über einen Datenträger verschoben/kopiert/transferiert wird, der nicht auf NTFS formatiert ist. Die Markierung geht auf halbem Weg verloren, beziehungsweise entsteht erst gar nicht.

Was bei genauerer Betrachtung dieser Beispiele vielleicht noch teils nachvollziehbar erscheint, verdeutlicht aber dennoch, wie filigran die MOTW Technologie ist. Zu viele Zahnräder müssen erfolgreich in einander greifen, ein Umstand, der von Angreifern natürlich bewusst ausgenützt werden kann.

Game Over, MOTW!

Dass Angreifer jene gerade beschriebene Schwäche von MOTW nicht nur ausnützen können, sondern es effektiv tun, sei an dieser Stelle anhand eines Beispiels, das sich dem zurzeit besonders beliebten ISO Image (.iso Dateien) Ansatz bedient, skizziert.

Worum geht's bei besagtem Ansatz? Angreifer versenden E-Mails (Spams) mit einer .iso-Datei - ein ISO Image - als Attachment. Ein ISO Image ist nichts anderes als ein virtuelles Abbild einer CD/DVD, das weitere Dateien (wie eben eine echte CD/DVD) enthalten kann. Der Empfänger, zumindest so das Kalkül der Angreifer, das sich leider nur allzu oft erfüllt, speichert das Attachment zur weiteren Begutachtung auf einem lokalen Datenträger oder öffnet dieses, sofern vom verwendeten E-Mail Client unterstützt, direkt (was im Hintergrund letzten Endes wiederum zu einem, wenn auch temporären, Zwischenspeichern auf dem Datenträger führt). Wird diese Datei nun ausgeführt, manuell über den Windows Explorer oder implizit (durch das direkte Öffnen), so wird diese virtuelle CD/DVD vollwertig verbunden (gemountet). In Abhängigkeit vom verwendeten E-Mail Client wurde beim Wegschreiben des Attachments auf den Datenträger eventuell auch eine MOTW Markierung gesetzt. Gehen wir mal vom Best-Case aus, das heißt, die MOTW Markierung wurde gesetzt und die Datei manuell mit dem Windows Explorer geöffnet. Unter dieser Voraussetzung wird das erwähnte Mounting nicht automatisch in Eigenregie ausgeführt, sondern der Benutzer wird zuvor noch wegen der *externen Abstammung* der Datei nach einer Bestätigung gefragt (siehe Abbildung).

Nehmen wir an, diese Bestätigung wurde erteilt, wie geht es nun weiter? Da das ISO Image jetzt erfolgreich gemountet wurde, wird dessen Inhalt im Windows Explorer normal angezeigt, das heißt, die enthaltenen Dateien, beziehungsweise nur eine, die dem Angreifer grundsätzlich ja schon reicht. Diese Datei kann jetzt alles sein, ein Office Dokument mit integriertem Makro oder aber auch eine direkt ausführbare Datei. Aus der Perspektiv der MOTW Thematik betrachtet, muss dieses Szenario nun nicht mehr weitergesponnen werden, es verhält sich so, als gäbe es MOTW nicht.

Wie kommt es dazu, dass uns MOTW in diesem Fall so im Regen stehen lässt? Wie bereits zuvor einmal erwähnt, handelt es sich bei einem ISO Image um ein virtuelles Abbild einer CD/DVD. Eine CD/DVD enthält Dateien, also braucht es auch ein Filesystem, das diese Dateien verwaltet. Bei diesem Filesystem handelt es sich allerdings nicht um NTFS, was aber wiederum Voraussetzung für MOTW wäre. Die enthaltenen Dateien tanzen damit aus Sicht eines Angreifers erfolgreich aus der MOTW Reihe. Insofern ist diese Situation auch mit Archiven vergleichbar, die beim Entpacken eine etwaige MOTW Markierung nicht weitervererben (siehe auch weiter oben).

Fazit

MOTW ist ein Paradebeispiel dafür, dass eine an sich geniale Idee und dessen Umsetzung dennoch (oder gerade deswegen?) an der Diversität und Disziplin aller Beteiligten scheitern kann. Dennoch sei hier unbestritten festgehalten: MOTW ist eine wichtige und wertvolle Technologie, die schon vielen Usern, gerade unter Verwendung von Mainstream Software, gröbere Probleme/eine Infektion mit Malware erspart hat. Analog zu vielen anderen Verteidigungsansätzen, legt auch diese am Ende des Tages die Latte für einen Angreifer (nur) wieder etwas höher.

Quellen

- https://nolongerset.com/mark-of-the-web-details/
- https://textslashplain.com/2016/04/04/downloads-and-the-mark-of-the-web/
- https://office-watch.com/2022/inside-the-office-vba-motw-changes/
- https://blog.actorsfit.com/a?ID=01650-2b32beec-b371-45a9-9ecb-1aee69b9314c
- https://outflank.nl/blog/2020/03/30/mark-of-the-web-from-a-red-teams-perspective/
- https://www.bleepingcomputer.com/news/microsoft/7-zip-now-supports-windows-mark-of-the-web-security-feature/
- https://en.wikipedia.org/wiki/Optical_disc_image
- https://malicious.link/post/2022/blocking-iso-mounting/
- https://threatpost.com/threat-pivot-microsofts-macro/180319/

Sicherheitslücken - jetzt auch in deiner Appliance

CERT.at — Mon, 22 Aug 2022 14:28:03 GMT+0100

Die Entwickler des quelloffenen Frameworks YARA haben vor knapp zwei Wochen fast schon heimlich still und leise eine neue Version veröffentlicht, v4.2.3, welche in der medialen Berichterstattung beinahe untergegangen ist.

Grundsätzlich ist eine neue Softwareversion zwar nichts ungewöhnliches, aber wenn sich in den Patchnotes folgende Zeile befindet tendiere ich doch zur leichten bis mittleren Unruhe:

BUGFIX: Fix security issue that can lead to arbitrary code execution

Bei dem Bugfix handelt es sich um eine Veränderung in libyara/exec.c. Ich bin so weit von der Rolle eines C-Programmierers (oder irgendeines Programmierers, was das anbelangt) weg, wie man sich nur vorstellen kann. Aber sogar ich traue mich mit relativer Gewissheit zu sagen, dass ein potentiell korrumpierter Stack in einem wichtigen Bestandteil der C/C++-API von YARA eine wirklich hässliche Sache ist.

Auf den ersten Blick lässt sich das Problem wohl trivial lösen, wenn man die aktualisierte Version verwendet ist man auf der sicheren Seite. Das Einspielen eines Updates ist für mich als Analyst nicht unbedingt die größte aller Herausforderungen.

Aber: YARA kommt wohl, auf die eine oder andere Art und Weise, im Großteil der Sandboxen, Antivirenlösungen und sonstigen Sicherheitsapplikationen, sowohl kommerziell als auch quelloffen, zum Einsatz. In vielen Produkten oder Lösungen ist es sogar ein integraler, tief im System verankerter Bestandteil. Das Einspielen einer neuen Version ist hier oft zeitaufwendig, manchmal komplex, und unter Umständen sogar ein Großprojekt. Was bedeutet, dass es in vielen Fällen eine lange Zeit dauern wird bis diese Sicherheitslücke geschlossen wird.

Mir ist bewusst, dass das nicht notwendigerweise ein Weltuntergang ist. Ohne größere Teile des Quellcodes der Software ausführlich durchgearbeitet zu haben kann ich nicht vertrauenswürdig beurteilen, wie trivial eine Ausnutzung der Schwachstelle ist, oder wie zuverlässig sich damit Codeausführung erreichen lassen würde (beispielsweise durch ein Sample, dass sich gezielt gegen meine Sandbox richtet).

Es ist aber dennoch eine subtil unangenehme Erinnerung daran, wie komplex moderne IT-Infrastruktur ist - und wie komplex wiederum die Systeme, die diese schützen sollen, ebenfalls sind. Mit allen Problemen die mit dieser Tatsache einhergehen.

Los VMware, noch einmal!

CERT.at — Thu, 11 Aug 2022 11:58:21 GMT+0100

In den Monaten April und Mai dieses Jahres veröffentlichte VMware zwei Security Advisories (VMSA-2022-0011 & VMSA-2022-0014) zu schwerwiegenden Sicherheitslücken in mehreren Produkten, zu denen teilweise bereits Patches zur Verfügung standen.

Besagte Sicherheitsaktualisierungen wurden daraufhin von verschiedenen Bedrohungsakteuren untersucht und dienten als Basis für erste Exploits, welche wiederum bereits binnen 48 Stunden nach dem Erscheinen der Advisories genutzt wurden um großflächig Systeme zu kompromitieren

Laut verschiedensten Berichten dauert die Ausnutzung dieser Schwachstellen auch Monate nach der Erstveröffentlichung noch weiter an - und nun konnten die Angreifer:innen ihr Arsenal um zwei weitere Sicherheitslücken erweitern.

Konkret handelt es sich hierbei um die Schwachstellen mit den CVE-Nummern 2022-31656 und 2022-31659. Die Ausnutzung Ersterer würde Angreifer:innen die entfernte Ausführung von Code erlauben, Letztere macht eine vollständige Umgehung der Authentifizierungs- und Autorisierungsmechanismen von mehreren VMware-Produkten möglich.

In beiden Fällen ist nichts weiter notwendig als die Möglichkeit ein verwundbares System über das Netzwerk zu erreichen. Diesmal waren für die Angreifer:innen anscheinend nicht einmal Patches zur Inspiration notwendig, laut VMWare selbst ist Code zur Ausnutzung der Schwachstelle bereits öffentlich verfügbar und wird auch eingesetzt.

Dementsprechend sei hier mit absolutem Nachdruck empfohlen, die verfügbaren Sicherheitsaktualisierungen schnellstmöglich einzuspielen. Auch sei an dieser Stelle nochmals auf die Empfehlungen aus unserem letzten Blogbeitrag zu der Thematik hingewiesen:

Management-Interfaces jedweder Art sollten unter keinen Umständen ungeschützt direkt aus dem Internet erreichbar sein - oder auch nur ungehindert von jedem Endpoint innerhalb des eigenen Netzwerkes.
Für den Fall, dass eine unbedingte betriebliche Notwendigkeit besteht, dass diese über das Internet erreichbar sind, sollte diese Notwendigkeit nochmals genauestens geprüft werden.
Sollte danach die Notwendigkeit weiterhin bestehen sollte der Zugriff zumindest über eine gesonderte VPN-Verbindung und/oder einen besonders gesicherten Jumphost erfolgen und jegliche anderen Zugriffe auf Netzwerkebene blockiert werden - schon einfache Filterlisten sind ein erster Schritt.

Sicherheitslücken in Management Interfaces

CERT.at — Wed, 11 May 2022 15:12:18 GMT+0100

Ob von HP, Sophos, Palo Alto, VMware, SonicWall oder wie zuletzt auch F5 - Sicherheitslücken in Management Interfaces sind an sich lästig genug, der Spaß (zumindest für Angreifer:innen) geht aber erst richtig los, wenn diese Management Interfaces aus dem öffentlichen Internet erreichbar sind.

Wir alle kennen die Situation, man ist sowieso im Dauerstress, irgendetwas ist vermeintlich dringend und wichtig und plötzlich sieht die bequemere Lösung weitaus verlockender aus als die richtige und sichere (a.k.a. "Es wird schon nichts sein" oder "Unser externer Vendor muss aber auch zugreifen"). Unter Umständen hat man sich somit selbst wider besseres Wissen eine Sicherheitslücke geschaffen, die für sich genommen erstmal gar nicht so schlimm gewesen wäre. Was anfangs gerade mal für Lateral Movement getaugt hätte, ist jetzt eine ausgewachsene Unauthenticated RCE auf dem Management Interface. Sollte der schlimmste Fall tatsächlich eintreten, stellt sich alsbald die Erkenntnis (a.k.a. "Oh sh*t") ein, dass man sich damit keinen großen Gefallen getan hat.

Positiv zu erwähnen ist, dass wir im jüngsten Fall (RCE in F5 BIG-IP Management Interface) mit Shodan keine einzige verwundbare Instanz in Österreich finden konnten - wir hoffen, dass dies ein genereller Trend im Umgang mit extern erreichbaren Management-Schnittstellen ist.

Nochmal zur Erinnerung:

* Management Interfaces haben im öffentlichen Internet nichts verloren. Das ist Software, Software ist voller Fehler. Nur weil man bis jetzt vielleicht keine Fehler gefunden hat, heißt das nicht, dass es keine gibt (Hint: Es gibt sie).
* Falls ein Zugriff von außen unbedingt erforderlich ist, sollte dieser nach Möglichkeit über ein gesondertes VPN oder einen Jumphost erfolgen.
* Selbst simple IP-adressbasierte Paketfilter vor dem Interface helfen bereits.

Neuer Shadowserver-Feed: DDoS Middleboxes

CERT.at — Tue, 26 Apr 2022 11:57:48 GMT+0100

Wir bekommen von Shadowserver seit 2022-04-26 Daten zu Middleboxes (Firewalls, Intrusion Detection Systems, Deep Packet Inspection Gateways, etc.), die sich für DDoS Angriffe mit mitunter hohem Verstärkungsfaktor missbrauchen lassen. Der Feed ist in unseren Aussendungen als shadowserver-vulnerable-ddos-middlebox gekennzeichnet, ein entsprechender Link führt zu weiteren Informationen.

An dieser Stelle möchte ich die hervorragende Arbeit von Shadowserver hervorheben, ohne die unsere Tätigkeit bei CERT.at weitaus mühsamer wäre. Wer also noch ein paar Euros auf der hohen Kante hat und diese in etwas Sinnvolles investieren möchte, von dem die gesamte IT-Security Community profitiert, dem kann ich eine Spende an die Shadowserver Foundation ans Herz legen.