Ransomware-Angriffe sind eine hässliche Sache. Mit einem in meinen Augen zu niedrig geschätzten Umsatz von 602 Mio. USD erzielt (PDF, S. 38) hat die organisierte Kriminalität ein neues, lukratives Geschäftsfeld mit relativ geringem Risiko entdeckt. Ich gehe also davon aus, dass Ransomware-Angriffe eher zunehmen. Gleichzeitig sind Abwehrtechniken recht hilflose Versuche, dem ganzen entgegenzutreten. Es folgt: Eine Gedankensammlung zum Thema.

1. Da sind keine Amateure am Werk

Die Conti-Leaks legen nahe, dass so eine Ransomware-Gang extrem professionell reagiert und über erhebliche finanzielle Mittel¹ verfügt. Es wird also Zeit, sich von dem Bild des Hoodie-tragenden Hackers zu verabschieden, der im Alleingang ein Unternehmen erpresst. Die Strukturen ähneln eher (agilen) Konzernen, die es schaffen, sich permanent an veränderte Rahmenbedingungen anzupassen. Die Opfer-Organisationen hingegen hinken der organisierten Kriminalität deutlich hinterher. Zeit also, um einmal grundsätzlich über das eigene Handeln nachzudenken und agiler auf externe Bedrohungen wie Ransomware-Angriffe zu reagieren.

2. Ransomware lohnt sich

Die geschätzten Umsatzzahlen der Ransomware-Branche — so unterschiedlich sie auch sein mögen — liefern einen soliden Hinweis auf die Profitabilität des Ransomware-Geschäfts. Wenn also ein hoher Ertrag bei geringem Geschäftsrisiko und relativ wenig Investment möglich ist: Warum sollte die organisierte Kriminalität derartige Unterfangen einstellen? Im Gegenteil, die rationale Entscheidung ist, das Geschäftsfeld “Ransomware” weiter wachsen zu lassen². Dieses Wachstum ist in vollem Gang, die finanziellen und organisatorischen Ressourcen der Ransomware-Erpresser dürften weit größer sein als diejenigen der IT-Abteilung der erpressten Organisationen.

3. Die Angriffe sind Hausmannskost

Eine profitorientierte Ransomware-Operation muss auch auf die Kostenseite schauen. Daher haben (gefühlte) 99 Prozent der Ransomware-Angriffe ihren Ursprung nicht in einer krassen, bislang unentdeckten Sicherheitslücke. Der hohe Marktwert derartiger Lücken macht deren Einsatz schlicht unrentabel. Stattdessen setzen Ransomware-Gangs auf Hausmannskost: Social Engineering-Angriffe, wie Phishing, führen zu einem ersten Zugang zur Opferorganisation. Von dort aus breiten sich die Angreifer über bekannte Softwareschwachstellen oder auch schlicht Fehlkonfigurationen aus, bis schließlich die Verschlüsselung beginnt³.

Die eigentliche Ursache für Angriffe liegt also in bekannten Schwachstellen und Fehlkonfigurationen. Bei den meisten Ransomware-Erpressungen werden daher auch die üblichen Verdächtigen angegriffen: Windows, Office und später Active Directory. Gerade letzteres ist, aufgrund seiner Komplexität, ein sehr dankbares Ziel für Ransomware-Operationen.

4. Angreifer sind schneller als Verteidiger

Von der Veröffentlichung einer Sicherheitslücke bis zu den ersten Angriffen vergehen oft nur Stunden. Hat man also z.B. innerhalb der ersten 24 Stunden nach Publikation noch keine Updates installiert, steigt das Risiko erheblich. Insbesondere im Enterprise-Umfeld wird dies zum Problem: Geplante Wartungsfenster verzögern das Einspielen, und ein ungetestetes Einspielen von Sicherheitsupdates führte insbesondere bei Windows-basierten Systemen immer mal wieder zu nicht funktionierenden Systemen. Eine Organisation muss also sorgfältig planen, inwiefern sie Sicherheitsupdates wirklich schnell einspielen kann — oder ob sie vorher lieber die Updates noch einmal in einer Testumgebung auf Herz und Nieren prüft. Letztlich ist es also eine Festlegung der Organisation, wie schnell Updates eingespielt werden, und diese Geschwindigkeit ist oft nicht hoch genug.

