Sicherheitsexperten entschlüsseln Malware-Steuerzentrale Flame: Analyse der Command and Control Server

Autor / Redakteur: Dennis Kowalski / Peter Schmitz

Ein Team von Sicherheitsexperten konnte jetzt den Aufbau zweier Command and Control Server für den Flame Trojaner entschlüsseln und fanden dabei Hinweise auf drei bisher noch nicht entdeckte Schädlinge. Die Ergebnisse erlauben auch genaue Rückschlüsse auf die Entwickler.

Drei noch nicht entdeckte Schädlinge und mehr Infektionen als gedacht: Die Analyse der Flame Command & Control Server durch Sicherheitsexperten zeigt, wie professionell das Spionagetool entwickelt wurde.
Drei noch nicht entdeckte Schädlinge und mehr Infektionen als gedacht: Die Analyse der Flame Command & Control Server durch Sicherheitsexperten zeigt, wie professionell das Spionagetool entwickelt wurde.

Um die Supermalware Flame/Flamer ist es ruhig geworden, aber das technisch hochentwickelte Spionagetool gibt Sicherheitsexperten noch immer eine ganze Menge Rätsel auf. Der Superspion Flame wurde erstmals im Mai 2012 publik. Wir berichteten dazu bereits: Flame: Superwaffe im Cyberkrieg. Eine Gruppe aus Sicherheitsspezialisten des BSI, des ITU-IMPACT, der Kaspersky Labs und Symantec Labs haben nun einen umfassenden Bericht zu der Analyse zweier Command and Control Server veröffentlicht.

Die Serverstruktur

Bei den beschlagnahmten Servern handelte es sich um eine Debian Installation die in einer OpenVZVirtualisierung lief. Der Command and Control Server, im folgenden CC-Server genannt bestand aus den Programmiersprachen PHP, Python und bash. Zudem wurde eine MySQL Datenbank genutzt.

Bildergalerie
Bildergalerie mit 5 Bildern

Die Nutzung von OpenVZ erschwerte die Analyse, da es so nicht möglich war den freien Festplattenbereich näher auf gelöschte Daten zu analysieren. Der Server konnte über HTTPS und den Ports 443 und 8080 erreicht werden. Die Grafische Oberfläche, die unter "newsforyou/CP/CP.php" zu finden war erstaunte die Spezialisten, denn Sie war sehr minimalistisch gestaltet. Dies weicht von dem bisherigen Bild bekannter Botnet Server ab, da dort die Betreiber sehr gerne aufwendige Photoshop Grafiken nutzen. Die Analysten fanden das Passwort zu dem Adminzugang als unsalted Hash in der Datenbank und ersetzten es um sich mit einem eigenen Passwort einloggen zu können.

Bei der Entwicklung wurde auf bei Botnetzen oft gesehene Begriffe wie bot,botnet,infection verzichtet und dafür eher allgemein vorkommende Begriffe gewählt. Man wollte eindeutig unentdeckt bleiben.

Ein weiterer technischer Unterschied zu bisher bekannten CC-Servern ist die Steuerung über Steuerungspakete in Form von "tar.gz"-Containern. Diese werden an den CC-Server übermittelt wo sie dann entpackt als ".ads" und ".news" Dateien in namensgleiche Verzeichnisse verschoben werden. Diese werden dann verarbeitet und resultieren in Befehlen die an die Clients weitergeleitet werden. Der Admin kann so alle infizierten oder einzelne Systeme mit updates versorgen. Zudem wurden die Befehle mit Prioritäten versehen wodurch eine Abfolge von Befehlen möglich ist.

Schaltzentrale für weitere Schädlinge

Bei der Analyse des Sourcecodes konnten vier Kommunikationsprotokolle gefunden werden, die sehr stark vermuten lassen, dass es vier verschiedene Schädlinge gibt die durch den CC-Server gesteuert werden können. Die Namen der Protokolle lauten: "OldProtocol, OldProtocolE, SignupProtocol, RedProtocol", wobei RedProtocol noch nicht aktiv implementiert war.

Dies lässt vermuten , dass ein weiterer Schädling sich in der Entwicklungsphase befindet. Die clients wurden intern unter den Namen "IP, SPE, SP und FL" geführt (Siehe Bild 3 in der Bildergalerie). FL konnte eindeutig als Flame identifiziert werden was die Analysten zu dem Schluss kommen lässt, dass es aktuell noch 3 unentdeckte Schädlinge gibt. Aufgrund des Quelltext und der Kommunikationsweise kann definitiv ausgeschlossen werden, dass der CC-Server im Stande wäre mit den Schädlingen Gauss und Stuxnet zu kommunizieren.

Ablauf der Kommunikation und Verschlüsselung

Die Kommunikation zwischen infiziertem System und dem zentralen CC-Server bestand aus folgenden Schritten:

  • 1. Ermittlung der Protokollversion
  • 2. Speichern von Verbindungsinformationen
  • 3. Entschlüsselung der Clientrequests
  • 4. Lokales Speichern der übermittelten Daten in verschlüsselter Form im Filesystem
  • 5. Metadaten zu den erhaltenen Dateien wurden in der MySQL Datenbank hinterlegt

Ein auf dem CC-Server befindliches Script verschlüsselte die erhaltenen Daten. Es wurden hierbei PGP ähnliche Mechanismen benutzt die ein Zeichen für professionelle Programmierung sind. Zuerst wurden die Daten mit dem Blowfish Algorithmus im CBC Mode verschlüsselt. Der dazu verwandte Blowfish Key wurde für jede Datei einzeln zufällig gewählt. Dieser Blowfish Key wurde dann in einem zweiten Schritt mit asymmetrischer Verschlüsselung über die open_ssl_encrypt Funktion in PHP verschlüsselt.

