Krypto-professor: Obfuskering kan stoppe falske NemID JS-klienter

4. juni 2014 kl. 14:5529
Den heftige obfuskering, der ser ud til at være brugt i NemID JavaScript, kan være for kunne validere, at der er tale om ægte NemID-kode og ikke et forsøg på hacking, vurderer kryptologi-professor Ivan Damgård.
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Muligheden for at verificere en ægte NemID-klient. Det kan være forklaringen på den obfuskering, der ser ud til at være lagt ind i koden bag kommende NemID JavaScript, vurderer professor og ekspert i kryptografi på institut for datalogi ved Aarhus Universitet Ivan Damgård.

»I et tilfælde som det her er formålet formentligt, at man gerne fra serversiden vil være sikker på, at man taler med den kode, man selv har sendt ud, og ikke med en modificeret version, der f.eks. også sender password med mere til en angriber. Det kan man forsøge at gøre ved at bage en hemmelig nøgle ind i programmet og så verificere fra serversiden, at den kode man kommunikerer med, kender nøglen. Man håber så, at hvis programmet er obfuskeret, så kan en angriber ikke finde frem til nøglen og lave sin egen version,« lyder vurderingen fra professoren i en mail til Version2.

Diskussionen om obfuskering i NemID JS er blevet aktuel her på Version2, efter datalog, internetaktivist og gør-det-selv NemID- og Rejsekort-hacker Christian Panton fandt frem til en testkode af, hvad der ser ud til at være den kommende NemID baseret på JavaScript. NemID JS-koden viser sig at være heftigt obfuskeret med det resultat, at koden ikke bare er ekstra kompliceret, men også fylder mere målt i bits og bytes, end den ellers ville gøre.

Det fik Christian Panton til at starte et projekt på GitHub, der er en webhosting-tjeneste for softwareprojekter. Pantons projekt har til formål at skrælle obfuskeringen af NemID JS. Han har fortalt til Version2, at det foreløbigt er lykkedes ham at mindske visse dele af testkoden på NemID JS med 33 pct, ved at køre den igennem den såkaldte de-obfuscator, som Panton har lagt på GitHub.

Artiklen fortsætter efter annoncen

Dermed er det spørgsmålet, om det overhovedet er umagen værd at bruge tid og kræfter på at obfuskere NemID JS, hvis det alligevel kun resulterer i computerkode, der fylder mere, og altså ikke de facto øget sikkerhed. Men det kommer an på den konkrete implementering af obfuskeringen, forklarer Ivan Damgård.

»Jeg tror de fleste er enige om at obfuskering i praksis kun kan forventes at holde i en vis begrænset tid. Så det vil sige at hvis der kun er én version af koden, og det er den der bliver sendt ud hver gang, så varer det formentlig kun en begrænset tid, før nogen har gravet den hemmelighed ud, der eventuelt er gemt derinde. Men der findes andre tilgange til obfuskering, hvor man hele tiden laver nye versioner af den obfuskerede kode, så man kan tvinge angriberen til at starte forfra hver gang. Det har en større chance for give noget sikkerhed,« skriver Ivan Damgård og understreger, at han ikke er bekendt med, hvad Nets gør i forhold til NemID JS.

Men hvis obfuskering øger kodestørrelsen, så er der også spørgsmålet, om koden dermed bliver tungere og langsommere at køre på klient-maskinerne.

»Obfuskeret kode kan være langsommere, men behøver ikke at være det. Hastighed har ikke altid en sammenhæng med hvor meget koden fylder, det er jo f.eks. ikke sikkert at det alt sammen bliver udført hver gang,« skriver Ivan Damgård.

Artiklen fortsætter efter annoncen

Version2 vil naturligvis gerne høre Nets, hvilke tilgange og overvejelser, virksomheden har i forbindelse med obfuskering i den kommende NemID JS. Virksomheden har dog tidligere afvist at kommentere på NemID JS med henvisning til, at det endelige produkt endnu ikke er frigivet.