Updates sind also extrem wichtig, und gleichzeitig recht schwierig durchzuführen. Diese Konstellation führt oft dazu, dass man mit dem Finger in eine andere Richtung deutet: zum Anwender. Perfide, wie ich finde.

5. Anwender dürfen eben nicht auf Schadsoftware klicken!

Rechts von meiner Tastatur liegt meine Maus. Sie ist dafür gedacht, auf Dinge zu klicken. Leider schafft es die Softwarebranche nicht, Software so robust zu schreiben, dass man gefahrlos auch auf ein Mail-Attachment klicken kann. Da finde ich es perfide, dem Anwender die Schuld zuzuordnen. Anderes Beispiel: Unsichere Passwort-Stores im Browser, aus denen man recht einfach Zugangsdaten auslesen kann. Wenn das ein Problem ist, warum geben wir Anwendern dann diese Möglichkeiten? Gleiches gilt für Makros in Office-Dokumenten. Wie soll denn ein Anwender ein legitimes Makro von einer Malware unterscheiden können?

6. Dann setzen wir auf Virenscanner/Endpoint Protection/…!

Ohne dafür harte Zahlen zu haben: Ich würde einmal davon ausgehen, dass 95 % der Ransomware-Opfer auch Software zum Schutz vor Malware im Einsatz hatten. Seit gut 20 Jahren verfolge ich die Versprechen der Antiviren-Branche, und genauso lange lebe ich ohne Virenscanner recht glücklich. Ich sehe zwei Probleme, die den Sinn von Antivirensoftware ad absurdum führen:

1. Die Ransomware-Erpresser sind nicht doof, im Gegenteil. Die bewegen sich sehr leise auf angegriffenen Systemen, um eben den Virenscanner o.ä. nicht auszulösen. Sie testen ihre Angriffswerkzeuge und Prozeduren, ob sie damit die marktüblichen Virenscanner auslösen. Und sie kaufen auch recht teure “Red Team”-Software ein, die gezielt dafür geschaffen wurde, bei einem Virenscan nicht aufzufallen. Das ist ein permanentes Wettrüsten, und wenn ein neues Tool bessere Verschleierung bietet, wird auch schnell mal gewechselt. Dafür geben die Erpresser auch signifikante Summen aus, und gründen auch einmal ein US-amerikanisches Unternehmen, um das Screening der Verkäufer entsprechender Softwarepakete zu umgehen.
2. Antivirensoftware klinkt sich sehr tief in das Betriebssystem ein, und liefert damit selbst eine Angriffsfläche. Beim SolarWind-Hack wurde eine solche Angriffsfläche gezielt ausgenutzt. SolarWind ist ein Hersteller von Systemmanagement-Software. Die Angreifer haben die Systeme von SolarWind kompromittiert und dann eigene Hintertüren in die Systemmanagement-Software integriert. Diese wurde dann (Cloud sei Dank!) durch SolarWind ausgeliefert und auf allen Kundensystemen installiert. Für die Kunden natürlich besonders blöd, denn diese standen dann plötzlich vor einem kompromittierten Unternehmensnetz.

Das BSI warnt daher auch vor unbedachtem Einsatz von Antivirensoftware:

“Antivirensoftware, einschließlich der damit verbundenen echtzeitfähigen Clouddienste, verfügt über weitreichende Systemberechtigungen und muss systembedingt (zumindest für Aktualisierungen) eine dauerhafte, verschlüsselte und nicht prüfbare Verbindung zu Servern des Herstellers unterhalten. Daher ist Vertrauen in die Zuverlässigkeit und den Eigenschutz eines Herstellers sowie seiner authentischen Handlungsfähigkeit entscheidend für den sicheren Einsatz solcher Systeme. Wenn Zweifel an der Zuverlässigkeit des Herstellers bestehen, birgt Virenschutzsoftware ein besonderes Risiko für eine zu schützende IT-Infrastruktur.”

Aber auch ohne Supply Chain-Angriffe wie z.B. den Solarwind-Hack ist eine Antivirensoftware eben auch nur eine Software, die selbst eine Angriffsfläche bieten kann. So nutzt z.B. eine Variante der Lockbit-Ransomware den Microsoft Defender, um Komponenten via DLL Sideloading in einem kompromittierten Rechner festzusetzen.

7. Zwischenfazit: Software ist unsicher

