DanID camouflerer programkode på din pc som billedfiler
Den nyeste version af McAfees antivirusmotor opdager to mistænkelige programfiler blandt de filer, som bliver gemt lokalt på brugerens pc, når han logger på med NemID.
Læs også: McAfee advarer om virus i NemID
I første omgang så det ud til at være en falsk alarm efter en opdatering af McAfees scanningsværktøj, men som flere læsere også har gjort opmærksom på, så er NemID-applettens billedfiler ikke, hvad de giver sig ud for at være.
De mistænkelige filer ligger i en pakket fil, et såkaldt JAR-arkiv, som bruges til at distribuere filer sammen med Java-appletter.
Version2 har pakket den pågældende JAR-fil ud for at se nærmere på de to GIF-filer, som udløser virusalarmen fra McAfee, og det viser sig, at der ikke er tale om billedfiler.
Filerne ligger ganske vist i mappen "/img" og hedder "large.gif" og "pause.gif", men ser man nærmere på indholdet, så er det ikke GIF-billeder.
I stedet er der tale om kompilerede programfiler. Halvvejs nede i large.gif bliver man således mødt af klartekst, som ser ud til at være fejlmeddelelser, som programmet kan give under kørslen i forbindelse med fejlfinding.

I stedet for harmløse billedfiler, så er der altså tale om programkode. Det fremgår også, hvis man ser på de sidste linjer af large-gif, som indeholder XML-kode, der bruges til blandt andet at angive, hvilke rettigheder programmet skal køre med.

Men det er ikke kun de to filer, som McAfees antivirus gav udslag på, som ikke er, hvad de udgiver sig for at være. Som flere læsere også har gjort opmærksom på i debatten til den første artikel, så ser de øvrige GIF-filer i JAR-filen også ud til at være programfiler.
Eksempelvis er filen "error.gif" en ELF-fil, altså en eksekverbar programfil til Unix-systemer. Ud af de GIF-filer, som ligger i appletten, er i alt fire ikke GIF-filer, som man også kan se ud fra visningen i Windows Stifinder:

Version2 har kontaktet DanID for at få svar på, hvorfor NemID-appletten inkluderer nogle programfiler, som udgiver sig for at være billeder ud fra filnavnet.
»Det kan jeg ikke svare på. Vi er i færd med at få det afklaret,« siger kommunikationschef Jette Knudsen fra Nets DanID til Version2.
De to umiddelbart nærliggende muligheder er, at der enten kan være tale om en fejl i filerne, som ikke er blevet opdaget tidligere, eller at filerne bruges i forbindelse med sikkerheden i NemID-appletten, hvilket kan forklare, hvorfor DanID har forsøgt at sløre dem ved at camouflere dem som billedfiler.
Kommentarer (96)
For the record:
Den første der blev opmærksom på dette skalkeskjul var Christian Callesen,
Tip med hatten!
Kør med IC4 via et rejsekort oprettet med NemID.
Måske har det været planen fra starten.
Så vidt jeg kan se, kan man ikke identificere sig med NemID på rejsekortet.dk, dog, men en skønne dag...
Ja, mange tak til de læsere, der har gjort os opmærksom på emnet og har hjulpet med at kigge filerne efter i sømmene.
Filerne er sendt til McAfee og et andet sikkerhedsfirma, og vi håber at få en kommentar derfra, og naturligvis en kommentar fra DanID.
Mvh.
Jesper Stein Sandal
Version2.dk
En filendelse skal vælges. Måske står GIF for noget andet i DanIDs system? Jeg har svært ved at se hvorfor dette er mere "skjult" end hvis de havde kaldt filerne .foobar.
Bortset fra filerne ligger sammen med alle de andre billedefiler (f.eks. blackdot.png, close.jpg, key.gif osv osv..) i en mappe der hedder img. Come on - lad være med at forsvare det - det er som mimimum security by obscurity - måske endda noget endnu værrere...
Man kalder altså ikke programkode for "large.gif" og den slags ved et uheld. Som det er blevet påpeget et par gange, så er det i absolut bedste fald "security by obscurity", og med DanIDs hidtidige demonstrationer af kompetencer skal man måske lade være med at forveksle inkompetence med bevidst destruktiv adfærd.
:D
Jeg synes som sagt til PHK at det er underligt at man forsøger at obfuskere. Hvorfor ikke bare vise det som det er?
Mvh
Christian Callsen
Der er jo faktisk også den mulighed, at DanId er blevet hacket, og de nævnte filer (og modifikationer til andre) er lavet af hackerne uden DanIds viden. I givet fald tyder det på seriøse huller i DanIds sikkerhedsprocedurer.
Har DanID ikke blot vist - gang på gang - at de ikke ønsker at vise/fortælle/offentliggøre noget som helst omkring hvorfor og hvordan de gør noget som helst?
De lever i et andet årti, hvor den slags var naturligt... befolkningen skal blot makke ret, og gøre som der bliver sagt. De ønsker ikke der bliver stillet spørgsmål til deres måde at løse tingene på - for der er kun en korrekt måde at gøre det, set fra deres side af sagen.
Ah ja. Det gamle gedemarked med filendelser.
Jeg kan simpelthen ikke tro at DanID har døbt filerne sådan af sikkerhedsmæssige årsager. Det ville være for dumt.
umidelbart ligener det samme ting som var i den gamle applet til den rigtig digital signatur, den samler info om ens hardware og bruger det som en hardware nøgle til at sikkere af filen ikke kan flyttes på en anden maskine, altså noget som der ikke er brug for.
Har kiggede på en ældre version, 16/01/2011 der var samme filer også det er ikke noget som de lige har smidt i den.
Tjah, jeg ved ikke hvad der er værst. Et dårlig forsøg på at skjule filerne ved at omdøbe dem og ligge dem i en img mappe med andre billedefiler. Eller have så lidt styr på filstrukturen at der rent faktisk findes ekskverbare filer i et mappe der indeholder billeder og er navngivet til at have billeder...
Kan ikke se et godt argument/god undskyldning for hverken det ene eller andet...
Der er jo faktisk også den mulighed, at DanId er blevet hacket, og de nævnte filer (og modifikationer til andre) er lavet af hackerne uden DanIds viden.
Dette tydeliggør hvorfor det er problematisk, at DanID prøver at holde så mange detaljer om NemID hemmelige. Hvis denne mærkelige opførsel var dokumenteret, kunne man slappe en smule af hvis man ellers har grundlæggende tillid til DanIDs hensigter. Nu ved vi hverken hvad de bruger filerne til, eller om de i det hele taget er en del af designet.
Det må man da ikke håbe:
ls -al ./DanID_Applet/img/*
236 Nov 15 2010 ./DanID_Applet/img/blackdot.png
55 Nov 15 2010 ./DanID_Applet/img/blank_16x16.gif
94 Nov 15 2010 ./DanID_Applet/img/checkbox_deselected.gif
104 Nov 15 2010 ./DanID_Applet/img/checkbox_selected.gif
456 Nov 15 2010 ./DanID_Applet/img/checkmark_16x16.png
743 Nov 15 2010 ./DanID_Applet/img/close.jpg
718 Nov 15 2010 ./DanID_Applet/img/combobutton.jpg
44325 Nov 15 2010 ./DanID_Applet/img/error.gif
956 Nov 15 2010 ./DanID_Applet/img/hash.gif
8666 Nov 15 2010 ./DanID_Applet/img/helpnogleandkortnummer.gif
3630 Nov 15 2010 ./DanID_Applet/img/helpnogle.gif
3892 Nov 15 2010 ./DanID_Applet/img/helpnoglekortnummer.gif
958 Nov 15 2010 ./DanID_Applet/img/key.gif
105984 Nov 15 2010 ./DanID_Applet/img/large.gif
180 Nov 15 2010 ./DanID_Applet/img/list_bullet.gif
4178 Nov 15 2010 ./DanID_Applet/img/loader.gif
93728 Nov 15 2010 ./DanID_Applet/img/logo2.gif
473 Nov 15 2010 ./DanID_Applet/img/nemid_logo.gif
1135 Nov 15 2010 ./DanID_Applet/img/noglebg.gif
92160 Nov 15 2010 ./DanID_Applet/img/pause.gif
3724 Nov 15 2010 ./DanID_Applet/img/print.gif
66 Nov 15 2010 ./DanID_Applet/img/small_checkmark.gif
file ./DanID_Applet/img/error.gif
./DanID_Applet/img/error.gif: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, not stripped
file ./DanID_Applet/img/large.gif
./DanID_Applet/img/large.gif: PE32+ executable (DLL) (GUI) x86-64, for MS Windows
file ./DanID_Applet/img/logo2.gif
./DanID_Applet/img/logo2.gif: Mach-O fat file with 3 architectures
file ./DanID_Applet/img/pause.gif
./DanID_Applet/img/pause.gif: PE32 executable (DLL) (GUI) Intel 80386, for MS Windows
Det ville være for dumt.
Har du ikke dermed argumenteret for, at det netop kunne formodes at være årsagen? :)
Lav det nu open source så kan alle se at det er sikkert, at gemme noget i en gif gør at det er de snu der finder ud af det, og så skifter de lige giffen, og så skal vi hører på det bavl og det skal op i folketinget og en masse god tid spildes
Security by obscurity er et vigtigt værktøj i stort set alt der har med sikkerhed at gøre i dag. Eksempelvis AES benytter sig i særlig høj grad af det, ligesom stort set alle andre krypteringsalgoritmer.
Der er intet galt i det princip, det fungerer, det skal bare være et bevidst funderet valg, og sikkerheden skal selvfølgelig ikke udelukkende være baseret på det, det er blot et komponent i den samlede helhed.
@Morten Hansen
Kan du give et eksempel på hvor fx AES bruger security by obscurity, eller poste et link til noget der dokumenterer dette?
@Morten Hansen
AES er da i den grad ikke security by obscurity. Den er så åben, som noget kan være, det var endda et krav fra NIST.
Her er lidt læsestof om AES:
* http://csrc.nist.gov/archive/aes/rijndael/wsdindex.html
* http://en.wikipedia.org/wiki/Advanced_Encryption_Standard
* http://en.wikipedia.org/wiki/AES_implementations
Hvordan kan du kalde det obscurity ?
Nogle der har set på log filen danid.log?
Hvad jeg lige hurtig har set, er at den indeholder en masse binært data der er base64 encoded.
En af mine bekendte formulerede det ret godt:
"Nu har NemID virkeligt et forklaringsproblem. Den kritik der blev rettet mod deres digitale signatur løsning, har nu vist sig at være berettiget. De kan ikke forklare, hvilke filer de har lagt på DIN computer, når du bruger DanID."
Gys - Dybt useriøst af en såkaldt sikker log in løsning, med mindre, som det er nævnt andetsteds at de er blevet hacket....
Ud af busken DanID - PR OMGÅENDE!
Dette her er en for alvorlig en sag til at I kan få lov til at lege Struds!!!
Efter at have leget lidt med strings, ligner det at de programmer der ligger der kan køres for at finde information om din computer, men gad vide hvad de så bruger de informationer til....
Ja, som Henrik viser her er der executables til Mac, Winx86 32 og 64 bit og 'Linux'.
Hvorfor skal Danid have kode installeret på min PC, der skal execute i OS ?
.....
// jesper
Jeg har sendt spørgsmålet videre til Finansministeriet, der vist nok har fået ansvaret for den det af IT- og Telestyrelsen, som har med NemID at gøre:
Kære Bjarne Corydon,
Jeg håber, at dette brev når den rette modtager; så vidt jeg har forstået, har Finansministeriet taget det tidligere IT- og Telestyrelsens ansvar for sager vedrørende digital kommunikation med borgerne, og som sådan formodentlig også ansvaret for NemID.
I dag er det kommet frem, at DanID har camoufleret udførbar kode i filer, som de har gemt og navngivet som billedfiler. Koden er skjult i forskellige filer, hvor de enkelte filers kode er særligt udformet, sådan den kan udføres på Windows-, Mac-, og Linux-maskiner: Se http://www.version2.dk/artikel/login-applet-til-nemid-camouflerer-exe-fi....
Dette strider imod DanIDs hidtidige forsikringer om, at der ikke ville blive installeret software på brugernes computer. Det afslører også, hvad IT-Politisk Forening har advaret om kunne ske, nemlig at DanID kan installere software, som de ikke kan eller vil redegøre for.
Hvad vil Ministeren konkret gøre for at sikre mere åbenhed omkring DanIDs reelle adfærd i udbredelsen af NemID, samt sikringen af borgernes computere mod muligheden for, at der via DanIDs applikation kan installeres overvågning af brugerne, såfremt dette skulle blive pålagt DanID?
Fra Wikipedia ( http://en.wikipedia.org/wiki/Malware ):
Malware, short for malicious software, consists of programming (code, scripts, active content, and other software) designed to disrupt or deny operation, *gather information that leads to loss of privacy or exploitation", gain unauthorized access to system resources, and other abusive behavior.
Hvis DanID uden min viden indsamler oplysninger om min computer, så er det vel malware.
Specielt når de gør sig så meget umage med at skjule det for mig?
Så det er vel egentlig fint at antivirus programmet reagerer på det, er det ikke?
Ifølge http://www.threatexpert.com/report.aspx?md5=30bca2b1e35b3c6d61186e0dab03... er pause.gif blivet "opdaget" den 6 April 2011, 12:16:02
Jeg har blot googlet md5sum'en af filerne.
large.gif er lige lagt op:
http://www.threatexpert.com/report.aspx?md5=35f9182e2df7777956c2f7506e96...
Ja, som Henrik viser her er der executables til Mac, Winx86 32 og 64 bit og 'Linux'. Hvorfor skal Danid have kode installeret på min PC, der skal execute i OS ?
Er NemID appletten ikke java bytecode? Hvad skal jeg så med dll'er og so filer i forklædning? Java appletten skal vel også kunne køre på andre platforme end Windows, Mac og Linux x86.
Til mail signering på Linux med NemID skal man i forvejen installere en række nye programmer, så det kan ikke være derfor.
Ok, jeg er vist en hat, men jeg kan sgi ikke finde de filer i min Java cache...heller ikke efter at have netbanket.
Kan én eller anden venlig sjæl lægge dem et eller andet sted, så jeg kan downloade dem ?
Jeg kunne godt tænke mig at se nærmere på dem.
Kan se mange andre er begyndt at decompile deres java app også... Jeg synes alle der kan og vil / har tiden bør gå igang. Download den i aften om ikke andet så de ikke kan nå at ændre i den.
Personligt vil jeg til bunds i hvad den kan og gør på mine maskiner når den kører!
- Ind til da kan i andre gøre det samme som jeg har gjort hele tiden, at køre alt med NemID login i VMWare under Linux Mint ell. Det er simpelt og lige til at sætte op :)
ELF'en (error.gif) har lidt flere detaljer i symbolerne. Det ligner mere kryptering og hash-algoritmer:
_ZN7cSHA25612ProcessBlockEPKh
_ZN7cSHA2567ProcessEPKhj
_ZN7cAES25612DecryptBlockEPKhPh
_ZN7cAES25612EncryptBlockEPKhPh
Men hvad er Wuddelcakes?
Java_dk_danid_plugins_Wuddelcakes_e
Java_dk_danid_plugins_Wuddelcakes_f
Java_dk_danid_plugins_Wuddelcakes_a
Java_dk_danid_plugins_Wuddelcakes_c
Java_dk_danid_plugins_Wuddelcakes_b
Java_dk_danid_plugins_Wuddelcakes_d
De der Wuddelcakes er vist noget Java obfuscering.
JAD kan heller ikke fuldt ud decompile Java koden.
I Windows, i hverfald på win7 ligger de i mappen C:\Bruger\"Brugernavn".oces2\danid\plugins
De der Wuddelcakes er vist noget Java obfuscering. JAD kan heller ikke fuldt ud decompile Java koden.
Da jeg prøvede at dekompilere de normale Java-klasser, så kunne http://java.decompiler.free.fr/ kan næsten fuldstændigt dekompilere dem.
Alle strenge var krypterede. Men funktionen til at dekryptere var selvfølgelig til stede i kildekoden, så det var ret let at rekompilere den klasse, og derefter dekryptere strengene.
Funktions-kaldenavne i bytekode er tilsyneladende bestemt ud fra navnet,argumenttyper,returtype mens de i Java er bestemt ud fra navnet,argumenttyper. Så hvis du ser 2 funktioner i den dekompilerede kode med samme navn og argumenttyper, så kan du kigge i den disassemblede bytecode for at kende forskel på dem på kaldstederne.
For mig at se er problemet, at når DanID spilder tid på denne ineffektive obfuskering, så er det et tegn på at de ikke ved hvordan man rent faktisk sikrer transaktionerne.
Det som DanID prøver at beskytte sig imod er, hvis computeren allerede er overtaget af en virus. Det kan man selvfølgelig ikke beskytte sig imod, så obfuskering er det bedste de kan gøre. Dette forsøg på at beskytte mod virus er så vidt jeg har forstået også grunden til at de overhovedet bruger en signeret java-applet, i stedet for for eksempel JavaScript.
(Jeg mener selvfølgelig, at DanID ikke skal køre programmer uden for en sandboks på min computer)
Som ekstra bidrag til mysteriet:
Jeg kunne se på min maskine og mit email-trail at denne "funktionalitet" i OCES appletten ihvertfald var til stede i februar. Så det er ikke en "ny opfindelse".
Hvis obfuskeringen skulle være endnu mere obskur, kunne de have ladet filerne ligne rigtige GIF-filer, dvs. så der vises rigtige ikoner i Windows Stifinder (illustrationen i artiklen). Så vidt jeg husker kan man til enden af en gyldig GIF-fil tilføje en vilkårlig mængde binære data, uden at filen “går i stykker”, dvs. så den stadig kan vises (selvom den måske strengt taget ikke er gyldig i henhold til GIF-specifikationen).
Ditto kan man til en ZIP-fil tilføje en vilkårlig mængde skrammel først i filen. Dvs. du kan have én fil, der – afhængigt af filendelsen – opfører sig enten som en gyldig GIF-fil eller en gyldig ZIP-fil. Viel Spaß!
Det er vel det samme som danske bank har/havde i deres applets? Finnerne blev opmærksom på det da en af deres banker blev købt af danske bank (og løb skrigende væk pga. dårligere netbank). På linux læste det /proc/cpuinfo og andet.
Jeg mindes nu ikke det var gemt i billedfiler.....
Hmm kan se et par af jer kigger i filen. Det er hverken obfuskeret eller krypteret, men bare 'manglet'. Jvnf.
http://en.wikipedia.org/wiki/Name_mangling#Name_mangling_in_C.2B.2B
Et hurtigt kig ud fra navnene, unmangled, viser at det er diverse krypterings og hashing algoritmer implementeret i c++ ,sha256, AES og noget der læser maskin information (/usr/sbin/system_profiler på mac). Derudover sikkert noget kode så det kan kaldes fra java. Ie, '*_wuddelcake_[a-f]'....
Det er ikke C++ koden, som er obfusceret...det er Java koden.
Havde det bare været compilet og ikke obfusceret, så kunne 'jad' (http://en.wikipedia.org/wiki/JAD_%28JAva_Decompiler%29) decompile det til noget der ligner den originale kode...det kan man ikke med det her. Navnen er mærkelige og strenge er endnu mærkeligere.
C++ koden er til gengæld ret nemt at læse med en disassembler. På Linux bliver der tjekket en masse system informationer med 'uname', 'getuid' og 'ioctl'...resultatet ser ud til at blive krypteret, base64 enkodet og skrevet til en fil...men jeg er ikke kommet så langt endnu.
Uden at have gravet dybt i det, så kunne det være native kode beregnet til at blive loadet via JNI
Altså... Nu har jeg mange gange kommenteret SlemID.... men denne gang er jeg mere forundret over Version2's screenshot...
Edit???? really??? Så vidt jeg kan se er den slet ikke med i win7 mere... Hvor pokker har i opstøvet den oldsag?
Uden at have gravet dybt i det, så kunne det være native kode beregnet til at blive loadet via JNI
Det kan jeg bekræfte, at det er. Det aflæser nogle system informationer, som bliver krypteret, base64 enkodet og skrevet til en fil.
Windows udgaven er lidt paranoid og kigger ofte efter, om der er en debugger tilstede...hvorfor er jeg ikke nået til endnu, men jeg tror heller ikke, at jeg vil bruge meget mere tid på det.
Det er ikke en virus eller trojaner, men jeg har svært ved at se, hvorfor NemID skal bruge disse informationer.
Det kan jeg bekræfte, at det er. Det aflæser nogle system informationer, som bliver krypteret, base64 enkodet og skrevet til en fil.
Er det filen ~/danid.log? Hvis ja, kan du se hvad der sker hvis den første skrivning fejler? Nogle har sat read-only på deres danid.log for at undgå at DanID skriver til disken.
Jeg har ikke lige de nævne filer, men man burde kunne spore alle informationer appletten søger efter ved at strace processen i Linux/UNIX.
Så kan man nemt finde ud af hvad appletens maskinekode samler ind af information.
I praksis skal man vel bare tilføje strace sporing til browserens pid, når man skal bruge NemID.
Til alle reverse engineers derude. Nu kan vi NemId brugere da i det mindste trøste os med at i kigger DanID i kortene :)
I august 2010 fortalte danid til version2, at de ikke havde kode til at snage informationer i ens pc'er:
http://www.version2.dk/artikel/danid-derfor-bruger-vi-en-signeret-java-a...
Er det filen ~/danid.log? Hvis ja, kan du se hvad der sker hvis den første skrivning fejler? Nogle har sat read-only på deres danid.log for at undgå at DanID skriver til disken.
Jeg kender ikke filnavnet...tror det kommer fra Java (Java_dk_danid_plugins_Wuddelcakes_d funktionen), og der har jeg ikke kigget endnu, men jeg ser to steder (Z2_fPci og Z2_oPci), hvor 'fopen' bliver kaldt, og hvis de fejler, så gør den bare intet, men den skriver ikke til filen. Den læser indholdet, en byte ad gangen, med '_IO_getc' (mon ikke det er 'fgetc'?).
Nogle af de statiske strenge er følgende:
* '/proc/sys/kernel/hostname'
* '/proc/ide/hda/geometry'
* '/proc/ide0/hda/geometry'
* '/proc/scsi/scsi'
Derudover er der noget, som ser ud som formatteringen af en MAC adresse:
* '%02X:%02X:%02X:%02X:%02X:%02X'
* 'eth0'
* 'eth1'
* 'wlan0'
Tror det var det mest interessante indtil videre :-)
Efter som sikkerhed ved sløring i IT sikkerhedsmæssig forstand som vist her ikke har en pind med sikkerhed at gøre vil det være meget ubehageligt hvis det ikke er en fejl og nogen har brugt vores skattepenge på sådan noget pjat.
Eller som jeg siger til vores kunder: Hvis jeg med hjælp af nogen kommerciel hjælp kan komme igennem system vi har bygget til jer når I ændre administrations koderne til nogen vi ikke kender så er det ikke sikkerhed der må holde på monetære værdier, personlige oplysninger m.m.
1321565819821DanID_Applet-boot-prod.jar som er bootstrap tingen er mere interessant, er det først som bliver loader og det som henter de andre ting ned, vil nok være den som man skulle interessert sig for.
Hvis man nu sammenlignede med det "virkelige liv".
Lad os sige du havde hyret til at lave arbejde i din have. Og du havde selvfølgelig givet dem lov til at benytte dit badeværelse til toilet besøg, og dit køkken til at lave the/kaffe og dit køleskab til deres frokost sodavand/øl.
Hvad nu hvis du så overraskede dem, i at stå og affotografere dit pas og dine personlige papirer, skødet på huset etc. Fordi de skulle jo vide om du nu også var den du udgav dig for.
Det her er for at sige det lige ud et tillids brud, og et groft misbrug af privilegier, som man har presset ned over hovedet på brugerne. Igen hvis det her ikke havde været 'IT' så ville de fleste folk jo have politi anmeldt sådan et firma.
// Jesper
Tror det var det mest interessante indtil videre :-)
Ud over at det ser ud til at være tusse gammel kode (formentlig Ubuntu 9.04):
0000A060 00 47 43 43 3A 20 28 55 62 75 6E 74 75 20 34 2E .GCC: (Ubuntu 4. 0000A070 33 2E 33 2D 35 75 62 75 6E 74 75 34 29 20 34 2E 3.3-5ubuntu4) 4. 0000A080 33 2E 33 00 00 47 43 43 3A 20 28 55 62 75 6E 74 3.3..GCC: (Ubunt 0000A090 75 20 34 2E 33 2E 33 2D 35 75 62 75 6E 74 75 34 u 4.3.3-5ubuntu4 0000A0A0 29 20 34 2E 33 2E 33 00 00 47 43 43 3A 20 28 55 ) 4.3.3..GCC: (U 0000A0B0 62 75 6E 74 75 20 34 2E 33 2E 33 2D 35 75 62 75 buntu 4.3.3-5ubu 0000A0C0 6E 74 75 34 29 20 34 2E 33 2E 33 00 00 47 43 43 ntu4) 4.3.3..GCC 0000A0D0 3A 20 28 55 62 75 6E 74 75 20 34 2E 33 2E 33 2D : (Ubuntu 4.3.3- 0000A0E0 35 75 62 75 6E 74 75 34 29 20 34 2E 33 2E 33 00 5ubuntu4) 4.3.3. 0000A0F0 00 47 43 43 3A 20 28 55 62 75 6E 74 75 20 34 2E .GCC: (Ubuntu 4. 0000A100 33 2E 33 2D 35 75 62 75 6E 74 75 34 29 20 34 2E 3.3-5ubuntu4) 4. 0000A110 33 2E 33 00 00 47 43 43 3A 20 28 55 62 75 6E 74 3.3..GCC: (Ubunt 0000A120 75 20 34 2E 33 2E 33 2D 35 75 62 75 6E 74 75 34 u 4.3.3-5ubuntu4 0000A130 29 20 34 2E 33 2E 33 00 00 47 43 43 3A 20 28 55 ) 4.3.3..GCC: (U 0000A140 62 75 6E 74 75 20 34 2E 33 2E 33 2D 35 75 62 75 buntu 4.3.3-5ubu 0000A150 6E 74 75 34 29 20 34 2E 33 2E 33 00 00 47 43 43 ntu4) 4.3.3..GCC 0000A160 3A 20 28 55 62 75 6E 74 75 20 34 2E 33 2E 33 2D : (Ubuntu 4.3.3- 0000A170 35 75 62 75 6E 74 75 34 29 20 34 2E 33 2E 33 00 5ubuntu4) 4.3.3. 0000A180 00 47 43 43 3A 20 28 55 62 75 6E 74 75 20 34 2E .GCC: (Ubuntu 4. 0000A190 33 2E 33 2D 35 75 62 75 6E 74 75 34 29 20 34 2E 3.3-5ubuntu4) 4. 0000A1A0 33 2E 33 00 00 47 43 43 3A 20 28 55 62 75 6E 74 3.3..GCC: (Ubunt 0000A1B0 75 20 34 2E 33 2E 33 2D 35 75 62 75 6E 74 75 34 u 4.3.3-5ubuntu4 0000A1C0 29 20 34 2E 33 2E 33 00 00 47 43 43 3A 20 28 55 ) 4.3.3..GCC: (U 0000A1D0 62 75 6E 74 75 20 34 2E 33 2E 33 2D 35 75 62 75 buntu 4.3.3-5ubu 0000A1E0 6E 74 75 34 29 20 34 2E 33 2E 33 00 00 47 43 43 ntu4) 4.3.3..GCC 0000A1F0 3A 20 28 55 62 75 6E 74 75 20 34 2E 33 2E 33 2D : (Ubuntu 4.3.3- 0000A200 35 75 62 75 6E 74 75 34 29 20 34 2E 33 2E 33 00 5ubuntu4) 4.3.3. 0000A210 00 47 43 43 3A 20 28 55 62 75 6E 74 75 20 34 2E .GCC: (Ubuntu 4. 0000A220 33 2E 33 2D 35 75 62 75 6E 74 75 34 29 20 34 2E 3.3-5ubuntu4) 4. 0000A230 33 2E 33 00 00 47 43 43 3A 20 28 55 62 75 6E 74 3.3..GCC: (Ubunt 0000A240 75 20 34 2E 33 2E 33 2D 35 75 62 75 6E 74 75 34 u 4.3.3-5ubuntu4 0000A250 29 20 34 2E 33 2E 33 00 00 47 43 43 3A 20 28 55 ) 4.3.3..GCC: (U 0000A260 62 75 6E 74 75 20 34 2E 33 2E 33 2D 35 75 62 75 buntu 4.3.3-5ubu 0000A270 6E 74 75 34 29 20 34 2E 33 2E 33 00 00 00 00 00 ntu4) 4.3.3..... 0000A280 24 00 00 00 02 00 00 00 00 00 04 00 00 00 00 00 $............... 0000A290 9C 13 00 00 22 00 00 00 C8 7F 00 00 13 00 00 00 ...."........... 0000A2A0 00 00 00 00 00 00 00 00 24 00 00 00 02 00 78 00 ........$.....x. 0000A2B0 00 00 04 00 00 00 00 00 C8 13 00 00 04 00 00 00 ................ 0000A2C0 E0 7F 00 00 04 00 00 00 00 00 00 00 00 00 00 00 ................ 0000A2D0 74 00 00 00 02 00 00 00 00 00 04 01 00 00 00 00 t............... 0000A2E0 00 00 00 00 2F 62 75 69 6C 64 2F 62 75 69 6C 64 ..../build/build 0000A2F0 64 2F 67 6C 69 62 63 2D 32 2E 39 2F 62 75 69 6C d/glibc-2.9/buil 0000A300 64 2D 74 72 65 65 2F 69 33 38 36 2D 6C 69 62 63 d-tree/i386-libc 0000A310 2F 63 73 75 2F 63 72 74 69 2E 53 00 2F 62 75 69 /csu/crti.S./bui 0000A320 6C 64 2F 62 75 69 6C 64 64 2F 67 6C 69 62 63 2D ld/buildd/glibc- 0000A330 32 2E 39 2F 63 73 75 00 47 4E 55 20 41 53 20 32 2.9/csu.GNU AS 2 0000A340 2E 31 39 2E 31 00 01 80 4C 00 00 00 02 00 12 00 .19.1...L.......
Nu har Danid jo udtalt at de har flere muligheder for at øge sikkerheden ved Nemid. Den kode der tales om her kan vel være en del af en sådan løsning?
Det som DanID prøver at beskytte sig imod er, hvis computeren allerede er overtaget af en virus.
Ved nærmere eftertanke - det er måske også for at prøve at forhindre, at nogen bygger et automatiseret MitM-angreb, i stil med det manuelle angreb som Version2 demonstrerede. Hvis det er svært at læse koden, så er det også svært at lave sin egen tilpassede version af appletten til det automatiserede angreb.
DanID kunne jo prøve at proppe kode ind i appletten som prøvede at detektere, at den samme angriber brugte NemID mange gange i træk, hvis angriberen brugte DanIDs applet umodificeret. Et automatiseret angreb med en custom applet vil jo være mere eller mindre immumt over DanID's forsvar.
DanID kunne jo prøve at proppe kode ind i appletten som prøvede at detektere, at den samme angriber brugte NemID mange gange i træk, hvis angriberen brugte DanIDs applet umodificeret. Et automatiseret angreb med en custom applet vil jo være mere eller mindre immumt over DanID's forsvar.
Den slags skal ikke i appletten, for det er client side security og ikke meget mere værd en security by obscurity.
Et sådant tjek skal på serveren for at være effektivt.
Den slags skal ikke i appletten, for det er client side security og ikke meget mere værd en security by obscurity. Et sådant tjek skal på serveren for at være effektivt.
Jeg sagde ikke at det ville være meget værd. Jeg sagde at DanID måske havde tænkt sådan.
Nu kan man se af gif-filerne at de indsamler hardware-information. Hvis nu appletten sende den information til serveren ved hvert login, så kunne DanID på server-siden lave statistik, og vide at den samme computer blev brugt med mange forskellige brugerkonto. Hvis altså MitM-angriberen brugte den officielle applet (på højre computer i Version2's demo-video).
Kigger man på dem, finder man ud af, det er PE filer.
Umiddelbart ligner de bare to udgaver af samme fil: en til x86 og en til x86-64. De importerer samme filer og eksporterer samme.
De eksporterer:
_Java_dk_danid_plugins_Wuddelcakes_a
... helt til...
_Java_dk_danid_plugins_Wuddelcakes_f
Hvilket passer meget fint med, at strengene brugt i Wuddelcakes-klassen fås gennem native metoder.
Noget af det interessante er dog, hvad de begge importerer:
advapi32.dll
kernel32.dll
ole32.dll
oleaut32.dll
user32.dll
Så der er helt sikkert mulighed for at læse fra og skrive til harddisk og registreringsdatabase.
I advapi32.dll importeres funktioner til at læse brugernavn og keys fra registreringsdatabasen. Mit bud på strengene i Wuddelcakes vil være strenge med ens brugernavn samt andre data.
Jeg har kigget på ELF-udgaven og du har i høj grad ret. Så vidt jeg kan se er eneste formål med den at skaffe system-data (på hashed form).
Den gør omtrent det her: http://pwnies.dk/nemid.py
P.s. jeg beklager at jeg kom til at anmelde dit indlæg.
Nogle af de statiske strenge er følgende: * '/proc/sys/kernel/hostname' * '/proc/ide/hda/geometry' * '/proc/ide0/hda/geometry' * '/proc/scsi/scsi'
/proc/scsi/scsi er bare en fil, og den er ret nem at læse direkte fra Java, og da NemID har adgang til hele disken, så er der ingen grund til at have en .so-fil (hvilket error.gif ligner) for at samle disse informationer. /proc/scsi/scsi indeholder bare oplysninger om disken, fabrikat etc.
De kald error.gif laver ligner mest noget med at få en ID på maskinen, og det bruges måske bare til at afgøre om der er sket ændringer på maskinen og om JAR filen skal hentes igen. I så fald en lidt underlig måde at afgøre det på.
Til dem der ikke kan pakke jar-filen ud, har jeg lagt dem her:
http://w0.dk/~chlor/nemid/
Noget af det interessante er dog, hvad de begge importerer:
Du skal ikke lægge alt for meget i et hurtigt kig på import tabellen - jeg har ikke selv kigget på filerne, men fra de EDIT screenshots i starten af artiklen ser det ud til at DLL'erne er compilet med Visual C++. Dens CRT har en række standard-imports, der ikke nødvendigvis bliver brugt. Der skal lidt disassembly til før man kan drage konklusioner :)
pause.idb gør så vidt jeg kan se præcis det samme som error.gif.
Dog snager den i en hel del flere ting - primært via WQL.
Det mest fristende er vel at se hvad de native kald i Wuddlecakes gør, men det er nok krypteret på det niveau også:
final class dk.danid.plugins.Wuddelcakes {
static native java.lang.String d(java.lang.String);
static native java.lang.String c(java.lang.String);
static native java.lang.String a(java.lang.String);
static native java.lang.String f(java.lang.String);
static native java.lang.String e(java.lang.String);
dk.danid.plugins.Wuddelcakes();
}
Det mest fristende er vel at se hvad de native kald i Wuddlecakes gør, men det er nok krypteret på det niveau også:
Det er de ikke. Det er det, du kan se ved at disassemble de der "gif" filer :-)
De laver et fingerprint af maskinen. Der hentes en masse system informationer, hostnavn, disk parametre, MAC adresser på netkortene. Den slags...det ser ud til at de så bliver hashet og så ved jeg ikke, hvad der sker derudover.
Måske det bare er en slags identifikation af hardwaren.
logo2.gif gør (overraskende nok) det samme.
Den får primært sine data fra /usr/sbin/system_profiler.
I Mac OS X udgaver er der ihvertfald både en cAES256, SHA256 og en HMAC_SHA256, så det er nok rigtigt (lærte lige otool og otx dér)
Det tyder på at appletten derved indsamler data, der potentielt ville kunne knytte brugen af NemID til en bestemt maskine - det kunne jo gode ekstra indicier hvis eller hvis en tvist opstår om hvem, der har underskrevet hvad hvornår.
Til dem, der ikke kender begrebet: Dette er præcis problemet ved security by obscurity:
Man forsøger at skjule noget som ikke er sikkert. Den manglende sikkerhed er jo at nøglen ikke er i brugerens lomme. Tiltag som det skjulte DLL/so/dylib, som bryder ud af Java-sandkassen gør det muligt at gå efter alle amatørerne med indicier.
En rigtig angriber vil selvfølgelig kombinere anvendelsen af et TOR netværk med en passende virtuel afvikling af appletten, hvis han ikke blot bruger et kompromitteret JVM. Det ville være dumt at antage at en alvorlig angriber vidste mindre om sikkerhed og disassemblering end et par emsige Version2-læsere.
Den skjulte DLL er selvfølgelig den eneste reelle grund til overhovedet at have en applet, som jo ville være er unødvendig i det rene NemID tilfælde (men nødvendig med den gamle signatur).
Har nogen af jer kigget efter, om det der ligner billedfiler, kun indeholder billeddata ?
Her er så et import dump af large.gif på Windows:
KERNEL32.dll
180013028 Import Address Table
1800177E8 Import Name Table
0 time date stamp
0 Index of first forwarder reference
1F6 GetModuleHandleA
220 GetProcAddress
223 GetProcessHeap
245 GetSystemDirectoryA
276 GetVersionExW
26E GetUserDefaultLangID
176 GetComputerNameA
4BD lstrlenA
142 FlushFileBuffers
43 CloseHandle
79 CreateFileA
1E8 GetLocaleInfoA
1AE GetCurrentThreadId
140 FlsSetValue
170 GetCommandLineA
431 TerminateProcess
1AA GetCurrentProcess
442 UnhandledExceptionFilter
419 SetUnhandledExceptionFilter
2CB IsDebuggerPresent
397 RtlVirtualUnwind
390 RtlLookupFunctionEntry
389 RtlCaptureContext
1E6 GetLastError
2A1 HeapFree
29D HeapAlloc
354 RaiseException
392 RtlPcToFileHeader
D6 EncodePointer
B8 DecodePointer
13F FlsGetValue
13E FlsFree
3F0 SetLastError
13D FlsAlloc
425 Sleep
1F9 GetModuleHandleW
105 ExitProcess
3EC SetHandleCount
23B GetStdHandle
1D8 GetFileType
239 GetStartupInfoA
BF DeleteCriticalSection
1F4 GetModuleFileNameA
14B FreeEnvironmentStringsA
1C0 GetEnvironmentStrings
14C FreeEnvironmentStringsW
47E WideCharToMultiByte
1C2 GetEnvironmentStringsW
2A5 HeapSetInformation
29F HeapCreate
2A0 HeapDestroy
396 RtlUnwindEx
34E QueryPerformanceCounter
266 GetTickCount
1AB GetCurrentProcessId
24F GetSystemTimeAsFileTime
3E4 SetFilePointer
491 WriteFile
184 GetConsoleCP
196 GetConsoleMode
DA EnterCriticalSection
2E9 LeaveCriticalSection
15C GetCPInfo
153 GetACP
213 GetOEMCP
2D5 IsValidCodePage
2A6 HeapSize
2A4 HeapReAlloc
2EB LoadLibraryA
2B5 InitializeCriticalSectionAndSpinCount
400 SetStdHandle
486 WriteConsoleA
19A GetConsoleOutputCP
490 WriteConsoleW
314 MultiByteToWideChar
2DB LCMapStringA
2DD LCMapStringW
23D GetStringTypeA
240 GetStringTypeW
USER32.dll
1800132E0 Import Address Table
180017AA0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
171 GetSystemMetrics
ADVAPI32.dll
180013000 Import Address Table
1800177C0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
15E GetUserNameA
25A RegOpenKeyExA
267 RegQueryValueExA
22A RegCloseKey
ole32.dll
1800132F0 Import Address Table
180017AB0 Import Name Table
0 time date stamp
0 Index of first forwarder reference
14 CoCreateInstance
6F CoUninitialize
42 CoInitializeEx
66 CoSetProxyBlanket
OLEAUT32.dll
1800132A8 Import Address Table
180017A68 Import Name Table
0 time date stamp
0 Index of first forwarder reference
Ordinal 6
Ordinal 12
Ordinal 8
Ordinal 10
Ordinal 9
Ordinal 2
...og der eksporteres som nævnt Java_dk_danid_plugins_Wuddelcakes_X for X i [a, f].
Har nogen af jer kigget efter, om det der ligner billedfiler, kun indeholder billeddata ?
Jeg har ikke kigget nærmere efter - men udover skjulte data indeholder de i hvert fald også rigtige billeder. Derudover er de ret små i forhold til de 4 relevante filer. Den største af de andre er på 8666 bytes, mens den mindste af programfilerne er på 44325 bytes.
DanID har her på Version2 udtrykt at der er en grund til, at de bruger en signeret applet: http://www.version2.dk/artikel/danid-derfor-bruger-vi-en-signeret-java-a...
Specielt dette afsnit:
"DanID afviser blankt, at NemID's Java-applet indeholder funktioner, der kan bruges til at snage på folks computere."
Har vi i fællesskab ikke netop påpeget, at dette er tilfældet?
DanID har her på Version2 udtrykt at der er en grund til, at de bruger en signeret applet: http://www.version2.dk/artikel/danid-derfor-bruger-vi-en-signeret-java-a... Specielt dette afsnit: "DanID afviser blankt, at NemID's Java-applet indeholder funktioner, der kan bruges til at snage på folks computere." Har vi i fællesskab ikke netop påpeget, at dette er tilfældet?
Det kommer desværre an på din definition af at snage. Hvis snage kræver at de får data ud, så har vi ikke. Hvis snage bare kræver at de læser og tager hashes af diverse ting, så har vi.
De bruger nok de informationer til enten:
1. Se hvilke computere og deres setup, der bruger NemID
2. Konstatere om brugerens computer kan bruges til NemID
3. En form for log, for at se hvis der kommer angreb, hvilken maskine de så kommer fra
Jeg går ud fra at NemID virker fra f.eks. FreeBSD (ellers havde vi jo nok hørt om det for længst), så gad vide hvad den gør i de situationer?
Hvis det er en del af NemID's sikkerhed, vil det være lidt upraktisk hvis man kan omgå det ved bare skifte til FreeBSD eller Solaris...
De bruger nok de informationer til enten: 1. Se hvilke computere og deres setup, der bruger NemID 2. Konstatere om brugerens computer kan bruges til NemID 3. En form for log, for at se hvis der kommer angreb, hvilken maskine de så kommer fra
Vær opmærksom på at:
- De får kun hashede værdier
- De tager også eksempelvis brugernavn, hostname og et id fra din harddisk.
Det vil sige, at de tager information der ikke har indflydelse på om nemid vil virke - og som derudover er hashed. De kan heller ikke være sikker på at værdierne er de samme, da jeg eksempelvis godt kan skifte min computers netkort eller hostname.
Det eneste jeg kan se at det kan bruges til er at identificere at der er blevet logget på fra en bestemt computer, så de kan bevise at en IT-kriminels computer er blevet brugt til at logge ind på Fru Jensens netbank. Og da de IT-kriminelle formentlig selv kan regne de her ting ud, kører de nok bare på en virtuel maskine med tilfældigt genereret hostname, brugernavn, osv.
Hvis der lige er nogen der kan pathce programmerne til altid at returnere "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" og så vi alle sammen forsøger at bruge NemID samtidigt. Så kan det være at vi kan trigge en interessant beskyttelsesmekanisme.
Hvis der lige er nogen der kan pathce programmerne til altid at returnere "01ba4719c80b6fe911b091a7c05124b64eeece964e09c058ef8f9805daca546b" og så vi alle sammen forsøger at bruge NemID samtidigt. Så kan det være at vi kan trigge en interessant beskyttelsesmekanisme.
Jeg har lavet en 32-bit windows-udgave som burde gøre det. (Bortset fra at jeg ikke bruger det tal).
Den skulle gerne give de samme hashes hver gang - og det skulle gerne være nogen som systemet ikke normalt bruger.
Jeg vil dog ikke garantere at jeg ikke har lavet en dum fejl - eller at deres applet ikke laver en checksum af den først.
http://pwnies.dk/pause.new.gif
Meld gerne tilbage hvad I finder ud af (jeg kører ikke selv windows). ;)
Jeg vil dog ikke garantere at jeg ikke har lavet en dum fejl - eller at deres applet ikke laver en checksum af den først.
Jeg vil håbe at DanID's Java applet laver checksum af koden i ~/.oces2 inden den bliver udført. Hvis en angriber kan komme til at overskrive nogle af filerne i ~/.oces2, vil du eksekvere denne kode (malware) når du bruger NemID. Executables i ~/.oces2 modarbejder også princippet om at den type filer skal være ejet at root (eller UAC på Windows).
Hvis man undersøger ELF version (error.gif) bliver det ganske tydeligt, at der er tale om native unsandboxed C++ kode, der bliver kaldt via JNI fra appletten.
Den benytter libstdc++.so.6, libm.so.6 og libc.so.6 og symboltabellen afslører det drejer sig om kaldene:
Symbol table '.dynsym' contains 88 entries:
Num: Value Size Type Bind Vis Ndx Name
0: 00000000 0 NOTYPE LOCAL DEFAULT UND
1: 00000000 0 FUNC GLOBAL DEFAULT UND abort@GLIBC_2.0 (2)
2: 00000000 0 NOTYPE WEAK DEFAULT UND gmon_start
3: 00000000 0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses
4: 00000000 0 FUNC GLOBAL DEFAULT UND _IO_getc@GLIBC_2.0 (2)
5: 00000000 0 FUNC GLOBAL DEFAULT UND uname@GLIBC_2.0 (2)
6: 00000000 0 NOTYPE WEAK DEFAULT UND pthread_once
7: 00000000 0 FUNC GLOBAL DEFAULT UND free@GLIBC_2.0 (2)
8: 00000000 0 FUNC GLOBAL DEFAULT UND ioctl@GLIBC_2.0 (2)
9: 00000000 0 FUNC GLOBAL DEFAULT UND socket@GLIBC_2.0 (2)
10: 00000000 0 FUNC WEAK DEFAULT UND pthread_mutex_unlock@GLIBC_2.0 (2)
11: 00000000 0 FUNC GLOBAL DEFAULT UND fclose@GLIBC_2.1 (3)
12: 00000000 0 FUNC GLOBAL DEFAULT UND memcpy@GLIBC_2.0 (2)
13: 00000000 0 FUNC GLOBAL DEFAULT UND strlen@GLIBC_2.0 (2)
14: 00000000 0 FUNC GLOBAL DEFAULT UND fopen@GLIBC_2.1 (3)
15: 00000000 0 FUNC GLOBAL DEFAULT UND strcpy@GLIBC_2.0 (2)
16: 00000000 0 FUNC GLOBAL DEFAULT UND getuid@GLIBC_2.0 (2)
17: 00000000 0 FUNC GLOBAL DEFAULT UND malloc@GLIBC_2.0 (2)
18: 00000000 0 FUNC WEAK DEFAULT UND pthread_mutex_lock@GLIBC_2.0 (2)
19: 00000000 0 NOTYPE WEAK DEFAULT UND pthread_cancel
20: 00000000 0 FUNC GLOBAL DEFAULT UND __sprintf_chk@GLIBC_2.3.4 (4)
21: 00000000 0 FUNC GLOBAL DEFAULT UND __snprintf_chk@GLIBC_2.3.4 (4)
22: 00000000 0 FUNC GLOBAL DEFAULT UND dl_iterate_phdr@GLIBC_2.2.4 (5)
23: 00000000 0 FUNC GLOBAL DEFAULT UND __gxx_personality_v0@CXXABI_1.3 (6)
24: 0000186b 38 FUNC GLOBAL DEFAULT 11 _Z23BytesToWordLittleEndi
25: 00002c99 116 FUNC GLOBAL DEFAULT 11 Java_dk_danid_plugins_Wud
26: 00001a5c 99 FUNC GLOBAL DEFAULT 11 _ZN7cAES25613InvMixColumn
27: 00002d3e 43 FUNC GLOBAL DEFAULT 11 Java_dk_danid_plugins_Wud
28: 00008c94 11 OBJECT GLOBAL DEFAULT 13 LibraryVersion
29: 0000b080 1024 OBJECT GLOBAL DEFAULT 23 _e_
30: 00002abe 92 FUNC GLOBAL DEFAULT 11 Java_dk_danid_plugins_Wud
31: 00002258 182 FUNC GLOBAL DEFAULT 11 _ZN11cCBC_AES2567DecryptE
32: 00003126 278 FUNC GLOBAL DEFAULT 11 _Z15CollectPcFpDataPA32_h
33: 00002b1a 205 FUNC GLOBAL DEFAULT 11 Java_dk_danid_plugins_Wud
34: 00007fc8 0 FUNC GLOBAL DEFAULT 12 _fini
35: 00002ff1 109 FUNC GLOBAL DEFAULT 11 _Z2_5Pci
36: 0000802c 4 OBJECT GLOBAL DEFAULT 13 _9
37: 0000171b 10 FUNC GLOBAL DEFAULT 11 _Z2_qv
38: 000019c2 34 FUNC GLOBAL DEFAULT 11 _ZN7cAES256D1Ev
39: 00002398 37 FUNC GLOBAL DEFAULT 11 _ZN11cCBC_AES2568KeySetup
40: 00002586 34 FUNC GLOBAL DEFAULT 11 _ZN7cSHA256C2Ev
41: 00002dc5 98 FUNC GLOBAL DEFAULT 11 _Z2_mPci
42: 00003260 159 FUNC GLOBAL DEFAULT 11 _Z16GetAuthenticatorjPKhP
43: 00003588 62 FUNC GLOBAL DEFAULT 11 _Z4Initv
44: 0000276c 837 FUNC WEAK DEFAULT 11 _ZN7cSHA25612ProcessBlock
45: 000026a2 201 FUNC GLOBAL DEFAULT 11 _ZN7cSHA2567ProcessEPKhj
46: 0000323c 36 FUNC GLOBAL DEFAULT 11 _Z5Closev
47: 00001ac0 850 FUNC GLOBAL DEFAULT 11 _ZN7cAES25612DecryptBlock
48: 000034dc 172 FUNC GLOBAL DEFAULT 11 _Z14GetIdentifiersPh
49: 000015d0 331 FUNC GLOBAL DEFAULT 11 _Z12Base64EncodePKhPcjj
50: 00002ecc 206 FUNC GLOBAL DEFAULT 11 _Z2_fPci
51: 000018ba 62 FUNC GLOBAL DEFAULT 11 _Z24BytesToWordsLittleEnd
52: 00008aa8 4 OBJECT GLOBAL DEFAULT 13 _i
53: 00001891 10 FUNC GLOBAL DEFAULT 11 _Z2_ev
54: 000024f4 13 FUNC GLOBAL DEFAULT 11 _Z5_rotrjj
55: 0000305e 200 FUNC GLOBAL DEFAULT 11 _Z2__Pci
56: 00001e12 838 FUNC GLOBAL DEFAULT 11 _ZN7cAES25612EncryptBlock
57: 00002e27 53 FUNC GLOBAL DEFAULT 11 _Z2_yPci
58: 000023f2 53 FUNC GLOBAL DEFAULT 11 _ZN12cHMAC_SHA2565ResetEv
59: 00001a3c 31 FUNC GLOBAL DEFAULT 11 _ZN7cAES2566FFmulXEj
60: 000023ca 40 FUNC GLOBAL DEFAULT 11 _ZN12cHMAC_SHA2567Process
61: 000032ff 477 FUNC GLOBAL DEFAULT 11 _Z6EnrollPKhPh
62: 0000b060 0 NOTYPE GLOBAL DEFAULT ABS __bss_start
63: 00001935 105 FUNC GLOBAL DEFAULT 11 _Z15HashFingerprintPKciiP
64: 00002502 97 FUNC GLOBAL DEFAULT 11 _ZN7cSHA2565ResetEv
65: 000019a0 34 FUNC GLOBAL DEFAULT 11 _ZN7cAES256D2Ev
66: 0000b5a4 0 NOTYPE GLOBAL DEFAULT ABS _end
67: 00001725 272 FUNC GLOBAL DEFAULT 11 _Z12Base64DecodePKcPhjj
68: 00007fe4 4 OBJECT GLOBAL DEFAULT 13 _s
69: 0000230e 137 FUNC GLOBAL DEFAULT 11 _ZN11cCBC_AES2567EncryptE
70: 00002ab4 10 FUNC GLOBAL DEFAULT 11 _Z2_lv
71: 00002d6c 7 FUNC GLOBAL DEFAULT 11 _Z23ReadCpuClockTickCount
72: 00008aac 256 OBJECT GLOBAL DEFAULT 13 _ZN7cSHA2561KE
73: 00002158 254 FUNC GLOBAL DEFAULT 11 _ZN7cAES2568KeySetupEPKh
74: 0000b060 0 NOTYPE GLOBAL DEFAULT ABS _edata
75: 000019e4 88 FUNC GLOBAL DEFAULT 11 _ZN7cAES2567SubWordEj
76: 00002564 34 FUNC GLOBAL DEFAULT 11 _ZN7cSHA256C1Ev
77: 000023c0 10 FUNC GLOBAL DEFAULT 11 _Z2_kv
78: 00002f9a 87 FUNC GLOBAL DEFAULT 11 _Z2_oPci
79: 0000189b 31 FUNC GLOBAL DEFAULT 11 _Z23WordToBytesLittleEndi
80: 000018f8 61 FUNC GLOBAL DEFAULT 11 _Z24WordsToBytesLittleEnd
81: 000025a8 249 FUNC GLOBAL DEFAULT 11 _ZN7cSHA2568FinalizeEPhj
82: 00002be7 178 FUNC GLOBAL DEFAULT 11 Java_dk_danid_plugins_Wud
83: 0000139c 0 FUNC GLOBAL DEFAULT 9 _init
84: 00002d0d 49 FUNC GLOBAL DEFAULT 11 Java_dk_danid_plugins_Wud
85: 00002488 107 FUNC GLOBAL DEFAULT 11 _ZN12cHMAC_SHA2568Finaliz
86: 00002428 96 FUNC GLOBAL DEFAULT 11 _ZN12cHMAC_SHA2568KeySetu
87: 0000183c 47 FUNC GLOBAL DEFAULT 11 _Z9IntToStr2iPc
Tilbage er så spørgsmålet, hvad har DanID brug for via native kode, som de ikke kan få igennem Java's sandkasse?! Det begynder jo helt klart at se ud som om at hovedårsagen til overhovedet at bruge en applet, er at downloade og eksekvere native kode via browseren!
Tilbage er så spørgsmålet, hvad har DanID brug for via native kode, som de ikke kan få igennem Java's sandkasse?! Det begynder jo helt klart at se ud som om at hovedårsagen til overhovedet at bruge en applet, er at downloade og eksekvere native kode via browseren!
Prøv at kigge på mit indlæg i en anden tråd: http://www.version2.dk/artikel/danid-ja-vi-staar-bag-de-fire-skjulte-pro...
Der er en en sætning der indeholder ordene "PET", "bagdør", og "krav om".
Synes du at det lyder som en mulighed, Casper Bang? Andre må naturligvis også meget gerne kommentere den mistanke.
Hvis du svarer, så begrund dit svar.
Synes du at det lyder som en mulighed, Casper Bang? Andre må naturligvis også meget gerne kommentere den mistanke.
Jeg har svaret i den anden tråd, så vi kan lukke denne ældre tråd.
http://www.version2.dk/artikel/danid-ja-vi-staar-bag-de-fire-skjulte-pro...
otx logo2.gif er lidt interessant... specielt i funtionen SystemProfiler henter den stort set alt der er at vide om min hardware, mac-adresse, serienummer (apple-computer) etc... den bruger /usr/sbin/system_profiler
Jeg kan simpelthen ikke tro at DanID har døbt filerne sådan af sikkerhedsmæssige årsager. Det ville være for dumt.
Det mest nærliggende er da også at det blot er et hack for at omgå en eller anden teknisk (måske sikkerhedsrelateret) begrænsning.
Men uanset. En national digital signatur burde aldrig være kommet i nærheden af sådan et scenarie her. Det er stadig en skandale.
Enhedslisten bringer spørgsmålet op i Folketinget, idet Stine Brix (EL) henviser specifikt til afsløringen af, at NemID benytter skjult programkode: http://politiken.dk/tjek/digitalt/computer/ECE1524164/enhedslisten-snige...
Psst. Husk, hvor partierne står i sager som denne, når det næste valg kommer. :)
Psst. Husk, hvor partierne står i sager som denne, når det næste valg kommer. :)
Problemet er bare at man kan finde et hvilket som helst parti, der i enkeltsager som dette agerer hensigtsmæssigt eller ej - og lige omkring de bizarre ting der sker for tiden, som dette og ACTA, så ser vi at det er yderfløjene der er de eneste der er nogenlunde vågne.
Desværre er mange andre parametre der indgår i styring af et land, så uagtet hvor gode intentioner EL ellers har på lige dette område, så er der også en masse takter der er uforenelige med en forsvarlig forvaltning af et land - og uagtet hvilken retning man vender kikkerten, så er det svært at finde nogen politikere der ikke enten er hamrende inkompetente, eller syltet ind i skandalerne på en måde der grænser til det korrupte.
