531 hjemmesider ramt af SSL-certifikat-tyveri

Hollandsk!? Det hedder Neder... *suk*... T.T

#1 Hvis du nu prøver at slå lidt op i en retskrivningsordbog, så tror jeg det vil glæde dig at se, at de to ord er synonymer. Så slipper du for at bekymre dig mere over dét :)

Men øøøh... træls nok med de SSL certifikater.
Nogen der ved hvordan de kan bruges? er det til phishing eller hvad?

#2: Ja med et SSL cerfifikat så er det garanteret at du er den du udgiver dig for at være.

Det kan Iran feks bruge til at udgive sig for at være CIA, således at iranske brugere som forsøger at tilgå CIA vil kunne blive dirrigeret hen på an iransk server som så kan lade som om de er CIA, uden at den som kobler op på serveren kan se at det ikke er tilfældet.


Jeg forstår ikke hvorfor browser producenterne skal gøre noget som helst for at undgå at disse certifikater misbruges. Certifikater har indbygget den sikkerhed at de kan revokes, hvorefter certifikatet er ugyldigt. Dette vil en bruger af en webbrowser naturligvis få at vide, når han forsøger at tilgå et site som bruger det ugyldiggjorte certifikat.

Det kan misbruges med "man-in-the-middle" angreb. Alle certs var blevet revoked på nær googles. Google og Mozilla har så valgt at alle cert fra samme udbyder vil blive afvist (som straf?).

"This is not a temporary suspension, it is a complete removal from our trusted root program." - Mozilla

"Effectively a death sentence for DigiNotar," - some guy

#3: Jeg forstår ikke at "virksomheder" som CIA, MI6 og Mossad, på noget seriøst plan benytter sig af SSL certifikater udstedt af en 3.-part, oven i købet beliggende i en fremmed stat...

>_<

Ok, så endnu en gang fik vi at se den nyværende sikkerhedsmodel ikke virker, og så vi bliver nød til at udvide X.509 standarten med mulighed for at være signeret af et flertal af CA

#5
CIA Mossad eller MI6 behøver ikke at bruge diginotar og det er heller ikke hvad der skete.

Browserne har et antal CAs (Certificate Authorities) som de stoler på udsteder ægte certifikater. Diginotar var en af disse.
De omtalte organisationer har nok brugt deres egen eller en for dem lokal og endnu mere trusted authority.

Problemet er at alle browserne stoler implicit på diginotar sammen med de "rigtige" CA's for CIA Mossad og MI6.

Det vil sige at de certifikater der er blevet udstedt fra diginotar stoles på lige så meget som de "rigtige" certifater.
Nu kan Iran så redirecte alle requests til eksempelvis CIA.com til deres egen server som præsenterer en side der ligner CIA's på en prik og præsenterer et gyldigt certifikat, det falske fra diginotar. Siden kan endda bare være et mirror af CIA's side.
Browseren ved kun at den stoler på diginotar og hvis de siger god for certifikatet er den god nok. Så den viser gladeligt at det er et gyldigt certifikat selvom det ikke er det rigtige gyldige certifikat.
Nu kan Irans styre sidde i midten mellem spion/oprører/nysgerrig teenager og USA og læse alt hvad der bliver sendt imellem de to.

TL;DR
USA Israel og Briterne har ikke brugt Diginotar, men hackerne har udnyttet at alle browserne stoler implicit på Diginotars certifikater.
Der var ikke tyveri i den gængse forstand, men forfalskning via en partner som alle har tillid til.

Cyber warfare. Det er jo det nye. Der kommer sikkert krig på WWW, med cyber nukes, spyware, cyber sabotage og alt sådan noget gejl.

Eller ja, det er nok ikke så nyt igen. Men flere lande har da lavet mere eller mindre officielle afdelinger, og Kina virker da til at være blevet næsten taget i at have beordret cyber angreb.

SuperZorro (4) skrev:

Google og Mozilla har så valgt at alle cert fra samme udbyder vil blive afvist

