Server-Side Request Forgery (SSRF): Voorbeelden en preventie

Elke dag komen er duizenden nieuwe kwetsbaarheden bij, wat nieuwe kansen creëert voor hackers. De slechteriken nemen geen pauzes of vakanties! Ze werken actief aan het compromitteren van uw systemen.

Het belang van de nieuwste kwetsbaarheden voorblijven kan niet genoeg benadrukt worden in het steeds evoluerende dreigingslandschap. Deze keer bespreken we de kwetsbaarheid voor Server-Side Request Forgery. Zonder verder oponthoud, zullen we verkennen hoe SSRF werkt, hoe SSRF-kwetsbaarheden in uw applicaties te ontdekken, en welke stappen ondernomen moeten worden om ze te voorkomen.

Wat is Server-Side Request Forgery?

De kwetsbaarheid, officieel Server-Side Request Forgery (SSRF) genoemd, staat in de OWASP Top 10 als een groot risico voor applicatiebeveiliging. Hackers van diverse pluimage maken gebruik van SSRF-kwetsbaarheden om serverfunctionaliteit te misbruiken en willekeurige uitgaande verzoeken vanaf een server te verzenden.

Door een URL te coderen, HTTP-headers te manipuleren en URL-pad-traversal te bewerken, kunnen dreigingsactoren ongeautoriseerde verzoeken doen naar een specifieke URL. SSRF-kwetsbaarheden kunnen leiden tot serviceonderbreking en, in sommige gevallen, tot totale systeemovername.

Soorten Server-Side Request Forgery-aanvallen

Als u zich afvraagt wat de verschillende SSRF-aanvallen inhouden, dan helpen wij u graag om dit te verduidelijken. Afhankelijk van hoe de server reageert op het initiële verzoek, zijn er drie soorten SSR:

Blind SSRF

Blind SSRF treedt op wanneer de hostserver geen zichtbare gegevens retourneert aan cyberactoren. Ransomware-criminelen streven ernaar kritieke bestanden te wijzigen of te verwijderen, serverinstellingen aan te passen en gebruikers- of bestandsmachtigingen aan te passen, in plaats van alleen specifieke gegevens van de server te stelen. Er wordt niets van de server naar de fraudeur gestuurd, wat het een veeleisende taak maakt om deze aanvallen te detecteren totdat de schade is aangericht.

Over het algemeen is blind SSRF het moeilijkst uit te buiten, maar het kan leiden tot denial of service (DoS) en volledige remote code execution op de server of andere back-endcomponenten.

Semi-blind SSRF

In dit scenario retourneert de semi-blinde instantie wel gedeeltelijke gegevens over een resulterend verzoek. Hierdoor krijgt de aanvaller toegang tot bepaalde geheime gegevens, maar niet de volledige set. Dit kan informatie bevatten zoals foutmeldingen of responstijden. Semi-blind SSRF is vaak voldoende om de kwetsbaarheid te valideren, maar legt geen gevoelige gegevens bloot.

Niet-blind SSRF

Niet-blind SSRF is meestal het meest schadelijk van allemaal, omdat gegevens van een willekeurige URL kunnen worden opgehaald en teruggestuurd naar kwaadwillende entiteiten die de query hebben gedaan. Na een succesvolle niet-blinde SSRF-aanval krijgen kwaadwillende operators toegang tot beperkte netwerkbronnen die hen zullen helpen bij het lanceren van verdere aanvallen.

Hoe kunnen dreigingsactoren SSRF misbruiken?

SSRF-kwetsbaarheden kunnen voorkomen in diverse softwaretypen, programmeertalen en platforms, zolang de software opereert in een netwerkomgeving. Simpel gezegd, als aanvallers de bestemming van het server-side verzoek kunnen controleren, opent dit de deur voor een overvloed aan beveiligingslekken, waardoor ze mogelijk kunnen:

IP-whitelisting omzeilen
Kwaadaardige HTTP-verzoeken injecteren in het doelsysteem
Firewallcontroles omzeilen
Remote Code Execution (RCE) uitvoeren
Door bedrijfsnetwerken bewegen om andere kwetsbaarheden uit te buiten
Legitieme HTTP-verzoeken kapen en omleiden naar een door de aanvaller gecontroleerde server
Netwerken scannen die verbonden zijn met de kwetsbare server, intern of extern
Configuratiebestanden of gevoelige gegevens van de webserver lezen
Een DDoS-aanval (Distributed Denial of Service) initiëren door verzoeken naar externe bronnen te sturen
Statuspagina’s benaderen en API’s benutten als de webserver
Gevoelige informatie ophalen, zoals wachtwoorden of API-sleutels
Het vertrouwen tussen de kwetsbare server en andere systemen misbruiken

SSRF-aanvallen zijn bijzonder lastig omdat ze vaak worden gecombineerd met andere kwetsbaarheden. Deze combinatie stelt aanvallers in staat een voet aan de grond te krijgen op de server, wat dient als basis voor verdere exploitatie.

Vaak is het hoofddoel van een SSRF-aanval het stelen van een schat aan documenten of een database met bedrijfsgegevens. Dit kan leiden tot verlies van klantvertrouwen, omzetdaling, juridische aansprakelijkheden en financiële boetes.

Hoe SSRF te detecteren?

Wat kunnen we precies doen om deze kwetsbaarheid te ontdekken? In de context van SSRF moeten de volgende stappen worden genomen om dergelijke kwetsbaarheden te detecteren:

Identificeer potentiële invoerpunten voor het construeren van URL’s of het initiëren van verzoeken naar externe servers, zoals GET- of POST-parameters en headers.
Test elke invoer door een reeks verschillende URL’s of IP-adressen als invoer te proberen. Dit moet interne bronnen, localhost en andere speciale waarden omvatten.
Onderzoek hoe de applicatie reageert op diverse invoer, specifiek zoekend naar tekenen van SSRF-kwetsbaarheden. Controleer op indicaties zoals de mogelijkheid om interne bronnen te benaderen of gegevens te extraheren.
Noteer alle ontdekte kwetsbaarheden, waarbij de invoer die de kwetsbaarheid veroorzaakte, het type kwetsbaarheid en de potentiële impact worden gedetailleerd beschreven.

Voorbeelden uit het echte leven

Nu we de basisprincipes van SSRF hebben behandeld, laten we enkele incidenten van dergelijke aanvallen uit het echte leven bekijken.

Capital One

Een goed voorbeeld van een SSRF-aanval was toen Capital One werd gehackt en de gegevens van ongeveer 106 miljoen mensen in de Verenigde Staten en Canada online werden gelekt. Dus, hoe vond de inbreuk plaats?

De hacker slaagde erin een reactie te ontvangen met inloggegevens als gevolg van een verkeerde configuratie van de webapplicatiefirewall. Dat stelde de hacker in staat om verbinding te maken met de server waar Capital One zijn gegevens opsloeg en toegang te krijgen tot klantbestanden.

Microsoft Exchange

Meer recentelijk werd ontdekt dat de Hafnium-dreigingsgroep e-mailsoftware van Microsoft Exchange Server infecteerde. De Microsoft Exchange-inbreuk in 2021 betrof vier kwetsbaarheden, maar specifiek de SSRF-kwetsbaarheid stelde kwaadwillende entiteiten in staat om zich te authenticeren als een Exchange-server en externe code uit te voeren via PowerShell. Het is een ander voorbeeld van hoe een gecompromitteerde vertrouwde bron aanvallen kan escaleren.

De groep, die vanuit China opereert, richtte zich op e-mailsysteem die werden gebruikt door 30.000 Amerikaanse advocatenkantoren, instellingen voor hoger onderwijs, onderzoekers naar infectieziekten, beleidsdenktanks, defensieaannemers en niet-gouvernementele organisaties.

