Sicher ist (nicht immer) sicher

Wie Sie Daten mithilfe von Data Loss Prevention schützen
Keine Kommentare

Das Ausspähen von Daten ist ein großes Problem. Unter dem Begriff „Data Loss Prevention“ werden alle möglichen Hard- und Softwarelösungen zusammengefasst, die dem unbefugten Kopieren von Daten einen Riegel vorschieben sollen.

Lösungen zur Data Loss Prevention beginnen bei einfachen manuellen Maßnahmen wie dem Ausbau des Diskettenlaufwerks (inzwischen mangels vorhandener Laufwerke nicht mehr nötig) oder der USB-Ports (heute durch USB-Tastaturen und -Mäuse im Allgemeinen nicht mehr praktikabel). Sie reichen weiter über Programme, die das Kopieren bestimmter Dateitypen auf USB-Sticks verhindern sollen. Schließlich gibt es Lösungen, die den Versand bestimmter Dateitypen über E-Mails oder allgemein den Transport über das Netzwerk verhindern sollen. Dann gibt es Lösungen, die Dateien verschlüsseln und nur die Weitergabe der verschlüsselten Dateien erlauben, sodass nur Befugte sie außerhalb des eigenen Netzwerks entschlüsseln und lesen können, und viele weitere Lösungen für alle nur denkbaren Möglichkeiten, Daten auszuspähen bzw. von einem Rechner zu schaffen. Schließlich existieren durch eine Air Gap, also eine Luftlücke, geschützte Systeme oder Netze, die gar nicht mit dem lokalen Netz und darüber mit dem Internet verbunden sind.

Datendiebstahl – eine Bezeichnung, die falscher nicht sein könnte

Oft wird das Ausspähen von Daten in den Medien als Datendiebstahl bezeichnet. Dieses Wort ist extrem irreführend. Die Daten werden nicht gestohlen, sondern kopiert. Und das macht an zwei Stellen einen gewaltigen Unterschied aus.

Erstens: Wenn Ihnen jemand das Auto stiehlt, merken Sie es sofort, wenn Sie das nächste Mal damit fahren wollen. Wenn Ihnen aber jemand z. B. die auf dem Rechner gespeicherten Konstruktionsunterlagen des „Next Big Thing“ stiehlt, merken Sie es womöglich gar nicht. Die Daten sind ja nach wie vor vorhanden, es gibt nur eine weitere Kopie davon. Ein Datendiebstahl wird oft erst bemerkt, wenn die Daten irgendwo anders auftauchen, wo sie nichts zu suchen haben.

Zweitens: Ein gestohlenes Auto kann man zurückbekommen. Wenn es z. B. bei einer Polizeikontrolle auffällt, kann es beschlagnahmt und dem Eigentümer zurückgebracht werden. Wenn gestohlene Daten irgendwo auftauchen, kann man sie zwar auch dem Eigentümer zurückgeben, nur braucht der sie nicht, er hat ja noch seine Originale. Was aber viel schlimmer ist: Niemand weiß, wie viele weitere Kopien dieser Daten existieren. Betrachten wir das Beispiel der Konstruktionsunterlagen: Wenn diese bei einem Mitbewerber entdeckt werden, ist noch lange nicht gesagt, dass er der einzige ist, der eine Kopie hat. Der „Dieb“ kann die Daten genauso gut auch an sämtliche Mitbewerber verkauft haben.

Man sollte also gut auf seine Daten aufpassen, und die vielen verschiedenen Lösungen zur sogenannten Data Loss Prevention sollen dabei helfen. Diese lassen sich aber oft unterlaufen.

„Hiding in Plain Sight“ – Exfiltration unter aller Augen

