Lehren aus Petya/NotPetya und Co

Der Juni 2017 war ein ereignisreicher Monat, da ausgehend aus der Ukraine ein neuer Schadcode mit dem Namen Petya viele System befallen und verschlüsselt hat. Neben eine Lücke in Windows war aber oft der Mensch die Schwachstelle. Ich sage bzw. schreibe schon lange, dass es eine dumme Idee ist, dauernd als "Administrator" zu arbeiten. Auch wenn "User Account Control" zuerst einmal diese erhöhten Rechte absichert, so sind wir alle Menschen und nicht fehlerfrei. Und selbst dann ist es doch "normal", dass Sie eine Software als Administrator installieren, ansonsten kann das ja gar nicht funktionieren. So hat es auch den ein oder anderen Kunden erwischt und ich durfte einige Stunden damit verbinden, Wiederherstellungen zu unterstützen. Darauf würde ich gerne verzichten und habe daher mir überlegt, warum Petya hier erfolgreich war und was man ändern könnte, um generell das Schutzniveau zu erhöhen. Was lernen wir also aus Petya (oder noPetya) und wir können wir es besser machen?

Angriffsvektoren

Ein Schadcode muss aktiviert werden, damit er was schädigen kann. Klassisch ist natürlich der Weg über eine Mail mit Anlage, ein verseuchter USB-Stick o.ä. Diese Wege können erschwert oder sogar fast unterbunden werden, wenn man gute Scanner, Filter oder z.B. auch Applocker und SmartScreen einsetzt.

Wenn der Schadcode aber ausgeführt wird, dann erfolgt dies erst einmal mit den Rechten des Benutzers. Davon ausgehend gibt es nun mehrere Wege sich weiter zu verbreiten.

  • Aktiv über Sicherheitslöcher
    Petya scheint die Sicherheitslücke "Eternal Blue" zu nutzen, die wohl von der NSA lange "geheim" gehalten wurde und nun "öffentlich" ist. Schon WannaCry hat sich dieser Lücke bedient und Microsoft hat diese schon viele Monate gefixt. Verwundbar sind also Systeme, die nicht aktualisiert wurden. Hier kann man nur sagen "Patchen Patchen Patchen" oder die System wirklich "abschotten". Diverse Produktionssysteme werden oft durch Firewalls dahingehend geschützt, dass nur wenige zwingend für den Betrieb erforderliche Orts geöffnet werden.
  • Aktiv über RPC-Aufrufe
    Nicht immer sind es "Sicherheitslöcher". Oft genug arbeiten Benutzer als "Administrator" und klicken ein User Account Control-Fenster einfach weg. Dann ist natürlich Tür und Tor geöffnet, je mehr Rechte der Benutzer hat und je weiter die Rechte reichen. Früher hat Microsoft gerne propagiert, dass jedes Land oder jeder Standort eine eigene Domäne hat. WAN-Leitungen waren knapp und Replikation eine Herausforderung. Der Vorteil für Firmen, die immer noch einen Forest mit vielen "Länder"-Domains haben, ist, dass es viele kleine "Domain Administratoren" gibt. Eine Firma mit einer "ukraine.firma.com"-Domäne, in denen ein Admin versagt, hat nur ein Land verloren. Vorausgesetzt, das es keine Lücken wie Eternal Blue im LAN gibt). Eine Firma mit einer großen "Welt-Domäne" im Forest ist empfindlicher für Fehler eines Domänen Administrators.
  • Passive als Dateiablage
    Natürlich kann sich der Schadcode auch auf über jeder Plattform verteile, die der Anwender nutzen darf (Netzwerkfreigabe, E-Mail, SharePoint etc) Allerdings ist er dann erst mal nicht aktiv. Ein anderer Anwender muss den Code dann "finden" und starten. Diese Datentöpfe sollte natürlich ein Viren/Mal-Ware-Scanner zumindest nach einiger Zeit erwischen. Eine andere Option besteht darin jeglichen ausführbaren Code auf solchen Plattform zu blockieren. Das ist im internen Einsatz mit Makros in Office-Dokumenten nicht immer einfach, aber Makros könnten z.B.: signiert werden.

