PHP bijgewerkt? Daarmee ben je er (nog) niet.

Woensdag is mijn vrije dag. Toen het nieuws over de PHP-lekken binnenkwam, was ik blij dat ik weinig PHP-projecten heb. Anders had die vrije dag er waarschijnlijk behoorlijk anders uitgezien.

Op 21 oktober werden twee kritieke kwetsbaarheden in PHP openbaar gemaakt. Onder bepaalde omstandigheden kunnen aanvallers daardoor code uitvoeren op een server, zonder eerst in te loggen. PHP bracht daarvoor beveiligingsupdates uit. Dat vroeg om directe actie van beheerders.

Wat ik interessant vond, was hoe de onrust zich verspreidde. Ik volgde de discussie al voordat alle technische informatie openbaar was. Vervolgens kwamen de berichten, de waarschuwingen en de vragen. Ook van mensen die normaal helemaal niet met programmeertalen bezig zijn.

Moet ik me zorgen maken? Draait mijn website hier ook op? Moeten we nu van PHP af?

Begrijpelijke vragen. Maar ik zou als ondernemer nog een andere vraag stellen: als iemand gisteren bij je is binnengekomen, wanneer kom je daar dan achter?

Ook een oplossing geeft informatie weg

Bij zo’n kwetsbaarheid ontstaat een ingewikkelde race. Je wilt beheerders zo snel mogelijk een oplossing geven. Tegelijkertijd kan een aanvaller die oplossing bestuderen om te achterhalen waar de fout zat. Daarmee worden systemen die nog niet zijn bijgewerkt een doelwit.

Daarom proberen onderzoekers en softwaremakers de ontdekking, het herstel en de bekendmaking op elkaar af te stemmen. Eerst de juiste mensen informeren, een oplossing voorbereiden en organisaties gelegenheid geven om maatregelen te nemen.

Bij dit PHP-lek liep die afstemming mis. Op 20 oktober verschenen de nummers van de kwetsbaarheden online, terwijl de gezamenlijke bekendmaking voor 22 oktober gepland stond. PHP vervroegde de release met een dag. Vervolgens verscheen per ongeluk een demonstratievideo van een werkende aanval. Ook publiceerde een leverancier de bijgewerkte software ruim zes uur vóór het afgesproken moment. Aanvallers konden die aanpassingen dus al bestuderen terwijl andere beheerders nog op hun update wachtten. De tijdlijn van de PHP Foundation laat zien hoe lastig het is om iedereen tegelijk te beschermen zodra informatie voortijdig naar buiten komt.

Met AI krijgt die race een extra dimensie. Ethische hackers gebruiken AI om fouten te vinden. Aanvallers kunnen dezelfde technologie gebruiken om software te analyseren en aanvallen voor te bereiden. Ook deze PHP-kwetsbaarheden werden met hulp van AI ontdekt.

Dat betekent overigens niet dat iedereen die een taalmodel wat code laat schrijven ineens een goede hacker is. Tussen een mogelijke fout vinden en betrouwbaar inbreken op een specifiek systeem zit nog steeds technisch werk. Maar zodra een aanval werkt en geautomatiseerd kan worden, kan die wel op grote schaal worden geprobeerd.

Dan wil je als bedrijf snel kunnen handelen.

C++ of Rust?

Ik ben persoonlijk geen liefhebber van PHP. Ook met WordPress en de verzameling plug-ins die daar vaak omheen hangt, heb ik weinig op. Je haalt allerlei onderdelen binnen die allemaal onderhouden moeten worden. Het gemak aan de voorkant neemt die verantwoordelijkheid niet weg.

Maar mijn smaak als programmeur is geen migratieadvies voor jouw bedrijf. PHP kan goed worden gebruikt. Je moet weten wat je draait, wie het onderhoudt en hoe snel je kunt ingrijpen.

Onder de motorkap speelt wel een groter vraagstuk. De PHP-interpreter is grotendeels in C geschreven. Zulke talen geven ontwikkelaars veel controle over het geheugen, en daarmee veel verantwoordelijkheid. Fouten in dat geheugenbeheer kunnen ernstige beveiligingsproblemen veroorzaken.

Daarom ben ik enthousiast over Rust. Die taal voorkomt door zijn ontwerp veel van zulke fouten. Ook veiligheidsdiensten adviseren om waar mogelijk talen met ingebouwde geheugenbescherming te gebruiken. Dat maakt software niet automatisch vrij van alle kwetsbaarheden, maar kan wel een belangrijke categorie fouten verkleinen.

Voor een bestaande PHP-website is overstappen naar Rust alleen geen eenvoudige oplossing. Rust is sterk in systeemsoftware en desktopapplicaties, maar voor veel websites is het ecosysteem minder toegankelijk dan dat van gevestigde webtalen. Je moet dus per toepassing afwegen of de voordelen opwegen tegen de complexiteit van bouwen en onderhouden.

Kijk eens wat er aan je voordeur gebeurt

