Nederlands bedrijf ontdekt kwetsbaarheid voor uitgeven valse ssl-certificaten

Een kwetsbaarheid in de StartEncrypt-tool van de certificaatautoriteit StartSSL maakte het aanmaken van valse ssl-certificaten mogelijk. Dat ontdekte het Nederlandse beveiligingsbedrijf Computest. Dit kon voor diverse grote domeinen, zoals die van Google en Dropbox.

StartEncrypt is een tool voor de StartSSL-dienst van het bedrijf StartCom, die het automatisch aanmaken en installeren van ssl-certificaten op servers mogelijk maakt. De dienst werd in juni aangekondigd en wordt door sommigen gezien als een alternatief voor het populaire Let's Encrypt.

De tool detecteert voor welke domeinen er certificaten kunnen worden aangevraagd, maar bevatte een bug waardoor een certificaat ook zonder de vereiste autorisatie afgegeven kon worden. Dit werkte niet voor alle domeinen, maar wel voor een groot aantal, zoals google.com, dropbox.com, login.live.com en linkedin.com. Dat ontdekte Computest.

De kwetsbaarheid opent de weg naar man-in-the-middle-aanvallen en ondermijnt volgens Computest het vertrouwen in certificate authority's en de certificaten die ze uitgeven. "Als de certificaatautoriteiten niet op de juiste manier omgaan met hun verantwoordelijkheid op dit gebied, kan op den duur het ssl-certificaat, het 'slotje' naast de url in de adresbalk, niet meer worden gezien als daadwerkelijk bewijs van veiligheid en vertrouwen."

De tool van StartSSL draait op Windows- of Linux-servers en detecteert de configuratie van de webserver. Vervolgens vraagt StartEncrypt certificaten aan voor domeinen die in de configuratie gevonden worden. De StartCom-api doet daarna een http-request bij de website van het domein van de aanvraag, om bewijs te krijgen dat de aanvrager toegang tot deze site heeft. Krijgt de api dit bewijs, dan verstrekt deze het certificaat en installeert die dit in de config.

Computest vond meerdere kwetsbaarheden bij die procedure en de voornaamste is wat het bedrijf de 'path-bug' noemt. De StartEncrypt-api vraagt een handtekening als bewijs dat de gebruiker geautoriseerd is voor een certificaat. Dit gebeurt standaard via de bestemming '/signfile' en de client kiest dat pad via een http-post-request naar de api. "Je kunt ook voor een mailtje met een autorisatie als bewijs kiezen, maar bij StartEncrypt is voor autorisatie via de website gekozen", zegt Christiaan Ottow, de cto Security van Computest, tegen Tweakers. "De aanvrager mag zelf de plek van het autorisatiebestand bepalen. Via die url gaat de server het ophalen."

POST / HTTP/1.1
Host: cg.startpki.com
...

{

"customerID": "general",
"encrypt": "",
"nonce": "",
"publicKey": "-----BEGIN PUBLIC KEY-----\n\n-----END PUBLIC KEY-----\n",
"sessionID": "",
"type": "authorizationRequest",
"verifyRes": [
"http://example.com:80/signfile"
]
}

"Een kwaadaardige client kan een pad naar elk bestand op de server gebruiken waar een certificaat voor is aangevraagd", aldus Computest. Het bedrijf wijst er op dat kwaadwillenden zo certificaten kunnen verkrijgen voor sites die uploads mogelijk maken en deze 'raw' kunnen terugserveren, zoals dropbox.com en github.com.

Erger is dat de api ook redirects volgt, totdat het zijn bewijs heeft verkregen, zelfs als het om url's bij andere domeinen gaat. Hiervoor moet een site 'open redirects' ondersteunen. Sommige beveiligingsexperts beschouwen open redirects als een risico, maar veel sites bieden dit en OAuth 2.0 stelt het nagenoeg verplicht. Veel login-sites hebben bijvoorbeeld 'open redirect'-functionaliteit, om gebruikers na het uitloggen naar een andere site te leiden. "Misbruik van de kwetsbaarheid zou werken in combinatie met heel veel domeinen en in ieder geval om sites die OAuth 2.0 bieden", zegt Ottow.

Computest vond nog meer onvolkomenheden met de tool. De client valideert bijvoorbeeld niet het certificaat bij de verbinding met de api. "Dat is behoorlijk ironisch voor een ssl-tool", meent Computest. Daarnaast bleek de private 'tokenpri'-sleutel die de tool opslaat in te zien en aan te passen.

