Kaspersky: Hjælp os med at bryde Gauss

Selv et program som kommer med en krypteret payload, skal stadigvæk indeholde (ukrypterede) instruktioner om hvor nøglen kan findes henne (eller hvordan den kan beregnes), da Payloaden ellers ikke kan benyttes.

Det undrer mig virkelig at Kaspersky ikke har kompetencen til at snuppe den payload. Enten er der tale om noget ekstremt sofistikeret, eller også er det bare noget de ikke er vant til at håndtere. Mit gæt er sidstenævnte, da der skam nok skal være nogen genier i det fri som kan håndtere den opgave. Spørgsmålet er så om de gider :o)

#1
Why? Hvis payload kun skal åbnes ved rette %PROGRAMFILES%, er det da en smart måde at undgå at have nøglen liggende i filen.

Athinira (1) skrev:

Selv et program som kommer med en krypteret payload, skal stadigvæk indeholde (ukrypterede) instruktioner om hvor nøglen kan findes henne (eller hvordan den kan beregnes), da Payloaden ellers ikke kan benyttes.

Læs bloggen, der er en forklaring på hvor nøglen kommer fra.

Da Stuxnet blev afsløret var der spekulationer om hvorfor det var så nemt at identificere dens mål. Stuxnet var meget målrettet. Dens payload kiggede efter en række specifikke parametre på systemet og koden blev kun aktiveret, når den nåede frem til det rigtige system.

Det blev påpeget at det kunne være meget sværere at afsløre hvilket system den var rettet imod, hvis den i stedet for at indeholde de søgte værdier indeholdte en hashværdi af værdierne.

Gauss gør netop det, og den har taget det et skridt videre ved at kryptere hele payload med en anden hashværdi af de samme systemparametre. På den måde er det ikke kun skjult hvilket system den er målrettet imod, men også fuldstændigt skjult, hvad den vil gøre hvis den inficerer målet.

Tilsyneladende er den målrettet imod systemer med et bestemt program installeret, eller en bestemt kombination af to programmer. Og Kaspersky har ikke været i stand til at finde det program Gauss er rettet imod.

Det betyder nok at enten er den rettet imod et meget specialiseret program, hvis præcise navn kun er kendt af ganske få personer. Eller også er det en hoax og den kan slet ikke dekrypteres.

Athinira (1) skrev:

eller også er det bare noget de ikke er vant til at håndtere

Jeg har læst bloggen. Jeg er ikke spor i tvivl om at de ved hvad de har med at gøre. Og nogle af dem som har kommenteret på bloggen ved også hvad de har med at gøre. De forhindrer dog ikke andre i at komme med totalt urealistiske forslag i kommentarerne, som f.eks. at lave en rainbow table over alle MD5 hashværdier.

#3
Hvis det nu var LM hashes...

Men nej.. Rainbow table af *alle* MD5 kan ikke lade sig gøre i dag :P

Jeg bemærkede en lille svaghed i den key derivation algoritme, der anvendes. Der beregnes MD5 hashes af sti og filnavne efterfulgt af to forskellige salt værdier. Den ene bruges til at verificere target, den anden til at udlede en nøgle.

Da begge hashinputs starter med stierne vil de første MD5 blokke i begge tilfælde beregnes på identiske inputs.

Dog betyder de itererede hashes at det nok er umuligt at udnytte den svaghed.

Det nemmeste vil nok stadigvæk være at finde frem til de computere som er målet for Gauss, og beregne nøglen vha. data på de computere.

#5 Kasperd: Alternativt kan man skrive en software specialiseret til at dumpe Guass hukommelse når den dekrypterer på omtalte maskiner. Alt software-kryptering har som bekendt den svaghed at krypteringsnøgler skal ligge i hukommelsen, som naturligvis kan dumpes :o)

Jeg tog selv lige et hurtigt kig på bloggen nu hvor jeg havde tid, og det ser bestemt ud til at være et større problem. Du har ret i at det nok vil kræve at man får adgang til en inficeret maskine først.

Athinira (6) skrev:

Alternativt kan man skrive en software specialiseret til at dumpe Guass hukommelse når den dekrypterer på omtalte maskiner.

Man skal jo stadig finde maskinen først. Og det eneste man har brug for af oplysninger fra den maskine er et par filnavne.

Athinira (6) skrev:

Du har ret i at det nok vil kræve at man får adgang til en inficeret maskine først.

Nej. Det er nemt nok at få adgang til en inficeret maskine. De kan jo inficere lige så mange af deres egne maskiner som de har lyst til for at se hvordan den opfører sig. Men det ville de aldrig have fundet ud af noget interessant ved.

Havde de bare observeret dens opførsel på inficerede maskiner ville de aldrig have fundet frem til den krypterede payload. Ved at analysere koden har de fundet ud af, at der er en krypteret payload.

Men for at dekryptere payloaden skal man finde en af de maskiner, der er målet for denne malware. Og det drejer sig jo netop om at finde en af de maskiner, før den bliver inficeret.

Det ville da overhovedet ikke være overraskende, hvis den krypterede payload starter med at lave lidt små modifikationer til den inficerede maskine, således at man ikke efterfølgende vil kunne genskabe krypteringsnøglen på den pågældende maskine. Payloaden behøver kun køre én gang for at droppe næste trin af malwaren.

Det er blevet foreslået at deres virusscanner kan undersøge om det system den kører på matcher kriterierne for at være et mål for denne payload, og hvis det sker, så kan virusscanneren sende oplysninger tilbage, som kan bruges til at dekryptere payload. Men ikke alle synes det ville være en acceptabel fremgangsmåde.

Dav vi ikke ved, hvad der ligger i payload, kan det være at der ligger endnu et lag af kryptering. I teorien kunne der have været udnyttet en kollision i MD5 til at give indtryk af at der kigges efter et enkelt specifikt mål, mens der i virkeligheden kigges efter to forskellige.

Det kan være at på en gruppe af mål dekrypteres en payload, som tilsyneladende skal bruge flere oplysninger for at dekryptere næste lag. Men dette er i virkeligheden blot en afledningsmanøvre, og den næste dekryptering er umulig at bryde fordi det i virkeligheden er tilfældige data.

Samtidigt kan der være en anden gruppe af mål hvor en anden payload kommer frem allerede efter den første kryptering, og dette er det egentlige mål.

Der er tre punkter som stemmer overens med ovenstående mulighed. Valget af MD5, valget af RC4 og de to forskellige check for at afgøre om dekrypteringen er korrekt.

Men salt værdien på 16 bytes er for kort til at der kan være udnyttet kendte kollisionsangreb imod MD5. Så jeg tror ikke selv helt på min teori om en mulig afledningsmanøvre. Og såfremt den teori var rigtig, så burde man også hurtigt have fundet den første dekrypteringsnøgle.

Gode pointer hele vejen igennem. Har ikke noget at tilføje :-)