Halten wir fest: Software ist im Allgemeinen unsicher. Dieses Kernproblem werden wir auf absehbare Zeit auch nicht in den Griff bekommen können, denn dazu existiert einfach zu viel fehlerhafte Software. Vielleicht wird das mit modernen Programmiersprachen wie Rust irgendwann besser, aber darauf können wir nicht warten. Bleibt eigentlich nur, die Angriffsfläche zu reduzieren. Hierfür bieten sich zwei Stellschrauben an:

1. Weniger Software.
2. Diese Software so “sicher” wie möglich betreiben.

Beide Punkte sind, nun ja, erläuterungsbedürftig:

Stellschraube 1: Weniger Software

Wenn Software inhärent unsicher ist, dann müssen wir sicherstellen, dass wir nur möglichst wenig Software vertrauen. Statt also einen separaten Virenscanner zu installieren würde ich einfach auf Bordwerkzeug setzen: Im Falle von Windows leistet der Defender eigentlich genau das gleiche, was andere Produkte auch leisten können. Microsoft müssen wir eh schon vertrauen, daher bietet sich der Einsatz des Defenders an. Wir können auch Software so konfigurieren, dass wir möglichst wenigen Funktionen vertrauen müssen. Beispiel Ausführen von Makros in Office-Dokumenten: Diese Funktion kann man via Gruppenrichtlinie einfach abschalten. Mailanhänge? Diese werden nur noch in einer Sandbox geöffnet⁴. Mobilgeräte sind da übrigens schon einen Schritt weiter: Dort läuft jede App in ihrer eigenen Sandbox, d.h. man muss nur der Sandbox selbst vertrauen.

Stellschraube 2: Software sicher betreiben

Oben schon beschrieben: Updates, Updates, Updates! Diese müssen schneller als bisher eingespielt werden, um neu bekannt gewordene Sicherheitslücken wirklich zeitnah zu schließen. Diese Prozesse müssen etabliert sein und natürlich in die Arbeit der Organisation integriert sein (siehe nächster Punkt!).

Ebenso wichtig ist, Administratoren auch mit hinreichender Arbeitszeit für diese Prozesse auszustatten. Die meisten Administratoren kennen die Schwachstellen ihrer Organisation genau, und meist wissen sie auch, wie diese Defizite zu beheben wären. Sie haben nur schlicht keine Zeit, sich darum zu kümmern. Gerade im Windows-Bereich gibt es viele werksseitigen Stellschrauben, von denen wir kaum welche einsetzen. Auch das BSI liefert fertige Gruppenrichtlinien zum Härten von Windows-Systemen. Ernsthaft: Wer braucht im Alltag schon Makros in Office-Dokumenten? Und wenn man die wirklich einmal braucht, kann man auch auf separate Systemumgebungen ausweichen. Unterschiedliche Projektumgebungen für unterschiedliche Anforderungen sind dank Terminallösungen kein Problem, und via IT-Automation (Ansible & Co.) auch kostengünstig umsetzbar.

Zusätzlich ergibt natürlich auch ein Training der Anwender Sinn. Nicht, weil sie Teil des Problems wären (meine Maus lässt mich ja klicken!). Sondern: weil sie durch bedachtes Klicken Teil der Lösung sein können. Bei relativ geringem Investment kann man so doch einiges an Sicherheitsgewinn herausholen⁵.

8. Intermezzo: Ich muss hier aber auch arbeiten können!

Die IT ist kein Selbstzweck, sondern hat das Ziel, die Arbeit in der Organisation zu unterstützen. Gerade für Universitäten oder Forschungsinstitute bedeutet produktive Arbeit, dass Anwender viel Freiheit im Umgang mit Computern brauchen. Es erscheint mir gerade dort nicht sinnvoll, den Rechnerbetrieb so einzuschränken, dass nur “von der IT freigegebene” Aufgaben mit Computern erfüllt werden können. In einer Forschungsinstitution fällt es schwer, den typischen Anwender zu identifizieren: Vom “naiven” Office-Nutzer über Power-User bis hin zu dezentral administrierten Spezialsystemen gibt es eine große Bandbreite der Nutzungsszenarien. Eine in einem Handelsbetrieb vielleicht sinnvolle Strategie des “Standard-Arbeitsplatzes”, der dem Anwender nur eine handvoll Anwendungen zur Verfügung stellt, ist zumindest im Forschungsbereich nicht denkbar.

