NemID-pilfinger kritiserer test af NemID uden Java: 1 megabyte obfuskeret kode

Et kig i testkoden bag den kommende NemID uden Java, imponerer ikke datalogen Christian Panton. Han har lavet et program, der reducerer størrelsen på dele af koden med omkring en tredjedel.

Obfuskeret computerkode der fylder omkring en megabyte. Et kig i den foreløbige test-kode til den kommende NemID JavaScript imponerer ikke umiddelbart internetaktivisten og datalogen Christian Panton, der blandt andet er kendt for at demonstrere dårlig sikkerhed i Rejsekort. Nu har han startet et softwareprojekt på nettet, der er designet til at reducere kompleksiteten og dermed også filstørrelsen på NemID JS.

Senest har Christian Panton været i vælten, for at lave sin egen udgave af NemID uden Java - netop ved brug af JavaScript i stedet. Et par måneder før den officielle lancering af NemID JS, der er sat til 1. juli. Et initiativ, der fik en kølig modtagelse af leverandøren af NemID, Nets.

Læs også: Studerende hacker dansk rejsekort og får gratis rejser

Læs også: Hjemmeudviklet NemID-klient får syngende nej: Trues med ‘nødvendige juridiske tiltag’

Christian Panton er faldet over testkoden på en demo-hjemmeside ved PortalProtect. Det beskrives som en sikkerhedsinfrastruktur til blandt andet portaler. Løsningen fungerer med forskellige login-metoder - herunder NemID. Firmaet er ejet af Asseco Denmark A/S, som over for Version2 bekræfter, at JavaScript-koden på NemID JS-demosiden kommer fra Nets. Testkoden bruger Asseco Denmark A/S til at forberede PortalProtects kunder til, når NemID JS går live.

Læs også: Smugkig på lukket test: Se en demo af NemID JavaScript her

I forhold til testkoden til den kommende NemID JS, som Christian Panton har kigget på, hæfter han sig ved, hvor obfuskeret JavaScript-koden bag NemID er gjort. Obfuskering vil sige, at koden bevidst er gjort svært gennemskuelig for at camouflere, hvad der sker i softwaren. En af pointerne kan være, at eksempelvis kriminelle får sværere ved at finde og udnytte sikkerhedshuller. Der er dog delte meninger om, i hvor høj grad, obfuskering giver øget sikkerhed, da det kan lade sig gøre at omgå obfuskeringen. Og noget kunne tyde på, at obfuskering i tilfældet NemID JS kan være skønne spildte kræfter.

I hvert fald har Christian Panton nu startet et projekt på webhosting-tjenesten for softwareprojekter GitHUB med navnet obfuscated-id. Det er et program, der har til formål at de-obfuskere NemID JS-koden. Altså fjerne de tiltag, der er lagt i koden for at gøre den så uforståelig som mulig. Han mener, obfuskeringen både får koden til at fylde langt mere, end den burde, og samtidigt gør det sværere at finde fejl.

Læs også: Derfor koster NemID til mobilen 100 millioner kroner

»Jeg googlede for lidt tid siden mig frem til en hjemmeside som havde en demo af NemID/JS. Da jeg tidligere har kigget på Java-versionen, var det interessant for mig at kigge på, hvordan den kommende løsning virker,« skriver Panton i en mail og fortsætter:

»Jeg fik næsten kaffen galt i halsen da jeg opdagede hvor meget energi der havde været brugt til obfuscation af JavaScript-versionen. Især fordi det netop var et af kritikpunkterne ved den nuværende løsning. For at automatisere analysen af de næsten én megabyte store JavaScript filer, så skrev jeg en simpel deobfuscator til at fjerne nogle af de lag af kompleksitet der er lagt ind over. På den del af koden jeg har analyseret indtil nu, reducerer den desuden filstørrelsen med ca. 33%.«

Læs også: Alarm: 4 millioner NemID-brugere truet af kritisk Java-hul

