© Daniel Jedzura, 123RF

Wie reagieren Unternehmen auf einen IT-Einbruch, um den Schaden klein zu halten? Das erklärt der Artikel anhand von Ratschlägen des BSI. Und er zeigt auch: Wer vorsorgt, hat’s nachher leichter.

Immerhin 58 Prozent der Unternehmen in Deutschland haben Notfallpläne beziehungsweise Störfallanweisungen für den Fall eines Hackerangriffs in der Schublade. Das berichtete [1] das Bundesamt für Sicherheit in der Informationstechnik (BSI) Anfang Oktober 2018.

Unter dem Titel “Die Lage der IT-Sicherheit in Deutschland 2018” (Abbildung 1) publizierte die Behörde auf 100 Seiten einen Überblick, aber auch zahlreiche lesenswerte Details, über Art, Qualität und Abwehr von ausgewählten Hackerangriffen. Der Berichtszeitraum erstreckt sich bis Mai 2018.

Abbildung 1: Auf 100 Seiten berichtet das BSI über “Die Lage der IT-Sicherheit in Deutschland 2018”.

Nach den Neuerungen des IT-Sicherheitsgesetzes müssen Betreiber so genannter kritischer Infrastrukturen diverse Angriffe und Hacks melden. In der Folge habe die “Zentrale Meldestelle und Nationales IT-Lagezentrum” im Jahr 2017 genau 157 so genannte SOFORT-Meldungen erhalten, das BSI seinerseits 145 so genannte KRITIS-Meldungen (siehe Kasten “KRITIS und SOFORT”).

Abbildung 2: Meldekriterien für IT-Störungen laut BSI.

Doch Angriffe und Malware-Befall betreffen meist nicht nur kritische Infrastrukturen, sondern auch gewöhnliche Unternehmen. Auf solche lassen sich die meisten BSI-Regeln problemlos übertragen, selbst wenn sie nur vergleichsweise wenige Mitarbeiter beschäftigen.

Die Lage

Tendenziell nehmen in Deutschland Distributed-Denial-of-Service-Angriffe (kurz DDoS) ab, während Ransomware-Attacken zunehmen. “Vor allem die finanziellen Folgen durch Produktionsausfälle, Beschädigungen des Maschinenparks, Patentdiebstahl oder Cyber-Erpressung” machen laut BSI erhöhte IT-Sicherheitsvorkehrungen notwendig. Die meisten Meldungen stammen aus dem Bereich IT und Telekommunikation, an zweiter Stelle steht der Energiesektor.

Die erwähnten 58 Prozent von Unternehmen mit Notfallplänen betrachtet das BSI als direkte Konsequenz aus der Bedrohungslage. Hier rangieren neben Zwischenfällen mit den Betriebssystemen Anwender-nahe Problemfälle auf den vorderen Plätzen (Abbildung 3).

Abbildung 3: Adobe Flash, der Linux-Kernel, OS X, Windows, der Internet Explorer und MS Office erreichten die höchste Anzahl an CVE-Einträgen im Jahr 2017, so berichtet das BSI.

Die Angst vor “einer schwerwiegenden Betriebsstörung” und möglichen Schäden, welche eine damit einhergehende Wiederherstellung aufdeckt oder gar erst verursacht (beispielsweise durch ein unsachgemäßes Restore veralteter Backups) treiben das Sicherheitsbewusstsein der Admins an. Denn die Gefahr, dass Angreifer über Browserlücken, Flash-Plugins, MS-Office-Makros, PDFs oder unsichere Geräte die eigene Firma erfolgreich attackieren, ist realistisch.

Unterschiede gebe es vor allem bezüglich der Unternehmensgröße, weiß das BSI: “Während zwei von drei großen Unternehmen über eine Notfallrichtlinie verfügen, traf dies nur auf gut jedes zweite kleine oder mittlere Unternehmen zu.” Und weiter: “Adäquate und aktuelle Notfallpläne sind eine besonders wichtige Maßnahme zur Erhöhung des Sicherheitsniveaus.”

