Verschlüsselungs-Trojaner, Hilfe benötigt

[markusg]

die version 4.02 bietet aber nichts neues.
wegen den firmen, schaut euch da einfach die adresse an, da siet man schon, alles fake

[Daniel]

Zitat:

Zitat von markusg (Beitrag 1175198)

wegen den firmen, schaut euch da einfach die adresse an, da siet man schon, alles fake

Eben nicht - das ist es ja leider. Eine der Adressen, die heute hier veröffentlicht wurden, gibt es tatsächlich. Wer ernsthaft recherchiert, der wird früher oder später dahinter kommen, dass auch diese Firmen letztlich Opfer sind - aber bis dahin möchte ich nicht, dass Unschuldige in unmittelbarem Kontext mit diesem Trojaner genant werden. Bei Google und etwa 1.000 anderen stellen im Netz brennt sich dieser vermeintliche Zusammenhang für die Ewigkeit ein.

Ich bitte um nicht mehr, als dies zu respektieren und die Situation für die Betroffenen durch Foren-Beiträge nicht noch zu verkomplizieren.

[johX]

Zitat:

Zitat von Marcu (Beitrag 1175138)

Hi JohX

Zitat:

ich habe mir gestern mal die Auslagerungsdatei (Pagefile.sys) vorgenommen. Dort findet man massenhaft Verweise auf alte Dateinamen (vor der Verschlüsselung) und neue Dateinamen (syLAoqLgsUVxda).

Das klingt sehr gut :-)

Der Aufbau der pagefile.sys wird hier erklärt:
http://jessekornblum.com/publications/di07.pdf

wollte mich nur als Zwischenbericht melden...

Bisher bei mir bei einem Kunden (den anderen wars unwichtig; partitioniert und neu installiert):
- Wichtige Dateien waren
- OpenOffice-Rechnungen
=> glücklicherweise war ein Bild als Briefkopf; das Bild stand in der OO-Zip unter Pictures und war verschlüsselt, zwei *unwichtige* Verwaltungsdateien waren verschlüsselt (zip\Configurations2\accelerator\current.xml und zip\mimetype), die wichtigen Daten nicht.
Den Dateinamen habe ich nicht wiederhergestellt, glücklicherweise gab es 2 Tags in den Dateien: Datum und Betreff, die in 99,5% aller Dateien vorhanden waren, deshalb konnte ich dieses als Dateinamen setzen.

Gruß
Joh

[sx2008]

Falls jemand aktuelle Verschlüsselungs-Trojaner testen möchte;
auf meta$-t$v.$ru kann man sich mit dem Ungeziefer anstecken.
Aus Sicherheitsgründen habe ich das $-Zeichen mehrfach in den Link gesetzt.

Warnung :!: :!:
Diese Seite infiziert einen Windows-Rechner über Java Drive-By Exploit.
Virenscanner und Firewall nützen nichts weil die Viren noch nicht bekannt sind.
Nur aus einer virtuellen Maschine heraus kann man das Wagnis eingehen die Seite zu laden.
Die Seite einhält einen unsichtbaren Frame der wiederum ein Java-Applet enthält was ohne Rückfrage gestartet wird.
Das Jar-Archiv (=Zip-Datei) wurde anscheinend mit einem Obfusikator bearbeitet.

[Michael Habbe]

Zitat:

Zitat von Marcu (Beitrag 1174366)

Die Frage ist ob man mit einer Plaintext-Attacke auf RC4 die Bruteforce-Suche so begrenzen kann, dass man doch noch in vernünftiger Zeit ein Ergebnis bekommt.

Da muss ich doch mal nachhaken.
Wenn man nun versucht mit Bruteforce die Datei(en) zu entschlüsseln, wie kann man dann während der Suche erkennen, ob die Datei richtig entschlüsselt wurde? Man weiss ja prizipiell nicht für jede Datei genau, obs nun eine doc, jpg, odt, ... ist. Es müsste doch nach jedem Schlüssel versucht werden die Datei zu öffnen, oder?
Oder hat die RC4-Routine einen Rückgabewert, der den Erfolg anzeigt, dass der richtige Schlüssel gefunden wurde?


