Wie wir DirCrypt (fast) besiegt haben



    Übersetzung des Artikels von der Firma Check Point Malware Research Team.

    DirCrypt ist eine der böswilligsten Arten, Geld malvari zu erpressen. Es verschlüsselt nicht nur alle gefundenen Benutzerdateien und fordert ein Lösegeld für deren Entschlüsselung an, sondern verbleibt auch im System und erfasst und verschlüsselt Dateien, die vom Benutzer im laufenden Betrieb gespeichert wurden. Das Arbeiten am Computer wird nach seinem Erscheinen zur Qual.

    Opfern solcher Malware wird normalerweise empfohlen, Dateien aus einem frühen Backup wiederherzustellen. Aber wenn es keine solche Sicherung gibt, bleibt uns eine schwierige Wahl: Wir müssen uns mit dem Verlust von Daten abfinden oder einen Angreifer bezahlen. Wir (Malware Research Team von Check Point) haben es jedoch geschafft, im Falle von DirCrypt einen Weg zu finden, um fast alle Daten wiederherzustellen, wobei wir die Schwachstellen bei der Implementierung der Verschlüsselung ausgenutzt haben.

    Ein typisches DirCrypt-Opfer erfährt von einem Angriff erst, nachdem er begangen wurde. Malvar durchsucht die Festplatten nach Dokumenten, Bildern und Archiven. Danach wird die Zeichenfolge ".enc.rtf" zum Namen der gefundenen Dateien hinzugefügt. Wenn Sie versuchen, ihren Inhalt in einer unformatierten Form anzuzeigen, wird keine Spur alter Daten angezeigt. Nachdem Sie diese Datei als RTF-Dokument geöffnet haben, werden Anweisungen zum Bezahlen von Geld an einen Betrüger angezeigt.


    Dateisystem vor der Dateiverschlüsselung


    Dateisystem nach der Dateiverschlüsselung

    Hier beginnen wir unsere Untersuchung. Der disassemblierte Code des Programms ist verwirrt und verschleiert, und wir müssen den Code finden, der die Verschlüsselung ausführt. Da jeder verarbeiteten Datei das Suffix ".enc.rtf" hinzugefügt wird, können wir schließen, dass irgendwo im Bereich der Verschlüsselungsfunktionen ein Link zu dieser Zeile angezeigt wird. Aber nach einer kurzen Prüfung bei Hex-Rays 'IDA-Pro stellen wir fest, dass die meisten Zeilen und die Binärdatei verschleiert sind. Wir stehen also vor der ersten Aufgabe: diese Zeilen zu entschlüsseln.

    Eine Möglichkeit, nach verschlüsselten Zeichenfolgen zu suchen, besteht darin, einfach alle Abschnitte auf einen Block scheinbar zufälliger Daten zu untersuchen. Danach müssen Sie eine Funktion mit einem Querverweis (DATA XREF) auf dieses Stück Binärdaten finden. Wenn dieser Funktion ein Index übergeben wird, der innerhalb bestimmter Grenzen liegt, haben wir gefunden, wonach wir gesucht haben.

    Das Auffinden eines Bereichs mit verschlüsselten Daten erwies sich als recht einfach - dies ist ein großer Teil im Abschnitt ".data".


    Verschlüsselte Zeichenfolgen

    Nachdem wir die Querverweise auf diesen Datenblock untersucht haben, stellen wir fest, dass mehrere Funktionen darauf zugreifen, von denen eine im Code bis zu 170 Mal aufgerufen wird. Wenn wir uns direkt den Stellen des Aufrufs zuwenden, sehen wir, dass der Index als erster Parameter übergeben wird. Bingo, wir haben dich erwischt!

    Der Code selbst zum Entschlüsseln der Zeichenfolgen ist ziemlich lang und kompliziert. Da es unser Ziel ist, die Zeichenfolgen so schnell wie möglich zu entschlüsseln, haben wir diesen Algorithmus nicht umgekehrt, sondern ein kleines Skript für Windbg geschrieben, das die harte Arbeit für uns erledigt hat:

    .while (@$t0 < 0xe1) { .printf “\n%02x”, @$t0; r eip = 0x40456a; p; p; p; eb esp @$t0; p; du @eax; r $t0 = @$t0 + 0x01 }
    


    Dieser Code in der Schleife ruft die Entschlüsselungsfunktion auf und übergibt ihrerseits die Indexwerte aus dem Bereich. Die entschlüsselten Zeilen selbst werden im Terminalfenster angezeigt.


    Beispiel für die Ausgabe von dekodierten Windbg-Strings Um

    die statische Analyse zu vereinfachen , müssen wir nun die empfangenen Strings an IDA-Pro übertragen. Wir haben uns dafür entschieden, sie als Kommentare an den Stellen in den Text aufzunehmen, an denen sie verwendet werden. Dazu habe ich in IdaPython ein kleines Skript geschrieben, das eine Datei ("strings.txt") mit einem windbg-Ausgabedump erstellt und die Zeilen einfügt, in denen die Funktion zum Entschlüsseln aufgerufen wird. Jetzt können wir im Dialogfeld "DecryptString" schnell durch Querverweise auf die für uns interessanten Zeilen navigieren.



    Jetzt finden wir in der Tabelle solcher Links ".enc.rtf" und stellen fest, dass es nur an einer Stelle verwendet wird. Da das Suffix nach der Verschlüsselung zu den Dateien hinzugefügt wird, können wir davon ausgehen, dass wir uns in der Nähe des Codes befinden, der es ausführt.

    Der Code für die Funktion, die auf ".enc.rtf" verweist, ist ziemlich visuell, und IDA-Pro hat einen Teil der Arbeit für uns geleistet und sein Argument korrekt als Dateinamen definiert. Zu Beginn der Funktion wird eine weitere Funktion aufgerufen, nach der das Suffix ".enc.rtf" empfangen und dekodiert und die Datei anschließend umbenannt wird. Das heißt, es ist ersichtlich, dass der Verschlüsselungsprozess selbst vor dem Umbenennen in der allerersten Funktion stattfindet.

    Wenn wir dorthin gehen, finden wir einen umfangreichen Code mit einem sich wiederholenden Muster: Daten werden von Blöcken aus der Datei gelesen, die dann geändert und in die Datei zurückgeschrieben werden. Dies ist das klassische Verhalten von kryptografischen Funktionen. Sie können also sicher sein: Wir haben gefunden, wonach wir gesucht haben. Jetzt fängt der Spaß an.


    Externer Wrapper der Funktion, die die Verschlüsselung durchführt

    Malvar liest in einem Zyklus Teile des Inhalts der Datei, verschlüsselt sie im Speicher und schreibt sie an denselben Offsets, wobei vorherige Daten überschrieben werden.


    Verschlüsselungszyklus

    Wenn wir etwas tiefer gehen, wissen wir, dass es tatsächlich zwei Verschlüsselungsfunktionen gibt. Der erste wird für jeden Teil der gelesenen Daten aufgerufen und verschlüsselt somit die gesamte Datei. Als Argument wird ein Zeiger auf ein Objekt an diese Funktion übergeben, für die in der zweiten Funktion Daten erstellt werden. Das erfahrene Auge erkennt hier die Initialisierung des S-Blocks des RC4-Algorithmus.

    Die Verschlüsselung wird für jede Datei einzeln durchgeführt, und gleichzeitig wird der S-Block für jede Datei mit demselben Schlüssel initialisiert.


    Initialisierung und Betrieb des RC4-Algorithmus

    Wenn Sie jemals Patzer in der Kryptographie gesehen haben, werden Sie Ihren Augen einfach nicht trauen. Und da der S-Block ständig neu initialisiert wird, wird für jede Datei der gleiche Schlüsselstrom verwendet. Wir müssen noch den letzten Schritt tun: Wenn wir den ursprünglichen Inhalt der verschlüsselten Datei auf dem Computer des Opfers kennen, müssen wir die XOR-Operation Byte für Byte zwischen den ursprünglichen und den verschlüsselten Daten ausführen, um den Schlüsselstrom zu erhalten.

    OK, wir müssen die Datei finden, die sich garantiert im Windows-Dateisystem befindet. Dies sind beispielsweise Standardbilder für den Desktop-Hintergrund. Ihre Größe beträgt ungefähr 100 KB, sodass wir ohne großen Aufwand einen Schlüssel-Stream mit derselben Größe erhalten können.

    Und nur dieser Gedanke schoss uns durch den Kopf, als uns folgender Code auffiel:


    Anhängen des RC4-Schlüssels an das Ende der verschlüsselten Datei

    Nachdem wir den Kiefer vom Boden aufgehoben haben, beginnen wir, den Autor dieser unvollendeten Malvari ernsthaft zu bedauern. Wahrscheinlich verwirrt darüber, wo der Schlüssel gespeichert werden soll, beschloss er, ihn an das Ende der Datei anzuhängen, wo ihn jeder finden kann. Aus irgendeinem Grund erschien ihm diese Idee angemessen.

    Dies ist auch für uns von Vorteil: Jetzt können wir dieselbe RC4 verwenden, um die Datei vollständig zu entschlüsseln.

    Aber warte einen Moment. Hier haben wir ein weiteres Problem: Nicht nur RC4 wird zum Verschlüsseln von Dateien verwendet.


    Verschlüsselung der ersten 1024 Bytes von RSA

    Der erste Block mit einer Größe von 1024 Byte wird mit dem RSA-Algorithmus verschlüsselt. Der private Schlüssel ist nicht in der Datei gespeichert. Sie können ihn daher auch abrufen, indem Sie dem Angreifer im Austausch gegen den Schlüssel Geld zahlen. Angenommen, wir zahlen kein Geld (und greifen den Schlüsselausgabeserver nicht an), besteht der einzige Ausweg darin, alles außer den ersten 1024 Bytes zu speichern.

    In einigen Fällen (abhängig vom Format der wiederhergestellten Datei) kann dieses Problem erfolgreich gelöst werden. Nehmen wir als Beispiel eine Standard-DOC-Datei. Darin steht ab Offset 0x1A00 der Text der Datei in Unicode. Lassen Sie DirCrypt unsere experimentelle Datei verschlüsseln und vergleichen Sie deren Inhalt "vorher" und "nachher":


    Experimentelles Dokument, das vor der Verschlüsselung in einem Hex-Editor in Microsoft Word- Dokument erstellt wurde





    Das Dokument im Hex-Editor nach der Verschlüsselung

    Bei DOC-Dateien haben wir ein einfaches Python-Skript geschrieben, das den RC4-Schlüssel extrahiert, die Datei mit Ausnahme der ersten 1024 Bytes entschlüsselt und den Text in ASCII speichert. Durch Ausführen für unsere Testdatei konnten wir den Text des Dokuments vollständig wiederherstellen.


    Extrahierter Text

    Nachwort


    In diesem Artikel haben wir über Tricks gesprochen, mit denen Sie eine Sicherheitsanfälligkeit in Cryptomalvari finden können. Zunächst wollten wir zeigen, dass die Angriffe dieser Malware-Kategorie mehr oder weniger gut analysiert werden können und dass die verteidigende Seite die erfolglosen Aktionen des Angreifers fast immer erkennen und ausnutzen kann.

    Jetzt auch beliebt: