Hackere stjal hashede kodeord på AAU: Har tilgået cpr-numre og lønoplysninger på ansatte

2. september 2020 kl. 03:4521
Hackere stjal hashede kodeord på AAU: Har tilgået cpr-numre og lønoplysninger på ansatte
Illustration: AAU.
I forbindelse med cyberangrebet på Aalborg Universitet har hackere fået adgang til lønoplysninger og cpr-numre på 28 nuværende og tidligere ansatte. Politiet efterforsker sagen.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Kriminelle hackere har haft adgang til lønoplysninger og CPR-numre på nuværende og tidligere ansatte på Aalborg Universitet i forbindelse med det cyberangreb, der 4. august fik universitetet til at lukke for adgangen til alle systemer.

Det fremgår af en ny underretning om brud på persondatasikkerheden til studerende og ansatte på Universitetet, som Version2 er i besiddelse af.

Her kan man også læse, at det er er lykkedes hackeren af dekryptere flere af de hashede kodeord.

Log ind og læs videre
Du kan læse indholdet og deltage i debatten ved at logge ind eller oprette dig som ny bruger, helt gratis.
21 kommentarer.  Hop til debatten
Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
21
7. september 2020 kl. 10:59

@Michael, jeg vil da mene, at det ikke er så ligetil som du siger? Eller kender du til en cracking rutine hvor cost-per-guess er væsentlig lavere?

Artiklen nævner bot-netværk og GPU processing. Der er ingen tvivl om at hvis man vil beskytte sig mod 16-årige der downloader noget kode fra internettet, så er selv korte passwords fine. Men hvis man er mål for kriminelle grupperinger med flere ressourcer, så er situationen en ganske andet. Og hvis man skal beskytte sig mod regeringsbetalte hackere så skal vi et helt andet sted hen.

20
3. september 2020 kl. 16:55

Det synes ikke at være noget problem at brute force.

10^16 / ( 6* 10^10 gæt per dag ) giver 166.000 almindelig laptop CPU dage med artiklens antagelse.

Så det er et problem for at brute force medmindre man har større muskler eller flere penge.

Hvis vi nu siger at CPU timepriserne er blevet 10 gange billigere siden denne artikel, så vil det koste følgende for brute force cracking af fire ord fra børnehaveklasse ordbog:

100.000$ hvis hash er uddateret SHA1

20 mia $ hvis hash er bcrypt level 12.

@Michael, jeg vil da mene, at det ikke er så ligetil som du siger? Eller kender du til en cracking rutine hvor cost-per-guess er væsentlig lavere?

18
3. september 2020 kl. 12:14

Kan du huske 8 eller 10 fuldstændigt tilfældige tegn i rækkefølge?

@Michael, jeg advokerer ikke for nogen særlig løsning, bortset fra aldrig at benytte et password, der kan verificeres via haveibeenowned at være lækket.

Men jeg argumenterer for at 4 ord i træk fra en børnehaveklasseelevs ordforråd ikke let kan gættes, antaget at vi er gode til at vælge 4 tilfældige-nok ord i forhold til andre mennesker.

Du har helt ret i, at jo flere mønstre vi selv finder på for at huske passwords, jo lettere vil man kunne skyde genvej under bruteforce.

Den største udfordring pt. er at undgå genbrug af password mellem tjenester. Det eliminerer muligheden for egne stærke passwords, som huskes uden ad. I hvert fald for de fleste af os.

17
3. september 2020 kl. 12:03

Der er mig bekendt ikke noget issue med at gemme cleartext salt-værdi - du har opnået det du vil, at hashes skal brydes per user.

@Sune, det er sandt at per user salt præcis modvirker rainbow attacks. Der er bare ingen ekstra sikkerhed i at gemme et random per user salt versus at beregne et per user salt. Og man sparer et unødvendigt felt i tabellen.

Eksempel: $userhash = hash($password + $per_user_random_salt)

er ikke mere sikkert end

$userhash = hash($password + $application_salt + $username)

Antaget at hacker har kendskab til algoritme og user/application-salt.