Wie sich zumindest kleine Datenmengen unter den Augen der verschiedenen Schutzsysteme aus einem System schmuggeln lassen, haben Itzik Kotler und Amit Klein auf der Hack in the Box Amsterdam 2016 gezeigt. Ihre Ausgangssituation: Von einem Desktoprechner in einer Hochsicherheitsumgebung (High Security Enterprise) aus sollen Daten an einen Empfänger außerhalb gesendet werden. Die benötigte Bandbreite kann dabei sehr gering sein, bis zu mehreren Dutzend Bits pro Tag. Als Beispiele für die zu übertragenen Daten nennen die beiden Forscher 128 Bit lange kryptografische Schlüssel, Ja-/Nein-Aussagen oder kleine Textmengen wie Namen, einzelne Sätze und Ähnliches. Die gesuchte Exfiltrationstechnik sollte einigen Anforderungen genügen:

  1. Skalierbarkeit und Sicherheit: Die Technik sollte Kerkhoffs Prinzip entsprechen, das System also auch dann sicher sein, wenn alles außer dem verwendeten Schlüssel darüber bekannt ist.
  2. Nur Web-, und damit verbundener Traffic (z. B. HTTP, DNS, TLS …), ist erlaubt.
  3. Es darf nichts verwendet werden, was üblicherweise für die Datenübertragung genutzt wird, also keine E-Mails, keine verschlüsselten Texte, keine Google Docs, keine Forenposts usw.
  4. Es gibt eine perfekte Netzwerküberwachung. Jedes Paket wird auf allen Protokollebenen eingehend untersucht, jede Anomalie wird erkannt, Reputation und Statistiken für jeden Host und jede IP-Adresse stehen zur Verfügung usw.
  5. TLS/SSL wird unterbrochen.
  6. Der Empfänger unterliegt keinerlei Einschränkungen.
  7. Es gibt weder eine staatliche Überwachung noch eine durch eine dritte Partei. Was es gibt, sind grundlegende Schutzmaßnahmen wie Intrusion-Detection-/Prevention-Systeme und andere Sicherheitsprodukte, es sollte also z. B. kein Flooding stattfinden.
  8. Es gibt eine Zeitsynchronisation auf Sekundenbasis zwischen den Kommunikationspartnern.
  9. Methoden, die auf der Senderseite manuell implementiert werden können (also ohne Software auskommen), bekommen Bonuspunkte.
  10. Eine aktive Unterbrechung durch das Unternehmen ist eine Option.

Aus Punkt 4, der perfekten Netzwerküberwachung, ergibt sich, dass es keine direkte Kommunikation geben darf. Diese würde auffallen, da der Empfänger identifiziert und die Kommunikation dadurch aufgedeckt würde. Es muss also indirekt, z. B. über einen unbeteiligten Dritten, kommuniziert werden.

Viele traditionelle verdeckte Kanäle wie z. B. Felder in TCP/IP oder Header in HTTP scheiden dadurch aus, da sie eine direkte Kommunikation erfordern. Außerdem fallen sie oft schon bei der Anomalieerkennung auf, da die übertragenen Werte vom Standard abweichen.

Auch der IP ID Covert Channel, bei dem der Server eines unbeteiligten Dritten mit einem Betriebssystem mit einer global inkrementierten IP-ID verwendet wird, scheidet aus. Bei diesem Verfahren sendet der Sender einen Request an diesen Server, die Antwort inkrementiert den IP-ID-Zähler und der Empfänger beobachtet das Verhalten vorher/nachher. Das einzige System, das global inkrementierte IP-IDs verwendet, ist jedoch FreeBSD, und ab Version 11.0 kann es nicht über TCP-Traffic und damit das Web missbraucht werden. Punkt 2 der Forderungen lässt sich damit also nicht erfüllen.

Genauso scheidet die Nutzung des Aufrufzählers von Bitly als Covert Channel aus. Dabei wird zu einem vorher vereinbarten festen Zeitpunkt auf einen Bitly-Link zugegriffen (oder auch nicht), und der Empfänger prüft kurz vorher und nachher den Zählerstand, um einen Zugriff bzw. keinen Zugriff zu erkennen. Die Kommunikation schlägt fehl, wenn als Schutzmaßnahme Bitly-Links abgefangen, das Ziel aufgelöst und dann intern dorthin weitergeleitet wird, ohne über Bitly zu gehen.

