Als u afgelopen week probeerde in te loggen bij MijnOverheid of DigiD, kreeg u mogelijk nul op het rekest. Ook RTL Nieuws en de website van de Tweede Kamer waren tijdelijk onbereikbaar. Dat was geen storing en geen aanval op die organisaties zelf: het was een bewuste keuze, genomen onder tijdsdruk.
De aanleiding was een kritiek lek in PHP, de programmeertaal waar een groot deel van alle websites en webapplicaties op draait. Denk aan WordPress, Drupal, Moodle, webshops en veel maatwerkapplicaties. Het lek, dat inmiddels de bijnaam PHP2Shell heeft gekregen, maakte het mogelijk om zonder in te loggen code uit te voeren op een kwetsbare webserver. Twee kwetsbaarheden, allebei met een ernstscore van 9,2 op een schaal van 10. De NOS legde goed uit hoe zoveel sites in één klap plat konden gaan.
Waarom dit lek anders was dan de meeste
Bij een normale kwetsbaarheid verschijnt eerst de oplossing en daarna pas de details. U heeft dan tijd om bij te werken voordat iemand weet wat hij moet aanvallen. Hier liep die volgorde volledig in de war, en het is leerzaam om te zien hoe. Tweakers heeft de gebeurtenissen op een rij gezet. Samengevat:
Dinsdag 20 oktober, in de middag. De twee CVE-codes duiken op in een bericht op Hacker News, nog zonder technische details. De afgesproken publicatiedatum was op dat moment donderdag 22 oktober, 16.00 uur.
Dinsdag 20 oktober, ‘s avonds. De PHP Foundation doet een vooraankondiging om verkeerde informatie voor te zijn, en vervroegt de release met een dag naar woensdag 16.00 uur. Kort daarna zet een van de beveiligingsbedrijven een video online waarin te zien is dat het werkt. Die video gaat weer offline, maar is dan al gekopieerd en gaat rond.
Woensdag 21 oktober, in de ochtend. Een bedrijf dat kant-en-klare PHP-pakketten maakt, publiceert de reparatie ruim zes uur voor het afgesproken moment. Daarmee kon iedereen aan de gerepareerde code aflezen waar het lek precies zat, terwijl de rest van internet nog niets had om te installeren. De PHP Foundation sprak van een eenzijdige schending van het embargo waarmee weken werk van vele partijen teniet werd gedaan.
Woensdag 21 oktober, rond het middaguur. Organisaties staan voor de keuze: online blijven en risico lopen, of uit voorzorg offline gaan. Tweakers zelf ging om 12.22 uur uit de lucht. DigiD, MijnOverheid, RTL Nieuws en de Tweede Kamer kozen dezelfde route.
Woensdag 21 oktober, 15.45 uur. De patch komt uit.
Daar zit de kern. Een halve dag lang was wél bekend waar het lek zat, maar viel er nog niets te installeren. In zo’n venster bestaat er geen technische oplossing. Het enige wat u dan heeft is een beslissing: zet u het kwetsbare systeem uit of niet. Dat DigiD en de Tweede Kamer offline gingen was dus geen paniek, het was de enige maatregel die in dat tijdsbestek werkte.
Dat dit geen theoretisch risico bleef, bevestigde het Nationaal Cyber Security Centrum donderdag. Het ziet actieve pogingen tot misbruik en ontvangt signalen van organisaties waar dat mogelijk is gelukt.
Wat wij hebben gedaan
Woensdagochtend 21 oktober, in datzelfde venster. Wij hebben alle klanten met een door ons beheerde webserver persoonlijk benaderd en per server bepaald wat verstandig was: helemaal afsluiten voor de buitenwereld, of beperken tot bekende adressen. Dat is een afweging die per klant anders uitvalt. Een webshop afsluiten kost omzet, een interne applicatie afsluiten kost niemand iets. Die afweging kunt u alleen maken als u weet wat er op elke server draait en wie ervan afhankelijk is.
Woensdagmiddag, zodra de reparatie er om 15.45 uur was. Getest en dezelfde middag uitgerold. Draaide een applicatie op een oudere PHP-versie die geen reparatie meer krijgt, dan is die afgeschermd gebleven en hebben wij in overleg met de klant naar een oplossing gezocht.
Donderdag, de controle achteraf. Updaten is niet hetzelfde als veilig zijn. Als iemand in het tijdvak daarvoor binnen is geweest, dan dicht u met die update alleen de voordeur, terwijl hij misschien al een sleutel heeft laten liggen. Daarom hebben wij elke beheerde webserver nagelopen op sporen van misbruik.
Wat zo’n controle precies inhoudt
Voor die controle hebben wij een eigen script geschreven dat op elke beheerde server hetzelfde rondje loopt. Handmatig is dat op tientallen servers niet vol te houden, en erger nog: handmatig slaat u bij server nummer twintig net dat ene ding over.
Het script kijkt naar de dingen die een aanvaller achterlaat, ook als hij zijn best doet om netjes te zijn:
Gebruikersaccounts. Nieuwe accounts op de server, accounts die plotseling meer rechten hebben gekregen, of accounts die mogen inloggen terwijl dat nooit de bedoeling was. Een aanvaller die ergens binnenkomt, wil vooral terug kunnen komen als het gat gedicht is. Een extra account is daarvoor de eenvoudigste manier.
Toegangssleutels. Bijgeplaatste SSH-sleutels waarmee iemand zonder wachtwoord binnenkomt, en wijzigingen in wie er op afstand mag inloggen.
Geplande taken. Opdrachten die de server zelf periodiek uitvoert. Een regel die elke nacht om drie uur iets ophaalt van een onbekend adres valt niemand op, tenzij u er gericht naar zoekt.
Bestandswijzigingen. Welke bestanden zijn er gewijzigd in de periode dat het lek open stond, en horen die wijzigingen ergens bij? Een webmap waarin precies in dat tijdvak één nieuw bestandje verscheen is een ander verhaal dan een map die niemand heeft aangeraakt.
Lopende processen en netwerkverbindingen. Draait er iets wat er niet hoort te draaien, en praat de server met adressen waar hij niets te zoeken heeft?
Logbestanden. Niet alleen wat erin staat, maar ook of er iets uit verdwenen is. Een gat in een logboek is op zichzelf een bevinding.
De uitkomst: bij geen van onze klanten zijn aanwijzingen voor misbruik gevonden. Daar hoort een eerlijke kanttekening bij. Volledige zekerheid is bij dit type lek door niemand te geven, ook niet door ons. Wat te controleren was, is gecontroleerd, en dat is wat wij kunnen beloven.
Waarom onze eigen website gewoon online bleef
Een terechte vraag: wij haalden bij klanten servers uit de lucht, maar www.rayflex.com bleef gewoon bereikbaar. Is dat dan niet met twee maten meten?
Nee, en het verschil is leerzaam.
Onze site is volledig statisch. Dat betekent dat alle pagina’s van tevoren zijn klaargezet als gewone bestanden. Vraagt u een pagina op, dan stuurt de server dat bestand toe, meer niet. Er wordt geen enkele regel code uitgevoerd om die pagina samen te stellen, en er is geen database die bevraagd wordt. Voor het tonen van onze website speelt PHP simpelweg geen rol.
Bij een website op WordPress of een vergelijkbaar systeem gaat dat anders. Daar wordt elke pagina op het moment van opvragen in elkaar gezet door PHP. Dat is precies het moment waarop dit lek toesloeg. Geen PHP in het uitserveren betekent hier dus: geen aanvalsoppervlak.
PHP draaide bij ons maar op één plek: de formulieren. Het contactformulier en de Security QuickScan sturen hun gegevens naar een klein PHP-script dat er een mail van maakt. Die hebben wij meteen uitgezet, en bezoekers kregen in plaats van het formulier een blokje met ons telefoonnummer en e-mailadres te zien, met daarbij de uitleg waarom. Dat is geen storing die wij wegmoffelden, dat was de maatregel zelf.
Het resultaat: onze site heeft geen seconde plat gelegen, terwijl het kwetsbare onderdeel wel degelijk uit stond. De formulieren gingen woensdag om 12.57 uur uit, ruim voordat de patch bestond, en stonden om 16.53 uur alweer open nadat de server was bijgewerkt naar PHP 8.5.12 en wij dat hadden getest. Vier uur zonder formulier, nul uur zonder website.
Hier zit de les die wij ook aan klanten meegeven, en die weinig met dit specifieke lek te maken heeft: hoe minder er meedraait, hoe minder er stuk kan. Een website die een nieuwsbrief, een blog en een contactformulier nodig heeft, hoeft geen systeem te zijn waar vijftig plug-ins in meedraaien. Eenvoud is geen zuinigheid, eenvoud is een beveiligingsmaatregel.
Wat u zelf kunt doen
Veel organisaties hebben hun website of webapplicatie bij een webbureau, een hostingpartij of een leverancier die hun IT-beheerder niet in beeld heeft. Die vallen buiten wat wij voor onze klanten hebben gecontroleerd. Ons advies, en u mag dit gerust letterlijk overnemen in een mail aan uw leverancier:
-
Vraag schriftelijk of de PHP-versie van uw website is bijgewerkt, en wanneer. De gerepareerde versies zijn 8.5.12, 8.4.27, 8.3.36 en 8.2.35. Draait uw site op 8.1 of ouder, vraag dan of er een gerepareerde versie is geïnstalleerd en of de webserver daarna opnieuw is gestart. Bij die oudere versies verandert het versienummer namelijk niet, dus daar kunt u het niet aan aflezen.
-
Vraag of er is gecontroleerd op misbruik in de periode tussen 20 oktober en het moment van bijwerken. “Wij hebben de update gedraaid” is niet hetzelfde antwoord, zeker nu het NCSC signalen van daadwerkelijk misbruik meldt.
-
Gebruikt u online diensten die op PHP draaien, zoals een boekhoudpakket, een ticketsysteem of een webshopplatform? Vraag de leverancier om een verklaring. De meeste grote partijen hebben die inmiddels gepubliceerd.
-
Heeft u een website die eigenlijk niet meer gebruikt wordt? Haal die offline. Vergeten websites zijn bij dit soort lekken steevast de eerste die misbruikt worden, juist omdat niemand ernaar kijkt.
-
Werk ook de software óp de webserver bij, dus WordPress zelf, de plug-ins en het thema. Het PHP-lek is gedicht, maar een verouderde plug-in is gewoon de volgende ingang.
De vraag die overblijft
Bij een lek als dit telt niet wie de beste firewall heeft. Wat telt is wie binnen uren weet welke systemen geraakt zijn, wie durft te besluiten iets offline te halen, en wie dat besluit ook daadwerkelijk uitvoert. Dat vraagt om een beheerder die uw omgeving kent, ook ‘s avonds en ook voordat het nieuws erover gaat.
Heeft u websites of applicaties waarvan u niet zeker weet wie ze beheert, en wie er bij een volgend lek in actie komt? Dat is de vraag die u naar aanleiding van deze week het beste kunt stellen. Komt u er met het antwoord van uw leverancier niet uit, stuur het ons gerust door. Dan laten wij u weten of het voldoende is.