Gerade der Faktor Resilienz, der bestimmt, wie gut eine Firmen-IT gegen Angriffe gewappnet ist, dürfte künftig wichtiger werden. Das BSI sieht Vorfalltrainings in großen wie auch kleinen Unternehmen auf dem Vormarsch. Auch andere Experten sehen gute Vorbereitung und Erfahrung im Krisenfall als den Schlüsselfaktor bei Angriffen.

Diese Erkenntnis muss sich vielerorts noch durchsetzen. Ausfallszenarien trainieren lehnen viele IT-Abteilungen mit Hinweis auf Zeitmangel oder ihre Prioritäten ab. Abgeklärte Admins witzeln daher, dass nichts das Management so gut überzeuge wie ein Ernstfall.

Beispiel 1: Neulich, beim Provider

Am besten kommen Firmen mit Angriffen und ihren Folgen klar, die regelmäßig unter solchen leiden. Der Grund: Sie sind in der Regel vorbereitet. Zu dieser Gruppe von Unternehmen gehören zum Beispiel Betreiber von Rechenzentren. Wie diese mit einem Einbruch umgehen, durfte der Autor als Betreiber eines Rootservers mehrmals erleben.

Zunächst informierte ihn eine automatisch versendete E-Mail, dass das Intrusion Detection System (IDS) des Rechenzentrums Alarm geschlagen habe. “Aus Ihrem Netzwerk wurde ein TCP-Scan auf die Infrastruktur unseres Rechenzentrums ausgeführt”, steht in der beunruhigenden Nachricht. In der Folge stellte das Rechenzentrum den Server unter Quarantäne.

Der Autor betreibt einen Cloudhost mit bis zu zehn virtuellen Maschinen. Die erledigen alles, was ein KMU so braucht: VPN, IMAP, Groupware, private Cloud, Chatserver und einiges mehr. Der Großteil der VMs besteht jedoch aus geklonten Images für Trainingszwecke, weil der Autor Open-VPN-Kurse anbietet.

Diese Maschinen stehen den Teilnehmern auch noch einige Wochen nach dem Kurs zur Verfügung – als VPN-Server mit vollem Rootzugriff und ohne zeitliche oder Volumenbeschränkung. Immer wieder kommt es aber vor, dass auf diesen Maschinen ein schlecht gewähltes Passwort oder ein falsch konfigurierter Dienst als Einfallstor für Einbrecher dient.

Wie aber erreicht der Betreiber seinen Server, wenn der Provider dessen Internetadresse sperrt? Beim Hosting-Provider Hetzner darf der Admin über das Support-Webfrontend den Zugang für eine Quell-IP für einige Stunden freischalten. Das geht auch mehrfach nacheinander. Ein kurzer Bericht an den Support, der die Details der Analyse und die getroffenen Maßnahmen schildert, führt (falls er überzeugt) dazu, dass Hetzner das Subnetz wieder freischaltet. Es ist dann also wieder von außen erreichbar.

Im vorliegenden Fall musste der Serverbetreiber klären, ob einer seiner Produktivserver oder eine der Schulungsinstanzen die Sperre ausgelöst hat. Zum Glück lieferte die Mail vom Hoster auch gleich die Quell-IP des Systems mit, das den Scan initiiert hatte. Ein schneller Abgleich zeigte: Schuld war einer der Trainingsrechner.

Ein Blick in die Shell-Historie bestätigte den Verdacht: Dort fand sich ein Nmap-Eintrag, der anstelle des eingerichteten VPN das gesamte Netzwerk (und damit auch andere Systeme des Providers) scannte. Weil die VPN-Schulung bereits einige Tage zurücklag, ließ sich der Rechner schnell ausschalten – Problem gelöst. (Fun Fact am Rande: Anspruchsvolle Hacker geben Shellbefehle gern mit einem Leerzeichen am Zeilenanfang ein – so tauchen diese gar nicht in der Historie auf. Dann würden nur die Firewall-Logs den Scan des Admin enttarnen.)