Auch die Nutzung des Einlogzeitpunkts bei Gmail scheidet aus. Theoretisch könnte der Sender sich zu einem vorher vereinbarten festen Zeitpunkt einloggen (oder auch nicht) und der Empfänger später prüfen, wann der Sender sich zuletzt eingeloggt hat. Da Gmail aber die letzten Zugriffe aller Geräte mitsamt verwendeten Browser und Geolocation anzeigt, könnte eine Schutzfunktion die Informationen ebenfalls abfragen und auswerten. Das Gleiche gilt sinngemäß für Yahoo Mail, dort wird auch die IP-Adresse angezeigt. Außerdem wird in manchen Unternehmen der Zugriff auf E-Mail- und Social-Network-Websites generell blockiert.

Die perfekte Exfiltration nach Itzik Kotler und Amit Klein

Für die perfekte Exfiltration setzen Itzik Kotler und Amit Klein auf reguläres Browsen über HTTP/HTTPS. Der Sender modifiziert den Status der Anwendung oder höherer Protokolle, der Empfänger beobachtet die Änderungen.

Covert-Channel-Server-seitiger Cache

Benötigt wird eine populäre Website mit serverseitigem Cache, die Seiten on the fly cacht. Sie muss sehr viele Seiten haben, von denen manche nicht sehr populär sind. Ideal sind daher E-Commerce-Websites. Der Zeitpunkt des Cache kann den HTTP-Response-Headern entnommen werden, z. B. durch die Ablaufzeit. Sender und Empfänger vereinbaren eine Seite (URL) und eine Zeit. Die Seite muss unpopulär sein, damit ein Zugriff durch Dritte unwahrscheinlich ist. Um eine 0 zu senden, tut der Sender nichts. Um eine 1 zu senden, erzeugt er zur vereinbarten Zeit einen HTTP-Request für die vereinbarte Seite. 10 Sekunden nach der vereinbarten Zeit erzeugt der Empfänger einen HTTP Request für den URL und prüft, ob die Seite vor Kurzem (=1) oder soeben gecacht wurde (= 0). Dabei sind jedoch einige Punkte zu berücksichtigen:

  • Websites ändern sich; idealerweise sollte es möglich sein, dem Sender einen neuen URL mitzuteilen.
  • Die Zeitsynchronisation sollte möglichst genau sein, am besten sekundengenau. Je genauer die Synchronisation, desto weniger muss der Empfänger warten, bevor er die Daten lesen kann. Das erhöht auch die Genauigkeit der Übertragung, da die Wahrscheinlichkeit sinkt, dass in der Zwischenzeit ein unbeteiligter Dritter auf die Seite zugegriffen und das Ergebnis evtl. verfälscht hat.
  • Zur Erhöhung der Ausfallsicherheit sollte „01“ oder „10“ gesendet werden, um Netzwerkstörungen und ähnliche Probleme zu erkennen.
  • Damit der Covert Channel nicht auffällt, müssen die dazugehörenden URL-Aufrufe in einer kompletten Browsersitzung versteckt werden. Es dürfen also nicht nur willkürlich die nötigen URLs aufgerufen werden, sondern die Aufrufe müssen im Rahmen der normalen Nutzung der Website verborgen werden.
  • Außerdem muss diese Session in weiteren regulären Web-Traffic-Sessions verborgen werden. Es wäre ja doch etwas auffällig, wenn von einem Rechner, der eigentlich nie Webshops aufruft, auf einmal gezielt einige Seiten eines Shops aufgerufen werden.
  • Es müssen das Vorhandensein mehrerer Cacheserver (was während der Untersuchungen aber nicht aufgetreten ist) sowie Geo-IP-basiertes Routing berücksichtigt werden.

