Microsoft blokkeert valse Google-certificaten

Microsoft heeft 45 ssl-certificaten die ten onrechte zijn uitgegeven door een Indiase certificaat-autoriteit geblokkeerd. Gebruikers van Windows 8 zijn automatisch beschermd, maar gebruikers van oudere versies moeten een update installeren.

Eerder deze week bleek dat de certificaat-autoriteit, het Indiase National Informatics Centre, ten onrechte ssl-certificaten voor Google-domeinen had uitgegeven. Microsoft is het enige bedrijf dat certificaten van de bewuste organisatie accepteert; naast Internet Explorer gebruikt de Chrome-versie voor Windows de certificaat-database van Microsoft.

Microsoft heeft de bewuste certificaten nu geblokkeerd, maar tekent aan dat onduidelijk is of er meer valse certificaten zijn gegenereerd. In Windows 8 en Windows Server 2012 worden de certificaten automatisch geblokkeerd; gebruikers van oudere, ondersteunde Windows-versies moeten een Windows Update installeren om de certificaten ongeldig te laten maken.

Het is nog altijd onduidelijk hoe de valse certificaten zijn gegenereerd. Het gaat om certificaten voor domeinen als Google.com, Gmail.com en imap.gmail.com. Daarnaast zijn valse certificaten voor verschillende Yahoo-domeinen gegenereerd, waaronder de loginpagina van Yahoo en Yahoo Mail. Overigens lopen Chrome-gebruikers minder risico dan Internet Explorer-gebruikers: Google levert een lokale kopie van zijn servercertificaten mee met installatie, waardoor de valse certificaten niet door Chrome zullen worden geaccepteerd.

Reacties (33)

[Verwijderd]

Als je OS automatic updater heeft van revoked certificates (voor gebruikers win 8 zowiezo) en voor windows 7 gebruikers die kb/2677070 hebben binnengehaald. (http://support.microsoft.com/kb/2677070) krijgen de updates van certificaten automatisch en men kan checken of men deze heeft gehad door in de event viewer (windows log) bij Application naar event id 4112 te zoeken.
Dit moet als resultaat het volgende geven:

Source: CAPI2
Level: Information
Event ID: 4112
Description: Successful auto update of disallowed certificate list with effective date: Thursday, July 3, 2014 (or later).

Is dit niet het geval, installeer dan alsnog certificate updater voor Windows (7) https://support.microsoft.com/kb/2677070.

Voor mensen zonder automatic updater van revoked certificates dienen de volgende entries in Untrusted certificates vermeld te staan (hiervoor certmgr.msc uitvoeren):

NIC CCA India 2007 ‎48 22 82 4e ce 7e d1 45 0c 03 9a a0 77 dc 1f 8a e3 48 9b bf
NIC CA 2011 CCA India 2011 ‎c6 79 64 90 cd ee aa b3 1a ed 79 87 52 ec d0 03 e6 86 6c b2
NIC CA 2014 CCA India 2014 ‎d2 db f7 18 23 b2 b8 e7 8f 59 58 09 61 50 bf cb 97 cc 38 8a

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:10]

[vali]

Niet alleen Windows 8 en 2012 server waren vatbaar, alle versies van Windows zijn vatbaar, dus ook Windows Phone. Ik ben blij dat er automatisch beschermt bent tegen deze valse certificaten (al gebruik ik bijna geen google dienst meer).

Het is genoeg keren aangetoond wat de schade van man-in-the-middle attacks kunnen zijn en de personen achter deze aanval konden hun aanval ook uitbreiden naar banken.

An automatic updater of revoked certificates is included in supported editions of Windows 8, Windows 8.1, Windows RT, Windows RT 8.1, Windows Server 2012, and Windows Server 2012 R2, and for devices running Windows Phone 8 or Windows Phone 8.1. For these operating systems or devices, customers do not need to take any action because the CTL will be updated automatically.