De kwetsbaarheid werd op 23 juni ontdekt door securityspecialist Thijs Alkemade van Computest en direct gemeld. StartCom haalde daarop het systeem offline verhielp de kwetsbaarheid op 29 juni. Het bedrijf heeft een nieuwe versie van StartEncrypt uitgebracht. "Aan de ene kant was misbruik kinderlijk eenvoudig, aan de andere kant is StartCom niet de bekendste Certificate Authority", stelt Ottow. Vanwege de overeenkomsten met Let's Encrypt heeft StartEncrypt volgens hem wel enige bekendheid gekregen. Ottow stelt dat misbruik van certificaten grote belangstelling heeft van zowel staatshackers als criminelen: "Dat heeft onder andere de Diginotar-affaire laten zien."

Reacties (43)

Dit soort slordigheden zijn de reden dat ik die gratis authorities niet opneem in mijn lijst van authorities. Firefox geeft me netjes een warning dat het certificaat ongeldig is, net zoals je zou krijgen bij een self-signed certificaat. Het enige nadeel is dat ik dit bij Tweakers dus ook krijg. Ik vind echter (en daar zullen velen het niet mee eens zijn, maar misschien snappen ze het wel) dat als je niet betaald voor een certificaat, het gelijkstaat aan simpelweg zeggen "ik ben te vertrouwen". Deze woorden zijn niets waard. Bij een betaald certificaat weet ik tenminste dat iemand geld heeft moeten uitgeven om het certificaat te krijgen, dan stijgt het vertrouwen bij mij ook al direct.

Wij hebben meer dan 250 EV-SSL certificaten en wij betalen per certificaat slechts 69 dollar. Veel grotere domain registries betalen ook maar een paar cent per domein, terwijl als jij slechts een enkel domein wilt, je vaak zo'n 15 dollar kwijt bent.

Echter een standaard ssl certificaat van Verisign is niet beter of slechter dan dat van Lets' Encrypt. Verisign als beheerder van onder andere .com, .net, .org heeft een aantal eisen gesteld waaraan de aanvrager van een certificaat moet voldoen. Die eisen zijn in de loop der jaren steeds soepeler geworden.

De meeste gebruiken een ssl certificaat ook slechts om de beveiligde verbinding en niet om de identiteit van de server vast te stellen wat ooit het beoogde doel van het certificaat was.

Die vaststelling van de identiteit is nu eigenlijk verplaatst naar de EV-SSL certificaten. Wij schrijven backend systemen voor grotere e-commerce bedrijven en medewerkers willen zeker weten dat zij met de officiele server zijn verbonden. Daarom vragen wij standaard voor deze bedrijven een EV-SSL certificaat aan voor hun backend omgeving. Ironisch genoeg draait hun reguliere website vaak op een 'gewoon' SSL certificaat, maar dat valt buiten onze scope.

Daarnaast is het verkrijgen van een 'vals' certificaat natuurlijk slechts 1 stap uit de keten, want je moet nog steeds bezoekers naar jouw phishing website zien te krijgen. Daarvoor zul je toch op een of andere manier het DNS systeem moeten veranderen. Dit kan met malware op de server welke een entry in het hosts bestand aanmaakt of welke andere DNS servers instelt voor je machine..

Maar als iemand als toegang heeft tot jouw systeem, maakt het eigenlijk niet meer zoveel uit of je de CA-autoriteit nou wel of niet vertrouwd. De malware kan namelijk ook zeer eenvoudig een malafide CA aan de trusted lijst toevoegen. Zowel Chrome als MSIE (Edge) maken gebruik van de Windows certificate store en is op dat punt best vatbaar voor manipulatie.

Echter de CA lijst voor EV-SSL authorities zit hardcoded in de browser en is dus vrij lastig te wijzigigen.

Daarnaast betreft het hier startssl welke geen goede controle uitvoerde. Een tool welke de webserver configuratie gebruikt om te bepalen welke certificaten beheerd moeten worden, mag natuurlijk nooit diezelfde website ter controle gebruiken. Men zal dan bijvoorbeeld gebruik moeten maken van DNS-verificatie waarbij je vaak een bepaald txt record moet aanmaken..

