Web cache deception: een niet te stoppen gevaar?

Voor het optimaliseren van websiteperformance wordt caching ingezet om statische inhoud zo efficiënt mogelijk aan te leveren. Hackers hebben echter een interessante manier gevonden om dit te misbruiken in de vorm van aanvallen genaamd web cache deception. 

Bij een aanvraag van je browser naar een website stuurt je browser verschillende HTTP-verzoeken naar een webserver. Een HTTP-bericht maakt in de meeste gevallen een reis door contentdelivery-netwerken (CDN) om zijn bestemming te bereiken, vanuit zijn oorsprong langs ontelbare proxies die verspreid zijn op weg naar zijn doel. Wanneer het uiteindelijk aankomt, levert het zijn informatie af en stuurt de server een HTTP-response onmiddellijk terug richting je browser. 

Een CDN is geschikt om statische bestanden over te brengen die nodig zijn voor het laden van internetcontent waaronder: HTML-pagina's, JavaScript-bestanden, stylesheets, afbeeldingen en video’s. Deze kan een CDN in een cache lokaal opslaan zodat het later weer snel alles kan aanvragen. Dit verbetert de prestaties van een website omdat het je de mogelijkheid biedt om inhoud aan de rand van het netwerk, dichtst bij de gebruiker, te cachen. Daarnaast helpt het in sommige gevallen ook websites te beveiligen tegen bijvoorbeeld DDoS-aanvallen. Om prestatie- en veiligheidsredenen zijn de meeste websites dus geneigd om voor CDN's te kiezen. Het grootste deel van het webverkeer wordt nu bediend via CDN's, inclusief verkeer van grote sites als Amazon, Netflix en Facebook.

Snelkoppelingen voor gegevenstoegang via caching op CDN’s zijn dus eigenlijk deel van de standaardomgeving van het internet. Voor de veiligheid mogen de gegevens natuurlijk in het cachegeheugen geen persoonlijke of gevoelige informatie bevatten. Cachingservers zouden dus alleen openbare, statische inhoud op moeten slaan - zoals afbeeldingen, CSS-bestanden en PDF-documenten - die niet gebruikersspecifiek zijn. Wanneer er miscommunicatie ontstaat tussen wat wel en niet gecachet mag worden is de webserver via de CDN kwetsbaar voor web cache deception. 

Wat is web cache deception?

Het fenomeen web cache deception is al een tijdje aan de gang. Zoals hierboven beschreven, verwijst ‘web cache’ naar technologieën waarbij veelgebruikte inhoud tijdelijk wordt opgeslagen om latere server aanvragen efficiënter te bedienen. Een 'typische' web cache deception aanval maakt hier op de volgende manier misbruik van:

1. Een aanvaller zoekt een dynamische, niet-cachebare webpagina op die zeer gevoelige informatie bevat. Dit kan bijvoorbeeld een instellingenpagina of winkelmandje zijn van een webshop. Laten we een voorbeeld verzinnen: een internationale webshop https://www.victim.com die gebruikmaakt van een CDN.
2. De aanvaller kiest de gewenste link, laten we het https://www.victim.com/cart noemen. Normaal gesproken is deze link toegankelijk voor het slachtoffer via een HTTP-bericht zoals GET /cart HTTP/1.1.
3. Deze link bevat gevoelige informatie en kan grotendeels niet gecachet worden - dus geen caching in ‘CDN-servers.’ 
4. De aanvaller wil dat de CDN-server toch een kopie van de pagina cachet. Een ‘suffix’ of achtervoegsel is dus toegevoegd aan het pad: /cart/deception.jpg zodat het voor de CDN op een statisch niet-gevoelige pagina lijkt (vanwege de extensie .jpg).
5. De aanvaller laat het slachtoffer de 'nieuwe' link https://www.victim.com/cart/deception.jpg bezoeken. De meest voorkomende vorm is veruit een call to action via een e-mail (phishing scam).
6. Als het slachtoffer op de link klikt, die nog niet gecachet is door de CDN, wordt er een response gedaan vanaf de webserver en worden ze naar hun cart gebracht. De CDN denkt echter dat de .jpg-extensie cachebaar is en dus is de sensitieve informatie van de gebruikers nu voor iedereen met de juiste link beschikbaar op de CDN-server.
7. Daarna hoeft de aanvaller alleen nog maar een GET-aanvraag voor de vervalste URL cart/deception.jpg naar de CDN-server te sturen en een kopie van de gecachete gegevens te ontvangen. De aanvaller ziet dus precies dezelfde informatie als het slachtoffer.

Belangrijk om te weten: de meeste websites zijn zo geconfigureerd dat ze flexibel zijn wat betreft de paden die ze behandelen en dus kunnen ze een verzoek voor het niet-bestaande pad cart/deception.jpg behandelen als gelijkwaardig aan een verzoek voor /cart. (In een webframework komt de expressie ^/cart/ overeen met zowel /cart/ als /cart/deception.jpg.) Hierdoor kan je een webserver laten denken dat er zich op een bestaande pagina een cachebaar element bevindt waardoor het proces van caching op de CDN-server in gang treedt.

Hoe groot is dit probleem?

Caches zijn een essentieel onderdeel van de internetinfrastructuur geworden. Zonder deze techniek zou het internetverkeer niet op zijn huidige schaal geleverd kunnen worden. Sinds 2017 maken steeds meer aanvallen gebruik van deze afhankelijkheid om kwetsbaarheden te misbruiken. Sterker nog: uit recent academisch onderzoek is gebleken dat 25 websites van de Alexa Top 5000 aanzienlijk worden geraakt door web cache deception.

