Het PHP-lek van 21 oktober uitgelegd: wat er gebeurde en hoe wij reageerden

Op woensdag 21 oktober domineerde één beveiligingsprobleem het technologienieuws: twee kritieke lekken in PHP, intussen bekend als “PHP2Shell”. In deze blog leggen we uit wat er gebeurde, wat het risico was en hoe wij als websitebouwer gereageerd hebben.

Update donderdag 22 oktober, 10u30

Onze hostingpartner Combell bevestigt dat het zo goed als volledige netwerk intussen beveiligd is. Na de vrijgave van de officiële updates rond 16u werden die meteen doorgevoerd, tijdens de werkuren in plaats van tijdens een gepland onderhoudsmoment, omdat de situatie zo dringend was.

Op de servers waar onze websites draaien, zijn alle PHP-versies van 5.6 tot en met 8.5 volledig gepatcht. Dat betekent dat ook de websites die wij woensdag naar een oudere, maar wel beveiligde versie hebben overgezet, beschermd zijn. Voor nog oudere PHP-versies werkt Combell verder aan oplossingen waar dat technisch mogelijk is.

Wij volgen de situatie verder op en vullen deze blog aan zodra er nieuws is. De technische updates van Combell zelf vind je op status.combell.com.

Onze tijdlijn

Woensdagmiddag namen we kennis van het incident. In het begin waren de ernst en de schaal nog niet helemaal duidelijk. In de loop van de dag werd dat wel duidelijk: dit was ernstig. Onze eerste prioriteit was opvolgen en ingrijpen waar nodig. Klanten die ons contacteerden, kregen meteen te horen wat we wisten en wat we deden. We bleven tot 21u opvolgen en vragen beantwoorden. Vandaag communiceren we breder.

Wat is PHP?

PHP is de programmeertaal die op de server draait en ervoor zorgt dat een website werkt. Denk aan formulieren, een webshop of een CMS zoals Drupal of WordPress. Bijna 70% van alle websites wereldwijd draait erop.

Wat was het probleem?

Er werden twee lekken gevonden in PHP zelf. Die zaten er al sinds 2012 in, maar werden pas nu ontdekt door een beveiligingsbedrijf, met behulp van AI. Volgens de onderzoekers was het al die jaren zo complex om het lek effectief te misbruiken, dat het voor mensen bijna onhaalbaar was. AI heeft die drempel nu weggenomen.

Omdat het lek in PHP zat en niet in een specifieke website, plug-in of CMS, was vrijwel elke PHP-website wereldwijd in principe kwetsbaar. Het was dus geen probleem dat eigen was aan onze websites. Het lek zat bovendien op een plek die al aan het werk is nog voor de website zelf iets doet. Een beveiligingsplug-in in je CMS kon dit dus niet tegenhouden. De oplossing moest op het niveau van de server komen.

Hoe ernstig was dit lek?

Beveiligingslekken krijgen een score op 10. Deze lekken kregen een 9,2, wat in de hoogste categorie “kritiek” valt. Sommige onderzoekers gaven zelfs een 10. Wat het zo ernstig maakte:

• Geen wachtwoord nodig. Een aanvaller hoefde nergens in te loggen.
• Geen hulp van binnenuit nodig. Er moest niemand op een link klikken of een bijlage openen.
• Van op afstand. Alles kon gewoon via het internet.

Beveiligingsexperts noemen dit een van de grootste lekken van de voorbije jaren.

Waarom was dit lek anders dan andere?

Net zoals bij computers en smartphones worden ook in websitesoftware regelmatig lekken ontdekt. Die worden volgens een vast stramien afgehandeld: de ontdekker meldt het lek in vertrouwen, de ontwikkelaars maken een oplossing en pas daarna wordt alles publiek gemaakt. De officiële bekendmaking stond gepland voor donderdag 22 oktober.

Deze keer liep dat mis. Details over het lek raakten per ongeluk vroegtijdig naar buiten, nog voor er een oplossing klaar was. De PHP-ontwikkelaars moesten daardoor hun planning loslaten en in allerijl een noodupdate maken, die ze een dag vroeger uitbrachten dan gepland.