Sicherheitslücken können Sie natürlich durch eine zeitnahe Installation der Updates stopfen. Aber viele Lücken beruhen auch auf der Ausnutzung von Diensten, die niemand eigentlich mehr braucht. So ist SMB1 schon lange eigentlich obsolet und "unsicher". Dennoch bieten es die Windows Server immer noch an und Clients können sich immer noch mit SMB1 verbinden. SMB2 und SMB3 gibt es aber schon eine lange Zeit

Ich rate dringend dazu, SMB1 zu deaktivieren! Siehe SMB1 Abschaltung

Sie können einfach per PowerShell den aktuellen Status einsehen und sowohl auf dem Server als auch auf dem Client Requestor deaktivieren.

# Anzeige der aktuellen Betriebsart
(Get-SmbServerConfiguration).enablesmb1protocol

# Abschalten von SMB1 auf dem Server
set-SmbServerConfiguration -EnableSMB1Protocol:$false 

# Abschalten von SMB1 beim Client Requestor. Restart des Computers erforderlich
Disable-WindowsOptionalFeture -online -Featurename smb1protocol

Das einzige was passieren könnte, sind sehr alte Clients und Server, die SMB2 noch nicht können. Aber darauf würde ich es ankommen lassen.

Petya und Updates

In den mir bekanten Fällen war es tatsächlich die schon andernorts beschrieben Einfallstor eines Softwareupdates. Ein Administrator hat in der Ukraine ein Update für eine betriebsrelevante Software (Buchhaltung) installiert und dieses Update war wohl infiziert. Durch die Ausführung als "privilegiertes Konto" hatte der Schadcode dann natürlich leichtes Spiel sich durch das LAN und WAN zu fressen und weitere Opfer zu finden. Wenn ich dann aber meine eigene Arbeitsweise überlege, dann bin ich durchaus auch diesbezüglich gefährdet und ich bin sicher, dass ich nicht der einzige bin. Ich schaue einfach mal, was ich so immer mal wieder mache:

  • Elster Update des Finanzamt für die Steuerformulare
    Da denke ich nicht an ihre jährliche Einkommensteuererklärung sondern die monatlichen Lohnsteuerbescheide etc. Und damit muss es nicht mal das "nackte Elster" sein. Selbst Drittprodukte wie LexWare u.a. nutzen das "Elster-Modul".
  • Banksoftware für das Finanzmanagement
    Darunter fallen VR Networks, S-Firm, Cotel, DreCash, DBDirect und alle die anderen Applikationen die Firmen häufig nutzen. Die Programme laufen auf den verschiedensten Clients und haben sehr sensitive Daten "im Bauch". Zudem haben Sie auch eine gewisse Priorität und Updates werden in der Regel nicht erst lange geprüft.
  • Handwerker-Software
    Aber auch Spezialsoftware unterliegt eine kontinuierlichen Weiterentwicklung. Insbesondere wenn es Software ist, die häufig an gesetzliche Änderungen oder Modellwechsel angepasst werden muss. Ich denke da Konfigurationsprogramme für Heizungen, Berechnungsprogramme für Bauplanungen, Verwaltungssoftware von Schornsteinfegern, Diagnosesoftware bei AutohäUsern etc. Überall werden Installationsdateien bereitgestellt, die natürlich zu installieren sind. Und meist muss das ein "Admin" machen.
  • Updates für Basissoftware
    Wir können alle nur hoffen, dass die Windows Update Server "sauber" sind und sich dort kein Schadcode einschleicht. Aber es gibt auch vergleichbare Programme, die quasi als "Unterbau" dienen. Auf vielen Systeme wir z.B. Java, Flash, Adobe Air, Silverlight installiert sein, die sich auch immer mal wieder aktualisieren. und gehört iTunes für die Apple-Anhänge nicht schon zum Betriebssystem?
  • Device Updates
    Ein ganz neues Feld eröffnet sich mit Geräten, die sich selbst aktualisieren. Das kann gut sein, um Lücken zu schließen, aber muss sicher sein, dass keine falsche Software aufgespielt ist. So sind DSL-Router wie eine Fritz!Box mit einem AutoUpdate konfigurierbar und auch Drucker und andere Geräte laden gerne mal eine Firmware herunter.
  • Apps
    Bei Smartphone-Apps aber auch Windows "UniversalApp" und selbst die "Apps" für einen HP-Drucker kommen aus dem Internet und laufen auf dem Gerät mit ziemlich vielen Freiheiten. Wer sagt mir, dass nicht jemand einen Schadcode in einem Spiel versteckt, welcher das Smartphone gar nicht stört sondern erst aktiv wird, wenn er per WLAN in einem Firmennetzwerk oder dem Heimnetzwerk hängt?. Das kann schon das Kind mit dem Smartphone im Homeoffice sein, um den Büro-PC zu verseuchen, der dann per VPN in die Firma springt.