Echter zijn er wel meer (betaalde) CA's welke hun validatie process niet helemaal op orde hebben. Het blokkeren van de LE CA zal in dat opzicht dat ook weinig tot geen toegevoegde waarde hebben..

Ik vind meer dan $17k per jaar voor wat certificaten nog altijd veel geld. Het is niet alsof de vetting procedure voor elk individueel certificaat word doorlopen en het genereren van een cert op zich is nu ook de kost weer niet.

HTTPS heeft voor zover mij bekend ook nooit als doel gehad om de identiteit van de server na te gaan maar net als doel om de verbinding te beveiligen. Waarom zouden we in een webbrowser dit ineens als authenticatie gaan gebruiken wanneer er zovele andere protocollen zijn (denk aan mail) waar vaak meer gevoelige informatie over gaat zonder dat er ooit iemand een audit van certificaten doet?

Zelfs een EV certificaar kan je niet altijd vertrouwen. Denken we maar aan de Digitnotar hack. Van zodra kwaadwillenden de juiste certificaten in handen hebben om hun eigen EV certificaten te maken valt heel het systeem in het water.

Zelf ben ik voorstander om af te stappen van CAs en over te stappen op DANE/TLSA. Het geeft meer controle aan de eigenaar van de website op zich doordat alle benodigde informatie in DNS komt te staan en je DNS dan weer beveiligd is met DNSSEC. Je weet dan dus al zeker dat je met de eigenaar van het domein aan het communiceren bent.

Blokker je hebt helemaal gelijk, ik kan ook niet wachten dat we over stappen naar Dane.

Voor wie niet weet wat Dane is, hier heb je een interessant artikel:
http://www.internetsociet...n-next-level-using-dnssec

Als je inderdaad zegt 17.000 voor alleen wat certificaatjes lijkt dat inderdaad erg veel ja. Onze prijzen beginnen met 850 euro (ex BTW) per maand. En dan is ineens 69 dollar op een omzet van ruim 10.000 dollar niet meer zoveel. Je moet het natuurlijk altijd in perspectief zien..

DANE/TLSA kan inderdaad een heleboel nadelen (zwakheden van de X.509 certificaten wegnemen), alleen zou je per definitie nooit die gegevens kunnen vertrouwen. want ik kan een 1ngbank.nl domein opzetten en alle daarvoor relevante records in de DNS opnemen. Dat is juist waar de CA's om de hoek komen kijken. Want zij hebben officieel de taak om te controleren of degene welke een certificaat aanvraagt ook daartoe geautoriseerd is. Het idee achter een CA is dat deze onafhankelijk is (zoals een notaris).

Alleen is het runnen van een openbare grote (EV-SSL) CA zeker geen gemakkelijke taak. Want je hebt al snel een hoop mensen nodig en het zijn vaak die mensen die soms een controle niet helemaal goed uitvoeren of in het geval van diginotar dat een sub-systeem niet correct was beveiligd waardoor men ongecontroleerd certificaten kon uitgeven.

Maar de hack bij diginotar toonde ook aan hoe snel men kan ingrijpen als een CA niet meer betrouwbaar is. Niet veel later ging het bedrijf ook ten onder. Maar beveiliging is altijd zo sterk als de zwakste schakel..

Een X.509 is natuurlijk ook niet heel erg veel meer dan een fingerprint en een PKI key pair. Als je voor de eerste keer verbinding maakt met een remorte desktop via RDP of SSH, krijg je altijd de fingerpint van die machine te zien. Daarmee stel je de identiteit van de server vast. Daarom kun je in DNS ook al enige tijd SSHFP records opnemen en de linux openssh client kan deze ook controleren.. Op die manier heb je een externe bron welke de fingerprint met de hostname matched..

Maar dan doe je wel weer de aanname dat je de DNS records kunt vertrouwen en die aanname is eigenlijk niet heel erg veel anders dan dat je een CA vertrouwd..

Let's encrypt heeft ondermeer een validatie door middel van DNS (nodig voor onderandere non-public servers, e.g. intranet). Het script voegt een DNS record toe en Let's encrypt vraagt dit dan op.

Absoluut niet!

Voor grote e-commerce websites is hun administratie backend systeem vele malen waardevoller dan dat jij (als klant) weet dat je met de correcte server bent verbonden.

