Kritieke PHP-lekken: wat er aan de hand is en wat je nu moet doen

Dinsdagavond 20 oktober kondigde het beveiligingsteam van PHP twee kritieke lekken aan. Woensdagochtend volgde een waarschuwing van de Europese cybersecuritydienst CERT-EU, en inmiddels gaan in heel Europa websites uit voorzorg offline. Ook in Nederland.

Omdat het nieuws snel gaat en lang niet iedereen weet of hij zelf geraakt wordt, zetten we hier op een rij wat er speelt, wie risico loopt en wat je nu moet doen.

Wat is er aan de hand?

PHP is een programmeertaal die op de server draait en webpagina's opbouwt. Ongeveer 70 procent van alle websites draait erop, direct of via systemen als WordPress, Drupal en veel webshop-software. "Het halve internet draait hierop", zei securityexpert Daan Keuper woensdag tegen NU.nl.

In PHP zijn twee lekken gevonden die allebei een score van 9,2 op 10 krijgen op de internationale ernst-schaal (CVSS). Het gaat om zogeheten remote code execution: een aanvaller kan van buitenaf eigen code uitvoeren op je server. Daarvoor is geen wachtwoord nodig en geen fout van een medewerker. Een server die bereikbaar is via internet is genoeg.

Wie zo binnenkomt, heeft volledige toegang tot het systeem en alle data erin. Denk aan klantgegevens, bestellingen en prijsafspraken, maar ook aan een site die bezoekers doorstuurt naar een nep-betaalpagina, of ransomware die alles versleutelt.

De tijdlijn

• Dinsdagavond 20 oktober: PHP kondigt twee kritieke lekken aan en meldt dat de update woensdag om 16.00 uur verschijnt. Details over het lek lekken kort daarna uit.
• Woensdagochtend 21 oktober: CERT-EU adviseert organisaties om klaar te staan voor direct updaten, en internetgerichte applicaties uit te zetten als dat niet lukt. Cloudflare meldt de eerste aanvallen en past tijdelijk zijn firewallregels aan.
• Woensdag in de loop van de dag: in Nederland gaat onder meer NotuBiz offline, de dienst waarmee gemeenten, provincies en waterschappen hun raadsinformatie publiceren (BNR).
• Woensdag 16.00 uur: PHP publiceert de beveiligingsupdate.

Waarom het na de update niet voorbij is

Je zou denken: om vier uur komt de oplossing, klaar. Het omgekeerde is waar. Zodra de update online staat, kunnen criminelen precies zien waar het lek zat en daar een aanvalsscript voor schrijven. Daarna scannen ze het hele internet af op servers die nog niet zijn bijgewerkt.

Vroeger duurde het dagen voordat zo'n script er was. "Tegenwoordig hebben we het vanwege de nieuwe AI-tools zeker niet meer over dagen, eerder over uren", aldus Keuper. Je hoeft dus geen doelwit te zijn om getroffen te worden. Je moet alleen kwetsbaar zijn. Wie woensdagavond nog niet heeft bijgewerkt, loopt direct achter.

Loop jij risico?

Dat hangt af van hoe je website of systeem is ingericht.

• WordPress of een standaard webshop bij een hostingpartij. Je draait vrijwel zeker op PHP. De hostingpartij moet PHP op de server bijwerken. Vraag na of en wanneer dat gebeurt.
• Maatwerk-software, een portaal of een interne tool. Grote kans dat dit in PHP gebouwd is, bijvoorbeeld met Laravel of Symfony. Je leverancier moet de update doorvoeren en controleren of alles daarna goed blijft werken.
• Een eigen server of VPS. Dan ben je zelf verantwoordelijk. Werk PHP bij zodra de update er is.
• Een oudere PHP-versie. Dit is het grootste risico. PHP 8.1 en ouder krijgt geen beveiligingsupdates meer. Voor die versies komt er geen oplossing, ook niet om 16.00 uur.

Twijfel je welke versie je draait? Je leverancier of hostingpartij kan dat in een paar minuten vertellen.

Wat als je op een verouderde versie draait?

Dan is de patch van vandaag geen oplossing voor jou. Wat overblijft is afschermen en extra lagen ervoor zetten, tot de onderliggende PHP-versie is bijgewerkt. Dat bijwerken is meestal geen kwestie van een knop omzetten, want oudere code moet vaak worden aangepast om op een nieuwe versie te draaien.

Het is daarom de les van deze week. Software die werkt is niet hetzelfde als software die veilig is. Een systeem dat al jaren zonder klachten draait, kan tegelijk een open deur zijn die alleen nog niemand had gevonden.

Hoe wij het bij onze klanten aanpakken

Nog dezelfde dinsdagavond ging per klant een mail de deur uit: welk systeem draait op PHP, hoe groot is het risico, wat stellen we voor en wie is je aanspreekpunt. Woensdagochtend vroeg zijn interne systemen en beheeromgevingen afgeschermd. Op publieke sites blokkeren we de verzoeken waarlangs het lek volgens de eerste analyses misbruikt wordt, en we testen zelf de bekende aanvalsscenario's om te zien of de maatregelen echt houden.

Een site helemaal offline halen doen we alleen na overleg. Voor een webshop betekent dat een dag geen bestellingen, en die afweging hoort bij de klant. Bij een aantal klanten kon de site online blijven, bij anderen was tijdelijk afschermen verstandiger. Ook onze eigen formulieren op skrepr.com staan tijdelijk dicht. Liever een dag geen formulier dan een open deur.

Even meekijken?

Twijfel je over jouw site?

Bel of mail ons. We kijken met je mee, ook als je geen klant bent.

Bel Skrepr, 0527 70 10 15 Mail info@skrepr.com