Jeg bemærkede godt for et par dage siden at der kom en opdatering til Firefox der fjernede certifikatet. Men jeg var ikke klar over om det var Mozilla der stod bag eller om det bare var Ubuntu der havde valgt at fjerne det.

Det er et drastisk træk, men det er et som jeg mener bør anvendes oftere end det historisk er blevet gjort. Det kan godt være at det kan blive dødsstødet for sådan en virksomhed. Men det er en trussel som de er nødt til at have hængende over hovedet for at tage sikkerheden alvorligt.

Nogle virksomheder ville i en situation som denne vælge at anlægge sag imod Google og Mozilla. Jeg ved ikke om DigiNotar vil finde på det, men hvis de gør, så håber jeg at DigiNotar taber sagen. For hvis det viser sig at en browser producent ikke må fjerne en CA som ikke tager vare på sikkerheden, så er det slut med sikkerhed på https sites.

HenrikH (5) skrev:

Jeg forstår ikke at "virksomheder" som CIA, MI6 og Mossad, på noget seriøst plan benytter sig af SSL certifikater udstedt af en 3.-part, oven i købet beliggende i en fremmed stat...

Det gør de nok heller ikke. Du kan f.eks. kigge på https://www.cia.gov/ og se nærmere på certifikatet. I firefox kan man trykke ctrl+i for at se oplysningerne. Certifikatet for https://www.cia.gov/ er udstedt af VeriSign.

Når nyheden skriver at nogen har stjålet certifikater, så er det lidt misvisende. Den korrekte hemmelige nøgle bliver aldrig leveret til certifikatudstederen, så den kan man ikke uden videre stjæle fra et større antal site. Selve certifikatet er der ikke nogen pointe i at stjæle. Du kan uden videre downloade det ægte certifikat fra websitet. Det sker automatisk hver eneste gang du åbner en https forbindelse. Men certifikatet er intet værd uden den hemmelige nøgle.

Det som der er sket er at der er blevet udstedt et antal falske certifikater. Altså at DigiNotar har skrevet under på at en forkert offentlig nøgle er knyttet til disse websites.

Der findes altså nu et ægte certifikat hvor VeriSign har skrevet under på en offentlig nøgle og et falsk certifikat hvor DigiNotar har skrevet under på en anden offentlig nøgle.

Så længe browserne havde begge CAs rodcertifikater ville man ikke få nogen advarsel hvis man bevægede sig ind på en server der anvendte det falske certifikat.

Hvis man besøger https://www.cia.gov/ med Firefox står der i titellinien "Central Inteligence Agency (US)". Hvis ellers Firefox har styr på sikkerheden kan der aldrig komme til at stå "(US)" hvis certifikatet er underskrevet af en CA i et andet land. Men hvor mange kigger efter det og hvor mange ved overhovedet hvilke sites det burde stå på og hvilke sites der fuldstændig legitimt anvender en CA i et andet land end sitet selv.

Her har vi fat i problemet med den nuværende model. Et website kan ikke beskytte sig imod misbrug ved at vælge en CA der har styr på sikkerheden. Så længe browserne har en så lang liste af CAer og der er en iblandt dem, der ikke har styr på sikkerheden, så kan man-in-the-middle-angreb udføres mod alle https sites ved hjælp af et forfalsket certifikat.

Det man beskytter sig imod ved at vælge en CA med styr på sikkerheden er blot besværet med at skulle købe et nyt certifikat med kort varsel, hvis den CA man bruger bliver droppet af browserne. Og jeg kan ikke huske hvornår det sidst er sket at browsere har valgt at droppe en CA. Når en CA bliver droppet vil det være til besvær for deres kunder, men det vil være et endnu større problem for denne CA.

Det bliver interessant at se om der er kunder hos DigiNotar som vil rejse erstatningskrav imod DigiNotar for de legitime certifikater det formodentlig har udstedt og som nu er ubrugelige.

Altså man kan da ikke stjæle noget som ikke findes? Certifikaterne er ikke blevet stjålet - der er tilgengæld blevet lavet falske certifikater (som til forveksling ser ægte ud).