Hvad kan de-opfuskatoren nu, og hvad skal den kunne?

»Det er ikke forfærdeligt meget kode, og det eneste, jeg i øjeblikket gør, er at lave en række reduktioner af kompleksitet. Der var blandt andet funktioner hvor tekststrenge blev gemt, som nu kan læses i koden med det blotte øje,« skriver Christian Panton og fortsætter:

»Den fremtidige udvikling bliver fokuseret på at skrælle mere kompleksitet af.«

Hvad er dit foreløbige indtryk af NemID JS?

»Jeg synes, det er meget positivt, at vi bevæger os væk fra Java. Jeg har kun set hvad jeg må formode er en test-version, så det vil jeg hellere svare på når det går live og jeg har fået lidt mere tid til at kigge på det,« skriver Christian Panton.

Læs også: Digitaliseringsstyrelsen udskyder NemID til mobilen i 11. time

Version2 har spurgt NemID-leverandøren Nets og Digitaliseringsstyrelsen, myndigheden der på statens vegne har indgået kontrakten med Nets om NemID-løsningen, om følgende:

  • Har Nets/Digitaliseringsstyrelsen nogen kommentarer til, at der nu ligger et open source projekt på GitHub, der er designet til at fjerne den kompleksitet, som bevidst er lagt ind i NemID JS?

  • Kan Nets/Digitaliseringsstyrelsen bekræfte, at koden i NemID JS bevidst er gjort kompliceret?

  • Vurderer Nets/Digitaliseringsstyrelsen, at øget kode-kompleksitet, giver øget sikkerhed?

  • Mener Nets/Digitaliseringsstyrelsen, det er hensigtsmæssigt, set ud fra et driftsmæssigt perspektiv, at kode-kompleksiteten i NemID JS lader til at være særdeles omfattende?

  • Mener Nets/Digitaliseringsstyrelsen, det er hensigtsmæssigt, at borgerne skal bruge båndbredde og cpu-kraft på at håndtere NemID JS, der lader til at have en omfattende størrelse, som følge af bevidst indbygget kode-kompleksitet?

  • Påtænker Nets/Digitaliseringsstyrelsen at foretage sig noget for at mindske kode-kompleksiteten i den endelige NemID JS-udgave, der er sat til at blive frigivet 1. juli?

Kontorchef i Digitaliseringsstyrelsen Cecile Christensen sender i en mail bolden videre til Nets:

»Vi stiller krav om et højt niveau af sikkerhed i den nye JS-klient. Vi forventer, at koden har den nødvendige kompleksitet, men heller ikke mere. Det er ofte sådan, at opretholdelse af høj sikkerhed tilfører en vis kompleksitet til systemer og kode,« skriver hun og fortsætter:

»Den konkrete tekniske udvikling af systemet ligger hos Nets, og vi må derfor henvise til Nets for en mere detaljeret besvarelse af spørgsmål til selve koden eller andre tekniske detaljer – i det omfang Nets kan svare på dette uden at gå på kompromis med sikkerheden.«

Kommunikationskonsulent ved Nets Ulrik Marschall oplyser, at virksomheden ikke ønsker kommentere på NemID JS inden det bliver officielt frigivet, og Nets har ej heller nogen kommentarer til Christian Pantons NemID de-obfuscator på GitHub.

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 opdateringen fra Oracle, der står bag Java, som sidste år bevirkede at NemID i tre døgn ikke fungerede hos de brugere, der havde fulgt gængs sikkerhedspraksis og opdateret til den seneste Java. Senere kom det frem, at Nets ikke havde testet om NemID ville virke med den nye opdatering fra Oracle.

Læs også: Nets brugte 3 døgn på at tilføje 2 linjer kode til NemID

Digitaliseringsstyrelsen forventer, at NemID JS, trods problemer i forbindelse med en planlagt pilottest, som planlagt bliver lanceret 1. juli.

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

Helt ærligt, det er Javascript, source er direkte tilgængelig for slutbruger.