Daarna komt iets wat veel minder aandacht krijgt dan een nieuwe programmeertaal: je logs.

Dat zijn de logboeken van je systemen. Afhankelijk van wat je vastlegt, zie je bijvoorbeeld welke verzoeken binnenkomen, welke foutmeldingen optreden en welke inlogpogingen worden gedaan.

Kijk daar eens in. Je zult waarschijnlijk verzoeken tegenkomen naar bestanden of beheerpagina’s die je helemaal niet hebt. Iemand probeert een bestand met wachtwoorden op te halen. Een bot zoekt naar een bekende kwetsbare plug-in. Er wordt voortdurend aan deuren gevoeld.

Ook de website van een klein bedrijf wordt automatisch op kwetsbaarheden gescand. Geautomatiseerde scanners komen vanzelf langs.

Zo’n poging betekent nog niet dat iemand binnen is. Maar om afwijkingen te herkennen, moet je wel zicht hebben op wat er gebeurt. En een logboek dat niemand bekijkt, waarschuwt niemand.

Je hoeft die logboeken niet zelf de hele dag te lezen. Je kunt software instellen die waarschuwt bij verdachte activiteit. AI kan helpen om daarin patronen te herkennen. Spreek met je IT-beheerder af wie die waarschuwingen ontvangt, onderzoekt en zo nodig ingrijpt. Anders weet je systeem straks wel dat er iets misgaat, maar doet niemand er iets mee.

Zorg dat je het nieuws eerder hoort

Zelf heb ik een AI ingericht die mij twee keer per dag nieuwe kwetsbaarheidsmeldingen stuurt, gesorteerd op belangrijkheid.

Veel publiek bekende kwetsbaarheden krijgen een CVE-nummer: een herkenbaar nummer waarmee softwaremakers, onderzoekers en beheerders over dezelfde fout kunnen communiceren.

Je hoeft als ondernemer niet al die meldingen te lezen. Je wilt vooral weten welke relevant zijn voor de software die jouw bedrijf gebruikt.

Daar begint het dus weer: weet wat je hebt draaien. Laat je beheerder of leverancier daarop gerichte waarschuwingen instellen. En spreek af hoe snel kritieke updates worden beoordeeld en uitgevoerd.

Dat gesprek kun je beter voeren voordat iedereen tegelijk belt.

Maak het makkelijk om je te waarschuwen

Dan nog een advies waar veel bedrijven direct iets mee kunnen: zet een security.txt op je website.

Stel dat een onderzoeker een kwetsbaarheid ontdekt. Waar moet die terecht? Bij je algemene klantenservice? Via een contactformulier? Bij iemand op LinkedIn?

Met security.txt maak je dat vindbaar. Het is een klein tekstbestand op een vaste plek: /.well-known/security.txt. Daarin staan onder meer een contactmogelijkheid en een vervaldatum, zodat duidelijk is hoe actueel de informatie is. Je kunt ook verwijzen naar je beleid voor het melden van kwetsbaarheden.

Het NCSC heeft hiervoor een uitleg over security.txt. Geef die link eens aan degene die je website beheert. Of aan mij natuurlijk;)

Zorg dat meldingen via dat adres terechtkomen bij iemand die ze kan beoordelen en opvolgen, zoals je IT-beheerder of security officer. De ethische hacker moet zijn melding kwijt kunnen en weten dat die wordt opgepakt. Wil je verder gaan, dan kun je een bugbountyprogramma overwegen: een beloning voor ethisch hackers die binnen afgesproken voorwaarden kwetsbaarheden melden.

Wie merkt het op?

Het PHP-nieuws zorgde voor aandacht. Terecht. Alleen: over een paar dagen gaat de aandacht weer ergens anders naartoe. Dan blijven dezelfde vragen over waar ik mijn vorige blog ook al naar verwees. Wie houdt jouw software bij? Wie volgt relevante beveiligingsmeldingen? Wie kijkt naar afwijkend gedrag? Wie ontvangt een melding van een onderzoeker? En wie grijpt er vervolgens in?

Dat zijn vragen waar ieder bedrijf antwoord op moet kunnen geven. Mijn advies voor nu: loop dit met je IT-beheerder of softwareleverancier na en leg vast wie verantwoordelijk is voor updates, het signaleren van verdachte activiteit en het opvolgen van meldingen. Spreek ook af wie ingrijpt als het misgaat. Dan weet je bij het volgende lek meteen wat je moet doen en wie je moet bellen.

Je wilt namelijk als ondernemer vooral dat je software veilig blijft draaien, zonder bij ieder nieuw lek in paniek te raken. Dan klinkt een taal (zoals Rust) die veel geheugenfouten voorkomt natuurlijk aantrekkelijk. Dus tja: meer rust in je software met Rust? Misschien bij je volgende project. Maar echte rust begint zoals ik zei met goed onderhoud en duidelijke afspraken over wie meekijkt en ingrijpt.