Ondertussen konden kwaadwillenden er al misbruik van maken. Beveiligingsbedrijven zagen al pogingen tot misbruik terwijl iedereen nog op de update wachtte.

Wat waren de risico’s?

• Overname van de website. Kwaadwillenden konden zelf zaken op een website plaatsen en het laten lijken alsof die van de eigenaar kwamen, bijvoorbeeld malware.
• Inzage in gegevens. Denk aan persoonsgegevens die bezoekers via formulieren invulden.

Belangrijk om te weten: dat een website kwetsbaar was, betekent niet dat ze ook effectief gehackt is. Het betekent wel dat snel handelen nodig was.

Wat was de oplossing?

De oplossing moest van de PHP-ontwikkelaars zelf komen, in de vorm van een update. Die werd woensdag rond 16u (Belgische tijd) vrijgegeven. Op dat moment was snelheid cruciaal: eens de update uit was, werd voor kwaadwillenden ook nog duidelijker waar de zwakke plek precies zat.

Dit hebben wij gedaan:

1. Websites met hoog risico tijdelijk offline. Voor websites in gevoelige sectoren, zoals die van een ziekenhuis, hebben we samen met de klant de afweging gemaakt om ze uit voorzorg offline te halen tot de update beschikbaar was.
2. Recente PHP-versies binnen enkele minuten gepatcht. Websites die op een recente, ondersteunde PHP-versie draaien, kregen de oplossing quasi onmiddellijk na de release.
3. Preventief overgezet naar nieuwere PHP-versies. De officiële update kwam enkel voor de recente, ondersteunde PHP-versies. Het was lange tijd onduidelijk of oudere versies ook een oplossing zouden krijgen. Daarom hebben we een aantal hostingpakketten preventief naar een nieuwere versie gezet. Het risico daarvan is dat een onderdeel van een website niet meer goed werkt. Maar liever een website die tijdelijk een foutje toont dan een beveiligingsincident, want de gevolgen daarvan zijn veel groter.

4. Ook oudere versies beveiligd. Tegen woensdagavond had onze hostingpartner Combell alle PHP-versies waarop onze websites draaien gepatcht. Enkele websites op nog oudere versies hebben we naar de oudste versie gezet die de oplossing wel kreeg.

    

Het resultaat: onze klanten hebben er nauwelijks iets van gemerkt.

Uit de praktijk: waarom updates het verschil maakten

Een concreet voorbeeld maakt duidelijk waarom updates zo belangrijk zijn. Een van onze klanten had eerder al de update naar Drupal 11 laten uitvoeren. Een recente versie van een CMS draait ook op een recente PHP-versie, en die werd als eerste beschermd. Hun website kreeg de beveiligingspatch dus vrijwel onmiddellijk na de release, rond 16u, en was vanaf dat moment niet langer kwetsbaar.

Websites op oudere, niet meer ondersteunde PHP-versies kregen pas later op de avond alsnog een patch. Dat de oplossing er ook voor hen kwam, is goed nieuws. Maar het was geen zekerheid, en het betekende wel enkele uren langer wachten op een moment dat het lek al publiek was en actief misbruikt werd. Wie up-to-date is, hoeft niet af te wachten.

AI verandert het beveiligingslandschap

Dit lek zat al 14 jaar in PHP en werd nu pas gevonden, dankzij AI. En het is niet het eerste. Deze zomer werd op dezelfde manier al een ernstig lek in WordPress ontdekt. Dat is goed nieuws, want lekken worden nu sneller gevonden en opgelost. Maar het betekent ook dat zulke ontdekkingen sneller en vaker zullen gebeuren, door goedbedoelende onderzoekers én door kwaadwillenden. Dit zal zeker niet de laatste keer zijn.

Daarom is het belangrijker dan ooit om je website regelmatig te laten updaten, zowel het CMS als de software eronder. Zoals het voorbeeld hierboven toont: websites die up-to-date waren, waren woensdag het snelst en het makkelijkst beschermd.

Is jouw website up-to-date?

We contacteren actief klanten met een verouderde website om een update voor te stellen. Wil je niet wachten of twijfel je of jouw website up-to-date is? Stuur ons dan gerust een berichtje via support@ikoon.biz.

Deze blog wordt aangevuld zodra er nieuwe informatie beschikbaar is.