Locky besteht im Wesentlichen aus JAVA-Code (JavaScript, VB-Script, Makros oder direkt als CMD getarnt), der sich meistens in einer Rechnung in einem E-Mail-Anhang verbirgt, dann automatisch ausgeführt wird und die weiteren zur Ausführung benötigten Code-Elemente aus dem Internet nachlädt. Einmal vollständig geladen ist Locky als “Schläfer“ organisiert, schlägt also nicht sofort zu. Locky schlägt zeitversetzt zu, indem alle für den Benutzer mit Schreibrechten zugreifbare Dateien vieler Dateitypen verschlüsselt werden – Betroffene sprechen von bis zu 40.000 Dateien in einer Minute, ohne dass der Anwender diese Dateien wieder lesen kann. Ein Erpresserschreiben wird auf den befallenen Rechner gebracht. Gegen die Übermittlung eines Betrages in Höhe von meist ca. 400 Euro wird die Übermittlung des benötigten Schlüsselmaterials versprochen – und nach den praktischen Erfahrungen im Markt auch geliefert. Die Landeskriminalämter, das BSI und alle anderen öffentlichen Stellen empfehlen NICHT zu zahlen, um diesen Geschäftsmodellen prinzipiell die Erfolgschancen zu nehmen.
Neben dem häufigsten Befall durch ein E-Mail Attachment sind auch Varianten im Markt gesichtet worden, die sich über Drive-by-Downloads (Browser), Water Hole (APT über Browser) und USB-Stick verbreiten. Details dazu weiter unten im Text.
Ohne hier zu detailliert auf die empfehlenswerten Maßnahmen nach einem Befall einzugehen, sollen hier zuerst die gängigen technologischen Präventionsempfehlungen auf ihre Sinnhaftigkeit geprüft werden und konkrete Handlungsempfehlungen dargestellt werden:
1. Backup: als häufigste Empfehlung wird genannt, täglich Backups anzulegen, um wieder „sauber“ aufsetzen zu können. Bei Locky werden auch Dateien verschlüsselt, die auf Shares im Netz oder lokal z.B. über USB angebundenen Laufwerken liegen. Deshalb ist es für die Prävention zwingend die Backups zu entkoppeln, also physikalisch zu trennen, bzw. zumindest dem Benutzer (und allen lokal verfügbaren technischen Accounts inklusive der lokalen Administrationsaccounts) Schreibrechte zu entziehen, da eine physikalische Entkopplung meist technisch gar nicht möglich ist. Organisatorische Anweisungen zur physikalischen Entkopplung haben statistisch erkennbar geringen Erfolg, wenn sie nicht durch technische Awareness in Echtzeit unterstützt sind (z.B. AwareWatch).
Nachhaltig ist dieses Verfahren bei einem Schläfer wie Locky aber nur dann, wenn man auf dem gezogenen Backup mit 100%iger Sicherheit verifizieren kann, ob das Backup selbst befallen ist, oder nicht. Befallene Backups dürfen nicht wieder eingespielt werden und auch nicht als Quelle neuer Angriffswellen dienen – sondern müssen automatisiert sicher vernichtet werden (z.B. mit DataEx). Je nach der Latenzzeit des „Schlafes“ kann also das letzte nicht infizierte Backup auch über ein halbes Jahr alt sein, denn man muss hier berücksichtigen, dass das Erkennen eines Eindringlings bei APT Angriffen im Mittel Zeitraten von über 200 Tagen aufweist.
Bei Locky ist bisher noch kein sicheres Prüfverfahren vorgestellt worden, weshalb dieses Verfahren bei Locky nicht geeignet ist.
2. Virtualisierung des Browsers: die Virtualisierung des Browsers schützt vor Water Hole und Drive-by-Attacken. Der virtualisierte Browser gilt dabei als Opfersystem – man geht also davon aus, dass er angreifbar ist. Prinzipiell würde der virtualisierte Browser auch vor Locky schützen, wenn ein Ausbrechen aus der Virtualisierung sicher verhindert werden kann und der schreibende Zugriff auf alle Nutzdaten mit den im virtualisierten System verfügbaren Accounts verhindert würde, was leider in den seltensten Fällen stringent implementiert ist. Die Browservirtualisierung findet normalerweise nach dem ReCoBS Standard in der DMZ statt. Der Anwender hat aber meist die Möglichkeit Daten aus der Browser-Umgebung direkt in die produktive Umgebung zu bringen – z.B. über Ausdrucke. Wesentlich ist es hier jeden aktiven Code auszufiltern (Makros, Java-Skript-embedded – z.B. in jpg Comments, cmd, exe, dll … embedded in double enveloped oder mittels Archivierungswerkzeugen rekursiv verpackte Objekte …) was z.B. über Produkte wie XRayWatch getan werden kann. Daten auf den Intranet-Servern sind natürlich geprüft und deshalb von diesen Schutzverfahren völlig auszunehmen. Diese Unterscheidung zwischen Intranet und Internet und evtl. noch Extranet und die oben genannten Integrationen für Druck und Datenimport machen solche Lösungen „im Eigenbau“ sehr komplex. Deshalb empfiehlt es sich auf fertige Marktprodukte zurückzugreifen, die auch die komplexen Fragen rund um das Patchen und der Wartung lösen.
3. Virtualisierung des Mail-Clients: Die Virtualisierung des Mail-Clients darf aus Gründen des Datenschutzes nicht auf einem Opfersystem in der DMZ stattfinden, sondern muss im inneren Netz implementiert sein. Aus Sicherheitssicht am besten hinter einer Firewall.
Der Zweck des E-Mail-Clients liegt in der Kommunikation von strukturierten und unstrukturierten Daten. Wieder sind Inhalte, die aus dem eigenen Unternehmen kommen anders zu behandeln als Daten „von außen“. Wieder gilt es wie oben jeden aktiven Code aus den Mails und ihren Anhängen sicher zu identifizieren und Schadcode sicher auszumustern. AntiVirus Lösungen genügen hier nicht, wie Locky gezeigt hat, denn die pattern-basierte Schadcode-Suche von Anti-Viren-Lösungen hat eine Latenzzeit von mehreren Stunden.
Praktisch ist es optimal, potentiell kritischen Code zu identifizieren und sofort in eine geeignete Sandbox, also eine Schutzzone zu übermitteln und erst dort auszuführen. Es sei denn alle Anwender können auf jedes Attachment verzichten in welchem Makros oder anderer ausführbarer Code enthalten ist, was in den seltensten Fällen gegeben ist. Die Sandbox muss nun bestimmte Sicherheitsvoraussetzungen erfüllen, die sicherstellen, dass ein Zugriff auf andere Kennungen (Mimikatz, PassTheHash etc.), eine Nutzung von technischen Standard-Accounts, eine Nutzung von Schwachstellen im Opfersystem, etc. nicht dazu führen kann, dass Dateien außerhalb der Sandbox mit Schadcode befallen werden können. Gleichzeitig muss aber für den Anwender die Möglichkeit bestehen Daten aus der Sandbox heraus zu transportieren, da Ausdrucke, Screenshots, Datenexporte in vielen Fällen zwingend erforderlich sind. Eine reine „Prüfung“ der Anhänge in einer Sandbox genügt nicht, da Advanced persistant Threats (APT) die Ausführungsumgebung analysieren und sich nur in realen benutzergesteuerten Umgebungen zeigen.
Diese Komplexität führt ebenso wie in dem Fall der virtualisierten Browser dazu, dass eine vorgefertigte Lösung, die vom Hersteller gemanagt wird, selbst gebauten Systemen vorzuziehen ist.
4. Schutz vor USB-Angriffen: der Schutz vor Angriffen über USB oder allgemeiner allen Schnittstellen (Ports) eines Clients oder Servers bezieht sich nicht nur auf den Schutz vor:
a. Dateien, die den Angriff in sich tragen, sondern auch auf Angriffe, die
b. Schwachstellen des Betriebssystems im Plug and Play Subsystem ausnutzen (z.B. lnk) und
c. Angriffen aus dem Controller der Geräte (Devices) an diesen Schnittstellen (z.B. BadUSB).
Es gilt die Angriffe aller drei Kategorien sicher abzuwehren.
Die Angriffe unter b und c (z.B. lnk, BadUSB …) werden von den wenigsten Device Control Lösungen abgewehrt. Aktuelle Tests in der Bundesverwaltung haben gezeigt, dass sich einige Device Control Lösungen bereits durch simple Tricks der Anwender aushebeln lassen – umso einfacher natürlich durch professionellen Schadcode. Die wesentlichsten Punkte zum Schutz vor Locky über USB Datenträger bestehen also in folgenden – robust implementierten – Maßnahmen. Organisatorische Anweisungen können hier nicht helfen, da der Anwender den Controller oder die zu lesende Datei nicht vorher inspizieren kann, ob sich z.B. in dem jpg ein Executable in den Kommentaren oder ausführbarer Code in einem rtf verbirgt.
Die Angriffe werden professionell erstellt und als Toolkit im Darknet verkauft, so dass auch DV-Laien sich ihren eigenen Angriff zusammenbauen können. Die Abwehr muss deshalb professionellen Schutz implementieren – also robust gegen Angriffe sein, sonst ist sie das Geld und die Zeit nicht wert die man zur Umsetzung benötigt.
Optimal ist es natürlich mit einer einzigen Lösung mit einer prüfbaren und durch Experten im Schutzgrad geprüften Implementierung vor allen Bedrohungen zu schützen und trotzdem das Arbeiten des Anwenders zu unterstützen.
Wie kann man sich vor Locky und anderen Krypto-Trojanern sicher schützen?
Optimaler Schutz besteht nur über integritätsgeschützte, als Opfersystem ausgelegte, sicher gekapselte Systeme die keinen Durchgriff auf produktive Systeme haben und das Ausbrechen aus einer Virtualisierung mit zusätzlichen Mitteln verhindern, wie z.B. die virtuelle Schleuse ReCAppS:
Mit ReCAppS, Remote Controlled Application System, werden die potentiell kritischen Daten automatisch, für den Anwender nahtlos in eine virtuelle Quarantäne gebracht und dort durch die geeigneten Anwendungen geöffnet, um zu verhindern, dass potentiell enthaltener Schadcode die produktiven Systeme infiziert. In einer „Remote Controlled Session“ kann der Anwender alle aktiven Inhalte nutzen und beliebige Daten einsehen, sowie kritische Aktionen durchführen, ohne die produktive Umgebung zu gefährden. Kritisch ist etwa das Anklicken einer problematischen URL, das Herunterladen von ausführbaren Elementen aus dem Internet, das Anstecken eines fremden nicht in Echtzeit geprüften Peripheriegerätes (siehe auch Angriffsvektor BadUSB), das Installieren einer unbekannten Anwendung von einem fremden Datenträger oder aber eben wie das Beispiel Locky zeigt das Öffnen von E-Mail Anhängen, welche ausführbaren Code beinhalten. Inhalte werden sowohl auf dem Remote Controlled System als auch auf dem Client des Anwenders nach den zentralen Vorgaben kontrolliert, so dass kein Schadcode ins interne Netz gerät.
Die Virtualisierung von potentiell schädlichen Inhalten und unbekanntem Code alleine ist als Lösung jedoch zu kurz gegriffen. Erst wenn die Arbeitsergebnisse aus der virtualisierten Umgebung sicher in die Prozesse der Produktionsumgebung eingebunden werden und die Aktivitäten in der virtualisierten Welt nahtlos und barrierefrei automatisch für den Anwender eingebunden sind, schafft das effiziente sichere Arbeitsumgebungen, die gleichzeitig prüfbar geschützt sind. Dazu müssen Virtualisierung, Applikations- und Contentkontrolle sowie Verschlüsselung geeignet kombiniert werden und können dann die sichere und flexible Alternative zu rigiden Verboten oder physikalisch getrennten Systemen darstellen. Durch ein Remote-Controlled-Application-System (kurz ReCAppS) werden sicherheitskritische Aktionen in der produktiven Umgebung sicher erkannt und dann automatisch in eine virtualisierte Umgebung ausgelagert. Inhalte werden sowohl auf dem Remote Controlled System als auch auf dem produktiven Client-System des Anwenders nach den zentralen Vorgaben kontrolliert, so dass kein Schadcode ins interne Netz gerät. Wesentlich ist hier, dass eine Prüfung auf Schadcode wie sie von Anti Viren Programmen durchgeführt wird, nicht ausreicht, da jeder potentielle Code der fremd und nicht positiv authentisiert ist erkannt werden muss und in der virtuellen Schleuse auszuführen ist.
Für den sicheren Betrieb von Browsern hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) mit ReCoBS ein Konzept vorgestellt, welche das sichere Surfen durch Auslagern des Browsers in die sogenannte demilitarisierte Zone (DMZ) über eine Trennung von Anzeige und Ausführung ermöglicht. Die ReCAppS Lösung nutzt dieses Verfahren nicht nur zum sicheren Betrieb des Browsers, sondern für alle ungeplanten, sicherheitskritischen Aktionen.
Ein Remote-Controlled-Application-System ergänzt damit das BSI-Verfahren ReCoBS und kann also für alle unbekannten oder ungeplanten sicherheitskritischen Aktionen verwendet werden. Dieses Verfahren erweitert ReCoBS auch um einige in der Praxis wesentliche Elemente. Arbeitsergebnisse, die der Anwender in der virtuellen Schleuse erstellt hat, können über spezielle abgesicherte Kanäle ausgedruckt werden, ohne dass der Ausdruck selbst wieder eine Angriffsmöglichkeit darstellt.
Neben dem Drucken unterstützen ReCAppS auch den Datentransport für den Anwender vollautomatisch. Der Datentransport wird durch eine automatische Datenkonversion abgesichert, so dass nur sichere „Bilder“ aber keine ungeprüften Makros oder Ähnliches transportiert werden. Gegenüber Standardschleusen und physikalisch getrennten Netzen, die mittels einer „Drehstuhlschnittstelle“ gekoppelt sind hat diese Lösung einen entscheidenden Vorteil: Der an der Drehstuhlschnittstelle verwendete oder in dem Schleusensystem als „geprüft“ markierte Datenträger kann selbst von Schadcode wie BadUSB befallen sein. Dadurch, dass es in ReCAppS keinen Kontakt des Datenträgers zum produktiven System gibt fällt ein wesentlicher Angriffsvektor weg. Auch Angriffe wie .lnk oder ähnliche sind dadurch eliminiert.
Details zu Locky
So genannte Krypto-Trojaner können sich in einer auf den ersten Blick harmlosen E-Mail-Rechnung verbergen. Wer den Anhang so einer E-Mail anklickt, infiziert seinen Rechner mit der Verschlüsselungssoftware und hat damit keinen Zugriff mehr auf seine Daten.
Ist der Computer infiziert, werden durch den Trojaner alle Dateien mit vordefinierten Endungen verschlüsselt - und tragen zum Beispiel den Namen „*.Locky“. Es sind mehr als 100 Dateiendungen hinterlegt. Nur eine Datei ist lesbar: Die mit einer Lösegeldforderung der Erpresser, die auch eine genaue Handlungsanweisung enthält. In der Internetwährung Bitcoin soll das Lösegeld gezahlt werden – meist ca. 400 Euro. Eine Anweisung, wie ein Konto in der Internetwährung eröffnet werden kann, schicken die Kriminellen gleich mit.
Weitere Verbreitungswege von Krypto-Trojanern sind Drive-by Attacken, watering hole, USB-Datenträger in doppelter Weise: einmal über infiltrierten Content, der identisch zu den Mail-Anhängen oben gestaltet ist, oder noch perfider, wenn der Krypto-Trojaner gleich im Controller des USB-Datenträgers verborgen ist.
Deshalb sind in diesem Zusammenhang fremde USB Sticks oder allgemeiner fremder Peripheriegeräte nicht weniger gefährlich, denn auch in einer schicken Maus oder einer Tastatur kann sich ein Trojaner verbergen. Auch in der Firmware können sich Krypto-Trojaner verbergen, im so genannten Controller des USB-Sticks. Dann hat man keine Chance, die Schadsoftware zu erkennen. Einmal eingesteckt, zieht sich der Trojaner das weitere Verschlüsselungsprogramm aus dem Netz. Für so genannte Targeted Attacks, also ganz gezielt Angriffe auf Firmen oder konkrete IT-Systeme in einer Firma werden subtile Wege verwendet.
Bei den Recherchen des Bayerischen Rundfunks zu „Locky“ wurde auch Ramon Mörl (Geschäftsführer itWatch) als IT-Security Experte zu Rate gezogen (TV-Beitrag BR vom 11.03.2016 ansehen). Unter anderem ging es bei diesem Austausch um konkrete Fälle: Auf Anfrage des Bayerischen Rundfunks habe eine Firma aus Mecklenburg-Vorpommern bestätigt, sie habe niemals eine mit einem Krypto-Trojaner versehene Rechnung per Email verschickt. Die Rechnung liegt der Redaktion aber vor. Sie enthält einen Anhang, der die Verschlüsselungs-Werkzeuge aus dem Internet herunterlädt. „Die vermeintlichen Absender der Rechnungen sind oftmals doppelt geschädigt, denn ihre Kennungen und Namen werden ohne ihre Kenntnis benutzt, um den Schadcode zu verteilen. Damit ist ein Reputationsverlust verbunden.“, weiß R.Mörl und fährt fort: "Der Angreifer versucht nicht, mit dem Panzer durch die Haustür zu fahren, sondern ein kleines Stück zu verteilen. Das lädt sich dann von Servern diesen Schad-Code herunter. Und der wird dann stückweise zusammengebaut, bis er zur Anwendung kommt."
Verbreitung
In aller Regel werden die Systeme durch schadhafte E-Mail-Anhänge kompromittiert. Auch Drive-by-Infections und Malware-Makros wurden bereits festgestellt (z.B. drive-by-downloads in Kombination mit dem Neutrion Exploit-Kit).
SPAM-Mails als Verteilungsweg; Mails kommen als Rechnung daher, bisher keine Samples mit persönlicher Anrede (entweder mit „Sehr geehrte Damen und Herren“ oder ganz ohne – siehe Beispiel unten)
Infektionswege: Mail mit Officedokument + Makro[1], aber auch JavaScript-Dateien in ZIP-Attachments, Schadsoftware wird dann über das Makro / die JavaScript-Datei aus dem Internet nachgeladen. Der JAVA Code ist stark obfuskiert und häufig verschleiert z.B. in zip, um Schutzmechanismen zu umgehen. Die Domains, in welchen die Schadsoftware liegt, sind meist nur wenige Stunden gültig, d.h. man kann die Schadsoftware nur innerhalb dieser Zeit herunterladen.
Nach Ausführung werden die Nutz-Dateien verschlüsselt und mit einer Endung (häufig .locky) versehen.
_____________________
[1] Deshalb ist eine der Empfehlungen von Microsoft das Verhindern bzw. explizite Freigeben von Makros: https://blogs.technet.microsoft.com/...
Dieses Beispiel einer E-Mail liegt vor:
In den jeweiligen Verzeichnissen der verschlüsselten Dateien werden Textdateien abgelegt. Beispielhaft der Inhalt einer solchen Textdatei:
Unter http://www.heise.de/... findet sich ein bereits ins Deutsche übersetzter Text. Es kommen fast ausschließlich Bitcoin-Forderungen von Täterseite. Erfahrungsgemäß werden bei Bitcoin-Konten die (Teil-)Coins aber direkt über viele Kaskaden weiterverteilt, weswegen Bitcoin von Täterseite sehr beliebt sind.
Beispielmail:
Betreff: Ihre Rechnung D49017227657
Infektionswege
ZIP-Archiv mit Javascript-Datei als Inhalt:
<mime-attachment.png>
Word-Dokument mit maliziösem Makro:
<mime-attachment.png>
Beispieltext:
(Text war bei den Mails die bei einem befragten Provider eingingen alle gleich – geändert wurde lediglich die Kunden- und die Rechnungsnummer). Anschrift und Namen waren bei diesem Provider direkt von der Website eines Büromarktes entnommen entsprachen also real existierenden Daten zu dem Unternehmen, dem Firmensitz und den Inhabern.
Neben dem häufigsten Befall durch ein E-Mail Attachment sind auch Varianten im Markt gesichtet worden, die sich über Drive-by-Downloads (Browser), Water Hole (APT über Browser) und USB-Stick verbreiten. Details dazu weiter unten im Text.
Ohne hier zu detailliert auf die empfehlenswerten Maßnahmen nach einem Befall einzugehen, sollen hier zuerst die gängigen technologischen Präventionsempfehlungen auf ihre Sinnhaftigkeit geprüft werden und konkrete Handlungsempfehlungen dargestellt werden:
1. Backup: als häufigste Empfehlung wird genannt, täglich Backups anzulegen, um wieder „sauber“ aufsetzen zu können. Bei Locky werden auch Dateien verschlüsselt, die auf Shares im Netz oder lokal z.B. über USB angebundenen Laufwerken liegen. Deshalb ist es für die Prävention zwingend die Backups zu entkoppeln, also physikalisch zu trennen, bzw. zumindest dem Benutzer (und allen lokal verfügbaren technischen Accounts inklusive der lokalen Administrationsaccounts) Schreibrechte zu entziehen, da eine physikalische Entkopplung meist technisch gar nicht möglich ist. Organisatorische Anweisungen zur physikalischen Entkopplung haben statistisch erkennbar geringen Erfolg, wenn sie nicht durch technische Awareness in Echtzeit unterstützt sind (z.B. AwareWatch).
Nachhaltig ist dieses Verfahren bei einem Schläfer wie Locky aber nur dann, wenn man auf dem gezogenen Backup mit 100%iger Sicherheit verifizieren kann, ob das Backup selbst befallen ist, oder nicht. Befallene Backups dürfen nicht wieder eingespielt werden und auch nicht als Quelle neuer Angriffswellen dienen – sondern müssen automatisiert sicher vernichtet werden (z.B. mit DataEx). Je nach der Latenzzeit des „Schlafes“ kann also das letzte nicht infizierte Backup auch über ein halbes Jahr alt sein, denn man muss hier berücksichtigen, dass das Erkennen eines Eindringlings bei APT Angriffen im Mittel Zeitraten von über 200 Tagen aufweist.
Bei Locky ist bisher noch kein sicheres Prüfverfahren vorgestellt worden, weshalb dieses Verfahren bei Locky nicht geeignet ist.
2. Virtualisierung des Browsers: die Virtualisierung des Browsers schützt vor Water Hole und Drive-by-Attacken. Der virtualisierte Browser gilt dabei als Opfersystem – man geht also davon aus, dass er angreifbar ist. Prinzipiell würde der virtualisierte Browser auch vor Locky schützen, wenn ein Ausbrechen aus der Virtualisierung sicher verhindert werden kann und der schreibende Zugriff auf alle Nutzdaten mit den im virtualisierten System verfügbaren Accounts verhindert würde, was leider in den seltensten Fällen stringent implementiert ist. Die Browservirtualisierung findet normalerweise nach dem ReCoBS Standard in der DMZ statt. Der Anwender hat aber meist die Möglichkeit Daten aus der Browser-Umgebung direkt in die produktive Umgebung zu bringen – z.B. über Ausdrucke. Wesentlich ist es hier jeden aktiven Code auszufiltern (Makros, Java-Skript-embedded – z.B. in jpg Comments, cmd, exe, dll … embedded in double enveloped oder mittels Archivierungswerkzeugen rekursiv verpackte Objekte …) was z.B. über Produkte wie XRayWatch getan werden kann. Daten auf den Intranet-Servern sind natürlich geprüft und deshalb von diesen Schutzverfahren völlig auszunehmen. Diese Unterscheidung zwischen Intranet und Internet und evtl. noch Extranet und die oben genannten Integrationen für Druck und Datenimport machen solche Lösungen „im Eigenbau“ sehr komplex. Deshalb empfiehlt es sich auf fertige Marktprodukte zurückzugreifen, die auch die komplexen Fragen rund um das Patchen und der Wartung lösen.
3. Virtualisierung des Mail-Clients: Die Virtualisierung des Mail-Clients darf aus Gründen des Datenschutzes nicht auf einem Opfersystem in der DMZ stattfinden, sondern muss im inneren Netz implementiert sein. Aus Sicherheitssicht am besten hinter einer Firewall.
Der Zweck des E-Mail-Clients liegt in der Kommunikation von strukturierten und unstrukturierten Daten. Wieder sind Inhalte, die aus dem eigenen Unternehmen kommen anders zu behandeln als Daten „von außen“. Wieder gilt es wie oben jeden aktiven Code aus den Mails und ihren Anhängen sicher zu identifizieren und Schadcode sicher auszumustern. AntiVirus Lösungen genügen hier nicht, wie Locky gezeigt hat, denn die pattern-basierte Schadcode-Suche von Anti-Viren-Lösungen hat eine Latenzzeit von mehreren Stunden.
Praktisch ist es optimal, potentiell kritischen Code zu identifizieren und sofort in eine geeignete Sandbox, also eine Schutzzone zu übermitteln und erst dort auszuführen. Es sei denn alle Anwender können auf jedes Attachment verzichten in welchem Makros oder anderer ausführbarer Code enthalten ist, was in den seltensten Fällen gegeben ist. Die Sandbox muss nun bestimmte Sicherheitsvoraussetzungen erfüllen, die sicherstellen, dass ein Zugriff auf andere Kennungen (Mimikatz, PassTheHash etc.), eine Nutzung von technischen Standard-Accounts, eine Nutzung von Schwachstellen im Opfersystem, etc. nicht dazu führen kann, dass Dateien außerhalb der Sandbox mit Schadcode befallen werden können. Gleichzeitig muss aber für den Anwender die Möglichkeit bestehen Daten aus der Sandbox heraus zu transportieren, da Ausdrucke, Screenshots, Datenexporte in vielen Fällen zwingend erforderlich sind. Eine reine „Prüfung“ der Anhänge in einer Sandbox genügt nicht, da Advanced persistant Threats (APT) die Ausführungsumgebung analysieren und sich nur in realen benutzergesteuerten Umgebungen zeigen.
Diese Komplexität führt ebenso wie in dem Fall der virtualisierten Browser dazu, dass eine vorgefertigte Lösung, die vom Hersteller gemanagt wird, selbst gebauten Systemen vorzuziehen ist.
4. Schutz vor USB-Angriffen: der Schutz vor Angriffen über USB oder allgemeiner allen Schnittstellen (Ports) eines Clients oder Servers bezieht sich nicht nur auf den Schutz vor:
a. Dateien, die den Angriff in sich tragen, sondern auch auf Angriffe, die
b. Schwachstellen des Betriebssystems im Plug and Play Subsystem ausnutzen (z.B. lnk) und
c. Angriffen aus dem Controller der Geräte (Devices) an diesen Schnittstellen (z.B. BadUSB).
Es gilt die Angriffe aller drei Kategorien sicher abzuwehren.
Die Angriffe unter b und c (z.B. lnk, BadUSB …) werden von den wenigsten Device Control Lösungen abgewehrt. Aktuelle Tests in der Bundesverwaltung haben gezeigt, dass sich einige Device Control Lösungen bereits durch simple Tricks der Anwender aushebeln lassen – umso einfacher natürlich durch professionellen Schadcode. Die wesentlichsten Punkte zum Schutz vor Locky über USB Datenträger bestehen also in folgenden – robust implementierten – Maßnahmen. Organisatorische Anweisungen können hier nicht helfen, da der Anwender den Controller oder die zu lesende Datei nicht vorher inspizieren kann, ob sich z.B. in dem jpg ein Executable in den Kommentaren oder ausführbarer Code in einem rtf verbirgt.
Die Angriffe werden professionell erstellt und als Toolkit im Darknet verkauft, so dass auch DV-Laien sich ihren eigenen Angriff zusammenbauen können. Die Abwehr muss deshalb professionellen Schutz implementieren – also robust gegen Angriffe sein, sonst ist sie das Geld und die Zeit nicht wert die man zur Umsetzung benötigt.
Optimal ist es natürlich mit einer einzigen Lösung mit einer prüfbaren und durch Experten im Schutzgrad geprüften Implementierung vor allen Bedrohungen zu schützen und trotzdem das Arbeiten des Anwenders zu unterstützen.
Wie kann man sich vor Locky und anderen Krypto-Trojanern sicher schützen?
Optimaler Schutz besteht nur über integritätsgeschützte, als Opfersystem ausgelegte, sicher gekapselte Systeme die keinen Durchgriff auf produktive Systeme haben und das Ausbrechen aus einer Virtualisierung mit zusätzlichen Mitteln verhindern, wie z.B. die virtuelle Schleuse ReCAppS:
Mit ReCAppS, Remote Controlled Application System, werden die potentiell kritischen Daten automatisch, für den Anwender nahtlos in eine virtuelle Quarantäne gebracht und dort durch die geeigneten Anwendungen geöffnet, um zu verhindern, dass potentiell enthaltener Schadcode die produktiven Systeme infiziert. In einer „Remote Controlled Session“ kann der Anwender alle aktiven Inhalte nutzen und beliebige Daten einsehen, sowie kritische Aktionen durchführen, ohne die produktive Umgebung zu gefährden. Kritisch ist etwa das Anklicken einer problematischen URL, das Herunterladen von ausführbaren Elementen aus dem Internet, das Anstecken eines fremden nicht in Echtzeit geprüften Peripheriegerätes (siehe auch Angriffsvektor BadUSB), das Installieren einer unbekannten Anwendung von einem fremden Datenträger oder aber eben wie das Beispiel Locky zeigt das Öffnen von E-Mail Anhängen, welche ausführbaren Code beinhalten. Inhalte werden sowohl auf dem Remote Controlled System als auch auf dem Client des Anwenders nach den zentralen Vorgaben kontrolliert, so dass kein Schadcode ins interne Netz gerät.
Die Virtualisierung von potentiell schädlichen Inhalten und unbekanntem Code alleine ist als Lösung jedoch zu kurz gegriffen. Erst wenn die Arbeitsergebnisse aus der virtualisierten Umgebung sicher in die Prozesse der Produktionsumgebung eingebunden werden und die Aktivitäten in der virtualisierten Welt nahtlos und barrierefrei automatisch für den Anwender eingebunden sind, schafft das effiziente sichere Arbeitsumgebungen, die gleichzeitig prüfbar geschützt sind. Dazu müssen Virtualisierung, Applikations- und Contentkontrolle sowie Verschlüsselung geeignet kombiniert werden und können dann die sichere und flexible Alternative zu rigiden Verboten oder physikalisch getrennten Systemen darstellen. Durch ein Remote-Controlled-Application-System (kurz ReCAppS) werden sicherheitskritische Aktionen in der produktiven Umgebung sicher erkannt und dann automatisch in eine virtualisierte Umgebung ausgelagert. Inhalte werden sowohl auf dem Remote Controlled System als auch auf dem produktiven Client-System des Anwenders nach den zentralen Vorgaben kontrolliert, so dass kein Schadcode ins interne Netz gerät. Wesentlich ist hier, dass eine Prüfung auf Schadcode wie sie von Anti Viren Programmen durchgeführt wird, nicht ausreicht, da jeder potentielle Code der fremd und nicht positiv authentisiert ist erkannt werden muss und in der virtuellen Schleuse auszuführen ist.
Für den sicheren Betrieb von Browsern hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) mit ReCoBS ein Konzept vorgestellt, welche das sichere Surfen durch Auslagern des Browsers in die sogenannte demilitarisierte Zone (DMZ) über eine Trennung von Anzeige und Ausführung ermöglicht. Die ReCAppS Lösung nutzt dieses Verfahren nicht nur zum sicheren Betrieb des Browsers, sondern für alle ungeplanten, sicherheitskritischen Aktionen.
Ein Remote-Controlled-Application-System ergänzt damit das BSI-Verfahren ReCoBS und kann also für alle unbekannten oder ungeplanten sicherheitskritischen Aktionen verwendet werden. Dieses Verfahren erweitert ReCoBS auch um einige in der Praxis wesentliche Elemente. Arbeitsergebnisse, die der Anwender in der virtuellen Schleuse erstellt hat, können über spezielle abgesicherte Kanäle ausgedruckt werden, ohne dass der Ausdruck selbst wieder eine Angriffsmöglichkeit darstellt.
Neben dem Drucken unterstützen ReCAppS auch den Datentransport für den Anwender vollautomatisch. Der Datentransport wird durch eine automatische Datenkonversion abgesichert, so dass nur sichere „Bilder“ aber keine ungeprüften Makros oder Ähnliches transportiert werden. Gegenüber Standardschleusen und physikalisch getrennten Netzen, die mittels einer „Drehstuhlschnittstelle“ gekoppelt sind hat diese Lösung einen entscheidenden Vorteil: Der an der Drehstuhlschnittstelle verwendete oder in dem Schleusensystem als „geprüft“ markierte Datenträger kann selbst von Schadcode wie BadUSB befallen sein. Dadurch, dass es in ReCAppS keinen Kontakt des Datenträgers zum produktiven System gibt fällt ein wesentlicher Angriffsvektor weg. Auch Angriffe wie .lnk oder ähnliche sind dadurch eliminiert.
Details zu Locky
So genannte Krypto-Trojaner können sich in einer auf den ersten Blick harmlosen E-Mail-Rechnung verbergen. Wer den Anhang so einer E-Mail anklickt, infiziert seinen Rechner mit der Verschlüsselungssoftware und hat damit keinen Zugriff mehr auf seine Daten.
Ist der Computer infiziert, werden durch den Trojaner alle Dateien mit vordefinierten Endungen verschlüsselt - und tragen zum Beispiel den Namen „*.Locky“. Es sind mehr als 100 Dateiendungen hinterlegt. Nur eine Datei ist lesbar: Die mit einer Lösegeldforderung der Erpresser, die auch eine genaue Handlungsanweisung enthält. In der Internetwährung Bitcoin soll das Lösegeld gezahlt werden – meist ca. 400 Euro. Eine Anweisung, wie ein Konto in der Internetwährung eröffnet werden kann, schicken die Kriminellen gleich mit.
Weitere Verbreitungswege von Krypto-Trojanern sind Drive-by Attacken, watering hole, USB-Datenträger in doppelter Weise: einmal über infiltrierten Content, der identisch zu den Mail-Anhängen oben gestaltet ist, oder noch perfider, wenn der Krypto-Trojaner gleich im Controller des USB-Datenträgers verborgen ist.
Deshalb sind in diesem Zusammenhang fremde USB Sticks oder allgemeiner fremder Peripheriegeräte nicht weniger gefährlich, denn auch in einer schicken Maus oder einer Tastatur kann sich ein Trojaner verbergen. Auch in der Firmware können sich Krypto-Trojaner verbergen, im so genannten Controller des USB-Sticks. Dann hat man keine Chance, die Schadsoftware zu erkennen. Einmal eingesteckt, zieht sich der Trojaner das weitere Verschlüsselungsprogramm aus dem Netz. Für so genannte Targeted Attacks, also ganz gezielt Angriffe auf Firmen oder konkrete IT-Systeme in einer Firma werden subtile Wege verwendet.
Bei den Recherchen des Bayerischen Rundfunks zu „Locky“ wurde auch Ramon Mörl (Geschäftsführer itWatch) als IT-Security Experte zu Rate gezogen (TV-Beitrag BR vom 11.03.2016 ansehen). Unter anderem ging es bei diesem Austausch um konkrete Fälle: Auf Anfrage des Bayerischen Rundfunks habe eine Firma aus Mecklenburg-Vorpommern bestätigt, sie habe niemals eine mit einem Krypto-Trojaner versehene Rechnung per Email verschickt. Die Rechnung liegt der Redaktion aber vor. Sie enthält einen Anhang, der die Verschlüsselungs-Werkzeuge aus dem Internet herunterlädt. „Die vermeintlichen Absender der Rechnungen sind oftmals doppelt geschädigt, denn ihre Kennungen und Namen werden ohne ihre Kenntnis benutzt, um den Schadcode zu verteilen. Damit ist ein Reputationsverlust verbunden.“, weiß R.Mörl und fährt fort: "Der Angreifer versucht nicht, mit dem Panzer durch die Haustür zu fahren, sondern ein kleines Stück zu verteilen. Das lädt sich dann von Servern diesen Schad-Code herunter. Und der wird dann stückweise zusammengebaut, bis er zur Anwendung kommt."
Verbreitung
In aller Regel werden die Systeme durch schadhafte E-Mail-Anhänge kompromittiert. Auch Drive-by-Infections und Malware-Makros wurden bereits festgestellt (z.B. drive-by-downloads in Kombination mit dem Neutrion Exploit-Kit).
SPAM-Mails als Verteilungsweg; Mails kommen als Rechnung daher, bisher keine Samples mit persönlicher Anrede (entweder mit „Sehr geehrte Damen und Herren“ oder ganz ohne – siehe Beispiel unten)
Infektionswege: Mail mit Officedokument + Makro[1], aber auch JavaScript-Dateien in ZIP-Attachments, Schadsoftware wird dann über das Makro / die JavaScript-Datei aus dem Internet nachgeladen. Der JAVA Code ist stark obfuskiert und häufig verschleiert z.B. in zip, um Schutzmechanismen zu umgehen. Die Domains, in welchen die Schadsoftware liegt, sind meist nur wenige Stunden gültig, d.h. man kann die Schadsoftware nur innerhalb dieser Zeit herunterladen.
Nach Ausführung werden die Nutz-Dateien verschlüsselt und mit einer Endung (häufig .locky) versehen.
_____________________
[1] Deshalb ist eine der Empfehlungen von Microsoft das Verhindern bzw. explizite Freigeben von Makros: https://blogs.technet.microsoft.com/...
Dieses Beispiel einer E-Mail liegt vor:
In den jeweiligen Verzeichnissen der verschlüsselten Dateien werden Textdateien abgelegt. Beispielhaft der Inhalt einer solchen Textdatei:
Unter http://www.heise.de/... findet sich ein bereits ins Deutsche übersetzter Text. Es kommen fast ausschließlich Bitcoin-Forderungen von Täterseite. Erfahrungsgemäß werden bei Bitcoin-Konten die (Teil-)Coins aber direkt über viele Kaskaden weiterverteilt, weswegen Bitcoin von Täterseite sehr beliebt sind.
Beispielmail:
Betreff: Ihre Rechnung D49017227657
Infektionswege
ZIP-Archiv mit Javascript-Datei als Inhalt:
<mime-attachment.png>
Word-Dokument mit maliziösem Makro:
<mime-attachment.png>
Beispieltext:
(Text war bei den Mails die bei einem befragten Provider eingingen alle gleich – geändert wurde lediglich die Kunden- und die Rechnungsnummer). Anschrift und Namen waren bei diesem Provider direkt von der Website eines Büromarktes entnommen entsprachen also real existierenden Daten zu dem Unternehmen, dem Firmensitz und den Inhabern.
