Verschlüsselungs-Trojaner, Hilfe benötigt

[nahpets]

@Luckie

Zitat von Luckie:

@nahpets: Danke für die Ausführungen, aber das beantwortet meine Frage irgendwie nicht.

finde ich doch, die Erstellung einer vollständigen Liste der möglichen Passwörter erscheint mir unmöglich.

Übrigens habe ich doch einen gigantischen Rechenfehler eingebaut.
Es muss nicht 61^31 heißen, sondern 31^61, das sind dann ungefähr 9,4e+90 mögliche Passwörter, also noch vielvielvielviel mehr. Das ergibt dann ungefähr so was um die 3e+74 Jahre zum durchprobieren der Passwörter, pro verschlüsselter Datei! Bei einer Normalverteilung der Passwörter dürfte sich dies allerdings halbieren.

Der erforderliche Plattenplatz für die Liste der möglichen Passwörter dürfte sich auf etwas über 3,52e+68 Yottabyte belaufen.

Bisher habe ich keine Information finden können, die eine gezielte Einschränkung dieser Passwortmenge möglich erscheinen ließe.

Zitat von Luckie:

Warum generiert ihr nicht nur mögliche Passwörter und lasst alle nicht möglichen weg?

Die Antwort auf diese Frage lautet (aus meiner heutigen Sicht) schlicht und einfach: Geht nicht, zeitlich und speicherplatztechnisch nicht realisierbar.

[brick]

Hallo zusammen,

ich bin neu hier, habe aber das Thema schon einige Zeit verfolgt.
Einen Bekannten hat es auch erwischt, aber da war der Dateiverlust nicht so schlimm.

Es wurde schon viel über die Verschlüsselung geschrieben, aber was ich noch nicht gesehen habe oder auch möglicherweise überlesen habe ist, dass der Zufallsgenerator für die Passwörter/Dateinamen nicht untersucht wurde.

Hat sich jemand mal mit dem Zufallsgenerator beschäftigt, mit dem die Dateinamen erzeugt werden bzw. die Dateien verschlüsselt werden ?
Ich vermute, dass zuerst der Dateiname und dann das Passwort erzeugt werden. Alles mit der selben Funktion.
Wenn man jetzt wüsste, wie der Generator funktioniert kann man ihn mit dem Dateinamen füttern (SOGDHHsdjsh usw.) und dann eine limitierte Anzahl von Passörtern bekommen.
Damit wäre theoretisch eine Brute-Force Attacke denkbar, die man noch erleben könnte.
Wie denkt ihr darüber ? Wäre das ein Weg ?

Viele Grüße,
Robert

[Blup]

Zitat von brick:

Es wurde schon viel über die Verschlüsselung geschrieben, aber was ich noch nicht gesehen habe oder auch möglicherweise überlesen habe ist, dass der Zufallsgenerator für die Passwörter/Dateinamen nicht untersucht wurde.

Das hast du überlesen, wurde weiter vorn gründlich untersucht, der Zufallsgenerator an sich ist verdammt gut.

[deraddi]

Sorry das ich mich so extrem spät zurückmelde, habe so viel auf der Arbeit zu tun ...
habe eine neue Version "eingefangen" die hoch interessant ist: sie macht nun einiges mehr und erstellt u.a. ein Memdump und lädt ihn hoch. Wer Interesse hat, dem kann ich sie zukommen lassen.

[markusg]

also ich hab immer interesse an aktueller malware
http://markusg.trojaner-board.de

[deraddi]

Zitat von markusg:

also ich hab immer interesse an aktueller malware
http://markusg.trojaner-board.de

habe ich mehrfach versucht, bekomme immer "550, relaying denied." euer server will meine mail nicht

[pcnberlin]

Es geht wieder los

Habe hier einen Rechner mit neuem Verschlüsselungstrojaner, Datum vom 27.08.2012, Detection Ratio 5/42

IPs u.a.

seneesamj.com 203.91.113.6 A 92.50.171.166 A 123.101.2.10 A 195.198.124.60

LG aus Berlin

[bombinho]

Zitat von nahpets:

@Luckie
finde ich doch, die Erstellung einer vollständigen Liste der möglichen Passwörter erscheint mir unmöglich.

