Qubes und der Hacker-Vorfall in Berlin

Nachdem das BSI veröffentlicht hat, auf welche Weise die IT-Systeme der Berliner Senatsverwaltung kompromittiert wurden, habe ich, aus purem Jux, einmal das KI-System Gemini Notebook gefragt, ob dieser Hacker-Angriff auch erfolgreich gewesen wäre, wenn dort Qubes statt Windows verwendet worden wäre.

Das Ergebnis war erstaunlich sinnvoll. Es gab eine Analyse, welche Sicherheitsmängel vorhanden waren / sind und wie diese ausgenutzt wurden, um die IT zu kompromittieren. Anschließend wurde dargestellt, weshalb der Angriff unter Qubes gescheitert wäre, und es wurde gleich ein Migrationskonzept hin zu Qubes vorgeschlagen, sogar einschließlich SaltStack-Formeln zur Erzeugung einer sinnvollen Anfangskonfiguration. Ergänzt wurde das Ganze noch durch den Entwurf eines Schulungskonzepts für den allmählichen Umstieg auf Qubes.

Hier ist der von der KI erzeugte und von mir noch etwas redigierte Text:

Rettung Berlins durch Qubes OS.pdf.gz (235.1 KB)

Das sieht dann ja fast so aus, als sei die KI inzwischen schlauer als der Berliner Senat (was vermutlich nicht viel heißt), und man könnte auf die Idee kommen, den Senat durch eine solche KI zu ersetzen. :grinning_face: Viel schlimmer kann es dadurch auch nicht mehr werden.

Daran ist überhaupt gar nichts sinnvoll, da Qubes OS gar nicht für so etwas ausgelegt ist. Qubes OS ist ein OS für einen Nutzer und nicht für mehrere, die auch noch in großem Stil administriert werden müssen. Mit viel gutem Willen kann man es für mehrere Nutzer verwenden, die sich gegenseitig zu 100% vertrauen, das ist aber weder bei Firmen noch bei Verwaltungen der Fall.

Das kann die KI-Analyse gar nicht wissen, da die Sicherheitsmängel und vorhandenen Maßnahmen nicht öffentlich sind. Es ist nur ein grober Ablauf des Angriffs öffentlich skizziert worden. Wenn ich spekulieren würde, würde ich wetten, dass die vorhanden Fähigkeiten, die Windows (teilweise optional) bietet, einfach nicht hinreichend eingesetzt worden sind.

Die Sicherheitsmängel wurden vom Bundesrechnungshof veröffentlicht und die KI bezieht sich darauf.

Mit entsprechender Konfiguration lässt sich Qubes durchaus in einer Organisation verteilen, zumindest für die kritischen Bereiche. Voraussetzung ist allerdings, dass man sich um fähige Administratoren kümmert - und das geht bei Behörden nicht.

Quelle?

Eine steht mal hier. Ist zwar BSI und nicht Rechnungshof, aber der “Tathergang” wird als “rekonstruiert” angenommen.

Wenn Du Dir das Elend in vollem Umfang geben willst …

https://www.youtube.com/watch?v=KVLhj4F97pc [Berlin schiebt leider alle Streams auf YouTube; mir ist keine bessere Alternative bekannt.]

[Aber sei gewarnt. Informierte Teile der Öffentlichkeit könnten die Ausführungen als verstörend empfinden.]

Es geht nicht um den Tathergang, sondern um:

und das wird in dem von dir genannten Dokument überhaupt nicht diskutiert.

Wird Sicherheitsmängel und vorhandene Maßnahmen überhaupt technisch ausführlich diskutiert, oder verschwende ich damit weitere 3 Stunden meiner Lebenszeit, genau wie mit dem ganzen Thread hier?

Was Deinen “Anforderungen” entspricht, wirst Du beurteilen müssen. Ich empfehle als Teaser die 2min ab 3:03:10.

Die Vektor-Kette war offensichtlich Phishing → Fake-Captcha → Terminal-Befehl/PowerShell.

Da hätte Qubes als Workstation-Umgebung etwas verhindert. (Auch wenn ich nicht glaube, dass so etwas im ÖD in D implementierbar wäre.)

Eine TCB-Map von den angeblich 45.000 Maschinen (wie da wer was gezählt hat, weiß ich nicht) oder einen IncidentReport mit RootCauseAnalysis habe ich leider nicht parat.

Vollkommen nichts-sagend.

Was soll ich damit? Das ist keine technische Analyse und von 2024.

Lesen - ab Seite 149

Darf ich fragen, was Du erwartest? Du scheinst ja schon irrig davon auszugehen, dass QubesOS als “multi user OS” erforderlich sein sollte. (Das ist zwar in einem gewissen Rahmen möglich, aber für den hier angenommenen Fall nicht erforderlich.)

Der Angriffsvektor war eine einzelne Workstation eines einzelnen Mitarbeiters. @GWeck geht davon aus, dass ein Arbeitsplatz mit Qubes OS als Client die Vektor-Kette unterbrochen hätte.

Qubes hätte die Kette technisch unterbrochen.

Selbst wenn das mit Windows durch eine geeignete Konfiguration möglich gewesen wäre, hätte das in Berlin nicht funktioniert, weil die dortigen Strukturen der IT-Sicherheitsverwaltung dafür gesorgt hätten, dass die notwendigen Sicherheitsmaßnahmen nicht durchgängig umgesetzt worden wären. Das wird in diesem Dokument sehr deutlich.

Ich würde auch einmal empfehlen, die angesprochenen Bausteine des Grundschutz-Kompendiums zu lesen. Mit einer Strukturierung des IT-Betriebs nach dem GSK wäre es übrigens auch durchaus möglich, Qubes so einzusetzen, dass es in einer Behörde funktioniert. Wenn diese Behörde aber nicht in der Lage ist, Grundschutz zu realisieren, ist sowieso Hopfen und Malz verloren.

Noch einmal, das ist keine technische Analyse und absolut nicht ausreichend um die bisherigen Sicherheitsmaßnahmen zu bewerten.

Qubes OS wäre überhaupt nicht geeignet gewesen. Du baust ein Luftschloss aufgrund einer KI-Analyse, die wiederum auf völlig unzureichenden Informationen beruht.

Ich kann nur noch einmal empfehlen, die Dokumente zu lesen und, zumindest ansatzweise, zu versuchen, sie auch zu verstehen. Dazu gehört übrigens auch die technische Dokumentation von Qubes, die bei der Analyse verwendet wurde. Die KI hat hier also keine Luftschlösser gebaut, sondern sich auf die technischen Grundlagen bezogen.

Technische Sicherheitsmaßnahmen, die aufgrund unzureichender Organisation nicht umgesetzt werden, sind absolut wirkungslos. Und der Bericht des Rechnungshofes legt im Detail dar, dass die IT-Sicherheit hier nicht nur unzureichend, sondern im Wesentlichen überhaupt nicht vorhanden war / ist. Es ist also müßig, überhaupt über technische Maßnahmen zu spekulieren.

Inzwischen hat die KI den Angriff und die Nutzung auch ganz schön in ein paar Bildchen dargestellt, aus denen ich dann das Folgende manuell erzeugt habe:

Just for fun …