Uden kendskab til salt er bruteforce umuligt eller salt er for kort.

16
2. september 2020 kl. 23:11

Identifikationsskema Hash-funktion Saltlængde (antal antal tegn) Saltlængde (i bit)

1 MD5-krypt MD5 8 64 2a B-crypt Blowfish 8 64 md5 Sun MD5 MD5 8 64 5 SHA-krypt SHA-256 16 128 6 SHA-krypt SHA-512 16 128

Varighed symmetrisk RSA ECC Dage-timer 50512100 5 år 73 1024 146 10-20 år 103 2048 206 30-50 år 141 4096 282

Cracking MD5-krypt med GPU hardware.

Nvidia Tesla v100 16GB.

Dubex firmaet har forstået ting baglæns.

15
2. september 2020 kl. 21:04

Benytter man 8 karakterer jævnt fordelt blandt store og små bogstaver tager det 52^8 / 60 mia/dag = 890 dage for een laptop. Per hash</p>
<p>Benytter man 10 karakterer.. 52^8 / 60 mia/dag = 2.4 mio dage for een laptop. Per hash.

Kan du huske 8 eller 10 fuldstændigt tilfældige tegn i rækkefølge? Fuldstændigt tilfældige ... dvs. valgt af en random generator. Ikke noget med at lave dit eget mønster, for så er du allerede på glat is. Måske kan man huske et eller to, men mange ... nej.

Hver eneste gang en password database lækkes, så lærer vi ikke bare password men også mønstre for passwords. Et simpelt eksempel er hvis man i stedet for "password" vælger "passw0rd" ... maskinen kan selvfølgeligt blot lære ordet ordret, men en lidt smartere maskine lærer generelt at udskifte o med 0 (nul) i ord på forskellige sprog. Dette er blot et simpelt eksempel.

En maskine vil sikkert også lære at mennesker kan huske et antal tilfældige ord (fx. 10). Og når den når til længere kombinationer af ord, så kun at vælge meningsfulde sætninger. Fordi sådan er mennesker. Måske. Jeg ved det ikke for jeg er (måske) ikke en ML bot.

Mennesker er ikke specielt unikke. Hvis du har fundet et "hemmeligt" mønster, så er der nok også mange andre på kloden der har gjort det samme. Og så kan password crackeren udnytte dette.

14
2. september 2020 kl. 19:40

Bemærk at per-user salt ikke er en tilfældig streng per user, da denne ellers skulle lagres et sted. Og så ville man ikke være kommet særlig meget videre med sikkerheden.

Jo man er.

Salt er primært tilføjet for at undgå rainbow table attacks - og det skal være per-user salt, for hvis et stort nok site (med globalt salt) fik stjålet user-hashes, vil det give mening at udregne rainbow tables.

Der er mig bekendt ikke noget issue med at gemme cleartext salt-værdi - du har opnået det du vil, at hashes skal brydes per user.

13
2. september 2020 kl. 17:07

Salt skal ikke gættes

@Sune, du har ret. Måske det skal formuleres bedre:

Hashing algoritmen mapper en streng til en streng. Password + salt til hash.

Saltet er et valg i applikationslaget.

Man benytter et per-user salt i sunde implementeringer for at samme password giver forskellige hashes per user.

Bemærk at per-user salt ikke er en tilfældig streng per user, da denne ellers skulle lagres et sted. Og så ville man ikke være kommet særlig meget videre med sikkerheden.

Per-user-salt er en streng, som alene er determineret af kendt data per bruger. Typisk brugernavnet, email eller et tilhørende id. Data som er ved hånden for applikationen, når brugeren logger ind. Meget typisk er brugernavn, email og password hash i samme tabel.

Applikationens kildekode afslører tydeligt hvorledes per-user-salt etableres. Og i alle kendte frameworks kendes per-user-salt metoden.

Man benytter af og til også et per-applikations salt, så selvom frameworket er kendt af attacker, så er hashes forskelligt fra installation til installation.

Appliklations-salt kan evt. hentes og kun lagres i ram, så kildekodelæk ikke afslører det totale salt. Dette er mere sikkert, men mindre simpelt.