Via backend systemen heb je toegang tot zeer gevoelige informatie. Medewerkers wordt aangeleerd dat zij ALTIJD controleren dat zij in de adresbalk een groene balk zien met daarin de officiele naam van het bedrijf (vaak de moeder maatschappij) bij het doen van een inlog poging. Dit om te voorkomen dat credentials van medewerkers in verkeerde handen komen..

Een standaard SSL certificaat is alleen geschikt als je een beveiligde verbinding wilt opzetten. Niet als je met 100% zeker de IDENTITEIT van de server moet kunnen controleren..

Een echte backend kun jij via een browser niet bereiken, ik denk dat je kennis daar al enigszins schort.

Als jullie systemen ontwikkelen welke de volledige bedrijfsinformatie open legt bij een lek omdat deze publiekelijk benaderbaar is, zou ik toch even na gaan denken over je design of even iemand binnen je "organisatie" aan zijn jasje trekken.

Een EV voegt echt weinig toe, en ja ik heb ze en puurt alleen omdat de klant het wil "zien".

EV is een Wassen Neus.

Daarnaast is het verkrijgen van een 'vals' certificaat natuurlijk slechts 1 stap uit de keten, want je moet nog steeds bezoekers naar jouw phishing website zien te krijgen. Daarvoor zul je toch op een of andere manier het DNS systeem moeten veranderen.

Dat is een mogelijkheid. Een andere optie is om een publieke wifi te hebben (gebruik als naam die van "wifi delen" van Ziggo of KPN en een heleboel apparaten denken je te kennen en te kunnen vertrouwen). Dat is aanzienlijk eenvoudiger dan wat jij voorstelt en daarnaast heb je geen toegang tot andermans systeem nodig... waarmee de rest van je betoog helemaal onderuit gaat.
In alle eerlijkheid: mijn betoog valt om zodra DNSSEC helemaal is uitgerold en "standaard" DNS uitgeschakeld wordt. Hoewel dit op termijn wel zal gaan gebeuren zijn we daar echter nog lang niet.

Daar ben ik het niet geheel mee eens. Een gratis certificaat kan in ieder geval aangeven dat de data die ik krijg komt van de partij die eigenaar is van het domein. Dat is wat Let's Encrypt ook voor ogen heeft.
Extra zekerheid heb je natuurlijk bij Extended Validation, waarbij de naam van een persoon of bedrijf gekoppeld wordt aan een certificaat. Maar puur het overmaken van geld is volgens mij niet voldoende voor vertrouwen, het gaat mij meer om de inhoud van de daadwerkelijke controle: is het domein of is de persoon of het bedrijf gecontroleerd.

Daar ben ik het niet geheel mee eens. Een gratis certificaat kan in ieder geval aangeven dat de data die ik krijg komt van de partij die eigenaar is van controle heeft over het domein.

Fixed. Let's Encrypt en elke andere certificaatboer die uitgaat van 'domain validated' controleert juist niet de identiteit van de eigenaren. SSL/TLS is daarmee gedegradeerd tot degenen die controle hebben over hostnames. Immers is een domain validated certificaat net zo geldig als een organization validated certificaat.

Ja, er is ook extended validation. Onderzoek heeft ooit aangetoond dat eindgebruikers hier niet op letten, en de toegevoegde waarde ervan is beperkt. Immers is het op technisch niveau exact dezelfde beveiliging, met enkel een extra attribuut die browsers kunnen gebruiken om aan de gebruiker een groen balkje te tonen. Dat gaat de wereld niet veranderen.

Sowieso is de beveiliging van HTTPS m.b.t. dat het op de oplettendheid van de gebruiker rekent twijfelachtig. Immers is de tijd van de gebruiker te kostbaar om aan beveiliging te besteden.

[Reactie gewijzigd door The Zep Man op 30 juni 2016 15:04]

Bedankt! Het uitgangspunt is inderdaad dat de eigenaar als enige daar controle over heeft, maar dat hoeft helaas niet altijd het geval te zijn!

Gelukkig is er dan ook nog weer HSTS preloading. (https://hstspreload.appspot.com)
Dat dicht tot op zekere hoogte weer het lek dat je in je laatste linkje aankaart. Het is echter wel 'n enorme lappendeken geworden, het hele HTTPS-verhaal

Ja, er is ook extended validation. Onderzoek heeft ooit aangetoond dat eindgebruikers hier niet op letten, en de toegevoegde waarde ervan is beperkt. Immers is het op technisch niveau exact dezelfde beveiliging, met enkel een extra attribuut die browsers kunnen gebruiken om aan de gebruiker een groen balkje te tonen. Dat gaat de wereld niet veranderen.

Ik kan de PDF helaas niet openen, maar dit gaat toch wel erg in tegen mijn perceptie. Browsers zijn de afgelopen jaren veel (visuele) nadruk gaan leggen op het onderscheid tussen http, domain validated ssl en extended validation. En gebruikers worden door websited getrained in het herkennen. Je bank heeft een 'veiligere' adresbalk als een willekeurig forum. Ik denk dat je gebruikers onderschat als je denkt dat ze dat niet begrijpen. Het verschil moet wel heel duidelijk zichtbaar zijn en dat was het vroeger niet. En mensen moeten er aan wennen maar dat is al aan het gebeuren volgens mij.

Tegelijkertijd beschermt zelfs een domain validated certificaat de gebruikers honderd keer beter dan plain https. Ik zie domain validated certificaten dus als een vervanger voor plain http. En dan is het gewoon belangrijk dat het toegankelijk is en prijs geen barrière vormt.

Dat de prijs van een certificaat iets zegt over de mate van betrouwbaarheid ga ik niet in mee. Er zijn genoeg problemen geweest met cert. authorities die wel geld vroegen. Het is gewoon een barriere voor https waar we zo snel mogelijk van af moeten. Let's encrypt!

Zeker voor een site als Tweakers verwacht ik toch op z'n minst een betaald certificaat. Voor elke hobbyist die een klein webblog heeft vind ik een Let's Encrypt certificaat voldoende. Maar voor grotere websites en bedrijven vind ik het echt amateur-hour om een gratis certificaat te gebruiken.
Wat is voor een bedrijf nou de kosten om 12 euro per jaar voor een domein cert uit te geven?

Of om 140 euro per jaar uit te geven aan extended validation. Was er niet van bewust dat Tweakers ook Let's Encrypt gebruikt, en als ik heel eerlijk ben valt me dat erg van ze tegen.

Een DV certificaat is even betrouwbaar of dit nu betaald of gratis gebruikt word. Ga je voor een EV certificaat dan betaal je een hoog bedrag per domein dat je wenst de certificeren. En let daarbij op dat zulke certificaten niet bestaan in wildcard vorm. Je betaald dan ineens voor elk subdomein dat je zo wenst te server. Begin maar eens te tellen hoeveel certs men bij Tweakers nodig zou hebben.

Onzin, je kan ook op een EV certificaat gebruik maken van SAN (Subject Alternative Name).

Een SAN is nog altijd geen wildcard en voor elke aanpassing die je wenst te maken moet je dus opnieuw een certificaat aanvragen. Niet echt handig wanneer je kijkt naar iets als tweakblogs waar gebruikers zelf de naam kunnen kiezen (en vernaderen) van het subdomein waarop hun tweakblog leesbaar is.

Daarnaast zijn er SSL aanbieders die het aantal alternatieve namen beperken waardoor je bij het hebben van vele subdomeinen soms alsnog meerdere certificaten moet aankopen.

Ah nuance... mooi

en als ik heel eerlijk ben valt me dat erg van ze tegen

Misschien eerst even de achtergrond lezen waarom ze hiervoor gekozen hebben: reviews: Tweakers stapt over op https (en vergeet ook de reacties eronder niet! De eerste heeft gelijk betrekking op je opmerking).

Daarna mag je (hoeft niet) je mening bijstellen.

[Reactie gewijzigd door Siebsel op 30 juni 2016 14:44]

Een LE DV certificaat of een Comodo DV certificaat zijn technisch identiek. Waarom dan 12 euro uitgeven?

Ik vind terecht: geld geven aan CAs die teveel vragen en er ook veelvuldig een rommeltje van maken (diginotar oa) is zonde en misplaatst vertrouwen.

Het certificaat voldoet prima voor het gestelde doel. Zie niet in wat een betaald certificaat zou toevoegen.

Aan de ene kant zit daar wat in, aan de andere kant zal een beetje hacker niet te beroerd zijn om een paar tientjes uit te geven... Als iemand echt kwaad wil en daar geld mee denkt te kunnen verdienen, zal dat een lage drempel zijn. Uiteindelijk draait het toch om vertrouwen

Ja precies. De barriere voor een hacker die met een scan geld probeert binnen te halen is met een paar tientjes veel te laag.
Tegelijkertijd is diezelfde barrière te hoog om er elke recepten website mee te beschermen. En dus blijven die op http zitten.
Netto zijn we met zijn allen veel beter af door het aanbod van gratis certificaten.

Zoals de naam al aangeeft draait Let's Encrypt vooral om het versleutelen van je data. Oftewel, je weet dat je wachtwoorden en dergelijke niet in plain text over het lijntje worden gestuurd en dus niet door iedereen op het netwerk te lezen is. Hetzelfde geldt voor welke pagina's je bezoekt etc.
Voor grotere partijen waarbij je vooral wil weten met wie je communiceert zijn er inderdaad andere certificaten. Maar afgaan of iets geld kost is een hele slechte raadgever in de IT. Dat is een beetje als: hij heeft een dure auto voor de deur, dat moet wel een eerlijke en betrouwbare man zijn.

Er zijn ook mensen die betalen voor certificaten waar je ze gratis kan krijgen. Ik heb bijvoorbeeld een class 2 account bij startssl. Ik heb dus wel betaald voor mijn certificaten ook al kan ik ze gratis krijgen. Dus stel dat je naar een site van mij zou gaan, dan zou die als niet veilig gezien worden ook al heb ik betaald? Die kant is er ook maar ik begrijp wel waarom je 't doet. Verder ben ik al een tijd een tevreden klant bij startssl. Hopelijk fixen ze dit snel.

Dit soort slordigheden zijn de reden dat ik die gratis authorities niet opneem in mijn lijst van authorities.

WTF?

Dit is een slordigheid, ja. Maar hij heeft niks te maken met het al dan niet gratis zijn van certificaten.

1. DigiNotar was een CA met alleen betaalde certificaten, en die hebben het qua security zo gigantisch verprutst dat ze geblacklist werden door alle browsers en failliet gingen.

2. Let's Encrypt is een CA met alleen gratis certificaten, en die heeft nog nooit zulk soort security issues / slordigheden gehad. Integendeel, mijn indruk van Let's Encrypt is tot dusver dat ze erg zorgvuldig zijn.

3. StartSSL heeft niet alleen gratis certificaten, maar ook betaalde. Dus in welke categorie moet je ze überhaupt plaatsen?


Er is geen enkele relatie tot de prijs van de certificaten en de betrouwbaarheid van de CA. Ook CAs die alleen betaalde certificaten uitgeven maken fouten.

Mijn ervaring is dat StartSSL behoorlijke prutsers zijn; met de migratie van SHA-1 intermediates naar SHA-256 (waar ze ook pas mee begonnen toen Chrome daar warnings voor begon te tonen) veroorzaakten ze ook al een puinhoop. Hier hadden wij last van met onze commerciële, betaalde certificaten. Wij gaan met ons bedrijf waarschijnlijk over naar Let's Encrypt.

(edit: De manier waarop StartSSL omging met Heartbleed was ook al zo'n drama...)

Als je StartSSL blokt omdat je ze niet vertrouwt, omdat het prutsers zijn? Prima.

StartSSL blokkeren puur omdat ze (ook) gratis certificaten leveren? Dat slaat nergens op.

.

Bij een betaald certificaat weet ik tenminste dat iemand geld heeft moeten uitgeven om het certificaat te krijgen, dan stijgt het vertrouwen bij mij ook al direct.

Natuurlijk, want een aanvaller die drie tientjes uitgeeft (om een bank website te phishen bijvoorbeeld) is wel te vertrouwen!

[Reactie gewijzigd door deadinspace op 30 juni 2016 18:16]

Erger is dat de api ook redirects volgt, totdat het zijn bewijs heeft verkregen, zelfs als het om url's bij andere domeinen gaat. Hiervoor moet een site 'open redirects' ondersteunen. Sommige beveiligingsexperts beschouwen open redirects als een risico, maar veel sites bieden dit en OAuth 2.0 stelt het nagenoeg verplicht. Veel login-sites hebben bijvoorbeeld 'open redirect'-functionaliteit, om gebruikers na het uitloggen naar een andere site te leiden. "Misbruik van de kwetsbaarheid zou werken in combinatie met heel veel domeinen en in ieder geval om sites die OAuth 2.0 bieden", zegt Ottow.

Hoe werd er gebruik gemaakt van redirect functies? Je upload toch maar een simpel textfile'tje, daar kan men toch geen 302 in steken om te redirecten naar iets anders? Dat is iets wat de HTTP server terugstuurt normaal?

De server haalde het op bij een zelf in te geven URL. Deze stond in de POST data die de client naar de server stuurde. Het ophalen van deze URL volgde dus de redirects. Kijk in het plaatje naar "verifyRes".

[Reactie gewijzigd door ultimate-tester op 30 juni 2016 14:17]

Dat pad (absoluut gezien en op die site zelf) ben ik in mee, dat ging gewoon over de locatie waar het bestand stond, dat is op zich al een probleem, maar het voorbeeld hieronder maakt ook gewag van de URL er achter en dat wou ik even weten, met dat heb je natuurlijk helemaal vrij spel.

als je hxxp://www.hyperbart.nl/logout?url=http://aanvaller.com/signfile hebt dan doet jou domein een 302 naar het bestand van de aanvaller en zal de tool je een cert geven voor hyperbart.nl

[Reactie gewijzigd door DanielG op 30 juni 2016 14:19]

StartCom haalde daarop het systeem offline (en) verhielp de kwetsbaarheid op 29 juni.

Nu vraag ik me toch wel af hoe ze deze kwetsbaarheden verholpen hebben. Volgen ze geen redirects meer? Blacklisten ze sites die uploads ondersteunen? Ik kan het niet vinden op de StartSSL site.

Waarschijnlijk is het controle pad nu gewoon hardcoded. Ik snap sowieso niet waarom dat dynamisch moest zijn. Een bestand in de root, of in een map van de root, met een random naam, is dynamisch en uniek genoeg.

StartSSL is misschien niet de bekendste certificaatautoriteit, maar het is ook zeker geen kleine speler. Op dit moment is StartSSL de nummer 7 (in termen van gebruikers) van alle certificaatautoriteiten. Iedereen die wel eens gezocht heeft naar een goedkoop SSL-certificaat is StartSSL waarschijnlijk wel tegengekomen; ze bieden al sinds jaar en dag gratis Domain Validated-certificaten aan. (Geld verdienen ze aan Wildcard- en Extended Validation-certificaten.)

[Reactie gewijzigd door xrf op 30 juni 2016 14:38]

Het is voor mij geen onbekende en ik ken zelf ook personen die het gebruiken. Gewoon puur voor een SSL verbinding. Lets Encrypt was er toen nog niet en daarvoor waren ze het beste keuze. Ondanks dat je nu voor een paar euro een SSL certificaat heb.

Leuk om te gebruiken in combinatie met http://www.hackies.in/thegooglehack.html, 31 open redirects op Google domeinen die ze niet aanpassen.

Beide statements geven aan hoe misleidend dat groene slotje is. Het geeft alleen aan dat een verbinding versleuteld is, en verder niets.

Dat is simpelweg niet waar; het groene slotje geeft aan dat de verbinding versleuteld is met een correct, geldig certificaat voor dat domein. Dat is heel veel meer dan wat jij zegt.

Oneens. In beide uitspraken wordt gesteld dat de website als geheel veilig is, of dat wordt sterk geimpliceerd. Dat is duidelijk niet het geval, slechts de verbinding is veilig. En ook dat niet, aangezien het enigste wat nodig is om SSL te regelen controle over het domein is.

De vraag word vooral: wat wil je bekomen met dat slot? Voor mij is https simpelweg een manier om de verbinding tussen client en server te versleutelen en in dat opzicht werkt dit systeem zeer goed. Als je een certificaat evenwel voor authenticatie wenst te gebruiken dan voldoet een eenvoudig slot niet. Dan heb je EV certificaten nodig (en zelfs daar durft het al eens mislopen).

Voor mij blijft authenticatie van de verzendende kant nog altijd iets dat de client/gebruiker zelf in het oog moet houden en de eindgebruiker moet zich realiseren dat een slotje niet betekend dat je verbonden bent met de site waarvan je denkt dat je naartoe hebt gesurft.

Maar 'beveiliging tussen client en server' is redelijk nutteloos als je niet zeker weet dat de ontvangende server niet gewoon een MITM is. Helemaal als je op publieke hotspots zit.