Advanced Persistent Threats - So verrät sich der Angreifer!
Die "Operation Aurora", Stuxnet und der Angriff auf RSA - Advanced Persistent Threats, die man weder am eingeschleusten Schadcode noch am nachgeladenen Schadcode und seiner Steuerung erkennen kann. Und wie sieht es beim Zugriff auf die Datenbank oder dem Hinausschmuggeln der gesammelten Daten aus?
Der Zugriff auf die Daten
Jetzt klammern wir Stuxnet mal aus, da es dabei keine unbefugten Zugriffe auf Daten im eigentlichen Sinne gab. Stuxnet hat zwar die Steuerrechner manipuliert, aber das würde ich noch als "normale" Wurmfunktion einstufen.
Irgendwann greift der Angreifer auf die ihn interessierenden Daten zu. I.A. hat er sich dazu vorher die nötigen Rechte verschafft, so dass für ein Überwachungssystem alles normal aussieht. Lediglich Zugriffe zu ungewöhnlichen Zeiten könnten Verdacht erregen. Aber ein geschickter Angreifer, und den sollte man bei einem APT voraus setzen, wird darauf achten, sich nicht so leichtfertig zu verraten.
Man kann also bei Zugriffen auf die Daten nicht oder nur sehr schwer zwischen den normalen Zugriffen der dazu befugten Benutzer und den Zugriffen des Angreifers in deren Namen unterscheiden. Maximal könnte man Profile der normalen Nutzung erstellen und bei jeder Abweichung davon Alarm schlagen. Die Frage ist nur, wie praktikabel dieser Ansatz ist und ab wann man Alarm schlägt. Denn es wäre doch unpraktisch, wenn schon ein Mitarbeiter, der mehr oder andere Daten als üblich braucht, Überstunden macht oder von einem anderen als seinem eigenen Rechner auf die Daten zugreift, einen (falschen) Alarm auslöst.
Das gilt aber alles nur für die normalen Daten, auf die der Benutzer mehr oder weniger regelmäßig bei seiner normalen Arbeit zugreift. Und jetzt kommen wir zu den in der vorigen Folge erwähnten zusätzlichen Maßnahmen: Wie wäre es denn, wenn in die normalen Daten fingierte Daten integriert würden, auf die ein normaler Benutzer nicht zugreift? Jeder Zugriff auf diese fingierten Daten wäre dann ein Hinweis auf einen möglichen Angriff.
In der Tat funktioniert dieser Ansatz, und es gibt sogar einen Namen für diese fingierten Daten: Honeytoken.
Vereinfacht lässt sich das Konzept am Beispiel einer Kundendatenbank so erklären: Die Datenbank enthält außer den Kundendaten auch fingierte Einträge mit plausibel klingenden Werten. Ein Eintrag wie z.B. "Donald Duck, Entengasse 123, 45678 Entenhausen" würde ja auch beim Angreifer die Alarmglocken läuten lassen. Der Alarm wäre dann zwar schon ausgelöst, der Angreifer könnte aber noch Spuren verwischen oder schnell noch ausgespähte Daten in Sicherheit bringen.
Im normalen Arbeitsablauf gibt es keinen Zugriff auf diese Einträge, da der Kunde ja nie etwas bestellt und nirgends in Erscheinung tritt. Kopiert ein Angreifer die gesamte Datenbank, greift er auch auf die fingierten Einträge zu, was von einem Überwachungssystem erkannt werden kann. Und auch ohne Überwachungssystem kann so ein Honeytoken einen Angreifer verraten: Wird der fingierte Kunde irgendwann von der Konkurrenz kontaktiert, gab es ein Leck. Ob das dann wirklich ein externer Angreifer war oder ob ein Mitarbeiter die Kundendaten kopiert hat, muss man dann genauer untersuchen. Aber zumindest erkennt man, dass die Daten kopiert wurden.
Wir stellen also fest: Die unbefugten Zugriffe lassen sich mit zusätzlichen Maßnahmen erkennen.
Der Abtransport der Daten
Gehen wir mal davon aus, dem Angreifer ist es gelungen, unbemerkt auf die von ihm gesuchten Daten zuzugreifen und eine Kopie anzufertigen. Solange die Kopie sich nur im angegriffenen lokalen Netz befindet, ist sie für den Angreifer wertlos. Er muss die gesammelten Daten also irgendwie auf seinen eigenen Server bekommen. Im Fall von RSA wurden dazu verschlüsselte RAR-Archive per FTP auf einen externen Server übertragen, was von RSA bemerkt wurde. Und in der Tat ist der Abtransport der Daten die beste Gelegenheit, einen Angriff zu erkennen.
Ein Angreifer hat viele verschiedene Möglichkeiten, die Daten an seinen Server zu schicken: Er kann die Dateien per FTP oder HTTP auf seinen Server hochladen, per E-Mail verschicken, per Instant Messaging übertragen - jedes Protokoll, dass die Firewall des angegriffene Netzes nach außen durch lässt, lässt sich zum Übertragen der Daten missbrauchen. Dabei fallen sie aber u.U. auf, z.B. weil die Datenmenge sehr gross ist, ein auffälliges Format hat, verbotene Inhalte enthält, ... - kurz formuliert: Werden alle nach außen gesendeten Daten auf Auffälligkeiten überwacht, stehen die Chancen gut, einen Angreifer beim Hinausschmuggeln der gesammelten Daten zu erwischen. Entsprechende Systeme (und viele andere, die diesen speziellen Zweck nicht erfüllen) werden unter dem Marketingbegriff "Data Loss Prevention" verkauft. Aber da muss man sehr genau darauf achten, was man braucht und was das System zu leisten verspricht (was davon es dann hält, ist wieder eine andere Frage).
Fazit
Man kann einen APT weder am eingeschleusten Schadcode noch am nachgeladenen Schadcode und seiner Steuerung erkennen, der Angreifer verrät sich aber ggf. beim Zugriff auf entsprechend präparierte Daten, und auch beim Herausschmuggeln der gesammelten Daten aus dem lokalen Netz hat man gute Chancen, den Angriff zu erkennen. Wenn es, wie im Fall von Stuxnet, weder Zugriffe auf Daten noch eine Kommunikation mit dem Angreifer gibt, hat man allerdings kaum eine Chance, den Angriff rechtzeitig zu bemerken.
In der nächsten Folge gibt es einige weitere Beispiele für Advanced Persistent Threats.
Übersicht über alle Artikel zum Thema
- Was ist ein Advanced Persistent Threat (APT)?
- Ein bekannter Advanced Persistent Threat: Operation Aurora
- Ein weiterer bekannter Advanced Persistent Threat: Stuxnet
- Noch ein bekannter Advanced Persistent Threat: Der Angriff auf RSA
- Kann man Advanced Persistent Threats erkennen?
- Advanced Persistent Threats - Wo verrät sich der Angreifer?
- Advanced Persistent Threats - So verrät sich der Angreifer!
- Gezielte Angriffe und Advanced Persistent Threats
- Advanced Persistent Threats gegen tibetische Aktivisten und mehr
Trackbacks