Hvis nogen gætter et salt, så har man saltet for lidt.

Hvis du kender frameworket og har hashtabellen med de user data som frameworket etablerer per-user salt fra, og benytter det til at bruteforce korrekt effektivt, så er salt ikke gættet. Det er udledt.

Er framework kendt, men der også benyttes applikations-salt, som attacker ikke kender, og der bruteforces passwords. Så er der saltet for lidt.

Hvis du får en hashtabel, og du ingen andre info har om tabellen, og det lykkes at bruteforce passwords, så er der per definition gættet salt og saltet for lidt.

11
2. september 2020 kl. 16:22

Hashtabellen, som hackerne har fået fingrene i, indholder rækker med hhv. brugernavn og hash. Ellers ville tabellen være nyttesløs internt.

Hvert hash er funktion af password, salt og øvrig algoritmekonfiguration.

Hvis det er lykkedes at bruteforce passwords fra hash-tabellen, så må man nødvendigvis kende eller gætte salt og algoritme.

Hvis hackerne har adgang til kildekode eller blot hvilket framework der benyttes, så kan salt og algoritme formodes at være kendt. Hvis nogen gætter et salt, så har man saltet for lidt.

Antager vi ovenstående 60 mia forsøg per dag på en vanilje laptop, så ses det, at de 572 mio kendte lækkede passwords som haveibeenpwned har haft adgang til, kan checkes på 14 minutter. Per hash. Jeg gætter på at det er nogenlunde således at de kompromitterede passwords er fundet.

Benytter man 8 karakterer jævnt fordelt blandt store og små bogstaver tager det 52^8 / 60 mia/dag = 890 dage for een laptop. Per hash

Benytter man 10 karakterer.. 52^8 / 60 mia/dag = 2.4 mio dage for een laptop. Per hash.

Et barn i første klasse har et ordforråd på 5-10.000 ord.

Vi siger 5000 ord. Benytter man 4 ord med blandet forbogstav giver det 10000^4 / 60 mia/dag = 166.000 dage.

..4 ord, der let kan findes ved permutationer over en ordbog..

Nej. Det er ikke let at udtømme 4-ords kombinationer, selv med en lille ordbog. Selvfølgelig har XKCD ret.

Man kan mene meget om skiftende password best practices. Men en ting er sikkert. Hvis passwordet findes i haveibeenpwned, så skal man undlade at benytte det.

10
2. september 2020 kl. 15:49

... så kan man gætte passwords. AAU har ikke beskyttet "password filen" godt nok. Som eksemplet viser er hashing og salting ikke nok til at holde angribere ude. For at beskytte mod brute force skal passwords være så lange at mennesker ikke ikke kan huske dem. Derfor skal man beskytte "filen" med de hashed passwords lige så godt som hvis det blot var plaintext. Alternativt skal man over i løsninger med certificater o.lign., men hvis skurken først er så langt ide at han har adgang til de hashed passwords så er det nok game over alligevel.

8
2. september 2020 kl. 13:49

Ordbogsangreb?

Ja. Også det. Og sikkert en god blanding af forskellige tilgange, som Sune skriver, når password hashes skal knækkes.