Digitaliseringsstyrelsen har tidligere meldt ud, at NemID JS, trods problemer med en planlagt pilottest, som planlagt bliver lanceret 1. juli.

Fakta

NemID JavaScript er betegnelsen for den kommende udgave af NemID, som fungerer uden Java-platformen. Flere har kritiseret, at NemID i den nuværende form er afhængig af Java. Kritikken har blandt andet gået på, at sikkerhedshuller i Java i sig selv kan gøre en computer usikker, og desuden virker Java og dermed NemID typisk ikke på mobiltelefoner og tablets. Med til historien om NemID og Java hører sidste års opdatering fra Oracle, der står bag Java. Opdateringen bevirkede, at NemID i tre døgn ikke fungerede hos de brugere, der havde fulgt gængs sikkerhedspraksis og opdateret til den seneste Java-version. Senere viste det sig, at Nets ikke havde testet om NemID ville virke med den nye opdatering fra Oracle.

29 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
30
28. juni 2014 kl. 21:14

Man kunne forestille sig at NemID prøver at fikse det DoS problem de har haft. Hvis det var nogle af deres kald der var performance tunge, fx.

Det man kunne gøre, var at have en random algoritme, der fandt en random nøgle. Man kunne så encode kode, så den eneste måde at finde frem til nøglen, var ved at afvikle denne kode(og koden kunne være tilfældigt generet, med genveje(der ikke kunne genskabes af en angriber), så deres server ikke skulle gå igennem det samme for at finde ud af hvad resultatet var)

Denne nøgle blev så sendt med i de næste kald, for at de kan finde ud af om de overhovedet skal tage kaldet seriøst.

På den måde ville det besværre DoS angreb noget.

Synes dog ikke det er en god løsning, men kan forestille mig den i et omfang må have været nødvendig, hvis det er det de har gjort.

28
6. juni 2014 kl. 13:56

Beklager hvis det kom til at lyde som et forsvar af metoden, jeg ville egentlig bare have efterprøvet tanken og det har I på bedste vis gjort. Tak for forklaringerne.

29
6. juni 2014 kl. 14:51

No worries, den bedste måde at lære om noget på er at gennemgå det/forsvare positionen :)

22
6. juni 2014 kl. 09:00

Måske de obfuskerer koden for at afholde 99 ud af 100 version2 "eksperter" fra at kommentere på deres kode?

Obfuskering (alt efter teknik) kan give væsentlig mindre kode.

17
5. juni 2014 kl. 11:13

Og når de laver det nummer, lyder det jo totalt mere sikkert end java.... eller. Men benyt dog noget som OAuth 2, som også er nævnt i tidligere kommentarer.

16
5. juni 2014 kl. 11:08

Tjo, det kan vel nok holde de værste oppertunister væk, men er det mon dem der er problemet, eller er det de organisationer der har budget til at udføre et rimeligt angreb man skal beskytte imod?

Er sikkerheden mon baseret på at det er den "rigtige" kode der benyttes, eller er der mon et basalt problem med protokollen og virkemåden.

Hvor i systemet mon sikkerheden findes?

"Man håber så, at hvis programmet er obfuskeret, så kan en angriber ikke finde frem til nøglen og lave sin egen version"

Man håber at der ikke er nogen der kan lave sin egen version. Man prøver at undgå andre versioner af appletten, ... hmmmm

14
4. juni 2014 kl. 22:21

Det er da den argeste gang vås at påstå at obfuskering af kode på nogen måde skulle kunne lede til en sikring, validering eller på anden måde øge sikkerheden af det stykke software der skal afvikles.

Det er ren og skær røg og spejle, og som jeg skrev tidligere, hvis det er kvaliteten af den sikkerhedspolitik der ligger bag NemID, så er vi ilde stedt.

13
4. juni 2014 kl. 21:48

