Mozilla verhelpt man-in-the-middle-lek in Firefox

Mozilla brengt 20 september een update uit voor Firefox die een man-in-the-middle-lek dicht. Het lek treft gebruikers van add-ons en werd vrijdag gedicht bij de Tor-browser, die gebaseerd is op Firefox en gebruikmaakt van add-ons als Noscript.

Het lek in de Firefox- en Tor-browsers kwam vorige week aan het licht via een posting van beveiligingsonderzoeker Ryan Duff op de Daily Dave-Seclist. Het probleem zit bij de updatemethode voor add-ons. Mozilla gebruikt https-connecties voor het automatisch updaten van de add-ons via addons.mozilla.org en gebruikt additioneel certificaatpinning ter bescherming tegen misbruik.

Aanvallers zouden namelijk ongeautoriseerde digitale certificaten kunnen gebruiken om het te laten lijken alsof het updaten via Mozilla's servers verloopt en zo kwaadaardige updates naar de extensies te verspreiden. Certificaatpinning moet hiertegen beschermen maar er zat een fout in de manier waarop Mozilla Preloaded Public Key Pinning bijwerkte, waardoor certificaatpinning niet meer werkte voor Firefox 48 vanaf 10 september en voor ESR 45.3.0 vanaf 3 september.

Voor het omzeilen zou nog steeds een digitaal certificaat nodig zijn en het is Mozilla niet bekend of zulke certificaten in omloop zijn, maar volgens de organisatie is het desondanks een zorg voor met name Tor-gebruikers die beschermd willen worden tegen door staten gesponsorde aanvallen.

Het Tor Project zelf bracht vorige week vrijdag al een update uit naar versie 6.0.5 van de browser, dinsdag volgt Mozilla met een update van de stabiele versie van Firefox.

Reacties (17)

[Soldaatje]

Dus staten kunnen nu certificaten vervalsen? Dan kan https wel een update gebruiken.

[Blokker_1999]

In essentie kan iedereen certificatgen vervalsen. Alleen moet je nog altijd je root certificaat op de cliënt machine krijgen. Darom dat je meer en meer public key pinning ziet toegepast worden. Hierbij wordt een fingerprint opgeslagen zodat men kan nagaan of het juiste certificaat gebruikt is geweest in de SSL verbinding. Google past dit bijvoorbeeld ook al geruime tijd toe in de Chrome browser voor al zijn eigen domeinen waarbij enkele jaren terug ineens duidelijk werd dat Iran bijvoorbeeld met vervalste certificaten probeerde de communicatie van zijn inwoners met de Google servers te onderscheppen.

[The Zep Man]

In essentie kan iedereen certificatgen vervalsen. Alleen moet je nog altijd je root certificaat op de cliënt machine krijgen.

Of toegang hebben tot een bestaande vertrouwde root CA. DigiNotar was een voorbeeld waarbij een vertrouwde partij werd gebruikt om valse vertrouwde certificaten te maken.

HPKP (public key pinning) helpt hier inderdaad tegen, omdat een site daarmee bij het eerste bezoek kan aangeven welke certificaten (public keys) in de toekomst verwacht kunnen worden.

[MadEgg]

Dat is dan ook een enorm zwak punt van het certificaat-systeem: het verwacht van mij dat ik een derde partij vertrouw om te identiteit van een website te bevestigen. Mijn browser komt standaard met een enorme lijst aan root-CA's die vertrouwt worden. Waaronder bijvoorbeeld 'Staat der Nederlanden'. Nu zie ik het hier niet zo heel snel gebeuren, maar als je weinig vertrouwen hebt in je overheid om censuur toe te passen is dat natuurlijk niet echt wenselijk. Dat betekent dus dat de Staat der Nederlanden prima een geldig, valideerbaar certificaat voor wat voor domein dan ook kan uitgeven en vervolgens al het verkeer omleiden.

De staat der Nederlanden (AIVD?) zou daarmee dus ook prima ongericht kunnen tappen door ál het verkeer naar grote diensten te proxy'en met nagemaakte certificaten. Zonder certificate pinning merkt de gebruiker daar niets van, tenzij hij zelf handmatig de signatures gaat controleren.

DANE is een betere oplossing met een hiërarchische structuur, leunend op DNSSEC. Hierbij publiceer je zelf je fingerprint via DNS, en de authenticiteit van die fingerprint wordt bevestigd door DNSSEC, via je registrar en TLD. Dat geeft je registrar nog steeds de gelegenheid om de boel te vervalsen maar daarmee moeten er wel meerdere schakels onderschept worden en bovendien is de scope beperkt, terwijl met de huidige root CA's elke CA om het even welk domein kan vervalsen.

[Reactie gewijzigd door MadEgg op 26 juli 2024 06:29]

[P1nGu1n]

Ik weet dat de Nederlandse overheid zelf certificaten uitgeeft.
Root certificaat van https://www.rijksoverheid.nl/ is: Staat der Nederlanden Root CA - G2

Zo zullen er ongetwijfeld meer staten zijn.

[Reactie gewijzigd door P1nGu1n op 26 juli 2024 06:29]

[Rafe]

Die root zie je op internet vooral voor het PKIoverheid-programma. Het certificaat van rijksoverheid.nl is uiteindelijk uitgegeven door QuoVadis en niet door de overheid zelf.

[P1nGu1n]

Mijn punt was, de Nederlandse overheid (Staat der Nederlanden, ongetwijfeld andere staten ook) heeft een root-certificaat en zou in theorie een certificaat voor een andere domein uitgeven, wat browsers vervolgens als een valide certificaat zien.

De tree:
- Staat der Nederlanden Root CA - G2
- Staat der Nederlanden Organisatie CA - G2
- QuoVadis CSP - PKI Overheid CA - G2
- rijksoverheid.nl

[Rafe]

In theorie ja, maar het lijkt me zeer onwaarschijnlijk in de praktijk dat ze daarvoor de staats-CA willen burnen. Als je kijkt naar de onregelmatigheden omtrent WoSign kan er genoeg misgaan zonder daarmee een staat betrokken moet zijn.

[geez]

Ik zou er voor de veiligheid maar vanuit gaan dat er staten zijn die één of meer van de vele Certificate Authorities (CA's) gehackt/omgekocht/geïnfiltreerd hebben, dus ja, dat kan. Oplossingen hiervoor zijn dingen als public key pinning, maar dan zit je alsnog met het probleem dat bij de eerste verbinding je nog steeds niet zeker weet of je met de juiste server te maken hebt of dan al aangevallen wordt. Uiteindelijk heb je een manier nodig om de identiteit van de ander te controleren; dat kan via een vertrouwde derde partij (CA's), of via een side-channel (zoals ontmoetingen in persoon, etc).

Op mijn eigen domein gebruik ik hiervoor juist een self-signed certificate met controle van de SHA256 fingerprint.

Het EFF heeft hier ook een mooi project voor: het SSL observatory. Dit zit o.a. ingebouwd in hun HTTPSEverywhere plugin. Bijvoorbeeld: aangenomen dat niet elke bezoeker aan een bepaalde website tegelijk aangevallen wordt, als jij ineens een ander certificaat te zien krijgt dan andere bezoekers aan een site, is het redelijk om aan te nemen dat dit een man-in-the-middle poging is en kan de plugin hier een waarschuwing over geven.

[Reactie gewijzigd door geez op 26 juli 2024 06:29]

[svenslootweg]

Dat soort dingen gebeurt met enige regelmaat.

[mrdemc]

Zou dit dan misschien ook een van de manieren zijn die niet vrijgegeven werd door de VS aan firefox om tor-gebruikers te achterhalen? Ik had het wel netjes gevonden als het eerst was verholpen trouwens, i.p.v. Eerst publiekelijk gemaakt.

[edit aan hieronder]
Aah had wel 48 gezien, maar niet de datum :x

[Reactie gewijzigd door mrdemc op 26 juli 2024 06:29]

[Blokker_1999]

Gegeven de korte tijd waarin de bug bestaan heeft zou het mij verbazen. De pinning werkte niet meer sinds begin deze maand.

[Maurits van Baerle]

Dit zal een extra reden zijn geweest waarom de release van Firefox 49 ineens een week uitgesteld werd. Ik verwacht dat ze deze fix uitbrengen als onderdeel van 49 en iedereen dan aanraden om daar direct naar te updaten (hoewel dat bij vrijwel iedereen sowieso automatisch zal gebeuren).

[Reactie gewijzigd door Maurits van Baerle op 26 juli 2024 06:29]

[hansg]

Ik draai nog steeds FF47 - ik weet namelijk niet welke van mijn extensions gaan sneuvelen als ik update, en sommige wil ik niet kwijtraken. Is er een methode om daar vantevoren achter te komen? Of moet ik maar gewoon upgraden en verloren extensions voor lief nemen?

Kan ik ervan uitgaan dat als een extension bij Mozilla op de site staat hij automatisch ook gesigned is?

[Mitsuko]

In Firefox 47 stond xpinstall.signatures.required in about:config ook standaard al aan. Enige verschil in 48 is dat die optie verwijderd is, waardoor het niet meer uit te zetten is. Als je die optie nooit hebt aangepast dan zal je dus geen verschil merken - als je xpinstall.signatures.required uit hebt staan, dan zou je het even aan kunnen zetten om te kijken wat er geblokkeerd wordt.

[hansg]

Thanks, dat was inderdaad een zeer nuttige tip! Ik bleek geen problemen te hebben en heb hem inmiddels geupdate naar de meest recente.

Ik had ooit die key wel eens veranderd, maar was dat inmiddels allang weer vergeten... De extensie waarvoor het nodig was (geen idee meer welke) is ofwel inmiddels verwijderd of geupdate, dus alles werkt nu weer correct.

[Reactie gewijzigd door hansg op 26 juli 2024 06:29]

[kdekker]

Ik vraag me af of in het illegale wereldje officiële certificaten gebruikt worden. Zullen ze daar niet eerder private/self-signed public/private certificaten gebruiken? En helpt daar de firefox fix voor?

Er zijn ook providers die aan https filtering doen. Dat werkt ook d.m.v. het toevoegen van een certificaat. En is volgens mij ook in wezen een man-in-the-middle.