Problemet med SSL systemet er at for man skal tro på at en forbindelse er sikker, skal man "tro" på over 500 firmaer i 52 lande (<-- så vidt jeg husker). Det vil sige, at hvis bare ét firma er blevet hacket, så er der ingen "sikre" forbindelser.
Det er lidt hurtigt forklaret, men det giver en et meget godt indblik i problemet.

En lidt lang, men også meget interessant video er denne: ("BlackHat USA 2011: SSL And The Future Of Authenticity ").

Nicolai (10) skrev:

BlackHat USA 2011: SSL And The Future Of Authenticity

Jeg har nu set videoen og den er bestemt interessant. Den video nævnte den episode som jeg også erindrede fra starten af året. Jeg havde egentlig troet at denne nye historie var en fortsættelse af episoden fra dengang. Men nu ser jeg så at dengang drejede det sig om Comodo, og nu drejer det sig om DigiNotar.

Der er selvfølgelig ingen der kender alle de forskellige CAs og ved hvordan de er forbundet til hinanden, så jeg ved da heller ikke om Comodo og DigiNotar har noget med hinanden at gøre.

Der er et spørgsmål som jeg meget gerne ville se et officielt svar på: Hvad er det ved hændelsen med DigiNotar som er så meget værre end Comodo at DigiNotar bliver fjernet fra browserne når Comodo ikke blev det?

Videoen giver en meget god beskrivelse af hvad der er galt med det nuværende system.

Han beskriver efterfølgende to løsninger, DNSSEC og hans eget Convergence.

Men hans efterfølgende analyse af sikkerheden af hhv. DNSSEC og Convergence lider af flere fejl som ganske fejlagtigt giver indtryk af at Convergence er mere sikker end DNSSEC. Han ignorerer fuldstændigt et enkelt relevant faktum som reelt betyder at det forholder sig omvendt.

Han viser to kort med markeringer af hhv. lande der har en CA der kan underskrive SSL certifikater og lande der har en TLD administrator der kan underskrive de tilsvarende DNSSEC signaturer. Og han nævner at det ikke blot er antallet af lande der vokser men også antallet af involverede organisationer, og at registrars ikke nødvendigvis er mere pålidelige end CAs. Han nævner også at flere TLDs opereres af de samme instanser som fungerer som CAs, det gælder f.eks. Verisign.

Så langt er det korrekt hvad han har sagt, men hvad der er værd at huske er at hvor en CA kan lave underskrifter på alle domæner kan en TLD operator kun gøre det på domæner under deres egen TLD. Så du er ikke nødt til at stole på alle de forskellige organisationer, kun de få som er involveret med den TLD du bruger.

Han nævner at man ikke nødvendigvis stoler på det land hvis TLD man vælger at registrere sit domæne. Men hvis man vælger et land man ikke stoler på, så har man da også truffet en dårlig beslutning. Hvorfor er det så populært blandt danske virksomheder at registrere domæner på små stillhavsøer?

Det er operatoren af TLD som i sidste ende definerer hvem et domæne tilhører. Når det nu er denne operator som definerer hvem domænet tilhører, hvor stort et problem er det så at denne operator også laver signaturer der fortæller hvem det tilhører?

At de kan trække et domæne tilbage og give det til en anden på et meget tyndt grundlag er selvfølgelig et problem, men det er ikke et problem som Convergence løser.

Convergence er sikkert meget godt så længe operatoren af TLD ikke er involveret i misbrug. Men hvis operatoren af TLD vælger at fuske med opslag, så er det trivielt at give alle notaries i Convergence systemet samme forkerte certifikat.

Hvad det betyder er at man er nødt til at stole på det hierarki af organisationer som definerer hvem et domæne tilhører. Med DNSSEC er det kun dem man skal stole på med CA systemet og Convergence er det også andre.

Noget som Convergence tilsyneladende ikke fokuserer på er at forhindre notaries i at skære hjørner. Man sender et certifikat til en notary og spørger om det er samme certifikat som han ser. Hvad forhindrer en notary i en gang imellem at svare ja uden at faktisk checke? Det ville da være en oplagt løsning hvis man kommer under lidt højere belastning end man kan håndtere. Det ville være lidt bedre at sende en hash værdi af certifikatet til denne notary og lade notary sende certifikatet tilbage. Så er der i hvert fald et hjørne mindre en notary kunne vælge at skære af.