Macht den “sicheren Softwarebetrieb” natürlich noch einmal um ein vielfaches schwieriger.

9. Resilienz statt Immunität

Realistisch gesprochen denke ich nicht, dass sich Ransomware-Vorfälle verhindern lassen. Traurig, aber so sehr ich mir auch fehlerfreie Software und perfektes Anwenderverhalten wünsche: Das Aus für Ransomware werden wir auf absehbare Zeit nicht erreichen. Es scheint mir also angebracht, neben einer Verringerung der Angriffsfläche auch auf eine Begrenzung des Schadens bei einem Ransomware-Vorfall hinzuarbeiten. Letztlich ist ja das Risiko eines Ransomware-Befalls auch nur ein Risiko. Genauso, wie eine Organisation mit dem Zahlungsausfall eines Auftraggebers umgehen können muss, so muss sie auch mit einem Ransomware-Angriff klarkommen. Allerdings ist die Schadenshöhe bei einem Ransomware-Vorfall üblicherweise recht hoch bis existenzgefährdend.

Unterm Strich: Immunität gibt es nicht, wir brauchen Resilienz für den Ernstfall. Die ISO/IEC 27005 zerlegt Risiken in zwei Bestandteile: Schadenshöhe und Eintrittswahrscheinlichkeit. Die Eintrittswahrscheinlichkeit kann man durch die beiden Stellschrauben “Weniger Software” und “Software sicher betreiben” reduzieren. Mit einer gewissen Eintrittswahrscheinlichkeit muss man aber trotzdem rechnen. Bleibt also, die Schadenshöhe für diesen Ernstfall so gering wie möglich zu halten. Die folgenden Maßnahmen reduzieren die Schadenshöhe:

1. Weniger Zentralisierung, lieber dezentrale, kleine Einheiten. Statt Teams fürs ganze Unternehmen lieber Jitsi und Mattermost, gerne auch für einzelne Abteilungen oder Arbeitsgruppen. Von der Infrastrukturseite her sollte jeder nur auf das Zugriff haben, auf das er auch tatsächlich Zugriff braucht. Das läuft dem aktuellen Trend der IT, Dinge “in die Cloud” zu verlagern, etwas entgegen. Im Ernstfall ist dann aber nur ein Teil der Organisation betroffen, der Schaden begrenzt.
2. Unterschiedliche Kontexte erfordern auch unterschiedliche Lösungen. Wenn ein Kundenprojekt entsprechend hohe Anforderungen an die Resilienz hat, dann muss man auch die IT-Infrastruktur darauf anpassen und vielleicht eine separierte Umgebung für dieses Kundenprojekt schaffen.
3. Ransomware-resistente Backups vorhalten, als Notanker, falls es trotzdem schiefgeht.
4. Und letztlich: Einen Notfallplan für eine angemessene Krisenreaktion vorhalten.

Wichtig ist aber auch die Resilienz gegen Marketing-Lärm im Kopf der Entscheider. Natürlich versprechen Softwarelieferanten, gegen eine charmante Monatsgebühr pro Anwender, das Risiko eines Ransomware-Angriffs deutlich zu reduzieren. Warum auch nicht, denn effektiv kann man diese Behauptungen ja gar nicht objektiv prüfen. Ich möchte aber lieber dafür werben, die bereits vorhandenen Möglichkeiten erst einmal auszuschöpfen: Office-Makros abschalten kostet zunächst einmal nichts, und die wenigsten Anwender benötigen diese Funktionalität tatsächlich. Oder aber einen gezielten Pentest, um die tatsächlichen Schwachstellen der IT-Infrastruktur zu ermitteln. Richtige Patentrezepte zum Nachkochen habe ich (und andere!) allerdings nicht, und vielleicht ist genau das der wichtigste Punkt. ☐

Änderungshistorie

• 2022-06-30: Arbeit am Artikel begonnen
• 2022-07-11: Initiale Publikation
• 2022-07-19: Verweise hinzugefügt: Heise-Artikel zu Trickbot-Arbeitsweisen, Link zum SiSyPHuS Win10-Projekt des BSI.
• 2022-07-31: Verweis auf Lockbits Nutzung des Microsoft Defender hinzugefügt

Fußnoten

Ähnliche Artikel