Dies schützt die Daten vom Zugriff externer, da nur wer derjenige die Daten entschlüsseln kann, der den Private Key der asymmetrischen Verschlüsselung sein eigen nennt.

Die Spuren der Entwickler

Jeder Entwickler hat seinen eigenen Programmierstil und es gibt auch allgemeine Tendenzen und so konnte anhand der Analyse des Quellcodes einiges zu den Entwicklern ermittelt werden. So kann man anhand der Namenskonvention der Dateien und Klassen darauf schließen, dass es nicht typische Unix-Programmierer waren, die an dem Projekt gearbeitet haben.

So wurde z.B. jedes Wort in einer Variable, Funktion und Dateinamen mit einem Großbuchstaben begonnen, zudem gibt es spezielle Klassen die nie instanziert wurden. Klassen die nicht instanziert werden findet man in Vererbungsmechanismen der Objekt Orientierten Programmierung und werden Interfaces genannt. Der Großbuchstabe „I“ zu Beginn deutet zudem darauf hin, dass es sich um typische Windows C++ oder C# Entwickler handelt.

Die offensichtlichste Spur hinterließen die Entwickler in Form von Logs mit Zeitstempeln in den einzelnen Skripten wie im folgenden dargestellt. Zudem konnte ein Zeitstrahl der Entwicklung erstellt werden (Siehe Bild 4 in der Bildergalerie):

@author [O] censored in 12/3/2006@author [D] censored on 12/4/2006@author [D] censored on 01/23/2007@author [H] censored on 09/02/2007@author [O] censored, [D] censored@author [D] censored (modifications)@author modified heavily by [D] censored@author [R] censored @copyright 2011

Aus diesen Logs lässt sich folgende Arbeitsmengenaufteilung ableiten:

  • [D] censored: Entwickelte an 31 Dateien
  • [H] censored: Entwickelte an 10 Dateien
  • [O] censored: Entwickelte an 4 Dateien
  • [R] censored: Entwickelte 1 Datei

Die ersten Dateien wurden am 03. Dezember 2006 entwickelt. Ableitend hiervon kann nun die Aussage getroffen werden, dass die Flame-Plattform deutlich älter ist als bisher angenommen. Anhand der Arbeitsaufteilung kann man auch erkennen, dass es sich um vier Entwickler handelte bei denen der Entwickler [H] die Rolle der Teamleiters geführt haben muss. Denn dieser Entwickler ist deutlich fortgeschrittener und hat die vornehmlich die komplexen Algorithmen und Mechanismen geschrieben.

Löschskripte und die Spionagedaten

Es wurden diverse Skripte genutzt um den Server für die Funktion als CC-Server vorzubereiten sowie darauf zu achten ihn nicht mit gesammelten Daten voll laufen zu lassen. Das Server vorbereitende Skript zeigt auf, dass die Entwickler eine größere Anzahl an CC-Servern in Planung hatten und sich nicht die Arbeit machen wollten jeden Server einzeln manuell vorzubereiten. Eine in diesem Skript enthaltene Funktion zeigt auf, dass wohl Debian enthaltene Funktionen nicht so ganz bekannt waren und man hier von RedHat stammende Funktionen nutzen wollte, was das Entwicklerprofil immer deutlicher werden lässt.

Da anhand von diverser Löschskripte gesammelte Daten von den Betreibern alle 30 Minuten abgeholt und vom CC-Server gelöscht wurden ist es sehr schwer Aussagen über die gesamt gesammelte Datenmenge zu treffen. Jedoch konnte aufgrund eines Fehlers der Betreiber eine Menge von komprimiert 5.5 GB gesammelter Daten die nicht gelöscht wurden sicher gestellt werden. Zudem wurde vergessen auf einem CC-Server die HTTP Logs zu löschen wodurch man sich einen Überblick über Menge und Verteilung von Anfragen verschaffen konnte.

So wurden die Zugriffe einer Woche analysiert. Innerhalb dieser einen Woche (25.03.12-02.04.2012) verbanden sich 5377 einzelne IP-Adressen mit dem CC-Server, von denen 3702 aus dem Iran und 1280 aus dem Sudan stammen (Siehe Bild 5 in der Bildergalerie). In bisher veröffentlichten Statistiken tauchte der Sudan gar nicht auf.

Sinkhole

Die Kaspersky Labs waren in der Lage einen CC-Server zu simulieren und so eingehende Verbindung infizierter Systeme zu analysieren. Man konnte Verbindungen über 2 der genannten Protokolle feststellen: OldProtocol und OldProtocolE. Oldprotocol wurde Flame zugeordnet und OldprotocolE dem Schädling mit dem internen Namen SPE, was der Beweis ist, dass SPE aktiv verbreitet ist.

Zusammenfassung der Erkenntnisse

Die Entwicklung der Flame-Plattform begann Anfang Dezember 2006. Anhand von Quelltext Kommentaren konnten vier Entwickler bestimmt werden. Die letzte bekannte Quelltextänderung fand am 18 Mai 2012 statt. Der CC-Server ist in der Lage vier verschiedene Trojaner zu verwalten (SP, SPE, FL und IP). Es gibt 3 Kommunikationsprotokolle (OldProtocol, OldProtocolE, SignupProtocol).

Nur Flame ist von den vier Schädlingen bekannt. Der Schädling SPE ist verteilt und aktiv. Flame gehört zu den älteren der Schädlinge. Das noch nicht fertig gestellt Protokoll „RedProtocol“ zeigt auf dass die Entwicklung noch nicht komplett fertig gestellt war.

(ID:35734380)