Drei weitere Schritte ließen sich im Nachhinein optional ergänzen: Der Serverbetreiber könnte eine E-Mail an den Kursteilnehmer schicken, das VM-Image für weitere Analysen sichern, die virtuelle Maschine ohne eine Netzwerkverbindung neu starten und eine Live-Analyse des laufenden Systems anstoßen. Je nach dem zu erwartenden Schaden darf der Admin selbst entscheiden, wie viel Zeit er investieren möchte.

Dem Hoster reichte aber die Information “Schwaches Passwort oder durch Teilnehmer initiierter, falsch konfigurierter TCP-Scan auf Schulungsrechner, virtuelle Maschine dauerhaft deaktiviert” – und nach wenigen Minuten war das Subnetz wieder online.

Ein anderer namhafter Hoster wusste auf Nachfrage des Linux-Magazins Ähnliches zu berichten. Meist seien hier ungepflegte WordPress-, Joomla- oder Typo3-Instanzen die Ursache für ungewöhnliche Aktivitäten im Netzwerk.

In diesem Fall sucht der Administrator bei einer Amok laufenden Maschine gewöhnlich ein paar Schadskripte für den Kunden heraus. Anschließend sichert er dessen Dateien, löscht die zugehörigen Verzeichnisse und gibt die Daten an das hauseigene Abuse-Team weiter. Das kontaktiert dann den Kunden.

Die richtigen Fragen

Nicht immer läuft all das so glimpflich ab. Doch das Beispiel skizziert bereits viele Vorgehensweisen, die Experten als Ratschläge für Hacking-Opfer anführen. Anders als viele denken spielt die Attributierung, also das Lösen der Frage “Wer war es”, meist eine eher untergeordnete Rolle (siehe Kasten “Attribution”). Denn die nimmt die meiste Zeit in Anspruch, verspricht aber keinen angemessenen Erfolg. Viel wichtiger ist es für die Systembetreiber, alle kompromittierten und bösartig agierenden Systeme so schnell wie möglich zu deaktivieren und zu isolieren.

Den aktuellen Zustand gerichtsfest zu sichern, ergibt Sinn, wenn eine Straftat zu vermuten ist. Die Sicherung lässt sich kopieren oder klonen und später isoliert in einer Sandbox analysieren.

Bei der Analyse dieser Images sollte aber das “Wie?” im Vordergrund stehen, vor dem “Wer?” oder “Woher?”. “Welche Lücke hat der Angreifer ausgenutzt? Lässt sie sich schließen und wie genau?” lauten die Fragen, die Priorität verdienen. Sie sollen auch verhindern, dass der Angreifer erneut Zugang erhält.

Vom Netz damit, so schnell es geht!

Kompromittierte Systeme vom Netz nehmen und die Angreifer aussperren, das besitzt auch laut BSI Priorität. Allerdings ist das eher graue Theorie: Obwohl 97 Prozent der Internetnutzer in Deutschland bei Umfragen der IT-Sicherheit größte Bedeutung beimessen, informiert sich nur jeder Dritte tatsächlich regelmäßig zum Thema. Ein sicherheitsbewusstes Verhalten ist das nicht – gute Zeiten für Hacker und viel Nachholbedarf. In Unternehmen schaut es ein wenig besser aus (Abbildung 4).

Abbildung 4: Sicherheitsmaßnahmen rund um Netzwerkabsicherung, Antivirus und organisatorische Maßnahmen liegen auf Platz 1 bis 3 in Unternehmen.

Beispiel 2: Memcached

Das BSI dient oft als Anlaufstelle, wenn es um konkrete Hilfestellung bei neuen, über CERT-Bund veröffentlichten Sicherheitswarnungen [7] geht. Die Behörde stellt auch für Linux-Admins Gegenstrategien als Howtos bereit [8].

Schon im Februar 2018 berichtete das Institut beispielsweise, wie Admins die Memcached-UDP-Lücke in Linux schließen. “Alle großen deutschen Hosting-Anbieter haben zügig reagiert, sodass die Anzahl der für Angriffe in Deutschland ausnutzbaren Memcached-Instanzen von anfänglich über 2700 auf unter 130 (Stand 31. Mai 2018) geschrumpft ist. Entwarnung kann dennoch nicht gegeben werden, da weltweit noch zahlreiche Instanzen verfügbar sind und weiterhin für Angriffe genutzt werden”, weiß man heute zu berichten.

