image

SSL.com verstrekte door bug tls-certificaat clouddienst Alibaba aan onderzoeker

dinsdag 22 april 2025, 13:22 door Redactie, 5 reacties

Certificaatautoriteit SSL.com heeft door een bug een tls-certificaat voor de mail- en clouddienst van Alibaba verstrekt aan een onderzoeker. In totaal bleken elf certificaten ten onrechte zijn uitgegeven, die inmiddels allemaal zijn ingetrokken, zo laat de certificaatautoriteit in een incidentrapport weten. Tls-certificaten zorgen voor een versleutelde verbinding tussen website en bezoekers en maken het mogelijk om websites te identificeren.

Ten onrechte uitgegeven certificaten zijn bijvoorbeeld te gebruiken voor man-in-the-middle- en phishingaanvallen. Om te controleren of de partij die een tls-certificaat aanvraagt ook de eigenaar is van het domein waarvoor het certificaat wordt aangevraagd, beschikken certificaatautoriteiten over verschillende methodes. In de implementatie van één van deze methodes, Email Challenge Response, had SSL.com een fout gemaakt.

Bij deze optie moet een DNS TXT record voor het domein worden aangemaakt met daarin een specifiek e-mailadres. Vervolgens kan de aanvrager een certificaat voor dit domein aanvragen. SSL.com stuurt naar het opgegeven, aangemaakte e-mailadres een code en link. Vervolgens kan via de link een code worden opgegeven, waarmee de aanvrager aangeeft eigenaar van het domein te zijn.

SSL.com verstrekte echter ook het tls-certificaat als de aanvrager alleen e-mail voor het opgegeven domein kon ontvangen. De onderzoeker gebruikte een e-mailadres eindigend op @aliyun.com. Dit is de mail- en clouddienst van internetgigant Alibaba. Het is eenvoudig om bij deze dienst een e-mailadres aan te maken, net zoals een adres eindigend op @Yahoo.com of @Gmail.com.

Hoewel de onderzoeker geen controle over het domein aliyun.com heeft en ook niet het benodigde TXT record kon aanmaken, kon hij wel voor zijn eigen @aliyun.com e-mailadres mail ontvangen en dat adres gebruiken voor het aanvragen van een tls-certificaat voor aliyun.com en www.aliyun.com. Vervolgens ontving hij deze certificaten ook. Volgens de onderzoeker markeert SSL.com ten onrechte de hostnaam van het e-mailadres van de 'approver' als een geverifieerd domein. "Wat compleet fout is", aldus de onderzoeker.

SSL.com erkent de fout en heeft de betreffende methode om eigenaarschap van een domein te valideren uitgeschakeld. "We begrijpen de zorgen van de community", aldus de certificaatautoriteit. In totaal blijken er op deze manier elf certificaten ten onrechte zijn uitgegeven. Deze zijn volgens SSL.com inmiddels allemaal ingetrokken.

Reacties (5)
Vandaag, 13:44 door Anoniem
Single point of failure.
Vandaag, 14:56 door Anoniem
Ik ben wel benieuwd hoe dit heeft kunnen gebeuren. Natuurlijk slaagt niemand er ooit in om werkelijk elke bug te voorkomen, maar dit is wel een CA, dan moet de lat hoog liggen, en dat bij deze methode van certificaten verstrekken een controle hoort of het opgegeven e-mailadres ook werkelijk in zo'n DNS TXT-record staat, dat is geen exotisch uitzonderingsgeval maar de basis. Zoiets laat je niet alleen ad hoc door de ontwikkelaar testen als de code wordt gewijzigd, dat neem je op in automatisch uitgevoerde tests. Hebben ze die niet? Of zat daar zo'n grote fout in? Of werden bijvoorbeeld die tests door een andere fout of combinatie van fouten net bij de wijziging die deze fout introduceerde niet uitgevoerd en merkte niemand dat op?

Ze geven aan op of voor 2025-05-02 een volledig incidentrapport te publiceren.
Vandaag, 15:39 door Briolet
Hoewel de onderzoeker geen controle over het domein aliyun.com heeft en ook niet het benodigde TXT record kon aanmaken, kon hij wel voor zijn eigen @aliyun.com e-mailadres mail ontvangen

Dat is geen bug, maar een compleet fout ontwerp.

Bij deze methode behoort het e-mail adres in het DNS tekstbestand te staan. Als dat bestand er niet is, dan zou het per definitie onmogelijk moeten zijn een mail naar dat adres te sturen omdat het systeem dat adres niet kan weten. Schijnbaar wordt dat adres in de DNS alleen ter verificatie gebruikt maar gaat de mail naar het adres dat op een andere manier verstrekt is, ook al faalt de verificatie.
Vandaag, 18:11 door Anoniem
Betaalde certificatendiensten roepen altijd mega grote bedragen als verzekering, neem het normaal een beetje met een korreltje zout want bij een echte hack gaan ze failliet en is er dus niks. Vraag me wel af of dat er in dit geval wel een verzekerd bedrag wordt uitgekeerd aan de rechtmatige houder.
Vandaag, 20:37 door Anoniem
Door Briolet: Dat is geen bug, maar een compleet fout ontwerp.
Of een afwijking van het ontwerp die een enorme blunder is. De vraag is dan hoe die erdoor heeft kunnen komen.

Hoe dan ook, dit kan betekenen dat ze hun zaakjes schokkend slecht op orde hebben, het kan ook zo zijn dat ze waarborg op waarborg hebben in hoe ze dingen hebben opgezet, waarbij elke waarborg de kans op dit soort ellende sterk verkleint, maar dat net die uiterst onwaarschijnlijke situatie toch optrad dat al die waarborgen tegelijk faalden.

Ik weet niet of dat hier zo is, maar het kan, en het zou ook niet voor het eerst zijn dat zoiets gebeurt, ook serieus goed dichtgetimmerde systemen en procedures falen soms.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]

Je bent niet en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.