Der blev ringet med den store alarmklokke, da det blev offentlig kendt, at et ikke-patchet sikkerhedshul i Java blev aktivt udnyttet af it-kriminelle.
Ikke mindst fordi fire millioner danskere var berørt af hullet, fordi de som NemID-brugere har installeret Java på deres computere.
Medierne stod nærmest i kø for at advare befolkningen og give gode råd om, hvordan man kunne deaktivere Java og i øvrigt burde opføre sig på nettet.
Men nu viser det sig, at den reelle trussel fra Javahullet var til at overse. Version2 har med hjælp fra flere aktører på it-sikkerhedsfronten forsøgt at afdække, hvor mange danskere, der blev inficeret med malware gennem det pågældende hul i Java.
I den offentlige sektor overvåger den Center for Cybersikkerhed internettrafikken i de fleste ministerier og dele af forsvaret. Og her er antallet af infektioner dejlig nemt at gøre op:
»På de forbindelser, vi monitorerer, har vi ikke registreret forsøg på at udnytte hullet,« siger afdelingschef i Center for Cybersikkerhed Thomas Kristmar til Version2.
Det runde nul skyldes hverken, at hackere i al almindelig afholder sig fra at angribe den offentlige sektor, eller at Center for Cybersikkerhed er dårlige til at registrere denne type angreb.
»Der er en lang række exploit kits, som vi jævnligt ser forsøg på kommunikation med. Den aktuelle sårbarhed blev blandt andet optaget i exploit-kittet Blackhole, men vi har som sagt ikke set nogen forsøge at udnytte netop Javahullet,« uddyber Thomas Kristmar over for Version2.
Antivirusfirmaet Kaspersky kunne kort tid efter, at hullet blev offentligt kendt offentliggøre data, der placerede Danmark i den laveste kategori i en rangordning af ramte nationer, men helt fri er danskerne ikke gået:
»Vi optalte færre end 100 Exploit.Java.CVE-2013-0422.gen-detektioner på maskiner, der kører vores software i Danmark. Sammenlignet med adskillige tusinder detektioner i Tyskland er dette antal tydeligvis temmelig lavt. Dette er imidlertid ingen overraskelse, eftersom exploitet primært blev udnyttet af russiske, engelsksprogede og tyske websites," lyder det i et e-mailsvar fra Magnus Kalkuhl, der er vicedirektør i Kaspersky Labs globale research- og analyseteam, til Version2.
Kaspersky oplyser til Version2, at de er nummer to på det danske antivirusmarked med en markedsandel på 18 procent. Hvis man antager, at udnyttelsen af Javahullet er jævnt fordelt over brugere af forskellige antiviruspakker svarer Kasperskys tal derfor til, at højst 550 danskere har fået malware gennem sårbarheden i Java.
- emailE-mail
- linkKopier link

