Onderzoeker laat Symantec certificaat intrekken met nepprivésleutel

Beveiligingsonderzoeker Hanno Böck heeft Symantec zover gekregen om een certificaat voor een zelfingericht testdomein in te trekken. Hij maakte daarvoor gebruik van een nepprivésleutel. Comodo kreeg hij niet zover om tot intrekking over te gaan.

Böck schrijft in een blogpost dat certificaatautoriteiten verplicht zijn om een certificaat in te trekken als de privésleutel ervan is uitgelekt. Om dit proces te testen, richtte hij twee testdomeinen in en vroeg hij daarvoor digitale certificaten aan bij Symantec en Comodo, omdat het grote partijen zijn die bovendien gratis testcertificaten aanbieden. Vervolgens maakte hij een nepprivésleutel aan voor beide domeinen, zette deze op Pastebin en stuurde hij deze naar beide bedrijven, waarop alleen Symantec het certificaat introk. Hij combineerde de ingestuurde sleutels met daadwerkelijk uitgelekte privésleutels die hij online had gevonden.

De onderzoeker heeft de tool waarmee hij de valse sleutel heeft aangemaakt online gezet. Hij schrijft dat hij ervoor heeft gekozen om hetzelfde publieke deel van de sleutel in zowel het certificaat als de privésleutel te gebruiken, wat bij een 'naïeve controle' niet zou opvallen. Een grondige controle zou verder gaan dan alleen het vergelijken van deze delen. Als dit niet gebeurt is dat problematisch; een aanvaller zou immers een privésleutel kunnen aanmaken met een publieke sleutel van het certificaat en het privégedeelte van een willekeurige andere sleutel. Daarmee zou hij in principe het certificaat van een willekeurige site laten intrekken, waardoor deze te maken zou krijgen met downtime, aldus Böck.

Symantec heeft met een eigen verklaring op de actie gereageerd. Het zegt dat het zijn processen voor het intrekken van sleutels zal herzien. Het bedrijf zegt dat het bij de controle van een sleutel bepaalde delen ervan niet onderzocht, wat ook al bleek uit de manier waarop Böck zijn nepsleutel had gegenereerd. Symantec ontving in maart al kritiek van Google op de manier waarop het certificaten verstrekt. Google kondigde aan het vertrouwen in oude Symantec-certificaten te reduceren. De zoekgigant startte een onderzoek nadat Symantec ten onrechte certificaten had uitgegeven.

Reacties (17)

[jerrycan92]

Maar trekt comodo het certificaat wel in als het wel om de juiste private key gaat?

Dit betekent dat Symantec een verkeerde check doet, maar voor hetzelfde geld doet Comodo helemaal niets ook al klopt de key wel.

[robvanwijk]

Ik had precies dezelfde vraag en heb het oorspronkelijke artikel even nagelezen:

Comodo didn’t fall for it. They answered me that there is something wrong with this key.

Ik er dus even vanuit dat ze wel revoken als het om de juiste private key gaat.

Misschien goed als toelichting: hij heeft ie eerst een stel uitgelekte echte sleutels opgespoord (het is enigszins verontrustend hoe makkelijk dat ging...) en heeft vervolgens de hele meute in één keer gerapporteerd. Dus zowel Symantec kreeg een melding "er zijn vier sleutels uitgelekt" (drie echte plus de neppe) en bij Comodo werden acht (zeven echte en een neppe) sleutel gemeld.

Hij zegt expliciet dat Symantec "alle" certificaten op "revoked" zette. Het staat er niet expliciet, maar het scenario "Comodo zegt dat één sleutel niet klopt en doet niks aan de zeven die wel kloppen" kan ik me echt niet voorstellen. En zelfs áls het zo zou zijn, dan zouden ze in het artikel keihard afgebrand zijn op zulk onmogelijk prutswerk. Dus de enige logische verklaring is dat ze inderdaad wel netjes revoken als de key klopt. Met andere woorden: goed bezig Comodo!

[Nss]

Terechte opmerking, en ik heb alleen dit artikel gelezen, maar als het doel is om vast te stellen dat certificate authorities onzorgvuldig omgaan met dit soort meldingen mag ik hopen dat Comodo adequaat gereageerd heeft. Zo niet dan mogen zij ook op het strafbankje inderdaad!!

[TD-er]

Inderdaad, dat is een vraag die (nu nog) moeilijk te beantwoorden is en waarschijnlijk zullen meer CA's nu hun procedures wel langslopen om beide situaties na te gaan.

[mutley69]

Symantec is na eerdere problemen met certificaten nu opgenomen met de absoluut hoogste notatie - "loop ervan weg" - die kunnen dus aan mij niks meer verkopen (ook niet onrechtstreeks). We zetten dit met opzet op de lijst opdat Symantec op zou pikken dat dit pijn gaat doen. Ik ben maar een enkeling - maar hopelijk ben ik niet de enige enkeling die dit durft neer te pennen en uit te voeren. Symantec is dus notatie 304 op m'n zwarte lijst.