For systems running Windows Vista, Windows 7, Windows Server 2008, or Windows Server 2008 R2 that are using the automatic updater of revoked certificates (see Microsoft Knowledge Base Article 2677070 for details), customers do not need to take any action because the CTL will be updated automatically.

[Reactie gewijzigd door vali op 22 juli 2024 23:10]

[Gomez12]

Niet alleen Windows 8 en 2012 server waren vatbaar, alle versies van Windows zijn vatbaar, dus ook Windows Phone. Ik ben blij dat er automatisch beschermt bent tegen deze valse certificaten (al gebruik ik bijna geen google dienst meer).

Ik ben nog blijer dat ik gewoon browse met browsers die deze CA simpelweg niet accepteren.

MS zijn actie is leuk, maar blijft achteruitwerken

[westlym]

oke, en what about voor Firefox? Er wordt niks hierin genoemd.

[latka]

Die vertrouwt deze CA sowieso niet.

[cyberstalker]

Is het niet een beter idee om certificaten van deze onbetrouwbare CA niet langer te accepteren in IE? Nu is het een beetje dweilen met de kraan open.

[Tozz]

Dan hou je uiteindelijk geen enkele CA meer over. Een CA kan, net als alles, een keer gehacked worden. Het certificaat systeem leunt nou eenmaal zwaar op CA's en alles wat een CA uitpoept wordt als veilig geacht. Dat dat in praktijk anders kan zijn is nu al meermalen aangetoond.

[dtech]

De CA's zijn letterlijk de basis/sleutel/grondslag van de betrouwbrouwbaarheid van beveiligd internetverkeer.
Als een CA dat vertouwen niet waar kan maken, verdienen ze die vertrouwenspositie niet en moeten ze dus uit de diverse root stores verwijderd worden.

Als jij een bankkluis huurt en er wordt in die kluis ingebroken dan haal jij daar toch ook je spullen weg?

[Armin]

Probleem is echter dat ook grote jongens als Comodo al eens valse certifciaten uitgegeven hebben. Stoer zeggen dat die dan ook maar gebanned moeten worden, gaat dan niet lukken

Dat is ook het grote probleem. Je kunt een CA als geheel niet meer 'niet vertrouwen' aangezien teveel legitieme sites dan ook stoppen met werken, en die sites niet even snel kunnen overschakelen.

Dat is ook de achillishiel van het hele certifciaat model.

[TheMak]

Als ik een CA zou zijn, dan zou ik niet de illusie hebben dat ik bestand ben tegen hacks. Ik zou serieus overwegen om de machine die de certificaten genereerd los te koppelen van elk netwerk. Als ik een certificaat wil genereren, dan zou ik de benodigde gegevens van een uitgeprint formulier inscannen. Het resulterende certificaat laten uitprinten, en op kantoor inscannen en doorsturen naar de klant. Uiteraard moet het personeel wel het papier bekijken.

[Tozz]

Prima. En nu ben je een CA die duizenden certificaten per dag uitgeeft. Hoe doe je dat nu? En hoe zorg je dat je medewerkers niet 'gaar' worden van het repeterende werk en perongeluk dat Gmail.com certificaatje toch dooor de activatie halen?

[TheMak]

Dat voorkom je niet, maar ik denk wel dat je als criminele organisatie wel een risico neemt door zo'n poging te wagen. Je moet een e-mail verzenden, je moet klaarstaan om een e-mail in ontvangst te nemen. Je moet geld overmaken. Als een medewerker een aanvraag voor een gmail certificaat ziet binnenkomen, dan kan je alles in werk stellen om de aanvrager op te sporen. Uiteindelijk moet de aanvrager toch af en toe zijn e-mail checken, en geld overmaken. Vanaf welk IP-adres is te traceren. De CA kan andere CA's waarschuwen. Je zou zelfs een besmet e-mail terug kunnen sturen. Op zijn minst onthul je een deel van je infrastructuur.

Als de CA-generator via het netwerk is te bereiken dan kan je risicoloos een poging wagen, door achter een willekeurige computer te gaan zitten die op internet is aangesloten is. Niet je eigen computer natuurlijk.

Overigens ga ik er wel vanuit dat een CA niet klakkeloos certificaten genereert, anders hebben CA's weinig zin. Maar eigenlijk realiseer ik me wel hoe de praktijk zou kunnen werken. Als ik als klant ziet dat een CA 50% goedkoper een certificaat kan leveren, terwijl dat voor het resultaat niet uitmaakt... Dan weet ik wel waar de klanten naar toegaan.

[jimbo123]

Inderdaad, zo is diginotar destijds ook failliet gegaan.
Nu hoeft het natuurlijk niet zo te zijn dat deze CA hetzelfde is overkomen als Diginotar destijds, maar het kan toch bijna niet anders als dat deze CA iets fout heeft gedaan.

[leuk_he]

Diginotar is failliet gegaan omdat ze er niet goed op reageerden. Maar tot zover hoor ik ook geen reactie van deze "NIC". Ik denk daardoor dat ze binnenkort hun afdeling certificaten wel kunnen opheffen gezien het totaal gebrek aan response.

[Dennism]

houd er wel rekening mee dat de problemen bij Diginotar hier in nederland onder het vergrootglas lagen omdat het van origine een nederlands bedrijf was en groot leverancier van o.a. zeer veel overheidscertificaten en certificaten in de gezondheidszorg.

Misschien heeft deze organisatie allang gereageerd in India of in die regio, maar valt dat hier gewoon niet zo op omdat het in dit geval geen landelijk nieuws is (ik heb er in ieder geval in het journaal of op de radio niets over gehoord, wat bij diginotar wel anders was).

[Soldaatje]

Je kan zelf de CA verwijderen.

[GekkePrutser]

Ja, dat dacht ik ook al (ik denk toch niet dat ik ooit een Indiase website zal willen bezoeken), maar ik zie die er helemaal niet in staan. Zowel de "National Informatics Centre" als de " Government of India Controller of Certifying Authorities (CCA)" staan helemaal niet onder mijn trusted root certificates.

Ik zie alleen de gebruikelijke spelers, Thawte, VeriSign enz... Misschien valt die Indiase CA weer onder een van de andere PKI providers?

[pouyann]

kunnen jullie iets meer over de update vertellen, link naar KB, release datum etc..

Update: linkt naar KB https://support.microsoft.com/kb/2677070

[Reactie gewijzigd door pouyann op 22 juli 2024 23:10]

[Vengeful]

staat al een link in het artikel zelf, daar staat precies wat je moet doen als je geen windows 8 hebt.

[Armin]

Overigens wie even wil testen:

https://nicca.nic.in

Let wel, dit is een volledig legitieme site, maar één die hetzelfde intermediate certificaat gebruikt.

Krijg je een rood schildje, ben je veilig. Gaat de browser lekker door, niet.

[Verwijderd]

Mijn ipad vertrouwt het ook niet.

[Armin]

Klopt, Apple heeft alle certificaten van deze CA uberhaupt nooit vertrouwt.

Nadeel is dat alle legitieme sites het dan ook niet doen.

Jouw iPad zal waarschijnlijk een untrusted error geven, waar Chrome en Internet Explorer op Windows een revoked bericht geven.

Nietemin, je bent wel beschermt tegen deze valse cerificaten natuurlijk.

[HKLM_]

Voor de informatie die Microsoft heeft vrij gegeven staat een linkje in het artikel.

Microsoft Security Advisory 2982792

https://technet.microsoft.com/en-us/library/security/2982792

[Reactie gewijzigd door HKLM_ op 22 juli 2024 23:10]

[Verwijderd]

Als de certificates geblokkeerd zijn dan hoef je toch geen update te installeren? Bij het checken van de CRL list zal de browser automatisch toch een security melding geven? of mis ik iets?