Admins, die jetzt “Hoppla – war da was?” denken und vermuten, dass ihre Server zu den genannten fünf Prozent gehören, finden in Listing 1 den vom BSI empfohlenen Test, um betroffene Server zu identifizieren [9]. Gibt ein mit Netcat so getestetes System eine ähnliche Antwort, sollte der Admin schnellstens den Rat befolgen, UDP in der Memcached-Konfiguration zu schließen und seine Firewallregeln anzupassen. Nur in Ausnahmefällen muss ein Memcache-Dienst übers Netzwerk erreichbar sein.

01 $ echo "stats" | netcat 192.168.45.67 11211
02 STAT pid 1090
03 STAT uptime 1808125
04 STAT time 1483622758
05 STAT version 1.4.14 (Ubuntu)
06 STAT libevent 2.0.21-stable
07 STAT pointer_size 64
08 STAT rusage_user 57.424253
09 STAT rusage_system 54.322505
10 STAT curr_connections 5
11 STAT total_connections 643
12 STAT connection_structures 9
13 STAT reserved_fds 20

Der Jahresbericht des BSI ist auch eine gute Quelle, um sich über Auswirkungen von Malware zu informieren. Zum Beispiel seien die Nachwirkungen des IoT-Botnetzes Avalanche, das im Jahr 2016 für Ärger sorgte, immer noch spürbar: “In Deutschland haben sich die festgestellten Infektionszahlen nach einem Jahr um 61 Prozent reduziert, was verglichen mit der weltweiten Entwicklung – einer Reduzierung um 45 Prozent – ein großer Erfolg ist”, erklärt Seite 31 von [1].

Backups gegen Ransomware

Ransomware verschlüsselt wichtige Daten und erpresst dann die Opfer, diese erst nach dem Überweisen von x Bitcoin wieder zugänglich zu machen. Sie ist heute so verbreitet, dass es scheinbar sogar lukrativ ist, Spam-Mails mit fiktiven Ransomware-Behauptungen zu versenden. Bevor Admins bei solchen Mails aktiv werden, sollten sie also einen Blick in die Header riskieren.

Wer eine gute Backupstrategie hat, braucht zwar keine Datenverluste durch Ransomware zu befürchten – wohl aber die verlorene Zeit beim Neu-Einrichten des Systems und Schließen des Einfallstors. Als gute Strategie gilt ein regelmäßiges und ausgelagertes Backup, inklusive Tests der Wiederherstellbarkeit (Restore). Die Verbindung zum Backupmedium darf keinesfalls permanent bestehen, andernfalls könnte die Ransomware auch das Backup verschlüsseln.

Abbildung 5: Ein Managementsystem wie IGELs Universal Management Suite und so genannte Buddy Updates schaffen schnell ein frisches Linux auf Thin Clients.

Schutz vor derartiger Spam-Malware bieten ohnehin nur ein Training der Anwender, Aufklärung und Vorbereitung auf den Ernstfall. Dann ist im Falle eines erfolgreichen Hacks auch das Prozedere klar: Neu installieren, Sicherheitsupdates und Patches einspielen, Backup wiederherstellen. Bei derart automatisierten Hacks spielt die Frage nach dem Urheber ohnehin nur eine untergeordnete Rolle.

Vorbereitung ist alles: Monitoring und IDS

Um Angriffe schon im Vorfeld zu verhindern, sind auch jene Aufgaben wichtig, die im Beispiel 1 der Provider implizit übernommen hat: Monitoring und Intrusion Detection. Auch das BSI erwähnt diese Maßnahmen explizit.

Weitere betreffen den OSI-Layer 8, also den User vor dem Bildschirm [10]. Ihn sollen nicht nur strenge Passwortrichtlinien erziehen. Admins sollen seinen Fernzugriff aufs absolute Minimum einschränken und die “verwendete Serversoftware einem besonders intensiven Monitoring in Bezug auf ihre Schwachstellen und Exposition” unterziehen.