Jeg håber virkeligt ikke der er nogen der alvorligt talt har besluttet dette som led i en sikring af NemID, for så har vi da vist et alvorligt problem.

Minification, det ville give mening rent performancewise, men obfuscation?

Jeg er rystet

  • 47
  • 0
Anders Metnik

Det var noget af det første jeg lærte på universitetet da jeg havde om fag om sikkerhed, og det sidder printet ind i hovedet på mig.
Jeg er chokeret over at man ikke hellere vil gøre koden simple, så dem der kan gøre det, kan finde fejlene og melde det tilbage til Nets.

  • 24
  • 0
Mads Kn

Altså udover minify, så giver uglify jo også fint mening. Der er vel alligevel performance og pageloading at hente ved at forkorte samtlige variabler til a,b,c...

  • 0
  • 2
Rune Juhl Jacobsen

Nu er det så netop ikke minification, men decideret obfuscation de benytter. Du kan tage et kig her: http://pastebin.com/miGDVkdf

PortalProtects side kan forresten findes her: https://www.portalprotect.dk/demologinnemidjs.jsp

Jeg har ikke selv kigget på deres JS, men jeg undrer mig over at de har henter ~750 KB blob der er "krypteret" på den ene eller anden måde. Jeg siger krypteret, da ent siger at filen er næsten helt random (Entropy = 7.999764 bits per byte.)

Tjek forresten følgende screenshot: http://i.imgur.com/RIS1akb.png

8 sekunder for pageload. Firefox 28.0, Core i7, 8 GB RAM, SSD. Fuldstændigt forrykt.
Som forventet er det ikke bedre på mobilen. 50 sekunder blev det til, før siden havde loadet nok til at give mig en redirect (hvad der også sker i Chrome).

  • 13
  • 0
Daniel Gertsen

"Security through obscurity is no security at all"

Den lærte jeg for læææænge siden, og den sidder fast.
Og den giver god mening.
Dem der virkelig vil, skal nok se gennem det.
Mens dem der skal vedligeholde og rette i det, får langt sværere ved at rette selv simple problemer.

Det er uholdbart!

  • 14
  • 0
Hans-Christian Mose Jehg

Mens dem der skal vedligeholde og rette i det, får langt sværere ved at rette selv simple problemer.

Nej, det er ikke tilfældet. Rettelser og andet vedligehold gør de naturligvis på den ikke obfuskerede version - ... Ja det antager jeg i hvert fald :-)

De kan til gengæld få sværere ved at fejlfinde (incl. på "obfuskerings softwaren") på den kode som brugerne kører...

  • 7
  • 0
Rune Glerup

Når man ser på outputtet af Pantons deobfuscator, ser det ud til at noget af koden er placeret i strengværdier der klistres sammen og afvikles med eval().

Det er normalt ikke en god idé i JavaScript fordi man skal overbevise sig selv om at man ikke kan komme til at afvikle kode fra en usikker kilde.

  • 13
  • 0
Robert Larsen

Jeg er enig i at obfusceret kode er noget hø, især i en løsning, som ville have gavn af at blive kigget efter i sømmene.

Men måske har obfusceringssoftwaren bygget et source map, så fejl i line X kolonne Y kan omdannes til: path/to/some/file.js linje 42 kolonne 15

Det kan vi i hvert fald med vores Google Closure compilede JavaScript.

  • 3
  • 0
Michael Hansen

Der er vel alligevel performance og pageloading at hente ved at forkorte samtlige variabler til a,b,c...

Min Chrome frøs i et par sekunder, det har jeg sgu aldrig oplevet selv på meget tunge javascript sites, så virker sgu lidt strange noget så (relativt) simpelt som det den burde gøre, kan forårsage det.

Reelt burde den jo ikke gøre andet end indlejre en <form action=https://blabla på et andet site.

Selv hvis de skulle implementere kryptering (but why?) client side, så fylder javascript libraries som cryptojs jo ikke mere end max et par hundrede KB (mindre minified).

  • 3
  • 0