Under den tvivlsomme forudsætning at det ikke lykkes Christian Panton at pille koden fra hinanden så er den smarteste teknik til at omgå obfuskeringen nok at sætte en JavaScript VM op hvor man kører koden. Denne VM skal blot simulere input og output, har man gjort det rigtigt kan man praktisk talt ignorere hvad der foregår inde i koden. Man kan passende basere sin VM på en almindelig browser, så kan den obfuskerede kode tjekke alverdens browser-quirks uden at det gør nogen forskel.

Obfuskeret kode eller ej så skal man stadigvæk udføre et phishingangreb eller overtage en brugers computer for at kunne imitere denne bruger. I den sammenhæng er det værd at kritisere Nets for at bruge et ulogisk sammensurium af domæner, hvis vi kunne opsætte en simpel regel i retning af: "Du må kun indtaste dit NemID login på https://nemid.dk " så kunne man muligvis opdrage størstedelen af befolkningen til at følge reglen. Som det er nu er der klart phishingpotentiale i at brugerne ikke kan kende de officielle domæner fra phishingdomæner.

15
5. juni 2014 kl. 10:11

Under den tvivlsomme forudsætning at det ikke lykkes Christian Panton at pille koden fra hinanden så er den smarteste teknik til at omgå obfuskeringen nok at sætte en JavaScript VM op hvor man kører koden. Denne VM skal blot simulere input og output, har man gjort det rigtigt kan man praktisk talt ignorere hvad der foregår inde i koden. Man kan passende basere sin VM på en almindelig browser, så kan den obfuskerede kode tjekke alverdens browser-quirks uden at det gør nogen forskel.

Det man skal have fat i er en headless browser. På (1) er der nævnt HTMLUnit(2), alternativt kan man bruge crawljax(3) eller watij(4).

crawljax(3) har et web interface man bruger, hvori den konfigureres f.eks. til at påstå at den er en Mozilla Firefox (User-Agent), hvor HTMLUnit(2) og Watij(4) i stedet har et Java API man koder op imod.

For HTMLUnit(2)'s og Watij(4)'s vedkommende er det oplagt at lave en transparant HTTP proxy server, der også gemmer evt scripts som NemID scriptet måtte hente ind, incl rækkefølgen de hentes i samt HTTP request (med headers) såvel som reponse headers. Kan man også gemme DOM træet imellem hver script kørsel er det også muligt at se hvordan NemID scriptet arbjeder op imod at blive den færdige NemID klient.

(1): https://developers.google.com/webmasters/ajax-crawling/docs/getting-started(2): https://htmlunit.sourceforge.net/(3): https://www.crawljax.com/(4): https://www.watij.com/

12
4. juni 2014 kl. 21:23

... er vel sådan set ikke hvordan koden molestreret. Det er er langt større problem at NemID stadig skal embeddes på den side hvor jeg logger ind, og ikke findes statisk på fx. login.nemid.dk. Jeg stoler i praksis på min bank, og har derfor ingen problemer med at bruge NemID til at logge ind der. Men på www.BizartOgSkummeltSite.dk tør jeg ikke gøre det - det er simpelthen i praksis umuligt at se om det er en legitim NemID-klient, eller bare noget hjemmelavet kode der giver sig ud for at være det. Så er konceptet bag f.eks. OAuth2 (som i "Login med Google") langt mere gennemskueligt: Tryk på linket, land på en side med en kendt URL, login, redirect tilbage til sitet.

6
4. juni 2014 kl. 16:54

Mon nets kommer med en specificeret regning så man kan se hvor mange timer der er brugt på at lave selve koden og på det fænakkeri obfuskering eval strings

8
4. juni 2014 kl. 17:34

Det er da den eneste måde de kan retfærdiggøre prisen på løsningen. de har haft 500 indere til manuelt at obfuskere koden. Til danske priser, men betaler kun indiske lønninger.

5
4. juni 2014 kl. 16:40

Jeg forstår ideen, men jeg tror ikke på sikkerheden i praksis. Der findes vel også metoder til at automatisere de-obfuskering, således at et angreb kan foretages inden den indbyggede nøgle i JavaScript-koden udløber. Jeg håber, at de har læst Javascript Cryptography Considered Harmful.