[XFlame]

Dit dus. Mijn werkgever koopt momenteel haar SSL certificaten in bij Thawte, maar we gaan dit jaar kijken naar andere partijen. Dit, gecombineerd met de Google/Symantec vete, is voor ons teveel onzekerheid om nog langer zaken met Symantec te doen.

[servicedb]

Je moet het plaatje groter zien. Hij is in dit geval de eigenaar van de test domeinnamen, maar dat had hij niet hoeven te zijn. Stel het gaat om google.com en stel dit is een symantec certificaat. Als hij een nep prive sleutel had verstuurd dan was het certificaat voor google.com ongeldig.

Een prive sleutel moet geheim blijven en staat normaal veilig op de server. Lekt die uit dan kan de verbinding worden ontcijferd. Vandaar dat deze ingetrokken moet kunnen worden. Maar het blijkt nu dus dat de controle onvoldoende is of de prive sleutel de echte sleutel is. En dat is een groot risico want in theorie kan alle ssl certificaten van Symantec via deze methode worden ingetrokken en zal je bijvb fouten bij het internet bankieren krijgen.

Reactie op de edit: je snapt kennelijk niet waar de quote op slaat. De quote gaat over de fake private key. Dit heeft hij gedaan om een overeenkomst tussen de public key en private key te maken. De rest van de key moet ook matchen maar dat kan bij een fake key niet. Symantec heeft de rest echter niet getoetst. Ik hoop dat je nu snapt hoe het werkt en waarom de -1 terecht is.

[Reactie gewijzigd door servicedb op 23 juli 2024 22:14]

[maplebananas]

Dit deed hij natuurlijk om aan te kunnen tonen dat Symantec zijn proces voor het intrekken van certificaten niet deugd. Hij heeft voor een zelf opgezette omgeving gekozen om niemand lastig te vallen.

PS Ik vind dat Symantec eigenlijk geen bestaansrecht meer heeft, ze hebben in het verleden veel zaken niet goed op orde gehad en zo te zien is het nog steeds vol met gaten... en dat voor een 'certificaten authoriteit'

[Reactie gewijzigd door maplebananas op 23 juli 2024 22:14]

[WhiteDog]

Inderdaad, Symantec schrappen. Dan blijven er nog maar 29 bedrijven over die certificaten verstrekken en eigendom zijn van... Symantec

Het hele CA systeem mag voor mij op de schop en vervangen worden door een blockchain.

[itcrowd]

Comodo komt goed uit deze test, maar verdient ook geen oeuvreprijs:
https://en.wikipedia.org/wiki/Comodo_Group#Controversies

[smiba]

Nee? Lees het hele artikel van hem eens

Dit had hij ook net zo hard kunnen toepassen op andere symantec certificaten. Hij deed het op zijn eigen certificaat omdat het netjes is en een controleerbare omgeving is

[Armin]

Dit had hij ook net zo hard kunnen toepassen op andere symantec certificaten

Dat is natuurlijk niet noodzakelijk waar. Als Jantje verzoekt om Jantjes eigen certifciaat in te trekken, is er minder reden om fraude te vermoeden dan als Jantje probeert Pietjes certifciaat in te trekken.

[maplebananas]

inderdaad, net zo hard zou veranderd moeten worden in mogelijk

[Armin]

Bij nader onderzoek blijtk echter dat 'Jantje' hier echter zijn identiteit verhulde. Dus dan was het wel degelijk een 3rd party key.

Wat mij betreft is het grootste schandaal het volgende: "Symantec never told the domain owner that the certificate was revoked due to a key leaked on Pastebin."

Keerzijde is wel dat het hier om test-certifciaten gaat, en voor echte certificaten het process mogelijk anders was. Ook gebruikte hij RapidSSL, hetgeen een beetje het budget merk van Symantec is.

Nietemmin geen goede dag voor Symantec.

[Devaqto]

Dit is toch wel zorgelijk, het is toch vrij eenvoudig om een tooltje te maken waarmee je de publicKey en de privateKey test of ze bij elkaar horen (en daadwerkelijk werken)? Bij elke melding gooi je die privateKey in de tool om het te checken.

[Reactie gewijzigd door Devaqto op 23 juli 2024 22:14]

[Keneo]

Ik dacht dat het zelf zo werkte: je maakt een certificate revocation request aan, signed dat met de private sleutel (die je beweert te hebben) en stuurt dit door naar symantec die dan checked of het correct gesigned is het dan automatisch verwerkt.
Waarom dit door symantec op een andere manier gebeurd is mij een raadsel (stuurde ze door? het lijkt erop dat iemand bij symantec een mailtje gekregen heeft en dan met het blote oog keys vergeleek?)