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

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

Kan man ikke bare benytte den allerede etablerede terminologi og kalde det symmetrisk kryptering?

@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.

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

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

Det var da lige sådan cirka dét, jeg kom frem til.

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.

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

Hvis de havde anvendt en asymmetrisk algoritme, kunne man så dekryptere med den hardcoded nøgle (som disse whitehats gjorde)? Altså den hardcoded nøgle var dén, man dekrypterede med.

@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.

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.

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.

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.

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

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.

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.

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.