...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.
Fortsæt din læsning
- Sortér efter chevron_right
- Trådet debat
Jeg spørger egentlig kun fordi der jo ikke er noget galt i at have Java installeret, det er browser plugin og dets runtime der er problemet her. I alm. medier kan jeg godt forstå at de tager fejl, de ved ikke bedre, men her? Det virker lidt som da en af de store landsdækkende medier sidst var ude med at der var et sikkerhedshul i internettet... WOW! (Ved læsning andre steder kunne man lokalisere hullet til IE...)
Ja Java er sikkert og en godt ting, og sikke de lapper deres huller hurtigt, og nu er det sikkert igen.
..... Eller også er der allerede fundet nye hullerhttps://threatpost.com/en_us/blogs/latest-java-update-broken-two-new-sandbox-bypass-flaws-found-011813
Så på den igen med hele baladen?
Jeg er forresten en af dem, der stemmer for at droppe Java i browseren, og syntes at DanID er ret incompetente
Linket siger 404
Enig. Det første har jeg ikke brug for til andet end NemId. Det næste har DanId vist selv bevist med deres meddellelser til V2-redaktionen.Jeg er forresten en af dem, der stemmer for at droppe Java i browseren, og syntes at DanID er ret incompetente
Antallet af infektioner på overvågede offentlige installationer er 0! LOL. Hvis jeg skulle vælge mellem MITM på 5 mio ikke-IT-kyndige brugere, eller at gå efter 500 offentlige myndigheder (med logning og overvågning), så var udfaldet da 100% klart; gå efter Hr og Fru Jensen, som intet aner om IT og -sikkerhed, og "bare" klikker ja til det meste.I den offentlige sektor overvåger den Center for Cybersikkerhed internettrafikken i de fleste ministerier og dele af forsvaret. Og her er antallet af infektioner dejlig nemt at gøre op:</p>
<p>»På de forbindelser, vi monitorerer, har vi ikke registreret forsøg på at udnytte hullet,« siger afdelingschef i Center for Cybersikkerhed Thomas Kristmar til Version2.</p>
<p>Det runde nul skyldes hverken, at hackere i al almindelig afholder sig fra at angribe den offentlige sektor, eller at Center for Cybersikkerhed er dårlige til at registrere denne type angreb.
Pressens opblæsning har alt andet lige påvirket udfaldet til det gode, men hvordan ville udfaldet have været, hvis exploitet ikke havde været igennem hele pressemøllen?...
Hvis man som hacker sidder med et day zero og man ved at det øjeblik man begynder at udnytte det er der en hvis tid man har inden det kommer på radaren hos sikkerhedsfirmaernes honeypots [...}
Det kommer ret meget an på hvem hackeren er, selv hvis vi kun kigger på blackhats er der forskel på om det er "for teh lulz" eller med profit i øje. Hvis det er profit, er der en nøje afvejning imellem "kan jeg bruge det her til at lave meget specifikke (blackmail? spionage?) angreb der giver mig kassen, eller skal jeg sælge til højestbydende exploit-kit vendor?".
Men lige meget hvordan et exploit starter med at blive brugt, ender det på et tidspunkt hos commonplace exploit-kit folkene. Og fordi hr og fru Jensen ikke holder deres software opdateret, er det stadig et lukrativt marked.
Og der kunne sagtens tænkes at være kriminelle der vælger at bruge købe & bruge et Java exploit specifikt mod Danmark, fordi de ved at det kan være interessant på grund af vores NemID monokultur. Det kan være en afvejning af om man har behov for flere zombier til sit DDOS-afpresnings-botnet, eller om man hellere vil køre en mule-siphon-kampagne med angreb mod banker. Eller måske noget identity fraud.
ang. fx sveriges valg med BankID så er det helt klart ikke en monokultur på samme måde som fx java er.
Når det er native kode har du ikke én platform du kan angribe med ét stykke binært malware, klart - og der sandsynligvis være en pæn del permutationer af OS, hardwareplatform og software i spil. Det er klart en fordel.
Til gengæld har du en platform der dækker "mange interessante ting" i helt land, og ikke påvirker andre lande. Så det er ikke længere et spørgsmål om man skal rekruttere 5mio zombie maskiner i USA eller lave 10k mule angreb i Danmark, det er et spørgsmål om hvilke kampagner man kører i et enkelt land. Det er også farligt. Jeg har dog ikke set på implementeringen af Sveriges bank-id... forhåbentligt er det ikke et browser-plugin, men et standalone program man kører? Det vil trods alt hjælpe lidt.
Ser jeg mig for før jeg går over gaden? Ja, naturligvis. Ligger jeg vågen om natten og bekymrer mig for om jeg bliver kørt over i morgen? Nej. Derfor vil jeg altså heller ikke blive hysterisk bange for advarsler om Java-problemer.
Sikkerhed og hysteri hører ikke sammen - det handler om fornuftige forholdsregler. Det er ikke en failsafe (at du kigger dig for, før du går over vejen, hjælper ikke nødvendigvis mod folk der kører 180km/t i en byzone), men hysteri hjælper intet. Med Javas track record er det dog ikke hysteri at slå browser-plugin'et fra i sin primære browser, og så åbne enten en sekundær browser eller en full-blown VM når man skal deale med browser-Java.
I øvrigt har jeg stadig ikke forstået hvorfor nemids funktionalitet kræver javascript. Det er funktionalitet som dybest set kan implementeres med form posts, en teknologi der må siges at være velafprøvet efterhånden.
Well, der er noget tunnelled crypto protokol, der muligvis hjælper mod SSL MITM... men tydeligvis ikke virker mod MITM as a whole :)
"Men nu viser det sig, at den reelle trussel fra Javahullet var til at overse." ?
Jeg har hørt, at betydningen af ordene "overse" og "overskue" er ved at skifte, men i min verden var truslen umulig at overse.
Jeg blev dynget til med "information" omkring "den reelle trussel" fra alle mulige medier (især fra Version 2).
Men jeg vil mene, at "den reelle trussel fra Javahullet" var til at overskue, hvis man med "den reelle trussel" mener "den reelle officielt it-kriminelle trussel".
Der er et generelt problem i forbindelse med al håndtering af sikkerhed:
Hvad er sandsynligheden for at en dansker bliver dræbt i trafikken i løbet af den næste måned? Meget tæt på 100%. Hvad er sandsynligheden for at jeg bliver dræbt i trafikken i løbet af den næste måned? Meget tæt på 0.
Der er derfor stor forskel på hvordan man bør forholde sig, afhængigt af om man taler til hele Danmarks befolkning, eller man kun tænker på sin egen situation. Er det rimeligt at advare danskerne om et Java-sikkerhedshul? Ja, for sandsynligheden for at en eller anden bliver ramt er stor. Men er det rimeligt at jeg skal være dybt bekymret for min egen Java-installation? Nej, for sandsynligheden for at jeg bliver ramt er meget lille.
Ser jeg mig for før jeg går over gaden? Ja, naturligvis. Ligger jeg vågen om natten og bekymrer mig for om jeg bliver kørt over i morgen? Nej. Derfor vil jeg altså heller ikke blive hysterisk bange for advarsler om Java-problemer.
NB! fx. hvordan virker den her phishing mail ? sårbarhed i javascript ?
"Din postkasse har overskredet det lagergrænse som fastsat af administratoren, og du vil ikke være i stand til at modtage nye mails indtil du igen validere det. At re-validere -> klik her
Xerne er blokering af det faktiske dokument så ingen.
Speaking of non java sikkerheds problemer...
Altid rart at ha et sprog med mystisk den/det detaljer der afsløre spearphishers "det lagergrænse".
Hvem ville have troet at det danske sprog skulle vise sig at være det nederste lag i NemID sikkerhedsmodellen. ;-)
Det er ikke det nederste lag. Jeg bliver først mistænksom, når min netbank en dag præsenterer sig på helt korrekt dansk, har et fornuftigt og ikke-udløbet certifikat, ikke kommer med dobbelt login fordi jeg har bedt om at bruge nøglekortet til login og har svartider som forventeligt med en elektronisk løsning.
(Jeg læser pt Peter Wrights bog: Spycatcher, der har mange pointer, der kan overføres til denne slags angreb. Jeg kan varmt anbefale bogen.)
Men det er et billede af Kim Aarenstrup I har lagt ind. ...omend de måske ligner hinanden en smule .-)
Sorry. Billedet er nu fjernet - jeg blev narret af overskægget.
Vh Morten, Version2.
Det sker for os alle.jeg blev narret af overskægget.
Men der blev brugt tusindvis af timer på opgraderinger, samtaler, brugere der ikke kunne deaktive deres java. m.v. Nogen gange har man på fornemmelsen, at den største trussel mod en ordentlig, økonomisk, sikker og stabil drift af it er "sikkerhedsfirmaerne"
Var advarselerne ikke kommet, var problemet måske meget størrer, da der så måske havde været mere interesse for at angribe os.
Jeg sammenligner det lidt med År 2000 problematikken. Der blev råbt meget højt fra alle sider, og i sidste ende skete der intet. Men det var KUN fordi der blev råbt meget højt. - For fejlene var der, men blev rettet i tide. Ligesom hullet her nåede at blive lukket i tide / før nogen udnyttede det målrettet imod os.
Men der blev brugt tusindvis af timer på opgraderinger, samtaler, brugere der ikke kunne deaktive deres java. m.v.
Det er tid som burde have været brugt i forvejen allerede for at sikre at alle er på nyeste og sikreste version, eller ikke kan rammes fordi java er deaktiveret. Det er muligt at du ser det som en "ulven kommer"-historie. Problemet er blot at vi har lagt så meget over på nemid at det er meget svært at prissætte et sikkerhedsbrud.
Når zero day hullet som ikke bliver opdaget og bliver speficikt målrettet Danmark, så er vi på røven med vores forkærlighed for at indrette en monokultur som ikke har sikkerhed eller rekationshastighed nok til at kunne forsvare os.
Når zero day hullet som ikke bliver opdaget og bliver speficikt målrettet Danmark, så er vi på røven med vores forkærlighed for at indrette en monokultur som ikke har sikkerhed eller rekationshastighed nok til at kunne forsvare os.
Der er vi heldigvis beskyttet en lille smule af vore obscurity though miniscule target size.
Hvis man som hacker sidder med et day zero og man ved at det øjeblik man begynder at udnytte det er der en hvis tid man har inden det kommer på radaren hos sikkerhedsfirmaernes honeypots og derefter kan forskellige sikkerhedsmekanismer træde i effekt nogen centralt aktiverede (så som antivirus programmernes blocklists, ISPernes firewalls eller Apples XProtect minimum safe plugin list) andre decentralt aktiverede så som informationskampangner der sigter til at få brugerne til at opdatere/slå java fra når der er en usikker version ude på markedet.
Uanset hvad vil det (uanset at Danmark er et land med meget stor java instalations rate) være en voldsom investering af en faktisk java day zero exploit at målrette den mod Danmark da udbyttet er meget lille sammenlignet med at målrette den mod USA eller Tyskæland.
PS! ang. fx sveriges valg med BankID så er det helt klart ikke en monokultur på samme måde som fx java er. Men samtidigt giver det en ret heterogen forsvars perimeter med alle de forskellige version af browsere og forskellige browsere. Fx. hvis man finder en sårbarhed i en android browser på android 2.2 hvordan vil man så udbedre den user client ? lære alle der har en små gammel android dims at roote deres telefon og hvilket android image skal de så instalere istedet ? Men klart vil en sårbarhed i en browser ikke medføre samme kollektive shitstorm som et farligt java hul vil medføre.
Men hvis NETS så skulle priotere at fikse hullerne der påvirker browser zeta eller browser gamma hvordan skulle de så gøre det tilfredsstillende ?
Med Java har man helt klart single point of intrusion, men hvis man så beskytter det ene punkt (fx. ved deaktivering af den usikre pluginversion) så har man faktisk sikret brugerene. Samtidigt skal man ikke være opmærksom på 102391203 forskellige browsere og deres implemtering af de html eller javascript funmktioner man anvender og hvornår de breaker ved versions skift.
Ved en fx. javascript implementering er der ingen klar strategi der vil sikre flertallet af brugerene når man bliver opmærksom på et sikkerhedsproblem og nogen steder fx i virksomheder er det ikke et gyldigt svar at udmelde "brug browser X som IT afdelingen ikke har godkendt"...
Samtidigt skal man ikke være opmærksom på 102391203 forskellige browsere og deres implemtering af de html eller javascript funmktioner man anvender og hvornår de breaker ved versions skift.
De delmængder af javascript man skal bruge til den slags har været stabile i over 10 år. Ovenstående kommentar er FUD.
Ved en fx. javascript implementering er der ingen klar strategi der vil sikre flertallet af brugerene når man bliver opmærksom på et sikkerhedsproblem og nogen steder fx i virksomheder er det ikke et gyldigt svar at udmelde "brug browser X som IT afdelingen ikke har godkendt"...
Javascript er som udgangspunkt usikkert. Sikkerhedslaget skal ligge i transporten og backenden.
I øvrigt har jeg stadig ikke forstået hvorfor nemids funktionalitet kræver javascript. Det er funktionalitet som dybest set kan implementeres med form posts, en teknologi der må siges at være velafprøvet efterhånden.
De delmængder af javascript man skal bruge til den slags har været stabile i over 10 år. Ovenstående kommentar er FUD.
For der har ikke været nogen ændringer eller sikkerheds patches til nogen browsere eller deres javascript engines de sidste 10 år...
Derfor skal man stadig være opmærksom på hvis de ændre sig så argumentet at det er mindre omkostinings tungt at være opmærksom på en implementering istedet for mange kan jeg ikke se er FUD.
For der har ikke været nogen ændringer eller sikkerheds patches til nogen browsere eller deres javascript engines de sidste 10 år...
Naturligvis har der det. Du glemte dog at forholde dig til "De delmængder man skal bruge til den slags". Vi snakker om core javascript her, og et par event handlere i DOM. Det har alt sammen været stabilt i mange år og/eller forskellene har været pænt pakket ind i libraries således at der fra udviklerens synspunkt har været en stabil platform at arbejde på.
Sikkerheden gider jeg ikke kommentere på. Jeg har allerede etableret at javascript bør opfattes som en usikker tredjepartsklient.
Derfor skal man stadig være opmærksom på hvis de ændre sig så argumentet at det er mindre omkostinings tungt at være opmærksom på en implementering istedet for mange kan jeg ikke se er FUD.
Du lyder ikke som om du har særlig erfaring med moderne webudvikling når du kommer med udtalelser som at forskellige browsere kræver forskellige kodebaser. Jeg vil gerne byde på en øl og bringe din viden om front end webudvikling ind i dette årtusinde.
Du lyder ikke som om du har særlig erfaring med moderne webudvikling når du kommer med udtalelser som at forskellige browsere kræver forskellige kodebaser. Jeg vil gerne byde på en øl og bringe din viden om front end webudvikling ind i dette årtusinde.
eeh... ok. det har ikke været min erfaring i den faktiske virkelighed.
Jeg ved godt det i teorien er muligt (specielt hvis man har ubegrænsede budgetter, specielt til testing), men har bare set meget få tilfælde hvor det faktisk er blevet leveret. Der har altid været en dum detalje her eller der der har fået det løfte som internettet og browser baserede apps gav os for snart mange år siden til at gå op i røg.
og måske der er nogen der kan kode i faktisk browser uafhængig kode (det tvivler jeg ikke på) men så arbejder de bare ikke for dem der levere de løsninger som jeg har været tvunget til at benytte (som der ikke findes alternative løsninger til).
Jeg ved godt det i teorien er muligt (specielt hvis man har ubegrænsede budgetter, specielt til testing), men har bare set meget få tilfælde hvor det faktisk er blevet leveret. Der har altid været en dum detalje her eller der der har fået det løfte som internettet og browser baserede apps gav os for snart mange år siden til at gå op i røg.
Du får det til at lyde som om nemid har brug for adgang til hardwareacceleration, lyd, webcam, kompas, gyrometer og hvad ved jeg af sjove ting som html5 stiller til rådighed. I så fald, ja, så er det svært at lave uden at det går i stykker og virker begrænset.
Men ærlig talt, nemid skal poste en formular. Det er ikke raketvidenskab, og der er ingen teknologi involveret som ikke allerede var velafprøvet ved årtusindeskiftet.
Men hvis jeg tager fejl på det punkt må du da meget gerne overbevise mig om hvorfor der er brug for en sådan grad af kompleksitet at det ikke kan klares med en simpel kodebase der virker på alle browsere.
Hvilke dele havde du forestillet du skulle laves i javascript, og hvad forestiller du dig er komplekst at få til at virke crossbrowser i hver af de dele?