Convergence fjerner tilsyneladende også muligheden for at verificiere CA certifikat og DNSSEC på klienten. Hvis du gerne vil have den slags checks uddelegerer man opgaven til en notary. De checks der kan klares på klienten er der ingen grund til at uddelegere, det er mere sikkert at lade klienten gøre det da klienten i sagens natur stoler mere på sig selv end på en notary.

kasperd>>>

Med de problemer der er med trust i SSL hierarkiet kan du så ikke se at det ikke var helt ugennemtænkt at danID kræver java?

Det er den eneste måde de kan sikre sig at den eneste der kan lytte med er dem der ejer deres eget rod CA, og ikke alle CAer i browseren.


Jeg tror også at det vil være endnu være med dnssec.

Jeg synes den bedste løsning er at domæne ejere kan købe certifikater fra så mange CAer som de vil.

Browseren kan så vægte dem efter hvor meget de stoler på caerne, og farve et barometer mellem grøn og rød efter hvor mange CAer de har identificeret sig overfor.

Det kan folk måske forholde sig til- den danske bank kan sagtens bruge 50.000 kr på at købe 100 certifkater, og for det får de barometeret fyldt helt op.

Men hvis du bare laver en lille webshop kan du bare købe et certifikat, og dit barometer er så kun på "sikker".

Hvis at én CA eller 5 bliver hacket vil det ikke ødelægge det HELE- og folk vil ligge mærke til hvis de bliver udsat for et MITM og ens bank pludseligt kun er meget lidt sikker istedet for super sikker(En hacker kan jo næppe hacke 100 ca´s )

Mamad (moveax1ret) (12) skrev:

Med de problemer der er med trust i SSL hierarkiet kan du så ikke se at det ikke var helt ugennemtænkt at danID kræver java?

Det betyder jo blot at nu kan du kompromittere sikkerheden ved enten at kompromittere sikkerheden i SSL eller ved at kompromittere sikkerheden i denne java applet.

De har ikke fjernet nogen angrebsflade, de har tilføjet en mere.

Problemerne med sikkerheden i SSL CA systemet kan brugere med lidt viden om systemet i stor udstrækning selv beskytte sig imod.

Før jeg logger på min netbank kigger jeg altid på certifikatkæden. Det har jeg gjort siden december 2008 hvor det blev demonstreret hvordan choosen prefix kollisioner for MD5 kunne udnyttes til at konstruere et forfalsket intermediate CA certifikat.

Jeg ville opdage hvis det angreb blev udnyttet. Og jeg ville opdage hvis der pludselig blev brugt et eller andet suspekt rodcertifikat.

Med nemid er man nu afhængig af flere forskellige certifikater og en applet. Der er altså tale om mange flere angrebspunkter og man kan kun checke nogen af dem ved at trykke ctrl+i og kigge på certifikatet.

Mamad (moveax1ret) (12) skrev:

Jeg synes den bedste løsning er at domæne ejere kan købe certifikater fra så mange CAer som de vil.

Det ville hjælpe imod angreb på CAerne. Men det ville ikke hjælpe imod angreb på DNS hierarkiet. Hvis du kan fuske tilstrækkeligt med DNS systemet, så kan du også overbevise mange CAer om at udstede certifikater til dig.

Men at lave muligheden for at certificere SSL forbindelsen med flere separate kæder er naturligvis et skridt i den rigtige retning.

Men der er andre tiltag som ville gavne mere.

Når et nyt certifikat udstedes til en server skal det ikke blot underskrives af en CA, men også af det tidligere certifikat der var tildelt serveren. Det vil sige to kæder. En der går fra serverens nuværende certifikat og tilbage til en CA og en anden der går fra serverens nuværende certifikat og tilbage til det første certifikat der nogensinde var udstedt til dette domæne.