Jeder Hack stellt zugleich einen Anlass dar, um geltende Regeln unter die Lupe zu nehmen und etwa zu prüfen, ob die verwendeten Container vielleicht doch veraltete Software verwenden, die als Einfallstor diente. Wer sich dann noch fortlaufend weiterbildet und die aktuellen Schwachstellen kennt, dem jagt auch Active Directory [11] weniger Angst ein, weil er für das Schlimmste gewappnet ist.

Fehlerhafte Hardware und Betriebssysteme

Der BSI-Bericht zieht auch all jenen den Zahn, die glauben, hundertprozentige Sicherheit sei möglich. Das betrifft sowohl Fehler in der Hardware als auch in Betriebssystemen. Zu Spectre und Meltdown schreibt das BSI: “Die Problemklasse bleibt, bedingt durch ihre tiefe strukturelle Verwurzelung in der Hardware, bis auf Weiteres erhalten.”

Zu Smartphone-Systemen wie Windows Phone, I-OS und Android heißt es: “Ein Produkt, welches zum Zeitpunkt des Kaufs öffentlich bekannte Schwachstellen enthält, muss aus IT-Sicherheitsgesichtspunkten als mangelhaft angesehen werden, wenn auf die Schwachstellen nicht ausdrücklich hingewiesen wird oder kein entsprechendes Sicherheitsupdate beim Kauf zur Verfügung steht.”

Die Behörde wünscht sich gerade hierbei auch, dass Verbraucher ihre Rechte offensiver wahrnehmen und von den Herstellern verlangen, dass sie ihre Software pflegen und Schwachstellen beheben.

Guter Rat

Wer sich, was gehackte Systeme angeht, nicht nur beim BSI, sondern generell bei IT-Experten und Security-Spezialisten umhört, kommt meist zu ähnlichen Ergebnissen. Zugleich kursieren im Internet Anleitungen für erste Hilfe nach dem Hack. Grob zusammengefasst stehen am Ende drei Aussagen:

• Vorbereitung ist alles: Ruhig bleiben und nur das Notwendigste für die Suche nach dem Urheber aufwenden. Zum Thema Vorbereitung gehören Monitoring, IDS und Backup und Restore sowie das regelmäßige Awareness-Training und Studium der neuesten IT-Sicherheitslage. Nur wer gut vorbereitet ist, kann auch dann ruhig bleiben, wenn es brennt.
• Das Problem entfernen: Der gehackte Server muss so schnell es geht vom Netz. Hier kommt die erste wichtige Entscheidung: Wer gerichtsfeste Beweise braucht, um den Urheber des Angriffs dingfest zu machen, der sollte auch gerichtsfeste Tools verwenden, um einen Snapshot des gehackten Systems zu ziehen.
• Einfallstor ausfindig machen und schließen: Die Analyse des befallenen Systems (oder der Systeme) sollte einzig dazu dienen, den Angreifer erfolgreich auszusperren, den Zugang zu sperren und einen erneuten Einbruch auszuschließen.

Diese drei Ratschläge decken die wohl wichtigsten Punkte ab und können Admins als Faustregeln dienen.

Ursachenforschung

Wer nach dem Hack – sei es wegen Schadenersatzforderungen oder ähnlichen Gründen – forensische Nachforschungen anstellen muss, dem stehen verschiedene Tools zur Seite. Für die bitweise Kopie, die das Original nicht verändert, bieten sich Klassiker wie »dd« an. Eine Forensik-Lektüre aus der Uni Washington [12], die das nötige Vorgehen beschreibt, ist auch heute noch relevant.

Vom kompromittierten Server zieht der Admin eine Kopie, die er neu starten und weiter untersuchen kann. Beim Entfernen des Systems sollte der Admin natürlich betroffene Clients beziehungsweise Kunden benachrichtigen – eine Rundmail oder ein Platzhalter auf dem Webserver sind unvermeidbar.

Dann gilt es, das mit »dd« erstellte Image zu durchsuchen. Protokolldateien, temporäre Dateien, Prozesslisten, offene Ports, Serverdienste und E-Mail-Warteschlangen, aber auch die Befehlshistorie und die letzten Logins (»last«) stehen da im Fokus. Autopsy aus dem Sleuth Kit ([13], Abbildung 6) hilft dem forensisch tätigen Admin ebenfalls.