[Reactie gewijzigd door Verwijderd op 22 juli 2024 23:10]

[Grootstyr]

De certificaten zijn niet revoked door de CA die ze heeft uitgegeven, in dat geval zouden ze op de CRL van die CA staan. De certificaten worden door Microsoft client-side revoked, en daar is wel een update voor nodig.

[Armin]

De certificaten zijn niet revoked door de CA die ze heeft uitgegeven

Ik had begrepen van wel?

Ars Technica beweert bijvoorbeeld ook van wel!

[GekkePrutser]

Ja, maar niet alle browsers gaan er goed mee om als ze de CRL server niet kunnen bereiken, dan geven ze vaak toch het slot icoon weer (omdat je anders helemaal geen SSL kan browsen).

[Armin]

Bij het checken van de CRL list zal de browser automatisch toch een security melding geven? of mis ik iets?

Inderdaad, echter er zijn stukken software die die check standaard gewoon geheel niet uitvoeren (Google Chrome) of toch vast beginnen met een SSL connectie.

Plus dat sommige checks zoals OCSP geen volledige bescherming biedt tegen MITM aanvallen gedurende de eerste paar dagen, of op sommige intranet netwerken niet kunnen functioneren vanwege beperkte access naar buiten.

Meer details op:

http://blogs.msdn.com/b/i.../2011/04/07/10151106.aspx

[Duke-it]

Thanks to Google Chrome loop ik minder risico. Volgens mij is Google nog steeds de beste havik in het blokkeren/voorkomen van aanvallen via internet. Zij beseffen blijkbaar heel goed de kracht van het Web. Denk aan hun snelle inzet van 2-stap-verificatie, implementatie van zwaardere encryptie en dat soort grappen..
Voor de privacy grijp ik dan weer liever terug op Firefox, maar Internet Explorer heeft me sinds IE6 niet meer kunnen bekoren. Het schijnt goed te werken, maar ik moet steeds aan dat IE6 gedrocht denken

[leuk_he]

Google chrome ondekt alleen de valse google certificaten. Dus weer een google feestje. Wat er nog meer fout gaat bij anderen is onder de radar. (leermoment voor valse certificaten bakkers: alles clonen, maar niet google)

[Reactie gewijzigd door leuk_he op 22 juli 2024 23:10]

[Armin]

Sterker nog, Google is out-of-the-box de slechtse browser betreft SSL security.

Dat zeg ik niet als sneer, maar omdat certifciaat-controle standaard uit staat. Dus ook nadat de certifcaten al waren ontdekt en als 'revoked' gemarkeerd, accepteert Chrome gewoon die vervalste certifciaten.

Ik heb het uberhaupt altijd al onbegrijpelijk gevonden dat die optie standaard uit staat. Zet je die optie aan, zit het met de certifciaat controle wel goed, dus dat is gelijk een tip voor alle Chrome gebruikers.

Pas met deze Microsoft update zijn Google Chrome gebruilers veilig ongeacht of ze dat vinkje aangezet hebben.

De 'criminelen' (we weten nog net hoe het gekomen is) hebben dus de domme fout gemaakt ook Google certificaten te vervalsen waardoor de certifciate pinning van Chrome het dus opmerkte. Maar de ook vervalste Yahoo certificaten bleven bijvoorbeeld gewoon tot vandaag braaf geaccepteerd, lang terwijl Internet Explorer ze begon te weigeren (wat 1 dag na ontdekking was).

En nee, niet bedoeld als anti-Google sneer, gewoon onbegrip dat Google die optie standaard uit zet. Zet je die aan, is er namelijk niets meer mis en kun je gerust surfen.

[Wolfos]

Gezien Chrome voor Windows deze database gebruikt, gebruikt Opera deze dan ook? Dit is immers een op Chromium gebaseerde browser.

[Armin]

Hangt van je versie af. In de meeste gevallen zal het op Windows inderdaad de Windows Trust Store gebruiken:

http://www.opera.com/docs/ca/