Amatør-ransomware slået ud af white hat-hackere: Brugte samme nøgle til alle angreb

To nye ransomware er sat til dørs af white hat-hackere på grund af svag kryptering.

White hat-hackere har dekrypteret to nye former for ransomware med overraskende lethed, skriver The Register.

Ny "PowerWare" og den nye "Bart" har krypteret deres ofres filer siden marts, men det er slut. Hackere fra "de godes side" har med et team af AVG ingeniører regnet de to ransomware ud og slået luften ud af dem.

De var begge præget af fejl, der gjorde det muligt at dekryptere filerne frit og kvit. "PowerWares" kryptering var svag – langt svagere end den stærke Locky ransomware, som den efterlignede.

Fast nøgle gjorde det nemt at dekryptere

White hat-hackere Tyler Halfpop og Jacob Soo's beskriver her "PowerWare" og hvordan, det skal dekrypteres. De skriver:

»Denne version bruger AES-128 kryptering med en hard-coded nøgle, som gør muligt for ofre at dekryptere filer uden at betale.«'

Hard-coded betyder, at "PowerWare" brugte samme nøgle til alle krypteringer.

Voksende sport for white hat-hackere

"Bart" kommer ud til sine ofre via email. Den kan dog overkommes med AVG's dekrypterer "Så nemt som 1-2-3", skriver Jakob Kroustek her.

Dekrypteringsredskabet er blot et ud af flere, på en liste som kun bliver længere.

The Register beskriver dekrypteringen som en voksende sport blandt hackere.

Disse to ransomware var svage ifølge white hat-hackerne, men der eksisterer stadig langt stærkere ransomware. Seneste version af CTB Locker, Cryptowall og Locky er endnu ikke besejret, og fortsætter med at tvinge ofre til at betale løsesum for at få deres filer dekrypteret, skriver det britiske medie.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Følg forløbet
Kommentarer (12)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Bjarne Mathiesen

@Michael Weber : Du blander begreberne sammen.

"hardcoded" betyder, at der altid benyttes den samme nøgle, samt at denne er givet som en værdi i programmets kode.

"symmetrisk" betyder, at der benyttes den samme nøgle t/ både kodning & dekodning.

Man kan sagtens have en symmetrisk kodning, hvor en ny nøgle hentes fra en server for hvert offer. Ligeledes kan man have en hardcoded asymmetrisk nøgle.

Har man en hardcoded symmetrisk nøgle, er dekodning simpel. Har man en hardcoded asymmetrisk nøgle, må man betale for den første dekodning for at få adgang t/ den private kode.

  • 0
  • 0
Jakob Jakobsen

Giver det så ikke sig selv, at når de kan dekryptere med den hardcoded nøgle, så er der tale om symmetrisk algoritme?

Nej, de kunne lige så godt have anvendt en asymmetrisk algoritme med en hardcoded nøgle.

"Symmetrisk" har ikke noget at gøre med at den samme nøgle anvendes mod flere ofre, blot at den samme nøgle der blev brugt til at kryptere filerne, også kan dekryptere dem.

  • 0
  • 0
Jakob Jakobsen

@Michael Weber Ja, det ville man kunne. Så længe den private del af et asymmetrisk nøglepar er den samme, vil alle ofre kunne anvende den til at dekryptere. Men asymmetriske algoritmer er meget langsommere end symmetriske, og bruges derfor kun til at "destruere" den symmetriske krypteringsnøgle.

Jeg skulle mene at stort set al ransomware krypterer dine filer med en symmetrisk algoritme, og derefter krypterer den symmetriske nøgle med den offentlige del af et asymmetrisk nøglepar. Hvad enten det er den symmetriske nøgle eller det asymmetriske nøglepar der er hardcoded er uden betydning; så snart en enkelt offer har betalt for at få nøglen udleveret, kan alle andre ofre også låse op.

  • 0
  • 0
Michael Weber

Jeg skulle mene at stort set al ransomware krypterer dine filer med en symmetrisk algoritme, og derefter krypterer den symmetriske nøgle med den offentlige del af et asymmetrisk nøglepar.

Hvis man forestiller sig at det var den måde, de havde lavet deres malware på, går tingene hen og bliver lidt mystiske.

Et ransomware program med hardcoded privat nøgle. Programmet henter den offentlige nøgle og en symmetrisk nøgle (alternativt også hardcoded). Programmet krypterer filer med den symmetriske nøgle. Herefter krypteres den symmetriske nøgle med den offentlige nøgle. Den ukrypterede symmetriske nøgle slettes. Med den hardcoded private nøgle er det så muligt at dekryptere den krypterede symmetriske nøgle og med den dekrypterede symmetriske nøgle, kan de krypterede filer dekrypteres.

I sådan et program, kan man sige at der er brugt asymmetrisk kryptering og at den hardcoded nøgle kan bruges til at dekryptere filerne med.