Dieser Angriff erfüllt alle zehn gestellten Forderungen:

  1. Skalierbarkeit und Sicherheit sind gegeben. Es kann ein eindeutiger URL (ggf. auf verschiedenen Websites) einem Bit zugewiesen werden. Weder die Kenntnis des Verfahrens noch die Kenntnis zuvor verwendeter URLs helfen bei der Aufdeckung der Kommunikation.
  2. Der Covert Channel ist rein webbasiert.
  3. Es wird nichts verwendet, was üblicherweise für die Datenübertragung genutzt wird. Der Traffic ist absolut harmlos, es werden keine Senderbits verschlüsselt oder eingebettet. Für den gesamten Traffic gibt es Erklärungen, bei der Rekonstruktion können keine verborgenen Daten gefunden werden.
  4. Die perfekte Netzwerküberwachung findet nichts Verdächtiges: Der gesamte Traffic geht vom Browser aus und ist an eine populäre Website gerichtet, alles kann regulären Aktivitäten zugeordnet werden.
  5. Falls TLS/SSL unterbrochen wird, ist das für den Covert Channel kein Problem.
  6. Der Empfänger unterliegt keinerlei Einschränkungen, was in diesem Zusammenhang aber irrelevant ist.
  7. Weder eine Überwachung noch Schutzmaßnahmen haben Auswirkungen auf den Covert Channel.
  8. Eine Zeitsynchronisation auf Sekundenbasis zwischen den Kommunikationspartnern kommt dem Covert Channel entgegen.
  9. Die Bonuspunkte für eine manuelle Implementierung auf der Senderseite können kassiert werden: Die Requests für den Covert Channel können manuell mit dem Webbrowser ausgelöst werden.
  10. Eine aktive Unterbrechung ist unmöglich.

Ein Proof of Concept des Covert Channels wurde auf GitHub veröffentlicht.

Eine Alternative mit Zählern

Das Verfahren kann auf Benutzerzähler übertragen werden, bei denen Zugriffe auf eine spezifische Seite/Ressource (YouTube-Filme, Stack-Overflow-Themen …) gezählt werden. Sender und Empfänger einigen sich auf eine nicht zu populäre Ressource und einen Zeitpunkt. Der Empfänger beobachtet vor und nach dem vereinbarten Zeitpunkt den Zähler (ohne ihn zu ändern). Der Sender lädt die Ressource zum vereinbarten Zeitpunkt herunter (=1) oder nicht (=0). Problematisch ist dabei, dass manche Social Websites wie z. B. YouTube im Unternehmensnetz blockiert sein können.

Und eine mit Onlinestatus

Auch der Onlinestatus webbasierter Chats (Facebook, Google Talk, Yahoo Chat, Skype …) kann als Grundlage des obigen Verfahrens dienen. Sender und Empfänger eröffnen jeweils einen Account und „befreunden“ sich gegenseitig. Die Datenübertragung erfolgt, indem der Sender zu einem vereinbarten Zeitpunkt online (=1) bzw. nicht online ist (=0). Außer dem Problem, dass auch diese Websites teilweise blockiert werden, kann das gegenseitige Befreunden verräterisch sein.

Eine perfekte Exfiltration ist möglich

Egal, welche Variante nun verwendet wird, fest steht auf jeden Fall, dass eine „perfekte Exfiltration“ möglich ist. Am besten ist es also, Rechner mit besonders schutzwürdigen Daten gar nicht erst mit einem Netzwerk, weder einem lokalen noch dem Internet, zu verbinden. Denn schon die Verbindung mit einem lokalen Netzwerk könnte das Ausspähen von Daten ermöglichen. Der Angreifer muss nur einen Zwischenschritt einlegen und die Daten vom Startrechner zu einem als Relay dienenden Rechner im lokalen Netz übertragen, von dem aus sie dann an den eigentlichen Empfänger im Internet gesendet werden.

Schlimmer geht immer …

Sie wissen ja, in der IT-Sicherheit ist nur eins sicher: Es kann immer nur noch schlimmer werden – was auch Itzik Kotler und Amit Klein bei der Exfiltration von Daten bewiesen haben. Auf der Black Hat USA 2017 [1] und der parallel stattfindenden DEF CON 25 [2] haben die beiden „The Adventures of AV and the Leaky Sandbox“ vorgestellt. Wieder ging es ihnen darum, Daten aus einer stark gesicherten Umgebung zu schmuggeln. Dabei gab es zwei Varianten: Entweder haben die Endpunkte nur eingeschränkten Zugriff auf das Internet (für Software- und Antivirusupdates) oder gar keinen direkten Zugriff (und Software- und Antivirusupdates werden über lokale Server ausgeliefert). Ihr Angriffspunkt ist die Cloud-Anbindung der Antivirusprodukte. Darüber lassen sich Daten aus dem geschützten Netz schmuggeln. Dafür sind zwei Voraussetzungen zu erfüllen:

Voraussetzung 1: Es muss ein Antivirusevent ausgelöst werden können. Das ist auf vielen Wegen möglich. Itzik Kotler und Amit Klein verwenden zwei sehr einfache Trigger: das Schreiben des EICAR-Testfiles (das von allen AV-Produkten als „Schädling“ erkannt wird) auf die Platte und die „Installation“ der Schadsoftware durch Verschieben der Programmdatei in den Windows-Startup-Ordner.

Voraussetzung 2: Exfiltration von einem mit dem Internet verbundenen Rechner. Auch dafür gibt es viele bereits bekannte Möglichkeiten. Die beiden Forscher haben sich für das Senden von HTTP/HTTPS Requests an den Host des Angreifers und erzwungene DNS-Auflösungen entschieden.

Ab die Post!

Für die Exfiltration über die AV-Cloud gehen Itzik Kotler und Amit Klein von folgenden Voraussetzungen aus:

  • Das AV-Produkt ist auf dem Endpunkt installiert und sendet verdächtige Dateien direkt oder indirekt an die AV-Cloud.
  • Die AV-Cloud verwendet eine Sandbox, die eine direkte Verbindung zum Internet hat.
  • Die Schadsoftware des Angreifers läuft auf dem Endpunkt.

Der Angriff besteht aus zwei Komponenten: Erstens aus der „Rakete“ (Rocket) genannten Schadsoftware des Angreifers, die die zu übertragenen Daten sammelt. Die Rakete enthält eine Kopie einer weiteren Schadsoftware, genannt „Satellit“ (Satellite). Zweitens aus der „Satellit“ (Satellite) genannten zweiten Komponente der Schadsoftware, die das AV-Produkt aktiviert und später die Exfiltration übernimmt. Der Angriff läuft dann folgendermaßen ab:

  1. Der Angreifer infiziert den Endpunkt mit der Rakete.
  2. Die Rakete sammelt die vertraulichen Daten auf dem Endpunkt und bettet sie in den Satelliten ein.
  3. Die Rakete schreibt den Satelliten auf die Platte und führt ihn aus.
  4. Der Satellit wird vom Virenscanner erkannt.
  5. Der Virenscanner sendet den Satelliten zur weiteren Untersuchung an die AV-Cloud.
  6. Die AV-Cloud führt den Satelliten in der Sandbox aus.
  7. Der Satellit sendet die gesammelten Daten an den Angreifer.

Nun sollte man ja eigentlich erwarten, dass die AV-Hersteller dafür sorgen, dass die von ihnen analysierten verdächtigen Dateien nicht „nach Hause telefonieren“. Leider ist das nicht immer der Fall, wie Itzik Kotler und Amit Klein feststellen mussten. Mit einigen AV-Lösungen war ihr Angriff erfolgreich.

AV-Cloud erkennen und lokale AV-Sandboxen

Damit der Satellit weiß, wann er Daten an den Host des Angreifers senden darf und wann nicht, muss er die Ausführung in der Sandbox der AV-Cloud erkennen. Dies ist problemlos möglich, da sich die Sandbox an vielen Stellen verrät, z. B. durch den Computernamen, die Seriennummer der Festplatte, die MAC-Adresse und vielem mehr.

Ob die Exfiltration auch über lokale AV-Sandboxen möglich ist, haben die beiden Forscher nicht getestet. Sie gehen aber davon aus, dass es bei einem nicht zu vernachlässigenden Anteil der Installationen möglich ist. Auf jeden Fall ist der Erfolg bzw. Misserfolg davon abhängig, ob und wie sowohl der ausgehende Netzwerkverkehr der Sandbox als auch der des lokalen Netzes gefiltert wird. Falls Sie selbst Experimente durchführen möchten: Die nötige Software wurde auf GitHub bereitgestellt [5].

