PHP2Shell, de kritieke combinatie van twee RCE-kwetsbaarheden in PHP die eind oktober wereldwijd overheidssites en webshops liet uitvallen, laat volgens beveiligingsbedrijf Token Security vooral zien dat een CVSS-score maar een deel van het verhaal vertelt. Lees hier het eerdere artikel over PHP2Shell. Volgens Token Security draait het na een aanval vooral om de vraag wat een aanvaller vervolgens kan bereiken, en dat hangt niet af van de kwetsbaarheid zelf maar van welke service-accounts, API-sleutels, cloudrollen en tokens een gecompromitteerd systeem kan gebruiken.
De twee PHP-lekken zaten al sinds 2012 in de code en werden in augustus ontdekt, deels met hulp van AI-modellen. Amazon zag op 17 oktober, vier dagen voor de openbaarmaking, al een eerste exploitatiepoging. Op 21 oktober kwam de patch, en volgens beveiligingsbedrijf watchTowr waren er diezelfde dag al aanvalspogingen te zien. Op 26 oktober voegde CISA beide kwetsbaarheden toe aan de lijst van actief misbruikte lekken. Censys telde op 27 oktober 32,5 miljoen internet-gerichte PHP-diensten met mogelijk kwetsbare versies, plus nog eens ruim 60 miljoen diensten waarvan de versie onbekend is.
Dat tempo staat in schril contrast met hoe snel organisaties doorgaans patchen. Volgens het Data Breach Investigations Report van Verizon duurt het gemiddeld 43 dagen om een actief misbruikte kwetsbaarheid te verhelpen. Qualys komt op een gemiddelde van 21,2 dagen en meldt dat 63 procent van de kritieke kwetsbaarheden na een week nog openstaat. Veel PHP-installaties zitten daarbij verstopt in firmware van appliances en hostingpanelen waar klanten niet zelf bij kunnen, en oudere versies vanaf 8.1 krijgen geen officiële patches meer.
Token Security wijst erop dat een shell op een PHP-server toegang geeft tot alles wat die server zelf kan lezen, zoals omgevingsvariabelen en cloudsleutels in configuratiebestanden, en dat het geheugen van PHP-workers vaak ook wachtwoorden en tokens bevat. Als voorbeeld noemt het bedrijf het eerdere LiteLLM-incident, waarbij een per ongeluk op een publieke coderepository beland masterkey leidde tot een token met onbeperkte rechten, waarmee aanvallers de release-workflow konden manipuleren.
Het advies is daarom niet alleen te patchen, maar ook te inventariseren welke AI-agents, service-accounts en andere niet-menselijke identiteiten toegang hebben, daar een eigenaar aan te koppelen, inactieve toegang te verwijderen en nieuwe toegang zo veel mogelijk te baseren op het concrete doel van een identiteit. Patchen bepaalt hoe snel een gat dichtgaat, toegangsbeheer bepaalt hoeveel een aanvaller daarbinnen nog kan doen.
Voor Nederlandse mkb-bedrijven die zelf PHP-applicaties draaien, is de praktische les dat een overzicht van wie en wat toegang heeft tot API-sleutels en serviceaccounts net zo belangrijk is als de patchstatus van de software zelf. Wie dat overzicht niet heeft, dicht wel het gat maar blijft gokken over de schade zodra een volgende kwetsbaarheid te laat wordt opgemerkt.
Bron: BleepingComputer (Token Security)
Blijf op de hoogte
Meld je aan voor de nieuwsbrief: spoedalerts bij kritieke dreigingen en een wekelijks overzicht. Geen mail achterlaten? Volg ons dan via RSS.