Måske et lidt ulogisk program, men det var mere om det kunne lade sig gøre.

  • 0
  • 0
Sune Marcher

Hvad enten det er den symmetriske nøgle eller det asymmetriske nøglepar der er hardcoded er uden betydning; så snart en enkelt offer har betalt for at få nøglen udleveret, kan alle andre ofre også låse op.

Forkert.

Fornuftigt designed RansomWare genererer en 100% random symmetrisk krypteringsnøgle (eventuelt flere), og gemmer en public-key krypteret version af denne nøgle. Herefter er den symmetriske nøgle kun i hukommelsen indtil krypteringsarbejdet er færdigt.

Når du betaler for at få låst dine filer op, bliver den pubkey-krypterede symmetriske nøgle sendt til de dumme møgsvin, der med deres privkey kan dekryptere den symmetriske nøgle. Deres privkey forlader altså aldrig deres kontrol, og der er ikke nogen måde du kan regne dig frem til deres privkey(*).

(*): med mindre de har brugt en latterlig lav keysize, eller laver amatørfejl i deres brug af PRNG.

  • 0
  • 0
Sune Marcher

Det minder om SSL, hvor der benyttes en symmetrisk session key, som distribueres krypteret med en public key.

På overfladen, måske - men der er en del flere ting involveret i SSL, ikke mindst at der foregår et handshake mellem client og server. Så det er ikke en sammenligning jeg ville bruge.

Det er til gengæld helt efter bogen i forhold til hvordan man normalt laver public-key kryptering. I princippet kan du sagtens undlade at bruge et symmetrisk cipher, og så kryptere hele din datamængde med pubkey algoritmen. De er bare voldsomt meget langsommere end symmetriske ciphers.

  • 0
  • 0
Michael Weber

På overfladen, måske - men der er en del flere ting involveret i SSL, ikke mindst at der foregår et handshake mellem client og server. Så det er ikke en sammenligning jeg ville bruge.

Nu kan jeg ikke lade være med at tænke på ligheden mellem ransomware og betalt indhold på nettet f.eks. en online avis. I begge tilfælde er der noget indhold, man skal betale for at se. Når du så nævner handshake, kigger jeg på beskrivelsen her: https://www.digicert.com/ssl.htm

Nu forestiller jeg mig så en modificeret udgave af SSL-handshaket, beregnet til indhold, man har betalt for at se.

(kopieret fra https://www.digicert.com/ssl.htm med mine ændringer) En kommende abbonnent går på en avis hjemmeside og vil bestille et abbonnement:

  1. Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
  2. Server sends a copy of its SSL Certificate, including the server’s public key.
  3. Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key using the server’s public key. Browser gemmer session key lokalt, som nu er en Authorization key.
  4. Server decrypts the symmetric session key using its private key and sends back an acknowledgement encrypted with the session key to start the encrypted session. Herefter gemmer serveren session keyen i en database over kommende abonnenter. 5 Server and Browser now encrypt all transmitted data with the session key.

Nu har abonnenten betalt og session keyen er - på serveren - flyttet til en database for abonnenter og er nu en Authorization key. Nu vil abonnenten gerne se det betalte indhold:

  1. Browser connects to a web server (website) secured with SSL (https). Browser requests that the server identify itself.
  2. Server sends a copy of its SSL Certificate, including the server’s public key.
  3. Browser checks the certificate root against a list of trusted CAs and that the certificate is unexpired, unrevoked, and that its common name is valid for the website that it is connecting to. If the browser trusts the certificate, it creates, encrypts, and sends back a symmetric session key + den gemte Authorization keyen using the server’s public key.
  4. Server decrypts the symmetric session key og authentification keyen using its private key og tjekker om Authorization keyen en ligger i databasen for abonnenter. Hvis Authentification keyen ligger i databasen for abonnenter: Serveren gemmer session keyen - som en ny Authorization key - i en database over abonnenter og sletter den gamle Authorization key og Server sends back an acknowledgement encrypted with the session key to start the encrypted session.
  5. Browser gemmer den nuværende session key som den nye Authorization key.
  6. Server and Browser now encrypt all transmitted data with the session key.

Authorization keyen kan kun bruges af én klient af gangen, så man kan godt kopiere den, men så snart den bruges, skiftes den. Hvis serveren reelt sletter den gamle Authorization key når den gemmer den nye session key som den nye Authorization key, er det anonymt.

  • 0
  • 0
Sune Marcher

Nu forestiller jeg mig så en modificeret udgave af SSL-handshaket, beregnet til indhold, man har betalt for at se.

Nej :-)

1) generate prng-symkey 2) store hardcoded-pubkey-encrypted symkey on victim's disk 3) encrypt user data 4) display "you're fucked" notice 5) if user pays, send pubkey-encrypted prng-symkey til badguys. 6) on confirmed payment, retrieve decrypted prng-symkey og decrypt.

Meget, meget simplere end SSL.

  • 0
  • 0
Log ind eller Opret konto for at kommentere