Audit SURFconext: gecoördineerde aanpak kwetsbaarheid

Inloggen via SURFconext moet natuurlijk met de hoogste betrouwbaarheid gebeuren, omdat meer dan duizend clouddiensten erop vertrouwen. Daarom laten we regelmatig securitytests uitvoeren door externe partijen: periodiek voor het bestaande platform, en ook bij nieuwe functionaliteiten. In de herfst van 2019 voegden we een nieuwe functie toe waardoor SURFsecureID en SURFconext beter integreren. Ook voor deze nieuwe functie hebben we dus een audit laten uitvoeren. Voor de tests werken we steeds met een andere partij, omdat ieder bedrijf een eigen invalshoek heeft en om de frisse blik te behouden. Voor deze opdracht kozen we voor het Duitse HackmanIT GmbH, gespecialiseerd in penetratietests van single sign on.

Kritiek probleem

SURFconext werkt op basis van het internationaal gestandaardiseerde SAML 2.0-protocol. Ook voor de nieuw gebouwde functionaliteit vindt er een SAML-berichtuitwisseling plaats: als iemand een tweede factor via SURFsecureID heeft, vraagt SURFconext middels een SAML-bericht aan SURFsecureID om het token van de gebruiker te verifiëren. De opdracht aan HackmanIT was dan ook om te verifiëren of deze koppeling niet te manipuleren viel. Bijvoorbeeld dat een aanvaller de tokencontrole kan overslaan.

De testers kwamen na enkele dagen terug met een kritieke bevinding: het was inderdaad mogelijk om de berichten tussen SURFsecureID en SURFconext te beïnvloeden. Echter, de bron van deze kwetsbaarheid zat niet in de nieuw ontwikkelde code, maar in de onderliggende softwarebibliotheek waarmee de SAML-berichten gecontroleerd worden. Deze externe bibliotheek, xmlseclibs, is echter niet specifiek voor de nieuwe koppeling, maar wordt gebruikt in heel SURFconext en SURFsecureID. En is bovendien ook onderdeel van andere veelgebruikte producten, zoals SimpleSAMLphp dat wereldwijd veel gebruikt wordt voor SAML-implementaties. Wat begon als een test van een specifieke functie, leidde tot de conclusie dat heel SURFconext, maar zelfs het hele ecosysteem van federatieve koppelingen, niet meer waterdicht was.

De kwetsbaarheid

De manier van authenticatie zoals SURFconext en vele andere SAML 2.0-federaties die gebruiken, is gebaseerd op XML-berichten, assertions, met de gegevens over de ingelogde gebruiker. Zie voor meer uitleg hierover het blog SAML voor Dummies. Belangrijk om te weten is dat deze berichten altijd via de browser van de inloggende gebruiker worden verstuurd. Deze moeten niet aanpasbaar kunnen zijn. Daarvoor zorgt een handtekening op het XML-bericht. De service provider die een assertion ontvangt, moet het bericht ontleden en controleert vervolgens de handtekening van SURFconext en weet zo dat hij niet onderweg is aangepast. De XML-standaard is zeer breed en biedt allerlei mogelijkheden om een bericht in te richten.

Signature wrapping attack

De gevonden kwetsbaarheid is een geavanceerde vorm van de zogeheten signature wrapping attack. De aanvaller moet beschikken over een geldige assertion voor de betreffende dienst. Hij moet dus wel al op de dienst kunnen inloggen, en vervolgens het bericht onderscheppen terwijl het langs zijn browser komt. In het bericht staat bijvoorbeeld zijn gebruikersnaam. Vervolgens laat hij de kern van dit bericht ongemoeid, waaronder het deel met zijn gebruikersnaam, zodat de handtekening van SURFconext in stand blijft. Hij plakt er echter nog een stuk XML achteraan, maar dan niet ondertekend met een handtekening, waarin de gebruikersgegevens nog eens zijn opgenomen, maar met een andere gebruikersnaam. De bug is dat de softwarebibliotheek de oorspronkelijke, door SURFconext gezette handtekening wel correct controleert, maar vervolgens de attribuutwaarden uitleest uit het extra toegevoegde stuk, in plaats van uit het ondertekende stuk. De aanvaller is nu ingelogd als de andere gebruiker en krijgt – in de dienst – dus de gegevens en rechten van die andere gebruiker.

Voor uitgebreide technische uitleg, zie de blog die HackmanIT erover schreef.

Gecoördineerde bekendmaking