Auf jeden Fall halten die beiden das Teilen von Schadsoftwareproben außerhalb des Unternehmens (und teilweise auch innerhalb) für gefährlich, da dabei Daten nach außen gelangen können. Außer der AV-Cloud sind z. B. auch Sicherheitsmailinglisten, Datei-Repositories und die Analyse durch Experten eine Gefahr.

Schwachstelle oder Feature?

Während einige der betroffenen Hersteller ihre Cloud-Produkte gepatcht haben, hat Kaspersky darauf verzichtet. Dort ist man (meines Erachtens zurecht) der Ansicht, dass jemand, der das genannte Szenario befürchtet, keine Daten in die Cloud schicken sollte. Was man ohnehin nicht machen sollte, wenn man sich nicht sicher ist, was man da hinschickt. Was ist, wenn einem z. B. eine per Mail zugeschickte Datei verdächtig vorkommt, man sie in die Cloud lädt und dann herauskommt, dass sie vertrauliche Informationen enthält? Natürlich hätte die Datei dann niemals unverschlüsselt per Mail verschickt werden dürfen, aber der Absender wird selbstverständlich den Empfänger für das Datenleck verantwortlich machen.

Auch VirusTotal wird die „Schwachstelle“ nicht beheben, da deren Sandboxes mit Absicht mit dem Internet verbunden sind, sodass die Kommunikation der Schadsoftware mit den Servern der Cyberkriminellen beobachtet werden kann.

Verbesserungsvorschläge für AV-Clouds

Itzik Kotler und Amit Klein schlagen folgende Verbesserungen vor:

  • Es sollte der komplette Verkehr aus der Sandbox ins Internet blockiert werden.
  • Alternativ sollten nur Proben mit dem Internet kommunizieren dürfen, die auch aus dem Internet stammen. Und zwar nur, wenn sie byteweise identisch mit der Datei aus dem Internet ist. So dürfte z. B. eine aus dem Internet geladene Rakete in der Sandbox mit dem Internet kommunizieren, nicht aber der auf dem Endpunkt „aus dem Nichts“ aufgetauchte Satellit. Für Standalone-Cloud-Scanner wie z. B. VirusTotal ist dieser Ansatz nicht anwendbar, da nicht bekannt ist, woher die hochgeladenen Dateien ursprünglich stammen.

Kommen wir nun von Rechnern mit eingeschränktem Internetzugang zu solchen, die gar keinen haben.

Funkende Rechner, ganz ohne Funkgerät

Das auch ein durch eine Air Gap geschütztes Netzwerk oder ein einzelner Rechner Daten nach draußen schicken kann, hat z. B. Ang Cui auf der Black Hat USA 2015 demonstriert [6]. Er hat mit Funtenna eine Software entwickelt, die die eigentlich nicht für diesen Zweck vorgesehene Hardware eines Rechners missbraucht, um Funksignale zu erzeugen, die dann von einem Empfänger aufgefangen werden können.

Die Software kommt ohne besondere Hardware aus, als Proof of Concept hat Ang Cui einen Laserdrucker Pantum P5202W als Sender missbraucht. Dazu wird im schnellen Wechsel der Strom für die Pins von General Purpose Input/Output (GPIO) und UART (serieller Anschluss) manipuliert, so dass sich aus den dadurch erzeugten elektromagnetischen Wellen ein moduliertes Funksignal ergibt. Im Fall des GPIO-Anschlusses war dessen Reichweite mit einigen Metern zu gering, um es auch außerhalb des Gebäudes aufzufangen. Der UART-Anschluss mit einem damit verbundenen zehn Fuß langen Kabel als Antenne erzeugte aber ein ausreichend starkes Signal, um es auch außerhalb des Gebäudes erfassen zu können.

Der Angriff lässt sich auf nahezu beliebige Hardware übertragen. Ein „harmloses“ Peripherie- oder auch IoT-Gerät zu verwenden, hat aber den Vorteil, dass diese Geräte sehr viel weniger geschützt sind als normale Rechner.