Michael

[Marcu]

Hallo Michael

Zitat:

Wenn man nun versucht mit Bruteforce die Datei(en) zu entschlüsseln, wie kann man dann während der Suche erkennen, ob die Datei richtig entschlüsselt wurde? Man weiss ja prizipiell nicht für jede Datei genau, obs nun eine doc, jpg, odt, ... ist. Es müsste doch nach jedem Schlüssel versucht werden die Datei zu öffnen, oder?

Genau so ist. Es gibt keinen Rückgabewert der den Erfolg anzeigt. Man muss nach nach jedem Entschlüsselungsversuch nachschauen ob es geklappt hat.

In diesem Fall muss man darauf hoffen, dass man nach der Entschlüsselung etwas bekommt das ungefähr so aussieht wie das Beispiel im Posting #247.

Anfangs hatte ich eine sehr kleine Funktion die ungefähr so aussah:

Delphi-Quellcode:

 Result := (Size >= 4)
      and (p[1] = ':') and (P[2] = '\') and (P[3] = '\')
      and (P[0] >= 'C') and (P[0] <= 'Z');

Der Ausdruck prüft einfach, ob nach der Entschlüsselung etwas vorliegt was mit "C:\\" oder mit "D:\\" oder mit ... oder mit "Z:\\" anfängt.

Es stellte sich aber heraus, dass die Funktion zu ungenau war. Es gab viele "False Positives" und viel Adrenalin wurde bei den Programmierern verschwendet die an einer Brute-Force-Methode arbeiten.

Deshalb habe ich eine genauere Funktion geschrieben:

Delphi-Quellcode:

function IsCatalogDecrypted(P: PAnsiChar; Size: DWORD): Boolean;

  function HasDriveSignature: Boolean;
  begin
    Result := (Size >= 4)
      and (p[1] = ':') and (P[2] = '\') and (P[3] = '\')
      and (P[0] >= 'C') and (P[0] <= 'Z');
  end;

  function HasValidCharacters: Boolean;
  var
    n: DWORD;
  begin
    Result := True;
    for n := 0 to Size - 1 do
      if ((P[n] < #32) and not (P[n] in [#10, #13]))
        or (P[n] in ['*', '?', '<', '>', '|', '"', '/', #127]) then
      begin
        Result := False;
        break;
      end
  end;

  function IsRndString(s: string; minlen, maxlen: Integer): Boolean;
  const // Thanks Martin!
    A = ['q', 'e', 't', 'u', 'o', 'a', 'd', 'g', 'j', 'l', 'x', 'v', 'n', 'p',
      'f', 'r', 'y', 's', 'Q', 'E', 'T', 'U', 'O', 'A', 'D', 'G', 'J', 'L', 'X',
      'V', 'N'];
  var
    i, l: Integer;
  begin
    l := length(s);
    Result := (l >= minlen) and (l <= maxlen);
    if Result then
      for i := 1 to l do
        if not (s[i] in A) then
        begin
          Result := False;
          Break;
        end;
  end;

  function HasCatalogFormat: Boolean;
  var
    sl: TStringList;
    i: Integer;
  begin
    sl := TStringlist.create;
    sl.text := copy(p, 1, size);
    result := sl.count mod 4 = 0;
    if result then
    begin
      i := 0;
      while i < sl.count - 4 do
      begin
        Result := (ExtractFilePath(sl[i]) = ExtractFilePath(sl[i + 1]))
          and IsRndString(ExtractFilename(sl[i + 1]), 14, 21) //Neuname
          and IsRndString(sl[i + 2], 30, 61) //Passwort
          and (sl[i + 3] = '');  //Leerzeile
        if not Result then
          break;
        inc(i, 4);
      end;
    end;
    sl.free;
  end;

begin
  Result := HasDriveSignature and HasValidCharacters and HasCatalogFormat
end;

Damit gab es soweit ich weiß noch keine False Positives - aber leider auch noch kein True Positive.
Die genauere Funktion prüft sehr viel mehr ab. Es wird z.B: geprüft ob die Passwörter nur aus genau den Zeichen bestehen, die Hofmar im Beitrag #181 ermittelt hat.


Viele Grüße
Marcu

[Luckie]

Wieso wird erst nach dem Entschlüsseln geprüft, ob das Passwort möglich ist? Warum generiert ihr nicht nur mögliche Passwörter und lasst alle nicht möglichen weg?

[nahpets]

Hallo Luckie,

Zitat:

Zitat von Luckie (Beitrag 1177010)

Wieso wird erst nach dem Entschlüsseln geprüft, ob das Passwort möglich ist? Warum generiert ihr nicht nur mögliche Passwörter und lasst alle nicht möglichen weg?

wenn ich das bisher hier geschriebene recht verstanden habe, so gibt es für das Passwort mindestens 61^31 Möglichkeiten, das sind also ca. 2,21e+55 Passwörter, die zu prüfen sind.

Bei der Berechnung gehe ich davon aus, dass die Länge des Passwortes auf 61 Zeichen begrenzt ist, dies ist die Länge des längsten Passwortes, welches in den weiter oben als Anhang zu findenden Dateien enthalten ist, 31 ist die Anzahl der "erlaubten" Zeichen.
Da die Passwörter aber auch kürzer sein können, kommen hier noch ca. 1^31 bis 60^31 Passwörter hinzu. Wird dürften es damit mit grob 61^32 Passwörtern zu tun haben.

Wenn Du unter diesen Bedingungen pro Sekunde 1.000.000.000 Passwörter überprüfst, bist Du "schon" in 4,28e+40 Jahren fertig. Dies entspricht in etwa dem 10e+30-fachen Zeitraum der Existenz unserer Erde. Schaltjahre sind dabei nicht berücksichtigt ;-)

Auch bei der zur Verfügungstellung sämtlicher Rechner der Forumsmitglieder und einer deutlichen Steigerung des Sekundendurchsatzes, dürfte die Berechnung insgesamt noch ein paar Jahre dauern ;-)

PS.: Bitte weise mir jemand die Fehler in meiner Berechnung nach, da mir der Aufwand zum Knacken der Passwörter doch deutlich zu hoch erscheint. :-(
PPS.: Wie lange braucht man, um eine Liste der Passwörter zu erstellen?
Die Datei für alle Passwörter bis zur Länge von fünf Zeichen ist bereits 200 MB groß (Erstellzeit ca. 70 Sekunden für 29.583.456 Passwörter),
bei sechs Zeichen sind es 7,3 GB (Erstellzeit ca. 55 Minuten für 917.087.137 Passwörter)
(Rechner: ein in die Jahre gekommener Latitude D810)

Ein Programm zum Erstellen einer Datei mit allen möglichen Passwörten hängt an.

[ulilüding]

Zu dieser Thematik eine kleine Annekdote:
Eine Bekannte hatte sich den Freund eingefangen (Mahnungs-Anhang.zip geöffnet, wie üblich). Die "böse Seite" mit der Zahlungsaufforderung erschien auch brav. Aber: War der Compi NICHT mit dem Internet verbunden, so konnte sie ihn normal benutzen. Die encrypted files waren vorhanden, die alten, unverschlüsselten, jedoch auch noch. So konnte sie offline ihre Daten retten (falls eine Neuinstallation angestanden hätte) und dann den Trojaner per AVirProg in Quarantäne schicken. Sie hat uraltes Zeug am Start: WIN XP der ersten Stunde, und ein Toshiba Laptop aus dem vorigen Jahrhundert. Da fehlte vielleicht was, um den Schaden vollständig anzurichten?
LG Uli

[Luckie]

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