NodeJS wordt snel steeds meer gebruikt als het platform van keuze in projecten van onze klanten. Een van de voordelen van dit relatief nieuwe platform is de overvloed aan open source bibliotheken: 'middleware' in Node-taal. Dit is natuurlijk een goede zaak, het verhoogt de ontwikkelsnelheid en we weten allemaal dat recyclen goed is voor het milieu.
Voor ons, als beveiligingsonderzoekers, betekent dit dat we opnieuw moeten nadenken over de manier waarop we op maat gemaakte applicaties van onze klanten beoordelen. Terwijl we ons vroeger voornamelijk richtten op op maat ontwikkelde code, wordt het steeds belangrijker om ook de middleware-laag in overweging te nemen bij het uitvoeren van codebeoordelingen.
Daarom hebben we onlangs ons (code) reviewbereik uitgebreid in een project en al snel beseften we het belang hiervan toen we een kwetsbaarheid ontdekten in populaire middleware, 'Express-saml2', die - afhankelijk van het daadwerkelijke gebruik van de middleware - ernstige gevolgen kan hebben. Express-saml2 wordt gebruikt om de implementatie van het saml2-protocol te ondersteunen dat wordt gebruikt om single sign-on te faciliteren. En is daarom natuurlijk een interessant doelwit voor aanvallers.
Na grondig onderzoek hebben we geleerd dat 'Express-saml2' nu verouderd is en is vervangen door 'Samlify' (https://samlify.js.org/#/). We hebben Samlify gecontroleerd en geconcludeerd dat de kwetsbaarheid nog steeds aanwezig was in de meest recente versie (2.2.0 op dat moment).
Een aanvaller die een SAMLResponse heeft waargenomen, kan NameID's toevoegen aan het SAMLResponse-bericht zonder de handtekeningcontrole te verbreken. Afhankelijk van de toepassingslogica kan dit misbruikt worden om in te loggen als een willekeurige gebruiker.
Legitieme gebruikers kunnen SAMLResponses waarnemen door eenvoudigweg hun browser te gebruiken of een onderscheppende proxy zoals ZAP. Bovendien kunnen SAMLResponses worden verkregen door het onderscheppen van netwerkverkeer of het uitvoeren van man-in-the-middle-aanvallen.
Merk op dat dit probleem kan worden gezien als een XML Signature Wrapping-aanval, wat een bekend aanvalspatroon is. Zie: https://www.usenix.org/system/files/conference/usenixsecurity12/sec12-final91-8-23-12.pdf
De middleware analyseert bepaalde elementen van de SAMLResponse-berichten en exposeert de verkregen gegevens aan de aanroepende applicatie. De applicatie vertrouwt op deze gegevens en gebruikt ze om de gebruiker te authenticeren. De kwetsbaarheid komt voort uit het feit dat de selectie van elementen wordt gedaan met behulp van naïeve XPath-expressies. Zie codefragmenten hieronder:
TDit leidt uiteindelijk tot de volgende XPath-expressie om het NameID-element te selecteren:
Deze expressie selecteert eenvoudigweg alle 'NameID'-tags, of ze nu deel uitmaken van een gevalideerde handtekening of niet. Alle NameID-waarden worden doorgegeven aan de applicatie met behulp van Express-saml2/Samlify.
Er werd een eenvoudig Proof of Concept (PoC) ontwikkeld op basis van de voorbeelden in de Express-saml2 module. Samlify 2.2.0 werd gebruikt om de SAMLResponses in de onderstaande screenshots te verwerken.
Normaal request (met geldige handtekening). Er is slechts één NameID-tag: er wordt een tekenreeks geretourneerd:
Extra NameID-tag is included in message:
Two NameID tags in the message: an array of strings is returned:
Of deze kwetsbaarheid leidt tot een uitbuitbare scenario, hangt af van de logica in de applicatie die de middleware gebruikt om gebruikers te authenticeren. In het reguliere gebruik (bijv.: geen aanval), retourneert de middleware NameID als een string. Wanneer een aanvaller een extra NameID toevoegt, retourneert de middleware een array. De applicatie kan de eerste of de laatste waarde in deze array gebruiken (beide staan onder controle van een aanvaller) of fout gaan. In het laatste geval is de kwetsbaarheid in Express-saml2/Samlify mogelijk niet uitbuitbaar via de applicatie.
Nadat we de kwetsbaarheid hadden ontdekt, hebben we contact opgenomen met de hoofdontwikkelaar van het Samlify-project: Tony Ngan (tngan op GitHub). De volgende acties werden voorgesteld om de kwetsbaarheid op te lossen:
Tony was zeer behulpzaam en heeft het probleem snel aangepakt.
Versie 2.3.0 van Samlify valideert nu inkomende berichten tegen een XSD, waardoor de kwetsbaarheid niet langer kan worden misbruikt. Als je Samlify gebruikt, zorg er dan voor dat je zo snel mogelijk upgrade naar de nieuwste versie. Als je nog steeds Express-saml2 gebruikt, migreer dan zo snel mogelijk naar de nieuwste versie van Samlify. Samlify is te vinden op:
Verder moet je er rekening mee houden dat Samlify momenteel niet alle SAML2-controles volledig implementeert. Het blijft de verantwoordelijkheid van de oproeper om tijdslimieten en de beoogde doelgroep/bestemming op de juiste manier te controleren. Deze controles kunnen in de toekomst worden opgenomen in Samlify.
Middelwares en andere applicatiecomponenten zijn een essentieel onderdeel van elke op maat gemaakte applicatie die ze gebruikt, en moeten daarom ook als zodanig worden behandeld bij het uitvoeren van beveiligingsbeoordelingen.
Update: Er is een CVE toegewezen voor dit probleem: CVE-2017-1000452
