Please Help, Panic!

PHP or Please Help Panic?!

Afgelopen woensdag ging digitaal Nederland en Vlaanderen op een gekke manier uit de lucht. DigiD, MijnOverheid en de Tweede Kamer gingen uit voorzorg offline. In Vlaanderen waren enkele websites van de Vlaamse overheid, Antwerpse en Limburgse ziekenhuizen en het schoolplatform Smartschool tijdelijk onbereikbaar. De ochtend nadien lagen onder meer FOD Financiën, de stadsbesturen van Gent en Brussel en het CCB zelf er nog steeds uit. Aan de overkant van de grens was NCSC.NL tijdelijk offline gehaald.

Het waren geen aanvallen. Het waren overheden die hun eigen etalage dichtgooiden. Mijn standpunt is dat we dit niet als een geslaagde noodstop moeten vieren. Het is de test die laat zien wat we, aan beide kanten van de grens, nog niet hebben.

Je kunt niet patchen wat je niet kent

De eerste vraag was niet hoe we patchen. De eerste vraag was waar we moesten patchen. Het CCB raadde aan om elke PHP-installatie te inventariseren, ook PHP die in leveranciersapparatuur, Windows-software en controlepanelen als cPanel en Plesk zit. Dat is geen technische tip. Het is een erkenning dat PHP in dingen zit die je nooit als "PHP" hebt geregistreerd.

Wie die lijst niet had, begon woensdagochtend aan een speurtocht, terwijl de klok tikte. Daar komt bij dat een update van je website of plugins niets oplost: het lek zit in PHP zelf, dus je moet de server of je hostingpartij laten bijwerken. En wie PHP 8.1 of ouder draait, heeft geen officiële fix.

Niemand krijgt een prijs voor een bijgewerkte inventaris. Tot er een lek in PHP opduikt en iedereen vraagt: waar draait het?

Waar zit de uit-knop?

Offline halen is een goed advies, maar alleen als je het kunt. Het CCB-advies sprak dan ook van "Patch Immediately or take offline!" Dat veronderstelt een knop, iemand die hem mag bedienen, en een afspraak over wat eerst uitgaat.

In een keten van leveranciers, hosters en onderaannemers is dat vaak onduidelijk. Het verschil tussen een organisatie die in een uur besliste en een die dagenlang discussieerde, zat niet in techniek. Het zat in wie vooraf had nagedacht over de afweging: wat kost een dag offline, en wat kost een overgenomen server?

Wanneer geef je preventief advies?

Het NCSC-advies kwam op een moment dat er een publieke proof of concept beschikbaar was, maar nog geen actief misbruik werd gesignaleerd. Ik vind dat het advies toen terecht was, om drie redenen.

De details waren al uitgelekt. Het bestaan van de lekken kwam twee dagen voor de geplande bekendmaking naar buiten, en daarmee verdween de voorsprong van de verdediger.

Er was ook geen tussenstap. Een PHP-kernontwikkelaar stelde dat patchen of upgraden de enige mitigatie was. Als je niet kunt patchen, blijft er één maatregel over, en dat is uitzetten.

Tot slot weegt een uur offline niet op tegen het risico dat het NCSC omschreef als een "zeer hoog risico op volledige overname van het systeem".

Preventief adviseren betekent dat je achteraf mogelijk te veel gedaan hebt. Dat is de prijs. Je kunt een voorkomen inbraak nooit bewijzen.

Waarom kunnen we dit niet verplichten?

In beide landen was dit advies, geen bevel. Het CCB raadde aan om de website offline te halen als je de update niet meteen kon installeren. Het NCSC adviseerde om voorbereidingen te treffen. Elke organisatie besliste zelf.

Voor Vlaamse en lokale overheden betekent dat dat een kleine gemeente met één ICT'er hetzelfde advies kreeg als een groot departement, en ermee deed wat ze kon. Een verplichting vraagt drie dingen die we nu niet hebben:

• Zicht. Wat draait waar, bij wie, op welke versie?
• Een kanaal. Wie bereiken we, en lukt dat binnen uren?
• Een grondslag. Wat is de verplichting, en wie draait op voor het niet nakomen ervan?

Daarom hoort een verplichting om bij zo'n crisis binnen een afgesproken tijd te handelen, met een centraal aanspreekpunt en rapportering, thuis in het decreet. Een crisis is geen moment om te onderhandelen over wie waarvoor verantwoordelijk is.

De patch is geen einde

Het gevaarlijkste misverstand is dat patchen gelijkstaat aan opgelost. Een patch sluit de voordeur. Hij vertelt je niet of iemand al binnen was.

Het wordt erger. Een patch geeft zelf aanwijzingen over welke kwetsbaarheid hij dicht, en dus gaan aanvallers het nu per direct gericht proberen. De eerste signalen kwamen snel: het NCSC onderzocht eerste signalen van misbruik, en een Nederlandse nieuwsbrief meldde dat er wereldwijd ruim 22,6 miljoen potentieel kwetsbare instanties zijn. Op het moment van schrijven is er volgens het NCSC nog geen sprake van succesvol misbruik, en het CCB meldt geen incidenten in België. Dat is goed nieuws, maar het is een momentopname. Experts waarschuwen dat het lek ook na de patch nog maanden gevolgen heeft.

Wie vóór de patch binnenkwam, heeft zijn voet tussen de deur gezet: een webshell, een extra account, een geplande taak. Daarmee komt hij later rustig terug, kijkt rond en haalt data weg. Jouw gepatchte voordeur is dan irrelevant.

Na het patchen begint dus het echte werk:

• Ga ervan uit dat systemen die vóór de patch blootstonden, mogelijk gecompromitteerd zijn.
• Zoek naar bestanden die er niet horen, nieuwe accounts, afwijkend uitgaand verkeer en wijzigingen in de weken ervoor.
• Bewaar je logs. Zonder logs kun je niet bewijzen dat er niets gebeurd is.
• Wissel geheimen die op die servers stonden: databasewachtwoorden, API-sleutels, tokens.

Dat is ook een communicatievraag. "We hebben gepatcht" is een onvolledige boodschap. De eerlijke versie is: "We hebben gepatcht, en we onderzoeken of er al iemand binnen was."

Conclusie

PHP Please Help, Panic! laat zien wat we, in Vlaanderen en in Nederland, nodig hebben:

• Actueel overzicht van wat we draaien, bij wie en op welke versie.
• Uit-knop met een eigenaar, en vooraf afgesproken volgorde van wat eerst uitgaat.
• Afgesproken afweging voor wanneer we preventief ingrijpen, ook zonder bewezen misbruik.
• Grondslag om dit bij Vlaamse en lokale besturen af te dwingen. Zonder verplichting blijft het hopen dat iedereen meedoet.
• Nazorg na de patch: nagaan of iemand al binnen was, logs bewaren en geheimen wisselen.