2
4. juni 2014 kl. 16:23

Men der findes andre tilgange til obfuskering, hvor man hele tiden laver nye versioner af den obfuskerede kode, så man kan tvinge angriberen til at starte forfra hver gang. Det har en større chance for give noget sikkerhed

Det skræmmer mig lidt at en professor kommer med den udtalelse ...

10
4. juni 2014 kl. 19:48

Det skræmmer mig lidt at en professor kommer med den udtalelse ...

Nu er der jo forskel på teoretisk, kryptografisk, sikkerhed, og sikkerhed i praksis. Fx er en PS3 ikke sikker pga. trusted client problem, men det tog i praksis flere år at hacke den fordi en hardware chip ikke er sådan lige at splitte ad.

Obfuskering kan give noget sikkerhed i praksis.

18
5. juni 2014 kl. 12:20

Obfuskering kan give noget sikkerhed i praksis.

Nej. Men det kan forlede dig til at tro at du har opnået sikkerhed.

Derudover kan du ikke sammenligne situationen fra PS3 med det her, da der her er tale om at software fra Nets skal køres i min browser - ikke at jeg køber en konsol og skal prøve at skille den ad.

Men lad os da prøve at kigge på mulighederne:

  1. Obfuskeret kode, der ikke ændrer sig. Det giver ingen sikkerhed.
  2. Obfuskeret kode, der er forskellig fra gang til gang det hentes, men de-obfuskeres til samme kode. Igen, ingen sikkerhed.
  3. Obfuskeret kode, der er forskellig fra gang til gang, også efter de-obfuskering - men laver 100% samme kald til NemID-serveren. Igen, ingen sikkerhed.
  4. Obfuskeret kode, der er forskellig fra gang til gang, også efter de-obfuskering - og ikke laver samme kald til NemID-serveren.

På niveau 4 begynder det at blive en anelse sværere at se hvad man skal angribe - men så husker man på at det er javascript der kører i en browser. Nets har ingen kontrol over miljøet deres software afvikles i og så er den ikke meget længere.

20
6. juni 2014 kl. 08:49

Vil du forklare hvad du mener med at den så ikke er længere? Hvilken betydning har det hvilket miljø koden køres i?

Hvis miljøet kontrolleres af brugeren, som det er tilfælde med Javascript i en browser (eller på enhver anden brugerkontrolleret maskine), så er obfuskering i sidste ende blot en midlertidig forhindring. Peter Linds pointe er nok, at selvom obfuskering måske kan bruges som en del af "defense in depth", så vil det før eller siden overvindes.

24
6. juni 2014 kl. 09:38

Det virker på mig som en rimelig sikker metode; koden som afvikles på klientsiden, ændres fra gang til gang og kaldet til serveren gør ligeså. Hvor ser I svagheden?

tl;dr: hvis koden bliver afviklet kan jeg tage den og gøre hvad jeg vil med den.

Du har fuld adgang til koden og kan singlesteppe gennem skidtet så meget du lyster. Du kan derudover holde koden fast i lige præcis denne form og køre den igen og igen lige så mange gange du lyster (det er ikke sikkert du får samme svar fra serveren, men det er ligegyldigt for at forstå koden).

Du kan monkeypatche de grundlæggende objekter i javascript og få så meget info og data ud du lyster, på ethvert givent tidspunkt.

Derudover ved du at serveren er nødt til at være ret fault-tolerant. Tilsyneladende tager deres obfuskerede kode op mod et minut på mobilbrowsere før den er klar - så du har minimum det tidsrum at arbejde med før serveren kan overveje at koden måske skulle være outdated. For ikke at snakke om at skidtet også skal virke hvis forbindelsen ikke er perfekt.

Derudover vil javascript koden være kodet op mod en api. Kaldet til serveren vil ændres fra gang til gang men er ikke random - serveren skal stadig kunne parse det på en meningsfyldt måde. Dermed har du en angrebsvinkel samt et brugerkontrolleret miljø at arbejde ud fra.