Das geht auch eine Nummer größer

David Atch und George Lashenko haben auf der Black Hat Europe 2017 ebenfalls gezeigt, wie eine Air Gap überwunden werden kann . Ihr Ziel war aber eine Nummer größer als das von Ang Cui: die Daten aus einem Industrienetzwerk herausschmuggeln, das durch eine Air Gap vom Internet getrennt ist. Nachdem die Schadsoftware z. B. über ein infiziertes Notebook in das Netzwerk gelangt ist und dort Daten gesammelt hat, steht sie vor dem Problem, diese Daten irgendwie dem Angreifer zukommen zu lassen. Sie könnte warten, bis sich wieder ein Notebook mit dem Netzwerk verbindet, aber das dauert unter Umständen zu lange, und in der Zwischenzeit könnte sie entdeckt werden.

Besser wäre es also, wenn die Air Gap überwunden werden könnte. Und das haben David Atch und George Lashenko geschafft. Auf speicherprogrammierbaren Steuerungen (Programmable Logic Controller, PLC) laufen keine Virenscanner, da ihre Leistung dafür nicht ausreicht. Die beiden Forscher programmierten den PLC so, dass er zuerst Daten sammelte und diese danach an den Angreifer funkte.

Das Funken erledigte dabei der Speicher des PLC. Beim Kopieren großer Speicherblöcke ändert sich die Frequenz der ausgestrahlten Signale. Die gesammelten Informationen werden codiert und danach Daten so im Speicher kopiert, dass darüber die Daten bitweise gesendet werden. Der Empfänger kann bis zu einem Meter entfernt sein, mit einer besseren Antenne auch weiter. Die Bandbreite beträgt 1 Bit pro Sekunde, mit besseren Algorithmen und Antennen geht es auch schneller. Die empfangenen Daten werden auf einem Rechner mit Software-defined Radio decodiert.

Fazit

Ich gehe einmal davon aus, dass jeder von Ihnen Daten auf seinem Rechner hat, die nicht für unbefugte Dritte oder gar die Öffentlichkeit bestimmt sind. Ich habe jedenfalls welche. Sofern der Rechner mit dem Internet verbunden ist, schützt uns alle nur das Desinteresse der Angreifer davor, dass diese Daten ausgespäht werden. Denn wenn ein Angreifer wirklich an Daten ran will und keinen Aufwand scheut, stoppen ihn weder Data-Loss-Prevention-Lösungen noch Air Gap – wo ein Wille ist, ist auch ein Weg. Selbst wenn die betroffenen Schutzprogramme laufend an neu vorgestellte Möglichkeiten für Covert Channel angepasst werden, verhindert das kein Datenleck. Gegen die von Itzik Kotler und Amit Klein vorgestellte perfekte Exfiltration ist jedes Programm machtlos, obwohl die Methode bekannt ist. Ohne Kenntnis des Schlüssels, also des verwendeten URL, lässt sich der Covert Channel nicht aufdecken und damit auch nicht schließen. Da kann man dann nur hoffen, dass im Falle eines Angriffs der Schadcode als solcher erkannt wird.

Wenig besser sieht es bei durch eine Air Gap vom Internet getrennten Netzen und Rechnern aus. Sobald ein Angreifer darauf Schadcode einschleusen kann, kann er auch Daten nach draußen funken. Und zum Einschleusen des Schadcodes kann er z. B. auf die Hilfe eines Innentäters oder infizierte USB-Sticks setzen. Da muss man dann wohl beim Gebäude nachrüsten: Dieses darf schlicht keine Funkwellen hinaus lassen – und in Zukunft dann auch nichts, was als Nächstes, Übernächstes, Überübernächstes … als Cover Channel genutzt wird. Irgendwie ist das alles ziemlich unschön.

Links&Literatur

[1] Black Hat USA 2017: https://www.youtube.com/watch?v=6pKLdiz18Ew
[2] DEF CON 25: https://www.youtube.com/watch?v=YZKAPKNY09g und Material

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -