Acht gecompromitteerde ondertekeningssleutels bij de Indiase certificaatautoriteit eMudhra hebben een kloof blootgelegd tussen browserbescherming en de software achter websites en handelsinstrumenten. Per 21 oktober hadden grote browsermakers de getroffen certificaten geblokkeerd, maar sommige programma’s buiten browsers om konden vervalste inloggegevens nog steeds accepteren, omdat ze niet controleren of certificaten zijn ingetrokken.
Belangrijkste punten
- Onderzoekers achterhaalden acht zwakke privésleutels waarmee certificaten konden worden ondertekend die zich voordeden als die van vertrouwde websites.
- Browsermakers blokkeerden de getroffen certificaten, maar intrekking alleen beschermt geen software die de intrekking nooit controleert.
- Er waren geen cryptoaanvallen gemeld; de zorg strekt zich uit tot verouderde software op het bredere internet.
Inhoudsopgave
- Waar de eMudhra-sleutelbreuk kwetsbaarheden achterlaat
- Welke bescherming had gebruikers bereikt?
- Hoe zwakke sleutels de websiteverificatie ondermijnden
- Waarom handelssoftware afzonderlijke aandacht nodig heeft
- Conclusie
Waar de eMudhra-sleutelbreuk kwetsbaarheden achterlaat
Het belangrijke onderscheid is dat tussen het intrekken van een certificaat en ervoor zorgen dat software het niet langer vertrouwt. eMudhra trok de getroffen certificaten in, maar beveiligingsonderzoeker Scott Helme waarschuwde dat deze maatregel geen bescherming biedt voor programma’s die de intrekkingsstatus niet controleren.
Helme zei dat zijn tests uitwezen dat curl, Python, Node, Go en Java een vervalst certificaat voor de API van Stripe accepteerden. Dit was een demonstratie dat het certificaat werd geaccepteerd, geen bewijs dat Stripe was gehackt.
Met een frauduleus certificaat kan een onderschepper op het netwerk zich voordoen als een vertrouwde dienst en verkeer lezen of wijzigen. Browserblokkades pakken die mogelijkheid aan in browsers die de bescherming toepassen; ze bewijzen niet dat elke afzonderlijke toepassing of backend gelijkwaardige bescherming heeft gekregen.
| Onderdeel | Details |
|---|---|
| Mozilla en Chrome | Beide blokkeerden de getroffen certificaten op 17 oktober; Mozilla voerde de blokkade ongeveer drie uur na de melding door. |
| Apple | Volgde met zijn reactie op 19 oktober. |
| Microsoft | Volgde op 20 oktober. |
| Certificaatintrekking | eMudhra trok de getroffen certificaten in, maar software moet de intrekking controleren wil die maatregel helpen. |
| Beschikbare oplossingen voor software buiten browsers | Er waren oplossingen beschikbaar voor Go, het certifi-pakket van Python en webpki-roots van Rust. |
| Node.js | Op 21 oktober was een oplossing nog in afwachting. |
Welke bescherming had gebruikers bereikt?
De reactie kwam op gang nadat een onderzoeker genaamd Wayne de browsermakers op 17 oktober had gewaarschuwd. Hij demonstreerde dat hij alle acht gecompromitteerde sleutels beheerste door er zijn waarschuwing digitaal mee te ondertekenen. Dat er oplossingen beschikbaar waren, betekende niet dat elke installatie was bijgewerkt.
Hoe zwakke sleutels de websiteverificatie ondermijnden
Certificaatautoriteiten leveren de inloggegevens die browsers gebruiken om de identiteit van websites te verifiëren. Hun privésleutels voor ondertekening brengen daarom een andere verantwoordelijkheid met zich mee dan een gewoon websitewachtwoord: een gecompromitteerde ondertekeningssleutel kan worden gebruikt om certificaten voor andere sites te maken die authentiek lijken.
Helme zei dat hij alle acht sleutels in minder dan een seconde uit openbare certificaten had achterhaald. Onder de waarden van privésleutels die hij identificeerde, waren 4 en 56; dat illustreert hoe weinig weerstand de sleutels boden tegen het achterhalen ervan. Volgens hem waren ze sinds april 2025 blootgesteld.
Volgens Helmes lezing van een Mozilla-bugticket gaf eMudhra de schuld aan een fout in het script voor het instellen van sleutels.
Waarom handelssoftware afzonderlijke aandacht nodig heeft
Voor cryptogebruikers beperkt het relevante risico zich niet tot het openen van een exchange in een browser. Bots van exchanges, handelsscripts en backends van wallets kunnen afhankelijk zijn van de getroffen software buiten browsers. In theorie kan een vervalst API-certificaat van een exchange een aanvaller op hetzelfde netwerk in staat stellen het verkeer van een bot te onderscheppen of te wijzigen.
Er waren geen cryptoaanvallen gemeld. Mudit Gupta, chief technology officer van Polygon Labs, zei dat de kwetsbaarheid een algemeen probleem rond softwarebeveiliging was en niet specifiek betrekking had op crypto; vooral oudere of niet-gepatchte software baarde zorgen. Volgens hem liepen gebruikers die hun wallets, handelsinstrumenten en apparaten bijgewerkt hielden minder risico.
Conclusie
De reactie van browsers sloot een directe route voor certificaatimitatie af, maar loste het bredere softwareprobleem niet op. Het resterende risico hangt af van de vraag of afzonderlijke tools de gecompromitteerde inloggegevens weigeren—niet alleen van de vraag of de uitgever ze heeft ingetrokken.
Lees meer nieuws
Disclaimer
Dit artikel van FinanceVelix bevat algemene informatie en geen persoonlijk financieel, beleggings-, juridisch of fiscaal advies. Marktprijzen, rentetarieven en economische omstandigheden kunnen veranderen; beleggen brengt risico op verlies met zich mee. De feiten weerspiegelen het materiaal dat beschikbaar was op het moment van publicatie en kunnen veranderen. Controleer belangrijke informatie zelfstandig en raadpleeg indien nodig een gekwalificeerde deskundige. Een vermelding van een activum, bedrijf of dienst is geen aanbeveling.