Microsoft Azure`s Services

Op 17 januari 2023 werden beveiligingsproblemen ontdekt die Microsoft Azure`s Services blootstelden aan SSRF-aanvallen. Twee kwetsbaarheden vereisten geen authenticatie, waardoor dreigingsactoren deze konden misbruiken zonder een Azure-account. Na het identificeren van kwetsbaarheden in Azure API Management, Azure Functions, Azure Machine Learning en Azure Digital Twins, heeft Microsoft de problemen snel aangepakt en opgelost.

Gelukkig werd in dat geval tijdig extra invoervalidatie voor de kwetsbare URL’s geïmplementeerd, en hebben de kwetsbaarheden geen schade veroorzaakt aan Azure-services of -infrastructuur. Toch heeft het bedrijf de risico’s van server-side request forgery-aanvallen goed ingezien.

SSRF-preventie en -mitigatie

Zonder de juiste preventieve processen is de veiligheid van uw applicaties een groot vraagteken. Zoals bij de meeste kwetsbaarheden is preventie de beste aanpak om SSRF-fouten te verhelpen.

Voer invoervalidatie uit. Vertrouw de invoer niet blindelings — verifieer altijd de authenticiteit ervan.
Maak een lijst van domeinnamen of IP-adressen waartoe uw applicatie toegang moet hebben. Minimaliseer het aanvalsoppervlak. In interne netwerken betekent dit meestal dat een server verzoeken met URL’s op een vooraf bepaalde lijst moet toestaan en alle andere verzoeken moet afwijzen.
Gebruik URL-codering. Correcte codering en decodering van gebruikersinvoer is een aanvullend verdedigingsmechanisme dat het risico op kwaadaardige URL’s die door de server worden verwerkt, beperkt.
Voer penetratietesten uit, inclusief een menselijk element om kwetsbaarheden te misbruiken. U kunt ook beveiligingstests gebruiken om simulatietests uit te voeren.
Schakel ongebruikte URL-schema’s uit. Deze aanpak wordt gebruikt om alleen die URL-schema’s toe te staan die uw applicatie gebruikt om verzoeken te doen, en beperkt daarmee de aanvaller om verzoeken te doen met potentieel gevaarlijke schema’s zoals file://, phar://, gopher://, data://, of dict://.
Handhaaf het principe van minimale privileges, waarbij het systeem alleen toegang verleent aan geautoriseerde gebruikers.
Segregeer het netwerk. Door interne netwerken te scheiden van externe netwerken, verkleint u het aanvalsoppervlak en maakt u het moeilijker voor hackers om toegang te krijgen tot interne systemen.
Als beveiligingsbeste praktijk, mitigeer verkeerde configuraties.
Informeer medewerkers over de risico’s die gepaard gaan met SSRF en manieren om deze te elimineren.
Documenteer en leer van SSRF-kwetsbaarheden die u hebt ontdekt om testprocedures te verbeteren en toekomstige incidenten te voorkomen.
Regelmatig software bijwerken biedt een extra preventief niveau.

Preventie is inderdaad slimmer dan wachten tot de vijandige aanvallers toeslaan.

Hoe kan QAwerk helpen?

Penetratietesten is een essentiële stap in de cyclus van kwetsbaarheidsbeheer, gericht op het verbeteren van de beveiliging van uw systemen. Met hulp van penetratietesters bij QAwerk kunt u geavanceerde bedreigingen met gemak en snelheid afslaan.

Wij zijn er om uw netwerken, servers en applicaties te doorzoeken om hackingkwetsbaarheden te vinden, analyseren en rapporteren. Onze deskundige testers voeren black-, gray- en white-box pen tests uit om beveiligingsfouten bloot te leggen. Met onze brede expertise kunnen we zelfs de meest ongrijpbare kwetsbaarheden identificeren.

Afsluiting

SSRF-kwetsbaarheden kunnen onverwacht optreden en de beveiliging van uw bedrijf in gevaar brengen. Om te voorkomen dat dit gebeurt, moet er regelmatig penetratietesten worden uitgevoerd. Dit zal het voor dreigingsactoren die proberen uw systemen binnen te dringen, moeilijker maken.

Penetratietesten is een proactief proces dat niet verwaarloosd mag worden. Houd dit in gedachten en blijf veilig met QAwerk!