Abbildung 6: Der Klassiker Autopsy aus Sleuth Kit macht Computerforensik einfach.

Wer besonders gut vorbereitet sein will, setzt ein Baseline Image ein. Gerade in Zeiten von Containern und Virtualisierung helfen solche Vorlagen, die den letzten “gesunden” Konfigurationsstand definieren, mit »diff« und »find« Unterschiede der letzten Tage, Wochen oder gar Monate zu entdecken. So lassen sich dann schnell etwaige Änderungen durch Hacker aufspüren.

Nicht zu weit gehen

Weitere zentrale Fragen für die Analyse lauten: “Wie weit soll der Admin gehen? Wie viel Zeit hat er? Wo liegen seine Prioritäten?” Auch hier helfen klare Vorgaben und Entscheidungen im Vorfeld – im Rahmen eines Katastrophenplans. Der sollte selbstverständlich auch Zeit für weitere Maßnahmen einplanen wie:

• Alle Passworte ändern.
• Neue Backups anlegen (inklusive Tests zur Wiederherstellung).
• Alle Third-Party-Produkte gegebenenfalls entfernen und wieder einspielen.
• (Temporär) alle Komponenten entfernen, die mit Geld, dem Zahlungsprozess und Abrechnungen zu tun haben (Schadenvermeidung).
• Alle möglicherweise betroffenen Kunden, Anwender und Stakeholder informieren.
• Intensives Rund-um-die-Uhr-Monitoring nach dem Neustart.

Gerade im amerikanischen Kulturkreis finden sich auf zahllosen Webseiten Tipps dazu, was Admins nach dem Hack tun sollten. Stellvertretend sei hier auf Jonathan Hassels “11 Things to do when you have been hacked” verwiesen [14].

Menschen machen Fehler

Aber wie machen das professionelle Ermittler? Ein Artikel aus der “Süddeutschen Zeitung” beschreibt die Möglichkeiten der Forensiker, um beispielsweise APT28, die “am besten erforschte Hackergruppe”, zu enttarnen [15].

Meist lassen sich nur über die Spur des Geldes Rückschlüsse auf Urheber ziehen. Oft passieren auch hier Fehler auf menschlicher Ebene, dank denen sich Angreifer verraten. Auch die meisten Ermittlungserfolge im Darknet basieren auf menschlichen Fehlern. So wurde Alexander U., Betreiber eines Darknet-Forums, in dem der Münchner Amokläufer seine Waffe besorgt hatte, über seine Bitcoin-Überweisungen aufgespürt [16].

Schweigen im Cyber

Bei der Artikelrecherche nahm der Autor auch Kontakt zum frisch geschaffenen Lagezentrum Cyber- und Informationsraum [17] sowie zu diversen Stellen der neuen deutschen Cyber-Abwehr auf und fragte um Rat. Leider kam von den Stellen nur wenig Gehaltvolles. “Wir geben doch den Hackern keine Informationen über unsere Maßnahmen nach einem Hack!” und “Wir wollen ja nicht, dass die unsere Schwachstellen kennen”, lauteten die Antworten. Auch die Frage, ob man plane, sich mit der militärischen Cyber-Expertise an den CERT-Howtos des BSI zu beteiligen, blieb in der Sache unbeantwortet.

Zu gefährlich sei das am Ende – und überhaupt, man dürfe und wolle dazu auch keinesfalls zitiert werden, so die einschlägige Auskunft. Diese zugeknöpfte Kommunikationsstrategie passt wenig zum modernen IT-Sicherheitsdenken, das Offenheit und Transparenz zur Grundlage für Vertrauen und Security macht.

Abseits der bundesdeutschen Cyber-Abwehr gilt meist: Erfolgreiche Angriffe auf die eigene Infrastruktur verschweigen ist die beste Strategie, um das Vertrauen der Kommunikationspartner zu untergraben. Auf die Dauer – und da sind sich viele Security-Experten einig – helfe nach dem Hack nur eine ehrliche, transparente und zügige Kommunikation.