SSRF-aanval: hoe een server wordt misbruikt als heimelijke boodschapper
Stel je voor: je werkt bij een postkantoor en een klant vraagt je om namens hem een pakketje af te leveren bij een adres dat hij zelf opgeeft. Normaal is dat geen probleem, want het gaat om een extern adres. Maar wat als die klant stiekem vraagt om het pakketje af te leveren bij de kluis in het kantoor zelf, een plek waar hij als buitenstaander helemaal niet mag komen? Omdat jij, als medewerker van het postkantoor, wel overal binnen mag, glipt hij zo via jou naar binnen. Dit is in essentie wat een SSRF-aanval doet met een webserver.
SSRF staat voor Server-Side Request Forgery, ofwel: het vervalsen van een verzoek dat door de server zelf wordt verstuurd. Een aanvaller misbruikt een functie op een website, bijvoorbeeld een knop die "controleer deze link" of "haal deze afbeelding op" doet, om de server een verzoek te laten sturen naar een plek die de aanvaller zelf niet rechtstreeks kan bereiken. Denk aan interne systemen achter een firewall, of gevoelige beheerinterfaces die alleen vanaf het eigen netwerk toegankelijk zijn. De server, die wél vertrouwd wordt binnen dat netwerk, wordt zo ongewild een boodschapper voor de aanvaller.
Wat is het precies?
Veel websites en apps hebben functies die op de achtergrond een ander internetadres (een URL) opvragen. Denk aan een website die een voorvertoning van een link toont, een dienst die een profielfoto ophaalt via een URL die je zelf invoert, of software die PDF's genereert op basis van webpagina's. Al deze functies hebben één ding gemeen: de server voert zelf een netwerkverzoek uit naar een adres dat, direct of indirect, door de gebruiker wordt bepaald.
Bij een SSRF-aanval vult de aanvaller niet het verwachte adres in, maar een adres dat wijst naar iets gevoeligs. Dat kan een interne server zijn die normaal niet vanaf internet bereikbaar is, bijvoorbeeld http://192.168.1.10/admin. Omdat de kwetsbare server zich wél binnen dat interne netwerk bevindt, kan hij die interne pagina gewoon bereiken, ook al zou een buitenstaander daar nooit bij kunnen.
Een bijzonder gevoelig doelwit is de zogeheten "metadata-service" die cloudleveranciers zoals Amazon Web Services (AWS), Microsoft Azure en Google Cloud aanbieden. Elke virtuele server in de cloud kan via een vast, intern adres (vaak 169.254.169.254) informatie over zichzelf opvragen, zoals tijdelijke inlogsleutels waarmee de server bij andere clouddiensten mag. Als een aanvaller via SSRF de server dwingt om dit adres op te vragen, kan hij die sleutels buitmaken en zich vervolgens voordoen als de server zelf, met alle toegangsrechten van dien.
Er bestaan verschillende varianten. Bij "blinde" SSRF krijgt de aanvaller het antwoord niet direct te zien, maar kan hij toch informatie afleiden, bijvoorbeeld uit de tijd die een verzoek kost. Bij zichtbare SSRF krijgt de aanvaller de inhoud van het interne antwoord rechtstreeks teruggestuurd, wat het aanvallen aanzienlijk vergemakkelijkt. Aanvallers gebruiken ook trucs om filters te omzeilen, zoals het coderen van adressen op ongebruikelijke manieren, het gebruik van omleidingen (redirects), of het combineren met DNS-trucs waarbij een domeinnaam pas op het laatste moment naar een intern adres verwijst.
Wat wil men ermee bereiken?
Het doel van een SSRF-aanval is vrijwel altijd hetzelfde: toegang krijgen tot systemen of gegevens die normaal buiten bereik zijn, door gebruik te maken van het vertrouwen dat interne systemen in elkaar hebben. Waar een firewall bedoeld is om verkeer van buitenaf tegen te houden, kijkt die firewall meestal niet kritisch naar verkeer dat van binnenuit, van de eigen server dus, lijkt te komen.
Concreet kunnen aanvallers met SSRF interne netwerken in kaart brengen (welke systemen bestaan er, welke poorten staan open), gevoelige configuratiebestanden of API-sleutels buitmaken, beheerpanelen bereiken die niet voor het publiek bedoeld zijn, of zoals bij Capital One, tijdelijke cloud-inloggegevens stelen om vervolgens grootschalig gegevens te downloaden. SSRF is zelden het einddoel op zich; het is meestal de eerste stap in een langere aanvalsketen die uiteindelijk leidt tot dataverlies, overname van systemen of verdere inbraak.
Voor verdedigers is het doel dus niet alleen het dichten van individuele kwetsbaarheden, maar het wegnemen van het onderliggende probleem: te veel impliciet vertrouwen tussen systemen die met elkaar praten.
Voorbeelden uit de praktijk
Het bekendste voorbeeld is het Capital One-datalek van 2019. Een voormalig medewerker van Amazon Web Services, Paige Thompson, misbruikte een verkeerd geconfigureerde webapplicatie-firewall om via SSRF bij de AWS-metadata-service te komen. Daarmee bemachtigde ze tijdelijke cloudsleutels waarmee ze gegevens van ruim 106 miljoen klanten van de Amerikaanse bank Capital One kon downloaden, waaronder namen, adressen en creditscores. De zaak wordt vaak aangehaald als het schoolvoorbeeld van hoe SSRF in combinatie met cloudinfrastructuur enorme schade kan aanrichten.
In februari 2021 werd CVE-2021-21972 openbaar gemaakt, een SSRF-kwetsbaarheid in de vSphere Client van VMware vCenter Server, veelgebruikte beheersoftware voor bedrijfsdatacenters. Kort na publicatie van de details doken er op internet actief scannende aanvallers op die kwetsbare, onbeveiligde vCenter-installaties probeerden binnen te dringen, wat de nood aan snel patchen bij veel organisaties benadrukte.
Ook de beruchte "ProxyLogon"-aanvalsketen tegen Microsoft Exchange Server in maart 2021 begon met een SSRF-kwetsbaarheid (CVE-2021-26855). Aanvallers gebruikten dit als eerste opstap om vervolgens dieper in Exchange-servers wereldwijd door te dringen, wat leidde tot een van de grootste gecoördineerde patchrondes in de recente beveiligingsgeschiedenis.
Buiten deze grote, publiek bekende incidenten komen SSRF-kwetsbaarheden ook regelmatig voor in bug bounty-programma's, waarbij onderzoekers tegen een beloning kwetsbaarheden melden bij bedrijven als GitHub, GitLab en diverse cloudplatformen. Dit soort meldingen bereikt zelden het nieuws, maar toont wel aan hoe vaak SSRF nog opduikt in alledaagse webapplicaties.
Hoe ver is de techniek?
SSRF is geen nieuw fenomeen; het probleem wordt al sinds het begin van de jaren 2000 beschreven, maar heeft de afgelopen tien jaar veel aan relevantie gewonnen door de opkomst van cloud computing. Juist doordat clouddiensten interne metadata-adressen gebruiken voor gemak en automatisering, is de potentiële impact van SSRF flink toegenomen.
De vakgemeenschap heeft dit erkend: in 2021 nam het beveiligingsplatform OWASP (Open Web Application Security Project) SSRF voor het eerst apart op in zijn invloedrijke "OWASP Top 10", een lijst van de belangrijkste beveiligingsrisico's voor webapplicaties, als categorie A10:2021. Opvallend is dat SSRF relatief weinig wordt gerapporteerd in vergelijking met bijvoorbeeld injectie-aanvallen, maar wel een hoge potentiële impact heeft, wat de reden was voor opname via een combinatie van data en een stemming onder beveiligingsexperts.
Als verdediging tegen SSRF bestaan inmiddels redelijk volwassen technieken: het isoleren van cloud-metadata-services achter extra authenticatie (zoals AWS sindsdien standaard doet met de zogeheten "Instance Metadata Service versie 2"), het toepassen van allowlists (alleen expliciet toegestane adressen benaderen in plaats van alles behalve een blocklist), en netwerksegmentatie zodat servers die externe verzoeken verwerken niet zomaar bij gevoelige interne systemen kunnen. Toch blijft het een terugkerend probleem, omdat elke nieuwe functie die een URL van een gebruiker verwerkt in potentie weer een nieuw kwetsbaar punt oplevert. Volledige uitroeiing is dan ook niet te verwachten; het blijft vooral een kwestie van consistente architectuurkeuzes en zorgvuldige software-ontwikkeling.
Wie werken eraan?
Aan de verdedigende kant speelt OWASP een centrale rol met documentatie, richtlijnen en de eerdergenoemde Top 10-lijst, die wereldwijd als referentiepunt geldt voor webapplicatiebeveiliging. Grote cloudleveranciers als Amazon (AWS), Microsoft (Azure) en Google (Google Cloud) hebben de afgelopen jaren hun metadata-diensten actief aangepast om SSRF-misbruik te bemoeilijken, mede als reactie op incidenten als Capital One.
Onderzoeksplatform PortSwigger, bekend van de beveiligingstool Burp Suite, publiceert uitgebreid lesmateriaal en praktijkoefeningen over SSRF via zijn "Web Security Academy" en behoort tot de meest geciteerde bronnen binnen de beveiligingswereld. Daarnaast dragen overheidsinstanties zoals het Amerikaanse NIST (National Institute of Standards and Technology) bij via de CWE-classificatie (Common Weakness Enumeration), waarin SSRF is opgenomen als CWE-918, een gestandaardiseerde manier om dit type kwetsbaarheid te categoriseren en te herkennen in kwetsbaarhedendatabases.
Ook bug bounty-platformen als HackerOne en Bugcrowd spelen een rol, doordat ze onafhankelijke onderzoekers wereldwijd stimuleren om SSRF-kwetsbaarheden bij bedrijven te vinden en verantwoord te melden, voordat kwaadwillenden ze kunnen misbruiken.