Ssl-certificaten voor beveiligde dataverbindingen blijken in de praktijk vaak een risico. Met een buitgemaakt certificaat valt een onveilige verbinding voor vertrouwd door te laten gaan. Bovendien is intrekken een theoretische exercitie.
Microsoft is opnieuw slachtoffer van beveiligingsproblemen dankzij certificaatfraude. De schade valt ditmaal mee. Het frauduleus verkregen beveiligingscertificaat voor Microsofts Windows Live-site in Finland is vroegtijdig ontdekt. Bovendien is de hacker die het in handen kreeg, geen kwaadwillende die er actief misbruik van heeft gemaakt. Sterker nog: de Finse man had de door hem ontdekte zwakke plek allang netjes gemeld, zo melden Finse media.
Admin-alias
De kwetsbaarheid was niet eens een technische kwestie. De hacker heeft enige tijd terug ontdekt dat Microsofts nieuwe e-maildienst gebruikers toestaat om aliassen aan te maken, waarbij hij ‘gewoon voor de lol’ een privileged accountnaam opgaf. De Live.fi-site was qua gebruikersnamen en aliassen kennelijk niet goed geconfigureerd, want deze gewone gebruiker kreeg zo een account waar hogere rechten aan zijn gekoppeld voor de domeinnaam. Op basis daarvan kon hij een beveiligingscertificaat verkrijgen voor het hele domein.
Voor het aanvragen en toekennen van zo’n domeincertificaat hanteren certificaatverstrekkers zoals Comodo controlemechanismes. Daaronder ook de traditionele optie van validatie op basis van een mailadres. Dat moet dan een privileged account zijn, zoals admin@, administrator@, postmaster@, hostmaster@ of webmaster@. De Finse hacker wist zo hostmaster@live.fi als alias toe te voegen aan zijn eigenlijke mailadres bij de gratis maildienst van Microsoft. Terwijl hij deze kwetsbaarheid al in januari heeft gemeld, zowel bij Finse autoriteiten als bij Microsoft, is er vorige week pas actie ondernomen.
Algehele blokkade
De hacker kreeg plotseling te horen dat zijn Live.fi-adres, met de privileged alias, was geblokkeerd. Dit resulteerde in het uitschakelen van onder meer zijn Lumia-smartphone, zijn Xbox-account en natuurlijk zijn e-mail. Al die apparaten en diensten zijn gekoppeld aan de identiteit van het Windows Live-mailadres. Daarnaast hebben Comodo en Microsoft het onterecht toegewezen https-certificaat in de ban gedaan.
Microsoft stelt gerust dat het certificaat niet is te gebruiken om andere certificaten uit te geven. Ook is het niet te gebruiken, meldt het getroffen bedrijf in de security advisory hierover, om andere domeinen te imiteren of softwarecode te ondertekenen. De twee laatstgenoemde opties voor certificaatfraude geeft kwaadwillenden de mogelijkheid om een eigen domein van hun of eigen malware door te laten gaan voor een officieel en vertrouwd domein of stuk software. In dit geval zou dat dan van Microsoft lijken te zijn.
Malafide mogelijkheden
Met de ban en de geruststelling van Microsoft is de kous niet af. De Windows Live-aanbieder waarschuwt dat het frauduleuze ssl-certificaat valt te gebruiken om content te spoofen, phishing-aanvallen uit te voeren of man-in-the-middle (MitM)-aanvallen uit te voeren. Het intrekken van het bewuste certificaat moet deze malafide mogelijkheden de pas afsnijden, maar daar schiet het huidige certificaatsysteem tekort.
Een eenmaal verstrekt certificaat is namelijk in de praktijk niet gegarandeerd te annuleren. Een certificaatverstrekker zoals Comodo – of het lang geleden gehackte Nederlandse DigiNotar – kan weliswaar aangeven dat een certificaat niet langer geldig is. Dat gebeurt door het op te nemen in de zogeheten certificate revocation lists (CRL’s) die periodiek worden gepubliceerd en die via het online certificate status protocol (OCSP) live zijn op te vragen.
Daarnaast kan Microsoft een frauduleus certificaat opnemen in de zwarte lijst die het bijhoudt in Windows’ Certificate Trust List (CTL). Dat laatste is in dit Finse geval al automatisch gedaan voor huidige Windows-versies. Voor Windows 8, 8.1, RT, RT 8.1, Server 2012 en Server 2012 R2 is deze CTL-update default mogelijk. Voor Windows Vista, 7, Server 2008 en Server 2008 R2 moeten eerst wel andere updates (KB2677070 of KB2813430) zijn geïnstalleerd waarmee dan de auto-updater voor ingetrokken certificaten is geïnstalleerd.
Kip en ei
Praktijkprobleem is echter dat niet alle applicaties de in Windows ingebouwde CTL benutten. Zo houdt de open source-stichting Mozilla een eigen root-lijst (en zwarte lijst) van certificaten bij, voor zijn webbrowser Firefox. En dan is er nog de eerder genoemde blokkade door certificaatverstrekkers, die biedt ook geen soelaas. Want voor het uitlezen van CRL’s en de controle via OSCP-servers is namelijk een verbinding met die informatiebronnen nodig.
Zo’n verbinding is door kwaadwillenden te blokkeren. Daarbij vallen browsers terug op het toch toestaan van ssl-verbindingen omdat zo’n CRL- of OSCP-controle ook door gewone netwerkproblemen even onbereikbaar kan zijn. Een ongevalideerd certificaat blijft dan gewoon geldig. Browsermakers moeten dus eigen zwarte lijsten bijhouden en die als update zien te pushen naar hun geïnstalleerde producten. Ook dat gebeurt via verbindingen die zijn te blokkeren of manipuleren door kwaadwillenden die een buitgemaakt certificaat inzetten voor MitM-aanvallen. Aanvallers kunnen dus frauduleuze of vervalste certificaten nog gewoon blijven gebruiken, ook als die officieel zijn ingetrokken.
Zoveelste fout
De fout met het Finse certificaat voor Microsofts online-diensten is het zoveelste ssl/tls-beveiligingsincident op rij. De afgelopen tijd is het veelgebruikte security-protocol geplaagd door het ene na het andere grote probleem: van bugs Heartbleed en Poodle, via MitM-adware Superfish en PrivDog (van certificaatverstrekker Comodo) tot antieke kwetsbaarheid Freak.
Het is teleurstellend te zien hoe slecht Microsoft reageert op meldingen van problemen, na 30 jaar nog niet gelukt dat te verbeteren.
Pffff, Jan van Leeuwen en Microsoft. Je kunt absoluut niet onderbouwen dat Microsoft slecht reageert op meldingen. Het is in vergelijking tot andere partijen namelijk helemaal niet waar.
De laatste alinea (Zoveelste fout) is weliswaar feitelijk correct, maar wekt de indruk dat het de zoveelste aan Microsoft gerelateerde fout is. Zeker met zo’n opmerking van Jan van Leeuwen eronder, zullen niet-technisch georiënteerde mensen (beslissers?) de indruk kunnen krijgen dat de verder opgesomde problemen met ssl ook allemaal Microsoft betreffen.
Eigen certificaten genereren met true quantum randomness en gebruiken in combinatie met PGP is een stuk veiliger.
Zeker wanneer je onafhankelijke bron- en kanaalcodering gebruikt, zoals bijv. op wuala.com/FreemoveQuantumExchange/Aspects/Security
@Rob
dat kan ik onderbouwen. Op 8 functioneerde .net 3.5 niet na 5 maanden soebatten met MS eindelijk gepatched, zonder melding.
MS reageert laat of niet, dat kunnen heel veel mensen bevestigen, kijk eens op technet zou ik zeggen.
En nee, ik ben niet anti-ms maar bepaald problemen lossen ze gewoon niet op.
@Q
eigen certifikaten worden in de markt niet goed gaccepteerd helaas.
@ Jan van Leeuwen, 19-03-2015 15:36:eigen certifikaten worden in de markt niet goed gaccepteerd helaas.
In de gegeven verwijzing worden eigen certificaten gebruikt voor End-To-End security met PGP. Daarvoor is acceptatie in de markt niet noodzakelijk.
Tja, ik begrijp ook niet waarom we voor de beveiliging van onze systemen vertrouwen op certificaten uitgegeven door organisaties met louter commerciele motieven.
Een eigen certificaat heb je voledig in de hand.
Sommige organisaties dwingen je eenvoudig een certificaat van hen te instaleren.
Toegeveven ik heb zo ook zo nog wel eens mijn bedenkingen bij de manier waarop dat gebeurd, maar van bijvoorbeeld een bank zo ik zoiets nog wel accepteren.
@Pascal, 20-03-2015 08:28: Tja, ik begrijp ook niet waarom we voor de beveiliging van onze systemen vertrouwen op certificaten uitgegeven door organisaties met louter commerciele motieven.
Op datacenteroverlords.com/2012/03/01/creating-your-own-ssl-certificate-authority/ kun je een handleiding vinden hoe je een Private Certificate Authority kunt maken.
@Pascal, 20-03-2015 08:28: Toegeveven ik heb zo ook zo nog wel eens mijn bedenkingen bij de manier waarop dat gebeurd, maar van bijvoorbeeld een bank zo ik zoiets nog wel accepteren.
Je kunt deze certificaten ook alleen in een Private Network gebruiken.
Private PKI’s zijn niet de oplossing. Het gaat namelijk niet over met jezelf communiceren, maar met anderen communiceren, en dan moet je beide kunnen vertrouwen op een gezamelijke sleutel.
Beveiligingscertificzten (X.509 Certificates) zijn ook niet de zwakke plek. De zwakke plekken zijn de certificaatuitgevers, en dan met name diegene die uitsluitend commercieel bezig zijn. Er moet gewoon meer afspraken over het uitgeven van certificaten komen. Zodat ‘Domain Validated’ bijvoorbeeld niet zomaar aangevraagd kan worden voor een bepaald Domain (microsoft.com, live.fi etc). En er moet een klassificatie van leveranciers en certificaat-typen komen (meer verschillende kleuren oid) zodat er onderscheid gemaakt kan worden tussen certificaten van bijv. Comodo en Verisign.
Het principe van de Publieke/Private sleutel is zeker met ECC nog jaren in stand te houden. Zelfs PGP werkt met dit principe. Het staat of valt echter met de uitgever van het uiteindelijke certificaat, en de ’trustworthyness’ daarvan