CorrectHorseBatteryStaple er et eksempel på et langt password. Det har været brugt som eksempel i xkcd (https://xkcd.com/936/). Nogen har brugt eksemplet, så det har efterfølgende været listet på forbindelse med en opgørelse over knækkede passwords.

Og så er der selvfølgeligt problemet med at det er 4 ord, der let kan findes ved permutationer over en ordbog, så længden på over 20 karakterer er ikke godt nok: I praksis er det kun 4.

7
2. september 2020 kl. 12:51

De har vel gemt en kombo af kodeord, logonnavn og evt yderligere salt. Altså værdier på langt over 20 karakterer. At bruteforce hashværdien af inputs af den længde, tager astronomisk lang tid, med mindre man vælger en algoritme, der producerer en alt i verden for kort hashværdi.

Man laver normalt ikke exhaustive brute-force, men bruger en blanding af wordlists og permutations-regler. Og moderne grafikkort er rigtigt, rigtigt effektive til at lave en helvedes masse parallelle hash-beregninger, hvis der ikke er brugt fx scrypt.

5
2. september 2020 kl. 11:44

Der er en unøjagtighed i 3. afsnit, hvor der skrives at hash'et dekrypteres. Det kan man ikke. I stedet afprøves mulige kombinationer fra en ende af indtil et muligt kodeord, der resulterer i en hash er fundet.

Her kan man også læse, at det er er lykkedes hackeren af <strong>dekryptere</strong> flere af de hashede kodeord.

I øvrigt fremgår det ikke, hvordan hackerne kom i nærheden af passwordfilen og hvordan der var hashed - der har vi kun udtalelser fra Jacob Herbst fra Dubex, der virker ret sandsynlige.

Når der er fundet så forholdsvis få adgangskoder

de IT-kriminelle er lykkedes med at gætte 15 ud af 30.907 adgangskoder

tyder det på, at der er brugt salt og at hashingen fungerer godt. Og at de har salt, så de kan afprøve.

Der kan så være et problem med for korte adgangskoder i nogle tilfælde (15?), som dermed bliver for lette at knække, når man brute forcer password-filen.

4
2. september 2020 kl. 10:40

Hvis man laver SQL injection angreb kan man få adgang til databasen uden nogensinde at have haft adgang til filerne, det er oftest sådan at angreb som dette sker. Når man har adgagn denne vej, kan man dumpe hele databasen til lokale filer og ellers bare gå igang med at prøve koder

3
2. september 2020 kl. 09:41

For at kunne teste 60 mia kodeord om dagen, kræver det vel, at de har adgang til filen med de hashede værdier af kodeordet.

Kodeords filen er åbenbart ret dårligt beskyttet på de fleste systemer. Der regnes normalt med at hackere kan hente den og afprøve kodeord lokalt. Hvis det skulle gøres over net var der ingen grund til at kræve lange logins, da det er ret let at begrænse hvor mange login forsøg der kan gøres på en server.

2
2. september 2020 kl. 09:33

Nu spørger jeg nok lidt dumt. Undskyld på forhånd.

Der er ingen dumme spørgsmål. Kun dumme svar.

Ja der er noget der ikke hænger sammen.

... med mindre man vælger en algoritme, der producerer en alt i verden for kort hashværdi

Jeg tror de har valgt en hash der er ens for alle brugere - hvilket også bekræftes af:

Det eneste et sådant angreb kræver er kendskab til, hvilken algoritme, der har krypteret de mange passwords på universitetet. Ved man det, kan man teste, hvordan hashene for de mest almindelige, og dermed dårlige, passwords er.</p>
<p>Så hvis man får hashes, der er identiske med bare ét af dem, man har stjålet fra universitetet, når man tester de 10.000 mest almindelige, danske passwords på denne måde, har man et kodeord. Hvis Aalborg Universitet har saltet dem kræver det en tur mere i ringen, men det gør bare, at gætteriet tager længere tid.

Hvis hver password, f.eks. var saltet med brugerens email adresse eller noget andet unikt, så ville der ikke være sammenfald mellem brugerne.

1
2. september 2020 kl. 09:21

Nu spørger jeg nok lidt dumt. Undskyld på forhånd. For at kunne teste 60 mia kodeord om dagen, kræver det vel, at de har adgang til filen med de hashede værdier af kodeordet. Man kan jo ikke teste 60 mia kodeord gennem almindelig web-adgang. Så hvis de har haft adgang til at stjæle filen med hashede kodeord, har de vel også kunnet kopiere andre filer, nu de var i gang. Dernæst: Tiden det tager at bruteforce stiger eksponentielt med længden af kodeordet, men AAU har vel ikke gemt de hashede kodeord. De har vel gemt en kombo af kodeord, logonnavn og evt yderligere salt. Altså værdier på langt over 20 karakterer. At bruteforce hashværdien af inputs af den længde, tager astronomisk lang tid, med mindre man vælger en algoritme, der producerer en alt i verden for kort hashværdi.