Alternativet er selvfølgelig at koden samt de serverkald den foretager ikke genereres af den obfuskerede kode, men er prædetermineret - dvs. serveren vælger selv hvilken URL der skal svares tilbage til. En art token-url om man vil. Og nu intercepter du så bare kald tilbage til serveren, man-in-the-middle-style.

25
6. juni 2014 kl. 11:49

serveren skal stadig kunne parse det på en meningsfyldt måde.

Serveren kan vel egentlig bare checke at et token returneres som forventet. Dette kunne indbages i koden på en tilfældig måde og et tilfældigt sted. Dermed har du kun tiden til at beregne hvad svaret skal være. Vil det ikke være muligt at konstruere noget som ikke kan re-engineres på det minut du har til rådighed?

27
6. juni 2014 kl. 13:02

Serveren kan vel egentlig bare checke at et token returneres som forventet. Dette kunne indbages i koden på en tilfældig måde og et tilfældigt sted. Dermed har du kun tiden til at beregne hvad svaret skal være.

Og jeg kan hive 100 forskellige versioner af koden ned og køre replays på dem igen, og igen, og igen, og ...

For ikke at nævne at du stadig er oppe imod dårlige forbindelser, langsomme computere, etc - som alle skal kunne logge på via nemid, hvilket betyder at serveren er mere tolerant.

Faktum er at hvis koden kører og jeg har adgang til den, så kan jeg pille den fra hinanden. Piller jeg 10 stykker kode fra hinanden, så kan jeg sammenligne og finde mønstrene, på trods af at koden er obfuskeret. Jeg kan gøre alt det her fordi der er tale om kode, der leveres til mig, og som skal køre på min maskine uden speciel beskyttelse - tværtimod køres al koden i userland.

26
6. juni 2014 kl. 12:29

Vil det ikke være muligt at konstruere noget som ikke kan re-engineres på det minut du har til rådighed?

Måske.

Men overvej hvad motiverede privat-personer har været i stand til at udføre... nok Reverse Engieering af World of Warcraft, til at der i dag findes private servers. Diverse black-hat angreb på soft- og hardware, også (mange) ting der ikke er open-source. Fjernelse af DRM i alle afskygninger (licens-check, watermarking, diverse funky schemes der benytter sig af bad-sector checks på optiske medier, og så videre).

Ovenstående har været udført af personer der ikke har haft noget større incitament (udover adgang til zomg-1337 0-second warez ftp-servere). Overvej så hvad folk der har "sådan relativt halv-stort" økonomisk incitament kan udføre.

9
4. juni 2014 kl. 18:11

Ivan Damgaard anvender formuleringen "... en større chance for at give noget sikkerhed", og siger da også dermed, at den form for obfuskering ikke giver nogen sikkerhed i kryptografisk forstand, men derimod er et "arms race" med hackerne. Jeg kan ikke se udtalelsen er problematisk (og vi ved jo ikke hvad han ellers har sagt).

11
4. juni 2014 kl. 19:54

Hej, den gamle artikel fra 2010 er da overhovedet ikke relevant i forhold til at beklikke Ivan Damgaards troværdighed. Ivan havde jo ret, den historie der var blevet bragt i Børsen dengang havde intet på sig og var blot baseret på udtalelser fra enkelte personer der tydeligvis ikke havde forstået hvad det gik ud på. Der er jævnligt folk der skråsikkert skriver at Nemid systemet tidligere er kompromitteret, uden kildeangivelse... blot baseret på "hukommelsen" af diverse tågehoveder der tidligere har udtalt sig.

1
4. juni 2014 kl. 15:06

Jeg tvivler på, at det er af hensyn til sikkerheden. Når en virksomhed vælger at "obfuskere" kode, er det ofte for at undgå, at koden bliver reverse engineered eller kopieret.

3
4. juni 2014 kl. 16:34

... Eller for ikke at blive bustet for at have kopieret andres kode!

I gamle dage var det en overgang populärt at slibe märkningen af IC'er indtil man fandt ud af det bare var ens egen tid og penge man spildte på det.