Jacob Lindquist

»Vi stiller krav om et højt niveau af sikkerhed i den nye JS-klient. Vi forventer, at koden har den nødvendige kompleksitet, men heller ikke mere. Det er ofte sådan, at opretholdelse af høj sikkerhed tilfører en vis kompleksitet til systemer og kode,«

Seriøst? Nødvendig kompleksitet?
Alle ved at kodekompleksitet øger risikoen for sikkerhedshuller!

  • 14
  • 2
Jan Borup Coyle

Hvis Nets fæler sig sikre på at det har lavet et sikkert NemId JS, skulle de måske skulle Nets stille den ene 1 mio. på højkant til en NemId Hackalon i stedet for at obfuskere kode, det ville de garanteret også blive meget klogere på, hvis man selv normalt kloge hoveder ville kunne finde på, og finde ud af hvad man skal tage højde at gøre det sikkert.

  • 8
  • 0
Max Tobiasen

Det er måske et dumt spørgsmål, men hvad gør Nem-id klienten egentlig? Sender den bare username/password afsted til srveren, er det noget challenge-response halløj, eller hvad?

Hvilken funktionalitet skal der rent faktisk bygges ind i javascript klienten?

  • 4
  • 0
Janus Knudsen

Der var det med en stor fed streg under!!

Obfuskeret javascript, jeg får kaffen galt i halsen *host**host*

Hvorfor skal det obfuskeres? Det havde da været langt nemmere bare at have det liggende evt. minificeret.
Der står jo intet i js-koden som kan kompromitere sikkerheden, hvad hulen er det som sker?

Er det endnu en kloge-åge-jeg-er-leder der har dikteret nogle stakkels udviklere haha.

  • 0
  • 0
Janus Knudsen

Spørgsmålet er såmænd ikke dumt, og jeg kan sagtens forstå at mange bliver forvirret med alt den sniksnak der konstant er om NemId og sikkerhed.

Der skal ikke bygges noget ind i browseren som ikke allerede findes der, udveksling af data skal ske igennem en krypteret forbindelse. Den findes allerede som HTTPS/ SSL, dvs. din browser står for sikkerheden og javascripten benytter denne tunnel til sikker datatransport.

Selve ordet JS-klient er også en gang vrøvl, javascript afvikles i en browser, så man kan kalde browseren for JS-klient.

Sludder for en sladder og 100millioner kr senere står man med et stykke javascript som enhver seniorudvikler ville kunne lave tilsvarende, hvis ikke bedre som i mindre kompleksitet.

Og hvad er det for nogle huller der snakkes om, det er jo ikke Java, men ren scripting som er underlagt nogle veldefinerede grænser i browseren. Det bliver da mere og mere pippet det her :)

Du sidder på en krypteret forbindelse, du logger ind med dit brugernavn og adgangskode, du kigger på dit nøglekort og indtaster en kode.

Det var det, lad nu være med at gøre det til mere :)

  • 1
  • 3
Frithiof Andreas Jensen

Jeg har ikke selv kigget på deres JS, men jeg undrer mig over at de har henter ~750 KB blob der er "krypteret" på den ene eller anden måde.


Hjälper dette overhovedet? Hvis sikkerheden afhänger af klienten og platformen, som angriberen absolut ejer og kontrollerer helt ned på chip-niveau, så er alle tiltag forgäves.

Hvis "blob'en" indeholder kode som dekrypteres og eksekveres på klienten så kan man vel i ro og mag fange den memory-block koden läses ind i og steppe igennem med en debugger og se hvad koden gör samt hvad der findes a spändende variable?

Hvis koden derimod ikke stoler på platformen, så er der heller ingen rationel begrundelse for at hoppe igennem alle disse brändende töndebånd med obfuskering & krypto - så det bekymrer mig faktisk at man gör det. Det er lidt for meget "Hax0r" og "L33T-kidz"-lugt over obfuskeret kode ;-)

