Waarom we de websites van bijna al onze klanten even offline haalden

Op 21 oktober verdween de ene na de andere bekende website uit de lucht, van DigiD en de Tweede Kamer tot gemeenten en ziekenhuizen. Zelfs het Nationaal Cyber Security Centrum toonde alleen nog een melding. Nergens was een hack vastgesteld. Toch zetten al die organisaties zichzelf uit. Zolang er geen update was, kon in principe iedere website die op PHP draait worden overgenomen, en dan is een paar uur onbereikbaar zijn het kleinere risico. Wij maakten dezelfde afweging. We belden al onze klanten met de vraag of we hun site tijdelijk uit de lucht mochten halen. Vrijwel iedereen zei meteen ja.

Bijna driekwart van alle websites draait op PHP, ook veel van wat wij bouwen. Bezoekers zien het nooit: het zit onder een website zoals een fundering onder een huis.

In die fundering zaten twee fouten, inmiddels bekend als php2shell. Wie ze wist te misbruiken, kon zonder fysieke toegang een webserver overnemen. De fouten waren zo ingewikkeld dat bijna niemand er een werkende aanval van kon maken. Daardoor zag ook niemand hoe ernstig ze waren, en bleef een oplossing uit.

Dat de fouten dit jaar toch werden gevonden, komt door AI. In augustus stuitten twee beveiligingsbedrijven er los van elkaar op, allebei met hulp van AI-modellen die de broncode van PHP doorzochten. Waar zo'n fout eerder alleen door een handvol specialisten te doorgronden was, deed AI nu een groot deel van het zoekwerk.

Volgens de onderzoekers verandert AI daarmee de economie van het hacken. Een lek dat vroeger te ingewikkeld was om te misbruiken, wordt nu een reëel doelwit: AI kan een aanval aanpassen aan verschillende PHP-versies en instellingen, en neemt veel van het specialistische werk over. Dat geldt voor onderzoekers die zo'n lek netjes melden, en net zo goed voor aanvallers die dat niet doen.

Op 20 oktober, nog voor de geplande bekendmaking, lekte het nieuws over php2shell uit. PHP haalde de oplossing naar voren, naar 21 oktober. Achteraf bleek dat Amazon al op 17 oktober een eerste aanvalspoging had gezien. Iemand kende het lek dus al eerder; daarom lopen we onze logs na tot die datum.

Voor ons was de afweging eenvoudig. Een site die een paar uur een onderhoudspagina toont, kost bezoekers. Een site die wordt overgenomen, kan gegevens, reputatie en weken herstelwerk kosten. Ook het Nationaal Cyber Security Centrum adviseerde om systemen zo nodig offline te halen.

Waar we de hosting zelf beheren, stonden de sites snel offline, met een melding voor bezoekers. Bij externe hostingpartijen duurde het soms langer; zij hadden het die dag net zo druk. Zodra om 15:43 de patches verschenen, hebben we de sites een voor een bijgewerkt en teruggezet. Ook dan belden we elke klant, zodra hun site weer veilig online stond. Op zo'n dag is duidelijke communicatie net zo belangrijk als de techniek: klanten moeten weten wat er gebeurt, waarom, en wanneer het voorbij is.

Rond 23:00 stonden vrijwel alle sites weer online. Voor de meeste duurde de onderbreking tweeënhalf tot negen uur. De laatste klant koos er bewust voor om extra voorzichtig te zijn en ging de volgende ochtend om 7:30 weer live.

Dat het lek in PHP zat, zegt weinig over PHP zelf. Java, JavaScript en .NET hadden de afgelopen jaren allemaal vergelijkbare lekken, waarna wereldwijd met spoed updates moesten worden geïnstalleerd.

Dat PHP wordt geraakt, komt onder andere doordat het zo veel gebruikt wordt: hoe meer websites op een taal draaien, hoe meer onderzoekers en aanvallers ernaar kijken. Het is een volwassen taal die actief wordt onderhouden; een dag nadat het nieuws naar buiten kwam, lag er een oplossing. Wat telt, is hoe snel je kunt bijwerken als het misgaat.

Een incident als dit laat zien hoe het internet in elkaar zit: een keten waarin iedere schakel op andere leunt. Ook onze leveranciers draaien op PHP en moesten hun eigen systemen deels uitzetten.

We gaan onze afhankelijkheid van die keten verder verkleinen. We schrijven een draaiboek om sites snel offline te halen, zorgen dat alle sites op een ondersteunde PHP-versie draaien en maken met leveranciers afspraken over spoedupdates.

Er zit een ongemakkelijke kant aan dit verhaal: dezelfde AI waarmee we sneller bouwen, maakt aanvallen makkelijker. Spoedupdates als deze zullen daardoor vaker nodig zijn.

De vragen die er op 21 oktober toe deden, kon geen model beantwoorden. Welke klant draait op welke server? Welke hostingpartij bellen we? Daarvoor waren mensen nodig die de systemen kennen en binnen een paar uur een afweging durven te maken.

Met AI wordt bouwen makkelijker, een platform veilig houden niet. Zulke momenten zullen vaker komen, en dan heb je een partner nodig die je platform kent. Dat blijft het werk van een bureau, en het blijft mensenwerk.