We waren natuurlijk heel blij dat HackmanIT dit probleem gevonden had, maar de vraag rees direct hoe dit goed en snel op te lossen. Er zijn vele kwetsbare diensten in de wereld, omdat de bug in xmlseclibs er al sinds jaar en dag in zat. Aan de andere kant was het enigszins geruststellend dat het bij een groot aantal eerdere audits nog niet gevonden was, dus dat de bug in ieder geval niet heel evident aan de oppervlakte lag. We moesten de balans zoeken tussen het zo snel mogelijk wereldkundig maken van dit probleem en het voorkomen dat aanvallers ermee aan de slag zouden gaan voordat diensteigenaren een update konden aanbrengen.

Betrokken partijen geïnformeerd, week later publiek gemaakt. Met een goede reden.

We hebben de vondst daarom initieel vertrouwelijk gehouden en contact gezocht met diverse betrokkenen: de auteur van xmseclibs, Rob Richards, en het SimpleSAMLphp-project, een belangrijke andere gebruiker van de library. Gelukkig kon Rob Richards snel met een patch komen, die door HackmanIT geverifieerd werd. De oplossing wilden we snel publiek maken, zodat alle partijen het probleem konden aanpakken. Maar we wilden ook weer niet te snel, zodat ze wel genoeg tijd hadden het probleem op te lossen voordat de bad guys ermee aan de haal zouden gaan. We kozen voor een datum een week later. Op dat moment, 6 november om 13.00 ’s middags, zouden alle betrokken partijen tegelijkertijd hun nieuwe versies uitbrengen – om te voorkomen dat de details al afgeleid konden worden uit het ene product voordat het andere product een oplossing had. Een echte specialist kan uit de wijzigingen in een nieuwe softwareversie namelijk vrij snel achterhalen hoe de kwetsbaarheid werkt. De uitleg over de kwetsbaarheid delen we wel pas een dag na de software-updates, zodat we in ieder geval een voorsprong hadden op de ‘niet-experts’ voor wie het lastiger is om dit uit de code af te leiden. Maar niettemin publiceerden we juist ook graag snel de details, omdat goed begrip van de kwetsbaarheid vooral ook de good guys helpt de impact te begrijpen.

Hoe kwetsbaarheid opgelost?

De week die er tussen zat, hebben we gebruikt om een CVE-naam vast te leggen (CVE-2019-3465) die helpt om een kwetsbaarheid eenduidig te identificeren, andere partijen te informeren, zoals installaties van OpenConext, teksten en aankondigingen voor te bereiden en en ervoor te zorgen dat iedereen op dat tijdstip paraat zou zitten. De dag van te voren rolden we de patch al uit op SURFconext, zodat die veilig was vanaf het moment van publicatie. Het was nog even spannend of de afspraken tussen diverse partijen ook echt goed zou gaan. Maar op 6 november 13.00 verscheen er inderdaad een nieuwe versie van xmlseclibs op Github, en heel kort daarna releases van SimpleSAMLphp en OpenConext. Dienstaanbieders die klaar zaten konden direct updaten. En dat gebeurde gelukkig in groten getale.

En nu?

We zijn heel blij dat deze kwetsbaarheid gevonden en gerepareerd is. Maar de vraag blijft hoe het kan dat deze zo lang bestaan heeft. Daar zijn vele samenhangende reden voor aan te wijzen. Een belangrijke factor is de complexiteit van zowel de XML- als de SAML-standaarden. Deze zijn zeer generiek en bevatten heel veel opties en mogelijkheden. Dat maakt dat software die die berichten moet interpreteren, met heel veel varianten rekening moet houden. Elke extra regel code verhoogt de kans op fouten en de flexibiliteit van de standaarden verlaagt de testbaarheid van de implementaties. Overigens is een alternatief als OpenID Connect wat complexiteit betreft niet per se op alle fronten eenvoudiger.

Niet alleen gepatcht, ook andere controles toegevoegd in SURFconext

Wat wij naast het aanbrengen van de patch nog gedaan hebben, is dat we in OpenConext juist heel vroeg in het verwerken van binnenkomende berichten al een aantal algemene controles opwerpen. Want alhoewel de SAML- en XML-standaarden heel breed zijn, is de subset ervan die binnen SURFconext gebruikt wordt veel beperkter. Instellingen gebruiken zo’n zes verschillende producten voor hun IdP-software, dus we hebben een behoorlijk compleet beeld van wat gewoon is voor die software om vrij te geven. Zo zal een legitieme identity provider bij onze instellingen altijd maar één set attributen per keer vrijgeven, en die set één keer ondertekenen. Daarom kunnen wij al vroeg controleren of een bericht “gek” is of in onze context nooit zou moeten voorkomen. Daarmee kunnen we al in een vroeg stadium pogingen tot manipulatie tegengaan.