Kæden der går tilbage til en CA skal browseren verificere præcist på samme måde som det altid er blevet gjort. Kæden der går tilbage til serverens første certifikat skal browseren verificere ved at cache det nyeste certifikat.

Derudover bør man udvide alle html tags der indeholder en URL til at have to ekstra tags der kan bruges til at verificere det target der peges på.

Det vil sige href, img, iframe, script, etc.

Det ene tag anvendes ved links til statiske filer. Tagget skal indeholde en kryptografisk hash af den fil der linkes til.

Det andet tag anvendes ved links til andre https sites. Tagget skal indeholde en kryptografisk hash af nøglen på den server linket peger på. Hvis det kombineres med kæden foreslået ovenfor skal browseren også acceptere hvis værdien i linket hvis den ikke matcher den nyeste nøgle men blot matcher en ældre version. På den måde sikres det at man ikke behøver ændre tagget alle links samtidigt med at man udskifter serverens certifikat. Det vil under alle omstændigheder være umuligt at ændre dem alle synkront, og nogle af de links der peger ind på et site vil uundgåeligt komme fra tredjeparter hvor man ikke kan sikre sig at de holdes opdateres. Så at tillade links at bruge vilkårligt gamle certifikater i deres hash værdi er afgørende for at systemet kan fungere i praksis.

De to tags er nødt til at være valgfrie af hensyn til bagudkompatibilitet. Sites der har brug for sikkerheden skal sætte minimum et af de to tags på alle links evt. begge to.

Hvis der er en hash værdi af en nøgle og den ikke findes i kæden for den server man kommer ind på skal browseren advare om at de to sites ikke stemmer overens.

Hvis der er en hash værdi af det statiske indhold linket peger på skal browseren give en advarsel hvis det faktisk indhold har en anden hash værdi.

Hvis et link fra en https URL til en http URL ikke har en hash værdi af det statiske indhold der peges på skal browseren give en advarsel.

Der findes så vidt jeg ved en artikel fra et par år tilbage som beskriver disse to tags i flere detaljer.

kasperd skrev:

Det betyder jo blot at nu kan du kompromittere sikkerheden ved enten at kompromittere sikkerheden i SSL eller ved at kompromittere sikkerheden i denne java applet.

Jeg forstår ikke hvad du mener? Kan du give et eksempel?

Det tænkte scenerie jeg forestiller mig er at uden java så ville en MITM med et certifikat fra en kinesisk CA til dendanskebank.dk kunne lytte med.

Men pga. Java spiller ind, så ville den MITM blive stoppet da java prøver eksplicit at validere dendanskebank.dk med rodcertifikatet fra danID, og der opdages at rodcertifikatet er fra kina.

kasperd skrev:

Det ville hjælpe imod angreb på CAerne. Men det ville ikke hjælpe imod angreb på DNS hierarkiet. Hvis du kan fuske tilstrækkeligt med DNS systemet, så kan du også overbevise mange CAer om at udstede certifikater til dig.

Browserne kunne vælge at vægte visse CA er mere end andre når barometeret påvirkes. Visse CAer kunne belønnes for at proceruren er at direktøren himself skal møde op med pas og en usb nøgle.

kasperd skrev:

Når et nyt certifikat udstedes til en server skal det ikke blot underskrives af en CA, men også af det tidligere certifikat der var tildelt serveren. Det vil sige to kæder. En der går fra serverens nuværende certifikat og tilbage til en CA og en anden der går fra serverens nuværende certifikat og tilbage til det første certifikat der nogensinde var udstedt til dette domæne.

Rigtig god ide. Den har jeg ikke hørt før.

kasperd skrev:

Før jeg logger på min netbank kigger jeg altid på certifikatkæden. Det har jeg gjort siden december 2008 hvor det blev demonstreret hvordan choosen prefix kollisioner for MD5 kunne udnyttes til at konstruere et forfalsket intermediate CA certifikat.

Det får du aldrigt hr og fru jensen til at forstå- de kan højest forstå et barometer. og sætningen "BAROMETERET SKAL VÆRE GRØNT"

