Verschlüsselungs-Trojaner, Hilfe benötigt

[Marcu]

Hallo

in der angehängten Datei befindet sich ein Programm (inkl Source) mit dem man das Temp-File ohne Erweiterung entschlüsseln kann. Der Virus muss sich verschiedene Informationen merken. (z.B: Wie viele Fehleingaben es bereits gab.) So etwas findet man in diesem ersten TmpFile.

@pcnBerlin und alle die einen Debugger haben
Hast du eine Idee wie wir übersetzten Assemblercode so tauschen können, dass der andere schnell die entsprechende Codestelle im Virus finden kann? Sollen wir eine hexadezimale Bytefolge als Kommentar in den Delphicode reinschreiben? Hast du eine Ahnung was für eine Bedeutung hinter der Zeichenfolge "12341234123412341234" im Tmp-File steckt? Ist mir bisher noch nicht über den Weg gelaufen.

(Damit kein falscher Eindruck entsteht... ich spreche Delphi normalerweise nicht mit so ausgeprägtem C-Akzent. Das ist nur damit man schneller im Virencode die Parallele findet )

@CAG83
Ich glaube jeder einfühlsame Mensch hat ein Problem dir zu antworten und hofft lieber etwas übersehen zu haben was ein anderer hoffentlich findet.

[CAG83]

@Marcu:
Ich versuche, einfühlsamer zu werden
OT aus.

[pcnberlin]

@CAG83

Auch hier bei mir kommen leider immer mehr Anfragen. Unsere Strategie bei verseuten Rechnern:
1) Komplettsicherung mit z.B. True Image, wenn die Daten sehr sehr wichtig sind, dann ein dd-image
2) Virus entfernen
3) Daten retten / shadow copy -> externe HDD
4) System neu installieren, Updates, Virenscanner
5) Daten zurück

@Marcu

Hey, schön wieder etwas von Dir zu lesen! Ich bin begeistert, dass Du immer noch an dem Trojaner arbeitest. Hier ist leider gerade Land unter und ich komme nicht zum Debuggen

Zitat von Marcu:

in der angehängten Datei befindet sich ein Programm (inkl Source) mit dem man das Temp-File ohne Erweiterung entschlüsseln kann. Der Virus muss sich verschiedene Informationen merken. (z.B: Wie viele Fehleingaben es bereits gab.) So etwas findet man in diesem ersten TmpFile.

Schade, wenn es nicht mehr sein sollte, aber super Arbeit! Ich werde mir das dann auch mal genauer anschaun.

Zitat von Marcu:

@pcnBerlin und alle die einen Debugger haben
Hast du eine Idee wie wir übersetzten Assemblercode so tauschen können, dass der andere schnell die entsprechende Codestelle im Virus finden kann? Sollen wir eine hexadezimale Bytefolge als Kommentar in den Delphicode reinschreiben? Hast du eine Ahnung was für eine Bedeutung hinter der Zeichenfolge "12341234123412341234" im Tmp-File steckt? Ist mir bisher noch nicht über den Weg gelaufen.

Zur Ersten Frage: Ich habe leider spontan keinen Einfall, wie das zu realisieren wäre. Gibt es hierfür nicht irgendein plugin für OllyDbg (Logfile o.ä.)? Zur Zweiten Frage: Von der Zeichenkettenlänge her könnte es sich um einen Platzhalter für einen Paysafe/Ucash-Code handeln, ansonsten ist es mir auch noch nicht über den Weg gelaufen.

[bombinho]

Mein tmp file ist nach dem Entpacken nur voller 00h. Allerdings habe ich mit dem kleinen tool sofort wieder meinen Arbeitsplatz vor mir gehabt und noch keine Eingaben getaetigt. Version 1.555.1

[johX]

Was ist eigentlich mit den Windows-Beispielbildern?
Hat mal irgendwer verschiedene Versionen von unterschiedlichen Rechnern auf Gemeinsamkeiten in den verschlüsselten Bereichen gecheckt?

[pcnberlin]

@johX

Ich denke nicht, dass uns das wirklich weiterbringen wird. Der zur Verschküsselung genutzte Schlüssel ist sehr wahrscheinlich zumindest anteilig dynamisch. Für jede einzelne Datei wird zudem ein eigener Schlüssel generiert.

@Marcu

Ich konnte anhand eines verseuchten Rechners und Deines Tools nachvollziehen, dass in der temp-Datei (1kb) die Paysafe/Ucash-Nummer mit abgespeichert wird, vermute deshalb, dass Du 1234123412341234 mal zum Testen eingegeben hattest und das nun in Deiner Datei steht. Bei dem verseuchten Rechner wurde eine reale Nummer eingegeben (es wurde NICHT entschlüsselt) und die Nummer steht in der Datei. Habe sie auch mit dem Kundenbeleg verglichen - identisch.

[bombinho]

Kann noch jemand bestaetigen, dass EAX mit DEADCAFE geladen wird? Dann waere das ja mal ein Name fuer das Teil.

[johX]

Zitat von pcnberlin:

@johX

Ich denke nicht, dass uns das wirklich weiterbringen wird. Der zur Verschlüsselung genutzte Schlüssel ist sehr wahrscheinlich zumindest anteilig dynamisch.

Ich habe mal die relevanten Teile deiner Aussage markiert.
Ich glaube zwar auch nicht, das es großartig helfen wird, aber dann wäre zumindest ausgeschlossen, das uns dieser Ansatz weiterbringt.

Zitat von pcnberlin:

Für jede einzelne Datei wird zudem ein eigener Schlüssel generiert.

Ist das sicher oder eine Vermutung?
Klar ist für mich nur, das die verschlüsselten Bytes bei ähnlichen Dateien unterschiedlich sind.
Aber wie sieht es aus bei gleichen Dateien im gleichen Verzeichnis?
Z.B. bei 2 Durchläufen des Trojaners auf die gleichen Daten?

wo ich gerade bei den mir offenen Fragen bin:
- was passiert mit einer Datei mit z.B. 30k (40k 50k) Nullen?
- wird wirklich verschlüsselt oder einfach mit Random-Werten überschrieben?
- wie werden die Dateinamen bei unterschiedlichen Durchläufen gesetzt? (ok, eher nebensächlich)
- warum hat der Programmierer er versäumt, bei der mir vorliegenden Original-Platte das Verzeichnis c:\Lego-Bilder zu verschlüsseln/umzubennen, obwohl ansonsten auf beiden Partitionen der Platte alles versclüsselt wurde?

eventuell schaffe ich es ja, am WE mal einen Testrechner aufzusetzen.

ich kann mir nicht vorstellen, das (wie du im Blog meinst), der Programmierer eine saubere, fehlerfreie Implementierung hinbekommt. Wie war das noch mit SSL...

Gruß
Joh

[johX]

Zitat von pcnberlin:

Bei dem verseuchten Rechner wurde eine reale Nummer eingegeben (es wurde NICHT entschlüsselt) und die Nummer steht in der Datei. Habe sie auch mit dem Kundenbeleg verglichen - identisch.

Das heißt, du hast tatsächlich jemanden, der definitiv bezahlt hat und dessen PC nicht entschlüsselt wurde?
Wie wäre es mit einem offiziellem Beitrag in c't oder Co. Dann hatte ich bei meinen Kunden mal was in der Hand

[Marcu]

@pcnberlin

Zitat:

... vermute deshalb, dass Du 1234123412341234 mal zum Testen eingegeben hattest..

Es ist schön dass wenigstens du weißt was für Testdaten ich eingegeben habe. ... mein lieber Schwan ... ist das peinlich...


@Alle

Es tut mir leid. Kein Happy End!

Es gibt kein Hintertürchen im Programm, keine nennenswerten Programmierfehler, keine logischen Fehler, keine Schwachstelle in der Parametrierung der Verschlüsselungsfunktionen und keine Schwäche in der Zufallsfunktion. Ich habe die relevanten Funktionen der Malware zurückübersetzt und im Detail nachvollzogen. Es ist keine Vermutung mehr von mir und ich kann mit Sicherheit sagen: Das benötigte Passwort ist nicht mehr auf den betroffenen Computern. Es gibt keinen Weg dieses Passwort zu berechnen. Es gibt keinen Weg das Passwort zu Lebzeiten zu erraten. Es ist diesmal nicht möglich mit einem Vergleich zwischen Originaldateien und verschlüsselten Dateien eine Entschlüsselung für alle Dateien abzuleiten. Es bleibt nur zu hoffen, dass ein Polizist das Passwort zurückbringt.

Benötigt wird das Passwort für eine Datei in der zu jeder verschlüsselten Datei der Originalname, der zufällige neue Dateiname und das zufällige Passwort steht mit der die Datei verschlüsselt wurde. Der Virus speichert diese Katalogdatei im Temp-Verzeichnis mit der Dateierweiterung ".$02" ab. Z.B: 1C7F90CE4148555A5355.$02
Eigentlich wäre es sehr einfach ein Programm zu schreiben welches die Daten restauriert. Man muss lediglich das Programm unter #138 mit der Funktion unter #41 koppeln und seine entschlüsselte $02-Katalogdatei als Eingabe bereitstellen. Daraus wird leider nichts solange das Passwort zum Entschlüsseln der $02-Datei nicht herbeigeschafft ist.

Es gibt eine einzige kleine Schwachstelle im Virenprogramm, die aber nicht reicht um die Daten zu entschlüsseln. Während der Verschlüsselungsphase legt der Virus eine Datei mit der Endung ".$03" im temp-Verzeichnis an. In dieser Datei steht für jede verschlüsselte Datei die Zuordnung zwischen dem Originaldateinamen und dem neuen zufälligen Dateinamen. Diese Datei wird nach der Verschlüsselung mit einem simplen kernel32_DeleteFileA gelöscht. Man hat also tatsächlich eine Chance diese Datei wiederherzustellen.
Mit der $03-Datei ist es möglich den verschlüsselten Dateien ihren Originalnamen zurückzugeben. Jedoch bleibt es weiterhin nicht möglich die Dateien vollständig zu reparieren, da in der $03-Datei nicht das Passwort für die Verschlüsselung steht. Die $03- Datei lässt sich mit dem Programm unter #138 entschlüsseln. Das zu machen hat aber wahrscheinlich für Niemanden einen Sinn.


pcnberlin hat Recht wenn er sagt, dass man den Opfern dieser Malware nicht hilft wenn man schweigt.
Es ist allen dringend zu raten eine Anzeige zu erstatten. Wenn viele Anzeigen bei der Polizei vorliegen, erhöht das sicher die Bereitschaft zu ermitteln. Vielleicht ist der Täter nicht in Deutschland. Es kann lange dauern bis die Passwörter beschlagnahmt sind. Deswegen sollten die Opfer eine Sicherungskopie anfertigen und jetzt eine Neuinstallation durchführen.

Ich möchte mich noch bei allen bedanken. Der konstruktive und freundschaftliche Umgang bei der Analyse der Malware war echt klasse. Vielen Dank an pcnberlin und Michael und Markusg und an alle anderen.
Falls sich bei mir mehr als drei Interessierte melden, werde ich ein Paper machen in dem die Funktionsweise dokumentiert ist. Bitte PM an mich.

Noch ein letztes Wort an die Opfer - falls die hier mitlesen:
Es gibt keinen Grund mit sich selbst böse zu sein, weil man dieses blöde Zip-File angeklickt hat. Der Gebrauch von E-Mailanhängen so wie er heute üblich ist, ist leider schrecklich kaputt. Die Regeln die empfohlen werden sind ein Armutszeugnis der EDV. Wenn man sich bei dieser Sache Selbstvorwürfe macht, dann richtet man seinen Zorn an den falschen.

Viele Grüße
Marcu