Übrigens habe ich doch einen gigantischen Rechenfehler eingebaut.
Es muss nicht 61^31 heißen, sondern 31^61, das sind dann ungefähr 9,4e+90 mögliche Passwörter, also noch vielvielvielviel mehr. Das ergibt dann ungefähr so was um die 3e+74 Jahre zum durchprobieren der Passwörter, pro verschlüsselter Datei! Bei einer Normalverteilung der Passwörter dürfte sich dies allerdings halbieren.

Die Rechnung ist nicht korrekt, da effektiv nur ein 128bit Schluessel verwendet wird. Im Worst Case sind das 2^128. Interessanter ist da der Einblick in die Prozessorarchitektur. Bei diversen Intelprozessoren reduziert sich die benoetigte Schluessellaenge auf unter 80bit.
Mit mehr Infos seitens Intel liesse sich das eventuell gar auf 56bit eingrenzen.

[bombinho]

Zitat von Blup:

Zitat von brick:

Es wurde schon viel über die Verschlüsselung geschrieben, aber was ich noch nicht gesehen habe oder auch möglicherweise überlesen habe ist, dass der Zufallsgenerator für die Passwörter/Dateinamen nicht untersucht wurde.

Das hast du überlesen, wurde weiter vorn gründlich untersucht, der Zufallsgenerator an sich ist verdammt gut.

Naja, das ist theoretisch richtig. Der Zufallsgenerator an sich ist gut. Die Parametrisierung weniger. Man haelt sich nicht an die Empfehlung des Autors. Spielt aber keine so grosse Rolle, da der Trojaner unter Win32 laeuft und deswegen einfach mal noch jede Menge andere Parameter reinspielen, die das Ausnutzen dieses Faktes bisher unmoeglich gemacht haben.

[ichi]

N'Abend zusammen.

Zunächst einmal möchte ich allen, die sich hier mit sehr viel Zeit und Herzblut in die Trojaner-Materie einarbeiten (inbs. Marcu) einen großen Respekt aussprechen!

Ein Freund hat mir eine Festplatte mit den entsprechend verschlüsselten Daten gebracht, daher bin ich auf das Thema gestossen und habe mir gerade alle 31 Seiten durchgelesen, da mich die Geschichte ziemlich gepackt hat.

Zunächst einmal möchte ich die für meine Fragen relevanten Informationen zusammenfassen. Bitte korrigiert mich sofort, sollte ich irgendetwas missinterpretiert haben.

1. Alle zum Entschlüsseln der Dateien benötigten Informationen sind in der $02-Datei (verschlüsselt) gespeichert.
2. Die $02-Datei ist mit dem RC4-Algorithmus verschlüsselt.
3. Der Schlüssel ist lokal auf dem infizierten PC erzeugt worden und NICHT von den CC-Servern beeinflusst worden.

Was ich leider noch nicht ganz verstehe, ist folgendes:

Zitat von Blup:

Die Function "RDTSC" liefert einen 64Bit-Zähler der CPU-Takte zurück.
Der niederwertige Anteil steht im 32Bit-Register EAX, der höhere im 32Bit-Register EDX.
Der Programmierer des Trojaners verwendet einen 32Bit-Wert als Ausgangspunkt für die "Zufallszahl", dafür verknüpft er die beiden Register mit xor. Das hat also nichts mit Delphi zu tun, sondern ist Teil des Programmablaufs, dessen Verständnis erst eine Einschätzung der Güte des Generators ermöglicht.

Wenn die Abfrage des Generators bei der Erzeugung des Passworts nach jeder Stelle immer im selben Abstand in CPU-Takten erfolgen würde, könnte man die Anzahl der möglichen Passwörter auf einige Milliarden eingrenzen (jeweils für einen PC/CPU). Bei meinen Versuchen schwankt die Anzahl allerdings erheblich, ich sehe hier keinen Angriffspunkt.

Wenn ich das richtig verstehe, geht es doch um den SEED des Pseudozufallszahlengenerators. Seien es jetzt CPU-Taktzyklen oder die Uhrzeit, warum genau kann man diese Wert nicht auf ein paar Milliarden Möglichkeiten eingrenzen? Die Uhrzeit des Befalls zumindest kennt man doch relativ exakt. Somit könnte man doch in vernünftiger Zeit Bruteforcen.

Evtl. kann man das ganze noch mit einer plain text attack (wie Marcu auch versucht) kombinieren - hat da mal jemand die einschlägigen Papers konsultiert?

Würde mich über alle zusätzlichen Infos den kryptographischen Teil betreffend freuen!

Beste Grüße,
ichi