Auch wenn diesmal der Schadcode wohl über eine Update-Funktion einer 3rd Party Software in die Firmen gekommen ist, bleibt der Zugang per Mail oder Download weiterhin ein häufiger Weg. Hier ist es wichtig, dass Spamfilter (z.B. www.nospamproxy.de) effektiv Schadcode filtern und Anlagen vielleicht erst einmal abtrennen und erste später oder auf Anforderung zustellen. Der Zwischenschritt zwingt Anwender die Herunter zu laden und damit gewinnen Scanner etwas Zeit, um die Daten erst beim Zugriff durch den Anwender noch al scannen zu können und nicht schon beim Eingang.

Quelle und Weg des Updates

Eine wichtige Komponente in dem Systems ist natürlich, wie das Update auf das Zielsystem kommt. Das Update wird von einem Hersteller bereitgestellt und sollte natürlich nicht kompromittiert sein. Das ist gar nicht so einfach, wenn selbst große Firmen "geknackt" werden. Die Verschlüsselungstrojaner machen ja schon dadurch auf sich aufmerksam, dass Sie möglichst schnell sich verbreiten und aktiv werden. Quasi in wenigen Tagen ist bekannt, was da passiert und dann sind recht schnell auch Antiviren-Produkte darauf trainiert. Aber was ist mit den "leisen blinden Passagieren", die sich in Firmen still einnisten und erst aktiv werden, wenn Sie wirklich einen neuralgischen Punkt gefunden haben?.

Noch sind Menschen die handelnden Personen und Menschen machen Fehler. Wer kann sicher sein, dass das Elster-Update nicht auch einmal durch einen stillen unerkannten Schädling verändert wurde und dann sogar digital signiert wird?. Vielleicht unwahrscheinlich aber sicher nicht unmöglich.

Auch auf dem Weg zum Ziel ist natürlich eine Veränderung möglich. Leider gibt es immer noch sehr viele Lösungen, die nicht einmal HTTPS einsetzen. Die Verschlüsselung interessiert mich dabei weniger. Per HTTPS sind die Daten aber auch signiert und damit gegen Veränderungen gesichert und ich kann das Zertifikat der Gegenstelle prüfen und damit die Identität des liefernden Servers überprüfen.

Das funktioniert aber nur, wenn der HTTPS-Tunnel nicht z.B. auf einem Proxy aufgebrochen wird. Damit hat ein Angreifer schon wieder eine neuralgische Stelle gefunden, die vielen Administratoren gar nicht bewusst ist. Ein kompromittierter Proxy-Server kann die SSL-Verbindung natürlich aufbrechen und "on the fly" die Dateien sogar verändern. Das ist kein Hirngespinst sondern schon Realität. Und wie sicher ist es da dann um Zertifikate bestellt? Selbst diese Bastion ist mittlerweile ja nur noch eine Sandburg.

URL Filterung als Lösung ?

Die meisten "Updates" kommen heute per HTTP (oder besser HTTPS) über das Internet. Die Zeiten, dass Anwender in einer Firma sich für den "Internet Zugriff" erst an einem Proxy authentifizieren mussten, sind zwar noch nicht überall vorbei aber in vielen Firmen wird der Zugang nicht mehr streng pro Benutzer kontrolliert. Sehr wohl gibt es aber noch Schutzsysteme, die Downloads kontrollieren. Diese Systeme erlauben natürlich auch entsprechende "Allowlists" auf URLs. Nun könnte man ja fordern, dass jede "Update-Anforderung" erst erlaubt sein muss. Das hilft aber nicht, wenn der Anwender selbst das Update herunterlädt.

Aus diversen WannaCry-Fällen habe ich auch schon gesehen, dass Empfänger eine Mail mit einem Link bekommen der auf "http://<tenantname.sharepoint.com/:..." geht. Wer hier als "Office 365" als "Vertrauenswürdig" ansieht und daher "sharepoint.com" auf eine Allowlist setzt, hat nichts gewonnen. Es liegt in der Natur der Sache, dass kriminelle Personen sich natürlich auch einen Office 365 Tenant besorgen können und über diese Plattform ein Vertrauen erschleichen wollen.

RBAC und Least Admin Privileges

WannaCry aber insbesondere Petya hat bei vielen Firmen so eingeschlagen, weil sie Software als "Admin" installieren. Ich denke, dass viele Server zwar noch nicht gepatched sind aber bei meinen Kunden bin ich recht sicher, dass die meisten wichtigen Server schon aktualisiert wurden, ehe Petya aufgetaucht ist. Es hat aber auch Server erwischt, die aktuell waren. Hier ist dann wohl der zweite Angriffsweg erfolgreich gewesen. Der Schadcode wurde mit einem administrativen Konto gestartet und musste damit gar keine Sicherheitslücke nutzen, sondern konnte bequem per C$, WMI, RPC sich auf weiteren Systemen austoben.

Hier sind Sie natürlich als "privilegierter Benutzer" gefragt, dieses Szenario zumindest zu erschweren. Ich sage bzw. schreibe schon lange, dass es eine dumme Idee ist dauernd als "Administrator" zu arbeiten. Auch wenn "User Account Control" zuerst einmal diese erhöhten Rechte absichert, so sind wir alle Menschen und nicht fehlerfrei. Und selbst dann ist es doch "normal", dass Sie eine Software als Administrator installieren. Ansonsten kann das ja gar nicht funktionieren.

Also müssen wir überlegen, wo dieser Administrator denn überhaupt Berechtigungen benötigt. Wenn ich in einer Firma sowohl für Exchange als auch für Skype for Business zuständig bin und zudem noch andere Dinge machen will, brauche ich dann wirklich für jeden "Tätigkeitskreis" ein eigenes administratives Konto um die "Reichweite" im Schadensfall zu begrenzen? Im Prinzip ja aber einige Produkte helfen mit dabei natürlich auch.

Ich kann Exchange und Skype vor Business per Webbrowser oder Remote PowerShell bearbeiten und hier mit als Administrator anmelden. Das ist aber nur für die Konfiguration ausreichend aber natürlich nicht zur Installation von Software. Wobei auch hier Exchange und Skype for Business wieder mit gutem Beispiel voran gehen. Ich kann einen Exchange als Administrator "provisionieren", so dass dann ein "Lokaler Admin auf dem Server" die eigentliche Installation vornimmt. Bei Skype for Business ist es sogar der Regelfall, dass ein Admin in der Topologie einen neuen Server addiert und die Installation in viele Fällen ein lokaler Administrator vornehmen kann.

Das gilt so leider nicht für andere Programme aber in vielen Fällen wird eine Software auf einem (1) Server installiert. Und dazu reicht es, wenn der Installateur für diese Zeit auf diesem Server administrative Rechte hat. Dummerweise ist das mit Bordmitteln nicht ganz so einfach immer umzusetzen.

Dynamische Admin-Rechte

Es gibt aber Drittprogramme, die ein Konto für den Zeitraum einer Installation die entsprechenden Rechte eben und danach wieder entfernen. Genaugenommen können Sie das schon heute praktisch umsetzen.

  1. Pro Service legen Sie eine Gruppe
    Das sollte eine Domänensicherheitsgruppe sein, damit Sie auf mehreren Systemen auch verwendet werden kann. Exchange und Skype for Business legen solche Gruppen ja schon direkt an
  2. Diese Gruppe bekommt die erforderlichen Rechte
    z.B. indem sie in der lokale Admin-Gruppe der betroffenen Server aufgenommen werden oder auch Rechte auf bestimmte andere Ressourcen hat aber eben nur auf dieses
  3. Die Gruppen enthalten per Default keine "Administrative Konten"
    Ich nutze gerne ein Prefix wie "ADM-Benutzer" um administrative Konten zu kennzeichnen. Sie liegen natürlich auch in einer eigenen OU und ich kann per geplanten Task z.B. dafür sorgen, dass in solchen administrative Gruppen diese Konten nach einer bestimmten Zeit wieder entfernt werden.
    Dienstkonten könnten aber eventuell auch dauerhaft in so einer Gruppe verbleiben. Ein Dienstkonto startet aber natürlich idealerweise keine unbekannte Software.