PS
Jeg har tidligere arbejdet en del med hardware debugging - dengang var "state of the art" en Philips PM3585 Logic Analyser med CPU-pods og disassembler. Hvis det virkeligt kniber kunne man skubbe en "sokkel" ind under CPU'en og se alle instruktioner (med break, trace, filtering på memory events og det hele) decompileret på en logic analyser.

I dag ville man nok spring det over og välge en forenklet CPU som ARM eller Intel Atom som man kan debugge via Boundary Scan - man kan endda "koge sin egen CPU" i en FPGA for fuld gennemsigtighed og kontrol. Det er i värste fald nogle hundrede timer og udstyr til höjest 20 - 30000 kroner. Penge som sandsynligvis hurtigt er tjent hjem hvis NemID-klienten virkeligt stoler på at den körer i et sikkert miljö som aldrig lyver eller snyder.

  • 3
  • 0
Palle Hansen

Hvilke data og hvilken webserver?
Der er ingen der har serveradgang ud over sysadmins m.v. som jo arbejder på og omkring webserverne.

webserver... https er kun kryptering mellem klient og webserver. Enhver med adgang til denne server kan installere lytteudstyr.

Vi ved reelt ikke, hvor mange der har adgang. Selvom det kun er en håndfuld, vil du så have, at de kan sniffe dine data?

Nets har nogle HSM-moduler, som klienterne taler med. De er lidt mere sikre end sådan en alm. webserver.

  • 5
  • 1
Niels Buus

Palle Hansen - hvis du ikke stoler på at driften hos Nets kan afholde sig fra at sniffe dine data, så kan du lige så godt give op. Hvis driften uhæderlig, så er den NemID.js (eller applet) som de sender til din browser nok også. Faktisk er hele organisationen det sikkert. (Hvilket virker plausibelt set i lyset af Se & Hør sagen)

Og med hensyn til data, så er det jævnt uinteressant hvad du sender til Nets.

Du sender dit brugernummer, brugernavn eller CPR-nummer. Alle tre ting har Nets i forvejen.
Du sender din adgangskode. Denne har Nets sandsynligvis kun et hash af.
Du sender din engangskode. Denne har Nets i forvejen.

Hvad skal medarbejdere med dit NemID password når de alligevel kan nulstille det eller installere kode som sjofler valideringen af det?

  • 3
  • 0
Janus Knudsen

Palle, hvis du har en trojan horse i serverrummet kan du ligeså godt kaste håndklædet i ringen.

"webserver... https er kun kryptering mellem klient og webserver. Enhver med adgang til denne server kan installere lytteudstyr."

Https, ja kryptering, men adgangskoder er ikke opbevaret i clear text, så de kan ikke uden videre kopieres, og hvis nogle endelige skulle finde det morsomt (hvilket kun vil understrege dumheden hos hackeren), så mangler vedkommende stadig et nøglekort.

Kort fortalt: I det øjeblik at nøglekortet blev opfundet, forsvandt risici fra kompromiteringen af brugernavn og adgangskode. At man så stadig på grund af god etik fastholder SSL-tunnelen er blot en formalitet, men en fornuftig formalitet.

Der er absolut ingen grund til at obfuskere eller på anden måde gøre NemId så besværlig som det er lavet, når alle brugere skal have et nøglekort.

Det er en stor forvirring det her :) jeg sidder med en sjov fornemmelse af at vi er vidne til et gigantisk teoretisk paradigme.

HSM er almindeligt og ikke noget NETS-magi. HSM anvendes til kryptografi hvor man ønsker en særlig stærk beskyttelse af public-private keys.

Kort fortalt anvendes SSL på en HSM-boks, men det er stadig SSL, bare håndteret væk fra webserveren.

Der mangler virkelig nogle gode argumenter for denne obfuskering og kompleksitet af NemId-JS.

  • 1
  • 2