Mamad (moveax1ret) (14) skrev:

Det tænkte scenerie jeg forestiller mig er at uden java så ville en MITM med et certifikat fra en kinesisk CA til dendanskebank.dk kunne lytte med.

Det kan de alligevel. Når de har udført angrebet med SSL forbindelsen kan de ikke blot lytte med, de kan også ændre trafikken. Det vil sige at de uden videre kan erstatte appletten med noget andet. Deres erstatning behøver ikke engang være skrevet i java, den kunne være lavet i javascript eller flash. Med kreativ brug af baggrundsbillede, html form og css kan det muligvis gøres helt uden at anvende nogen form for scriptsprog til browseren.

Denne lookalike behøver ikke lave nogen form for beregninger på klienten. Den sender bare brugernavn og de to passwords til den forfalskede server som så kan udføre de samme beregninger som den originale applet ville have udført.

At du bliver bedt om at godkende appletten har intet at gøre med beskyttelse af kommunikationen med serveren. Det drejer sig udelukkende om at beskytte din computer, da appletten får rettigheder til at modificere ting på din computer som et website ikke burde have adgang til. Havde appletten ikke bedt om de rettigheder ville den ikke blive valideret overhovedet.

Jeg har aldrig set denne type bekræftelse for flash eller javascript. Flash og javascript får ikke denne type rettigheder (der kunne godt eksistere en feature til det uden mit kendskab, i så fald er det ikke en jeg har set brugt).

Konklusionen er at hele sikkerheden i nemid afhænger af SSL. Enhver form for ekstra "sikkerhed" der måtte være indbygget i appletten er blot til pynt fordi SSL er det eneste de har der kan bruges til at sikre at de funktioner overhovedet er i brug.

Mamad (moveax1ret) (15) skrev:

Det får du aldrigt hr og fru jensen til at forstå

Nej. Men hvis nogle få sikkerhedsbevidste brugere er i stand til at holde øje med den slags angreb kommer det alligevel alle brugerne til gode.

Hvis nogen havde lavet systematiske angreb på SSL forbindelser til danske bankers netbank systemer ved hjælp af f.eks. den MD5 svaghed der blev fundet i 2007, så ville jeg med forholdsvis stor sandsynlighed have opdaget det. Jeg ville have kontaktet de relevante instanser med oplysningerne.

Det kræver kun et lille antal brugere der er så opmærksomme for at systematisk misbrug ville blive opdaget. Men med nemid er det ikke længere nok at kigge på et enkelt ssl certifikat, dermed er det i dag færre personer der er i stand til at opdage om der sker misbrug. Det er altså blevet nemmere at gennemføre systematisk misbrug uden at blive opdaget. Ikke dermed sagt at det er nemt at gøre, blot at det var sværere før nemid blev indført.

Hvad angår angrebet fra 2007, så blev angrebet publiceret i november 2007 (godt tre år efter den første kollision i MD5 var blevet fundet). Men det var først i januar 2009 at den sidste CA holdt op med at udstede certifikater med MD5 signaturer.

Det vil sige at der har været en periode på over et år hvor personer der ville misbruge SSL systemet har haft mulighed for at få udstedt forfalskede intermediate CA certifikater vha. denne MD5 svaghed. Og dem der måtte have gennemført sådan et angreb ville selv have mulighed for at vælge hvilken gyldighedsperiode deres certifikat skulle have. Den CA der lavede signaturen har ingen mulighed for at vide hvad det er de har skrevet under på.

Mig bekendt accepterer de fleste browsere stadigvæk MD5 baserede signaturer. Det blev set som tilstrækkelig beskyttelse at CAs holdt op med at udstede dem.

Det er teoretisk muligt at nogen har læst om angrebet i 2007 og gennemført det således at de nu ligger inde med et certifikat der er gyldigt i de næste 100 år og blot venter på det mest fordelagtige tidspunkt til at udnytte det. Hvor stor sandsynligheden for det er kan jeg ikke vurdere, men jeg vil sige at den er stor nok til at browsere burde holde op med at acceptere MD5 certifikater.