So wäre der Schadenfall auf diese Server begrenzt, zumindest wenn es sich um administrative Zugriffsversuche handelt. Sicherheitslücken sind damit nicht immer zu vermeiden. Ein "Patchen" ist also weiter erforderlich.

Wenn Sie nun etwas installieren wollen, dann ist der Prozess wie folgt

  1. Admin-Account in die Berechtigungsgruppe addieren und abwarten
    Damit bekommt ihr Admin-Account nun die Rechte. Die Gruppenmitgliedschaft muss nun natürlich noch im AD repliziert und ggfls. aus verschiedenen Cache-Speichern verschwinden.
  2. Neu Anmelden als Admin-Account
    Sie führen dann eine Anmeldung als Administrator aus. Für diese Anmeldung haben die dann die entsprechenden Rechte
  3. Aktion durchführen
    Nun können Sie die erforderlichen Tätigkeiten ausführen. Wenn die Rechte über die Gruppe ausreichend eng aber doch auch genügend umfangreich sind, können Sie ihre Arbeit durchführen und dennoch sich nur innerhalb ihres Korridors bewegen
  4. Abmelden
    Wenn Sie fertig sind, dann melden Sie sich einfach ab
  5. Admin-Account entfernen.
    Vergessen Sie danach nicht sich die Rechte wieder weg zu nehmen. Zudem ist natürlich wichtig, dass Sie in der Zeit der Gruppenmitgliedschaft sich nicht noch woanders anmelden

Damit wäre schon eine erste Verteidigungsbastion möglich. Vielleicht gibt es ja auch entsprechende 3rd Party Lösungen, die diesen Prozess On-Premises verbessern. In Office 365 gibt es ja schon eine ähnliche Funktion in Bezug auf den Datenzugriff. Dort müssen Sie als Admin dem Office 365 Support erst die Rechte einräumen, wenn er im Rahmen eines Supportfalls sie unterstützen soll.

Ein anderes Konzept basiert darauf, dass jeder Dienst einen "eigenen Admin-Benutzer" bekommt, dessen Kennwort aber niemand weiß. Der Prozess wäre hier dann der folgende

  1. Techniker beantragt "Admin-Zugriff" für einen Service
  2. Ein Prozess setzt das Password für das Dienstadmin-Konto und teilt es dem Techniker mit.
  3. Techniker meldet sich dann mit diesem Dienstadmin-Konto an und kann die Rechte ausüben
  4. Techniker meldet sich als Dienstadmin-Konto ab
  5. Techniker meldet "Fertigstellung" worauf das Konto wieder gesperrt wird

Auch das ist eine Option, dass ein Admin quasi nur dann Admin ist, wenn er es braucht und dass auch nachvollziehbar, wer etwas verändert. Voraussetzung ist natürlich erst einmal die mühselige Definition, welches Gruppe oder welches Dienstadmin-Konto wo überhaupt die Berechtigungen benötigt.

JitJea: A Windows PowerShell Toolkit to Secure a Post-Snowden World
https://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DCIM-B362 

Tägliche Administration

Allerdings ist die Steuerung mit einem Dienstadmin-Konto oder Dienstgruppe nichts für die tägliche Verwaltung von Servern. Und hier muss man ganz klar sagen, dass es in vielen Fällen gar nicht notwendig ist, dass ein IT-Mitarbeiter als "Admin" etwas tut. Exchange lebt das per RBAC schon vor. Ein "Exchange Recipient Administrator" hat gar nicht die Rechte direkt per LDAP an den AD-Benutzern etwas zu drehen. Er kann das aber sehr wohl über Exchange. Hier ist aber der Exchange Service die Kontrolle und ausführende Instanz. Die Exchange Server haben in Form der Rolle "Exchange Trusted Subsystem" die entsprechenden Rechte auf die verschiedenen Objekte in der Konfiguration Partition und den Domänen Partitionen. Sehr pfiffig gedacht aber so weit sind noch lange nicht alle Produkte.