Andreas Bach Aaen

"– i det omfang Nets kan svare på dette uden at gå på kompromis med sikkerheden".
udtaler: Kontorchef i Digitaliseringsstyrelsen Cecile Christensen.

Jeg er led og ked at at vi i Danmark har en digitaliseringstyrelse, der tror på at security by obscurity er en godt koncept at basere en væsenlig del af den danske infrastruktur på.

Må vi have lov at bede om at design baseret på åbne standarder. Det er langt hen af vejn Digitaliseringstyrelsens skyld, at vi i dag har så ringe et system som jeg anser NemID for at være.
Problem: usikre klienter og dumme brugere.
Den forkerte løsning: centralt opbevarede private nøgler og security by obscurity på klienterne. Transaktionsbaseret kommunikation gennem central aktør.
Den langt bedre løsning: Sikre klienter. F.eks. et hardware token, der kan generere og opbevare en privat nøgle. Autentifikation gennem et distribueret netværk, og kommunikation direkte mellem aktører. Transaktioner kan ikke logges og/eller blokeres centralt.

Vi har godt nok NemID på hardware, men den kan i praksis kun bruges til det offentliges centrale login-side. Så fordelene bliver stort set skyldes ud med badevandet igen.

Der har heller ikke været noget ønske om at løsnignen også skulle kunne bruges til at borgerne kan kommunikere sikkert og direkte med hinanden. Det vill ellers være en god gave fra staten. Digitaliseringstyrelsen har kørt hårdt på at gøre det nemmere for staten og ikke ret meget på at gøre det nemmere og bedre for borgerne.

  • 6
  • 0
Leif Neland

Mon jsnice kunne bruges?

http://jsnice.org

  • Welcome to JSNice — we make even obfuscated JavaScript code readable.
  • We will rename variables and parameters to names that we learn from thousands of open source projects.
  • Furthermore, often we are also able to guess or infer type annotations.
  • Try JSNice on your JavaScript code to see how it works!
  • Override the names suggested by JSNice (by enabling "interactive renames" in settings).
  • Click to learn more about JSNice.
  • 0
  • 0
Frithiof Andreas Jensen

Hvilken funktionalitet skal der rent faktisk bygges ind i javascript klienten?


Det er jo det der er problemet. Hvorfor behøver man både obfuskering og en 700 MB krypteret "payload" for kun at lave et sikkert login?

Man får nemt den tanke at blob'en på 700 MB kunne være en placeholder til en "bundestrojaner" som via NemID nemt & sikkert kan leveres til "rette vedkommende" eller måske at det faktisk er eksekverbar kode som skal køre på en sikret krypto-CPU som allerede (eller snart) er indbygget i folks computere. Måske kan "blob'en" bruges til at stikke kompromitterende ting i browser-cachen og "history", så behøver man ikke længere fængsle hackere på ubestemt tid imens man leder efter noget at anklage dem for!?

Det virker skummelt, som om der findes en ekstra, hemmelig, kravspecifikation der skrevet af PET, FET, Politiet, Skat, Justitsministeriet, e.t.c :)

  • 1
  • 0
Log ind eller Opret konto for at kommentere
Jobfinder Logo
Job fra Jobfinder

Call to action

Obfuskeret computerkode der fylder omkring en megabyte. Et kig i den foreløbige test-kode til den kommende NemID JavaScript imponerer ikke umiddelbart internetaktivisten og datalogen Christian Panton, der blandt andet er kendt for at demonstrere dårlig sikkerhed i Rejsekort. Nu har han startet et softwareprojekt
på nettet, der er designet til at reducere kompleksiteten og dermed også filstørrelsen på NemID JS. Senest har Christian Panton været i vælten, for at lave sin egen udgave af NemID uden Java - netop ved brug af JavaScript i stedet. Et par måneder før den officielle lancering af NemID JS, der er sat til 1. juli. Et initiativ, der fik en kølig modtagelse af leverandøren af NemID, N...