Dit aantal lijkt misschien geen reden tot zorgen, maar wie het onderzoek nader bekijkt, ziet dat er meer achter deze cijfers schuilt. Ten eerste heeft het onderzoek op websites in de Alexa-ranglijst slechts 295 en vervolgens 340 websites uit de Top 5000-lijst getest. Het gaat dus niet om 25 van de 5000 websites, maar 25 van de 340 – een veel zorgelijker aantal. Bovendien is het gebruikersbestand van deze websites gigantisch, waardoor aanvallers potentieel toegang kunnen krijgen tot miljoenen persoonsgegevens van gebruikers.

Dit is uiteraard geen verwaarloosbaar risico. Gevoelige gegevens kunnen worden gebruikt voor fraude, chantage, identiteitsdiefstal en nog veel meer. En de lijst slachtoffers van deze vorm van cybercrime groeit elk jaar weer. Er is geen inschatting gemaakt van de totale economische kosten van web cache deception, maar zeker is dat het een forse bijdrage levert aan de schade die tot nu toe veroorzaakt wordt door cybercriminaliteit, in 2021 naar verwachting een cumulatieve 6 biljoen dollar.

Wat kunnen we eraan doen?

Het antwoord daarop is nog niet helemaal duidelijk. Web cache deception is uiteraard een veiligheidsprobleem dat niet uit zichzelf verholpen wordt. Uit onderzoek blijkt dat veel websites het moeilijk vinden om dit soort kwetsbaarheden aan te pakken. Aanvallen zijn zeer eenvoudig om op te zetten, door gebruik te maken van kwetsbaarheden die veel voorkomen en die gemakkelijk toegankelijk zijn. Tegelijkertijd zijn deze kwetsbaarheden zeer moeilijk te beveiligen, met name omdat er niet maar één verantwoordelijke aan te wijzen valt. Dat vraagt enige uitleg, want er moet toch iemand verantwoordelijk zijn voor de aanwezigheid van kwetsbaarheden?

Niet precies. Neem bijvoorbeeld het geval van ons fictieve slachtoffer https://www.victim.com/cart. In isolatie is de server hier niet verantwoordelijk, omdat hij zijn beoogde functie prima vervult. Ook de techniek van web caching, op zichzelf, is niet fundamenteel gebrekkig of kapot. Die vervult gewoon zijn beoogde functie. Wat fout gaat, is dat meer dan één variatie van hetzelfde verzoek wordt verwerkt. Dit leidt tot conflicten en dus tot mogelijkheden voor misbruik. Dit is goed te zien als je het hele proces opdeelt in stappen, zoals in het stappenplan hierboven is gedaan. 

Een vanzelfsprekende manier om de risico als website-eigenaar van https://www.victim.com direct te verminderen is ervoor te zorgen dat de website niet zo flexibel is met paden die niet bestaan. Dit zou betekenen dat /cart/ niet gelijk moet zijn aan /cart/deceptie.jpg. In plaats daarvan zouden bezoekers van de tweede bestemming eenvoudigweg worden doorgestuurd naar een foutpagina of een echte pagina. Je zou ook cache-instellingen kunnen veranderen zodat bepaalde informatie niet gecachet wordt. Verschillende hostingproviders staan wijzigingen toe in de regels over wat wel en niet gecachet mag worden. 

Dat is makkelijker gezegd dan gedaan omdat je wel data moet kunnen cachen en omdat er ontelbare variaties aan paden bestaan. Voor velen is het dus een afweging tussen performance en security. Idealiter zou je alleen cachen in situaties met statische content. Dit kan je bereiken met een reusachtige lijst met uitzonderingen en het black- of whitelisten van bepaalde informatie. Met dataveiligheid als enige prioriteit zou een whitelist de meest logische stap zijn omdat je veel selectiever informatie kan kiezen wat gecachet dient worden. Het zou dan wel enorm veel tijd en moeite kosten om zo’n lijst te onderhouden. Ook moeten websites wel nog steeds snel kunnen laden en zijn dus veel systemen meer flexibel. Het doel van een CDN is bijvoorbeeld om snel data te leveren aan gebruikers. Veel webeigenaars kunnen dus niet alle deuren dichttrekken, maar moeten een overweging maken tussen de veiligheid van hun gebruikers en de gebruikelijkheid van hun website. Dit vraagt voor een veel genuanceerdere en systeembrede aanpak.

Kunnen we nog meer doen? De individuele elementen zijn immers niet inherent defect of onveilig. Het is van essentieel belang om te begrijpen dat de interacties tussen bijvoorbeeld de CDN-server en de webserver zelf potentieel gevaar kunnen opleveren, om bescherming tegen web cache deception te kunnen ontwikkelen. Hoe de webserver zelf bepaalt of iets wel of niet gecachet kan worden moet overeenkomen met hoe dat op de CDN-server wordt geregeld. Deze conclusie leent zich helaas niet voor snelle oplossingen. Software is niet kapot, dus een patch kan het niet fixen. Producten hebben niet gefaald en kunnen dus niet worden vervangen. 

Toch is er ook goed nieuws. Algemene best practices voor ‘assetmanagement’ en een beter overzicht van hoe je website omgaat met webverkeer zijn namelijk al flinke stappen voorwaarts om kwetsbaarheden en risico’s te verminderen. Het automatisch detecteren van kwetsbaarheden veroorzaakt door de interacties van verschillende componenten in een digitaal ecosysteem wordt momenteel uitvoerig onderzocht, dus als we nu niet alle antwoorden hebben, komen er hopelijk meer in zicht en kunnen we in de toekomst dit hele probleem wegschrijven.