Microsoft waarschuwt voor vals ssl-certificaat voor Windows Live

Microsoft heeft gewaarschuwd voor een vals ssl-certificaat dat bruikbaar is voor het Finse domein voor Windows Live. Kwaadwillenden zouden het valse certificaat kunnen gebruiken om een betrouwbare man in the middle-aanval op te zetten.

Het foutieve certificaat is afgegeven voor het domein Live.fi, dat inderdaad in handen is van Microsoft voor de Windows Live-diensten van de softwaremaker. Volgens Microsoft kan het valse ssl-certificaat niet worden gebruikt voor het genereren van andere certificaten of het certificeren van code. Wel zou een aanvaller het certificaat kunnen inzetten om, als hij de verbinding van een gebruiker kan onderscheppen, een vervalste website te serveren en zo bijvoorbeeld logingegevens onderscheppen. Daarbij kan de gebruiker niet zien dat er wat aan de hand is, omdat het certificaat ogenschijnlijk klopt.

Microsoft heeft zijn eigen certificate revocation list bijgewerkt, waardoor gebruikers van Internet Explorer en Chrome op Windows niet langer getroffen zouden moeten zijn. Firefox beheert zijn eigen certificaten, evenals Chrome op andere besturingssystemen; het is onduidelijk of de het vervalste certificaat ook op die configuraties ontoegankelijk is gemaakt. Microsoft zegt dat het geen aanwijzingen heeft dat een aanval heeft plaatsgevonden door middel van het valse certificaat.

Reacties (21)

[Tukkertje-RaH]

Opmerkelijk dat het probleem dus kennelijk schuilt in het revoken van certificaten: het idee achter de certificaten is prima en zou theoretisch goed moeten werken, maar als het proces om bij fouten deze weer in te trekken - over meerdere leveranciers - niet goed werkt, dan is er veel ruimte voor verbetering.

Gezien de grote aantrekkingskracht van certificaten op hackers zou Microsoft met Mozilla, Google en Apple om de tafel moeten gaan zitten zodat bij problemen zo'n certificaat in de tijd van een paar uur op elk platform kan worden ingetrokken. Niet dat halfslachtige gedoe zoals nu: met browser X en OS Y ben je veilig, maar andere combinaties weer niet...

Edit: certificaten berusten op vertrouwen: jij vertrouwt je browser, die kan het certificaat van de bank controleren bij Verisign, en die heeft (ooit) de identiteit van die bank geconrtoleerd. Als die keten stuk is, hoeft dat geen probleem te zijn, mits het proces dan de andere kant op werkt: Verisign trekt dat certificaat in, jouw browser ziet dat en weigert vervolgens jou een HTTPS verbinding op te laten zetten (en jij trapt vervolgens niet in de MitM aanval)...

[Reactie gewijzigd door Tukkertje-RaH op 24 juli 2024 03:57]

[Bor]

Dat is vrijwel ondoenlijk, helemaal omdat certificaten voor zoveel meer worden gebruikt als alleen websites (denk bijvoorbeeld aan VPN of user access tot applicaties, smartcard toepassingen etc).

Iemand die een implementatie doet van een protocol gebaseerd op certificaten hoort ook te zorgen voor een goede verwerking van ingetrokken certificaten (dus het controleren van de Cerificate Revocation List (CRL) en hierop actie ondernemen). Helaas blijkt dat sommige systemen niet goed (of zelfs helemaal niet) controleren of een certificaat is ingetrokken maar simpelweg de handtekeningen en de geldigheidsduur inspecteren.

[Korben]

Op client-systemen (laptops, desktop-pc's, smartphones) is het onpraktisch en wellicht zelfs gevaarlijk om altijd op CRL's te controleren. Wat moet een browser doen wanneer de CRL-URI onbereikbaar is? De pagina maar weigeren? Dat is zeer onwenselijk voor eigenaren van websites, omdat dan de beschikbaarheid van hun website afhankelijk wordt (of nóg afhankelijker) van een derde partij.

Daarnaast worden CRL's vaak op onbeveiligde URL's gehost, wat het voor een MITM natuurlijk erg makkelijk maakt om te zorgen dat zijn certificaat niet op de CRL staat.

[Bor]

Je kunt er natuurlijk voor kiezen om een maximum leeftijd te stellen voor een CRL. Hoe oud mag een CRL zijn voordat je de client weer verplicht deze te controleren? Wat betreft te doen wanneer een CRL niet kan worden gecontroleerd; je zou de gebruiker een waarschuwing kunnen geven dat er niet kan worden gecontroleerd of een certificaat reeds is ingetrokken (en daarbij bijvoorbeeld de laatst beschikbare datum / tijd kunnen weergeven wanneer dat wel kon worden gechecked). Legio opties.

[Korben]

Wat betreft te doen wanneer een CRL niet kan worden gecontroleerd; je zou de gebruiker een waarschuwing kunnen geven dat er niet kan worden gecontroleerd of een certificaat reeds is ingetrokken (en daarbij bijvoorbeeld de laatst beschikbare datum / tijd kunnen weergeven wanneer dat wel kon worden gechecked). Legio opties.

Dat is leuk voor jou als tweaker, maar voor de gemiddelde persoon is dat abracadabra, en de gemiddelde persoon kan niet beslissen of het risico te groot is of niet. Het netto-resultaat is dat mensen dan maar niet naar site X gaan, of niet afrekenen. Websites zullen daar niet blij mee gaan zijn.

[Armin]

Je kunt er natuurlijk voor kiezen om een maximum leeftijd te stellen voor een CRL. Hoe oud mag een CRL zijn voordat je de client weer verplicht deze te controleren?

Precies, en laat de knappe koppen van bedrijven als Microsoft dit allemaal al uitgevogeld hebben. Zoals jij beschrijft zit namelijk al sinds jaren ingebakken in Windows.

Er is op basis van praktijk ervaring een bepaalde leeftijd ingesteld en ook maximaal aantal individuele certifciaten (OCSP) dat opgevraagd kan worden tot dat men de hele lijst weer gaat checkken (CRL). Dit is voor power-users ook via registry keys aan te passen, maar het default systeem werkt in de praktijk uitstekend.

Zo kan Windows altijd het certifciaat controletren, en tegelijkertijd de vertraging hiervan en robbuustheid tegen netwerk onderbrekingen beperkt houden.

En het mooie is dat als je als ontwikkelaar de Schannel TLS bibliotheek gebruikt (bijvoorbeeld omdat je de .Net API's gebruikt) je dit allemaal gratis en voor niets krijgt. Dus als app of desktop applicatie ontwikkelaar hoef je je hier geen zorgen om te maken, want het OS doet dit allemaal transparent achter de schermen voor je.

[Armin]

Op client-systemen (laptops, desktop-pc's, smartphones) is het onpraktisch en wellicht zelfs gevaarlijk om altijd op CRL's te controleren

Larie, Mirosoft, Opera en Firefox doet dat namelijk gewoon wel altijd.

Wat moet een browser doen wanneer de CRL-URI onbereikbaar is? De pagina maar weigeren?

Nee, maar gelukkig zijn dit soort sirtuaties:
1) extreem zeldzaam
2) een voorwaardelijke check is altijd beter dan geen check.

Daarnaast worden CRL's vaak op onbeveiligde URL's gehost, wat het voor een MITM natuurlijk erg makkelijk maakt om te zorgen dat zijn certificaat niet op de CRL staatt

MitM aanvallen zijn heel erg moeilijk uit te voeren in het algemeen en al helemaal als je én de site, én de CRL én de OCSP moet blokeren. En dan ook nog eens op het goede moment, want als ik toevallig de CRL al in mijn cache heb staan ga je alsnog nat. Dus het is verre van 'erg makkelijk'.

Tenslotte zijn MitM aanvallen slechts een van de vele mogelijkheden tot misbruik. Tegen een geavanceerde MitM aanvaller werkt een klassieke CRL niet perfect, maar tegen al die andere aanvallen wel zo goed als.

[Armin]

Opmerkelijk dat het probleem dus kennelijk schuilt in het revoken van certificaten

Nou meer in dat sommige browsers besloten hebben het niet te controleren.

Wat in dit artikel besproken wordt is de tweede linie van beveiliging. Firefox, Internet Explorer en Opera (maar niet Chrome!!!) controleren bij elke toegang tot een HTTPS site het certifciaat op intrekken. Omdat Comodo het certificaat zelf al direct ingetrokken heeft is kans op misbruik erg klein.

Aanvullend heeft Microsoft een methode om remote de centrale database met certificaten in Windows aan te passen. Dit was een nieuwe feature van Windows 8 en hoger, maar is twee jaar geleden ook gebackport tot en met Vista via een 'Windows Update' patch. Is je Windows dus up-to-date dan zal automatisch - bovenop dus de normale controle - ook nog eens dit certificaat expliciet als 'untrusted' aangemerkt worden.
Dat doet Microsoft met of certifcaten die gebruikt kunnen worden om zelf certicaten te maken, of die - zoals deze - een grote gevolgen kunnen hebben.

Google Chrome op Windows heeft geluk dat ze kunnen meeliften met dit systeem van Microsoft, want anders waren hun gebruikers onbeschermd geweest. Firefox heeft een eigen centrale database en deze zal op soortgelijke wijze updaten, maar is in de tussentijd ook beschermd door de gewone certifciaat controle.

Google heeft wel een soort blacklist in de browser zitten voor kritieke certifciaten, maar doet dus zelf niet aan certifciaat controle. Deze blacklist zal binnenkort ook geupdate worden.

Android stock browser en iOS Safari echter hebben pech. Beide doen niet aan certificaat controle. Op iOS begreep ik - maar kon dat niet verifieren - dat er een mechanisme van Apple is om certifciaten in te trekken, dus denk ik dat die ook veilig zijn. Op Mac OS heef men dat nameijk ook. Android is gewoon dikke pech en zal tot het einde der tijden kwetsbaar zijn.

Het probleem zit hem dus vooral bij Google Android en in mindere mate Google Chrome. De rest van de wereld heeft zijn zaakjes goed (Microsoft, Firefox en Opera) tot redelijk goed (Safari) voor elkaar.

EDIT: typos

[Reactie gewijzigd door Armin op 24 juli 2024 03:57]

[Verwijderd]

Edit: certificaten berusten op vertrouwen: jij vertrouwt je browser, die kan het certificaat van de bank controleren bij Verisign, en die heeft (ooit) de identiteit van die bank geconrtoleerd.

Het kan ook zijn, dat je op je pc een ander certificaat dan van Verisign installeert. Je virusscanner pikt dit niet altijd op, en dat als je gaat naar de website van je bank, dat andere certificaat de site goedkeurt, zonder dat je echt op je bank de site zit. Gelukkig laat in dat geval (als een andere certificaat dan versisign de site goedkeurt) laat mijn bank gelukkig de inlogknop niet zien.

Wellicht kan Windows Live hetzelfde doen met als hun website wordt 'goedgekeurd' door onbekende certificaten.

[mgizmo]

Verklaar je nader, want ik zie het verband niet.

[Verwijderd]

Als er blijkbaar mogelijkheden bestaan om officiele certificaten te vervalsen, hoe betrouwbaar is dan nog de certificaten techniek?
Moet er naar een nieuwe methode van authenticatie gezocht gaan worden? Of moet het beheer van certificaten volledig op de schop?

[D11]

Zie de opmerking van djiwie hierboven. (17-03 10:54u)

[PolarBear]

Het certificaat is niet vervalst maar onterecht uitgegeven.

[Verwijderd]

Zelf heb ik ook een keer een vals certificaat op de pc van een van mijn familieleden gehad. Dat bij onderzoek een beetje hetzelfde deed als fisheye op de lenovo's, reclame injecteren.

Ik heb daardoor het gevoel, dat die vorm van 'malware' via een certificaat, dat websites vals als echt erkent en ondertussen een aangepaste versie met reclame ook steeds vaker voorkomt.

Certificaten installeren gaat schijnbaar makkelijk, viruscanners zijn er niet zo scherp op, en het verwijderen (ook van dit certificaat) behelst nogal wat stappen

Mooie is wel, dat banken heel scherp zijn op de juiste certificaten. We kwamen er ook achter dat m'n familie lids' pc besmet was, doordat op de website van haar bank, de [log in] voor internetbankieren button niet weergeven werd.

[Bor]

Zelf heb ik ook een keer een vals certificaat op de pc van een van mijn familieleden gehad. Dat bij onderzoek een beetje hetzelfde deed als fisheye op de lenovo's, reclame injecteren.

Een certificaat zelf doet helemaal niets, het wordt gebruikt om de authenticiteit van een gebruiker of systeem verifieerbaar te maken en de publieke sleutel van een asymetrisch encryptie systeem te openbaren. Het is gewoon malware wat gebruikt maakt van een fout certificaat om jou of jouw systeem te doen denken dat je met een legitiem systeem of gebruiker plaatst terwijl dat in de praktijk niet zo is. Op deze manier kun je een man in the middle aanval (MiTM) uitvoeren om gegevens te onderscheppen en te wijzigen (zoals bijvoorbeeld het injecteren van reclame).

Dat er "nogal wat stappen" nodig zijn om een certificaat te verwijderen is erg overtrokken.
In Internet Explorer is het bijvoorbeeld niet meer dan

1 internet options
2 content
3 certificates
4 kies certificaat en kies "remove".

Een kind kan de was doen.

[Reactie gewijzigd door Bor op 24 juli 2024 03:57]

[Verwijderd]

Een kind kan de was doen.

Dat dacht ik ook,

Maar uiteindelijk was het verwijderen via de browser niet genoeg, en bleek het certificaat in windows zelf genesteld te zitten. Dan heb je dus het MMC nodig. En zijn de stappen wat complexer:

An alternate way to manage certificates is to use the MMC console:
Start -> Run
Type 'mmc'
Click on 'File -> Add/Remove Snap-in...'
Click 'Add...' from the 'Standalone' tab
In the list of Snap-ins, choose 'Certificate', click 'Add'.
Choose 'My User Account' in the pop-up and click 'Finish'. Close the previous two windows. The console should now show 'Certificates - Current User' under 'Console Root'.
Navigate to 'Console Root/Certificates../Personal/Certificates'. You should see the same certificates as were listed with the 'amqmcert -k MY -l' command.
Click on each certificate and delete using 'Delete' on the toolbar or in 'Action'.

If the certificates are deleted, then you can use the 'amqmcert' command to verify that these certificates are no longer in the 'MY' store.

[Verwijderd]

Wat hier mist is de verklaring hoe het certificaat vervalst kon worden. Als *zelfs* microsoft zich daar niet tegen kan verweren, hoe moeten anderen dat dan doen?

Door wie is het certificaat uitgegeven, hoe kan het vervalst worden?

[djiwie]

Uit het KB-artikel van Microsoft:

What caused the issue?
A certificate was improperly issued due to a misconfigured privileged email account on the live.fi domain. An email account was able to be registered for the live.fi domain using a privileged username, which was subsequently used to request an unauthorized certificate for that domain.

Wijselijk vertelt Microsoft niet welk account is gebruikt, maar blijkbaar heeft iemand een account als [e-mail], [e-mail], etc. weten te registreren en via een Comodo-provider een certificaat aangevraagd. Certificaat is uitgegeven door Comodo.

[D11]

Ik neem aan dat Comodo dit certificaat dan ook heeft ingetrokken via hun CRL ?!?

[Armin]

Ja, dus Opera, IE en Firefox waren dus per direct beschermd.

Enkel Google Chrome, stock Android en Safari niet aangezien deze de CRL (of OCSP) niet controleren. Google Chrome op Windows is echter kort daarna door Microsoft gered, dus die gebruikers zijn nu ook veilig.