Daher ist für die tägliche Administration zu prüfen, welche Aktionen denn den Hauptanteil der Arbeit ausmachen und zu überlegen, wie diese automatisiert werden können. Das ist übrigens gar nicht mal so schwer.

Es gibt diverse Produkte, über Sie die gängige Verwaltungsaufgaben per Skript oder Webseite umsetzen können und der "Administrator" einfach als Benutzer über einen Browser die wesentlichen Aktionen einstellt. Der Benutzer hat dazu nicht mehr direkt die Rechte, sondern en Dienstkonto, welches aber nicht jeden beliebigen Code ausführt. Für einfache Dinge reichen auch Windows Gruppen, deren Mitgliedschaften sie "ungefährlich" verwalten können und ein Skript im Hintergrund, welches dann basierend auf den Mitgliedern entsprechende Einstellungen vornehmen. Einige Beispiele davon habe ich auf der MSXFAQ schon beschrieben:

Das ist natürlich keine direkte Lösung für die Installation von Programmen und Updates "als Admin", aber ein erster Schritt. Wenn Sie für die tägliche Regelarbeit schon kein Administrator sein müssen, dann sind schon viele Lücken geschlossen.

Zusammenfassung

Gegen Petya und zukünftige Schadprogramme mit vergleichbaren Verbreitungswegen hilft wirklich nur mit deutlich geringeren Berechtigungen zu arbeiten, und die neuen Code-Teile gewissenhaft zu prüfen. Dazu gehört auf jeden Fall der Download von vertrauenswürdigen Quellen.

  • Kommt die Quelle per HTTPS
    Ein Download von Programmen ohne HTTPS würde ich heute nicht mehr erlauben. Allerdings ist auch HTTPS erst der Anfang.
  • Ist das Zertifikat "korrekt"
    Nur sind sie ziemlich sicher, dass die Quelle authentisch ist. Es gibt leider immer noch zu viele "Update-Routinen", die Zertifikate nicht prüfen.
  • Ist der Code in sich unverändert
    Idealerweise sind vom Entwickler alle Teile ebenfalls "digital signiert". Wenn die der bereitstellende Service seine Systeme sicher betreibt, sollte nur legitimer Code signiert sein.
  • Limitieren Sie administrative Rechte
    Wenn jemand einen Schadcode ausführt, was sich nicht zu 100% verhindern lassen wird, dann sollte die Schadwirkung begrenzt bleiben. Das geht natürlich nur, wenn der ausführende Benutzer eben nicht auf "\\server\c$" von vielen Systemen im Netzwerk kommt.
  • Schützen Sie die Clients per Applocker und Co
    Auf den meisten Arbeitsstationen werden nur "bekannte" Programme ausgeführt. So kann zumindest auf den normalen Clients das Risiko der Ausführung von "unbekannten Programmen" deutlich verhindert werden. Gegen ein reguläres Update (mit Schadcode) durch einen Admin ist das nur eine teilweise Hilfe. So wird zumindest verhindert, dass der Code auf anderen PCs aktiv werden
  • Und letztlich eine Sicherung
    Halten Sie immer Kopien von Daten vor, sei es als Schattenkopien (wobei die bei vielen Äderungen versagen) oder als Snapshots oder eben klassische als Backup. Allerdings muss natürlich sichergestellt sein, dass das Backup-Ziel gegen Zugriffe geschützt ist. Es hilft nichts, wenn auch der BackupServer per \\servername\C$ o.ä. erreichbar ist.

Die Firmen, die schon von Petya betroffen waren, werden auf jeden Fall zukünftig bessere Schutzverfahren umsetzen wollen aber auch alle Firmen, die noch mal Glück gehabt haben, sollten nicht darauf vertrauen, dass dies morgen auch noch so ist. Sie müssen ihre Arbeitsweise anpassen, um gegen zukünftigen Bedrohungen besser gewappnet zu sein. 

Weitere Links