Zakelijke webhostingdienst KPN was kwetsbaar voor ernstig PHP-lek

De zakelijke webhostingdienst van KPN was kwetsbaar voor het ernstige lek in PHP dat donderdag bekend raakte. De broncode van sites van KPN-klanten kon daardoor worden bekeken en uitvoeren van eigen code was mogelijk.

Inmiddels zijn de problemen verholpen, nadat Nederlandse beveiligingsonderzoekers KPN en het Nationaal Cyber Security Centrum op de hoogte hadden gesteld.

Het is onbekend of alle zakelijke webhostingklanten van KPN door de bug risico liepen, of slechts een deel van hen. De provider was niet in staat om tijdig commentaar te geven.

De bug maakte het mogelijk om command line-argumenten door te geven aan PHP, waardoor met het aanroepen van '/index.php?-s' bijvoorbeeld de broncode van een bestand kan worden gedumpt. Ook is het mogelijk om eigen code uit te voeren.

Alle installaties die php-cgi of PHP in een cgi-wrapper gebruiken, zijn kwetsbaar. Die implementatie wordt niet zo vaak meer gebruikt; veel PHP-installaties draaien via fastcgi of als een Apache-module. Sommige shared hosting-providers gebruiken de kwetsbare methode echter wel, waaronder dus KPN.

Ook webhoster Byte was kwetsbaar, maar die provider werd ingelicht voordat het beveiligingsprobleem bekend werd. Daardoor had de provider voldoende tijd om haar PHP-installatie te patchen. De provider raadt nog wel aan om uit voorzorg wachtwoorden 'met enige regelmaat' te wijzigen.

Donderdag publiceerde PHP een patch voor het ernstige beveiligingsprobleem, maar deze blijkt zeer eenvoudig te omzeilen. De beveiligingsonderzoekers die de bug ontdekten, een groep die zichzelf De Eindbazen noemt, adviseren om een van de twee door hen geschreven patches zelf door te voeren in de broncode.

Het beveiligingsprobleem - dat al sinds 2004 aanwezig was - zou aanvankelijk pas geopenbaard worden wanneer er een fix beschikbaar was, maar nadat de bug per ongeluk was gepubliceerd, deed De Eindbazen zijn ontdekking uit de doeken. Naar nu blijkt is de kwetsbaarheid gepubliceerd door een bug in de bugtracker van PHP.

Reacties (25)

[Urk]

Werkte dit dan gewoon door bijv. http://website.nl/index.php?-s in je browser aan te roepen?
Dat zou wel echt een groot gat in PHP zijn dan...

[Reactie gewijzigd door Urk op 27 juli 2024 09:18]

[justahuman]

Ja, alleen php moet dan wel runnen via CGI wat al redelijk lek is. De fout zit er in dat hij het parsen wanneer er geen = in zit het als commandline argument ziet.

[Urk]

Nou, ik weet het niet hoor maar heb zojuist iets van 30 PHP sites gechecked en bij allen gaat er niets mis en krijg ik geen broncode te zien of te downloaden...
Blijkbaar komt dit scenario niet veel voor.

Of hebben ze er maar ?-s van gemaakt en is het in werkelijkheid een andere paramter?

[Reactie gewijzigd door Urk op 27 juli 2024 09:18]

[justahuman]

Het gaat niet om php websites, het gaat om apache websites dat de php code via de CGI wrapper runnen het is wel dergelijk de ?-s parameter

[Verwijderd]

Zoals bovenstaande al zegt, in combinatie met CGI. Een PHP site is dus niet per definitie een PHP module met CGI.

De meeste Nederlandse webhosters draaien PHP als Apache module waar geen CGI aan te pas komt.

[Squ1zZy]

Voorbeeld:
http://support.webroot.com/app/answers/detail/a_id/1761?-s

[Reactie gewijzigd door Squ1zZy op 27 juli 2024 09:18]

[Squ1zZy]

Je kan kijken welke modules gebruik maken van CGI en daarop zoeken met google.

Zo is te zien dat Nikon USA ook kwetsbaar is:

http://support.nikonusa.c...%3A-a%3A1.02,-b%3A1.02?-s

Er zijn grotere spelers waar ik wachtwoorden heb gevonden van databases. Een simpel script die gebruik maakt van google en kijken of het tekst is wat wordt weergegeven geeft me veel hits terug.

[Reactie gewijzigd door Squ1zZy op 27 juli 2024 09:18]

[Verwijderd]

En aangezien ik er vanuit ga dat jij niet de enige bent die dit weet, verwacht ik een hoop gelekte informatie op 't internet binnenkort van onze vriendelijke vrienden van 'groeperingen' zoals anonymous. Ben benieuwd hoe groot dit gaat zijn, dit is toch zeker niet iets wat je wil als serieus webdev platform!

Overigens is jouw voorbeeld ook een mooi voorbeeld waarom ik blij ben als ik kan inloggen over een trusted connection waarbij de toegang tot m'n database wordt geregeld door iets als een domain controller. Dan zit er toch nog een stapje tussen voordat mensen bij de gevoelige informatie kunnen komen.

[damanseb]

Dit heeft weinig te maken met php als ontwikkel platform.
Het gaat hier om een custom oplossing om php per host/user te kunnen draaien.
Dit word vaak gebruikt om cross-site php upload aanvallen te voorkomen door php-cgi niet als de standaard apache user uit te voeren.

Apache -> CGI -> Suexec -> Wrapper -> PHP

Suexec roept de wrapper aan met de ingestelde uid/gid.
De wrapper is veelal een shell script die de php scriptnaam doorgeeft aan php-cgi met verwijzingen naar per host php.ini files.
Het is echter wel noodzaak om de parameters te filteren die elke stap doorgeeft aan de volgende.

De nieuwe manier om dit te doen is door de php-fpm module te gebruiken.
Deze module is vanaf 5.3 standaard aanwezig en maakt het mogelijk efficient php per host/user te draaien..

Het wachten is alleen nog op een suexec implementatie binnen php-fpm om upload aanvallen onmogelijk te maken..
Dit staat op de todo list van de php-fpm ontwikkelaars.

Door suexec te implementeren binnen php-fpm kan je de uid/gid van geuploade bestanden veranderen naar eentje die anders is dan de uid/gid van je normale php bestanden waardoor suexec/php weigert deze te parsen.

@arjankoole: elke implementatie die een custom wrapper gebruikt is per definitie niet de schuld van php zelf maar van de ontwikkelaar die de wrapper geschreven heeft..

[Reactie gewijzigd door damanseb op 27 juli 2024 09:18]

[dualnibble]

Hey verhip, de UPC heeft er ook last van: http://vragen.upc.nl/?-s
en de kpn: http://kpn-customer.custhelp.com/?-s
enzovoort
Maarja, bovenstaande toont allemaal nagenoeg hetzelfde php scriptje natuurlijk.
(schijnbaar zijn dit mogelijke ingangen voor remote code execution oid) maar verder dan dit kom ik niet

Facebook doet het overigens wel leuk: http://www.facebook.com/?-s

[Reactie gewijzigd door dualnibble op 27 juli 2024 09:18]

[defixje]

Facebook doet het overigens wel leuk: http://www.facebook.com/?-s

Hahaha inderdaad, kan je gelijk solliciteren als software engineer:
https://www.facebook.com/...ng&req=a2KA0000000Lt8LMAS

Leuk gedaan. Van een nood(lek) een deugd maken

[Verwijderd]

Facebook doet het overigens wel leuk: http://www.facebook.com/?-s

Inderdaad!

[Squ1zZy]

"This isn't actually a vulnerability in Facebook, but a clever way in which the company looks for security engineers. The "source code" was actually a link to a job application page."

[xares]

Bij XS4all was gisteren precies hetzelfde probleem. Zij hebben dit gisterenavond nog opgelost.

[Eagle Creek]

Goed en snel afgehandeld door deze grote partijen dit keer.

Wel benadrukt het nog maar eens hoe kwetsbaar "we" zijn. Een dergelijk lek is vrij ernstig, en kan grote implicaties hebben, maar na de publicatie gaan de ontwikkelingen rap. Hoewel er (naar mijn kennis) nog geen grootschalige actieve exploits waren, is dat (of zou dat) een kwestie van tijd (zijn). Daar komt bij dat je je als bedrijf of consument vaak niet kunt wapenen, tot er een oplossing is gevonden. Bij een ware zero day, levert dat een extra gevaar op.

Dergelijke situaties zullen we in de toekomst zeker nog vaker gaan zien, en het is in mijn ogen zaak dat organisaties zich richten op het snel kunnen schakelen, en snel reageren op dergelijke ontwikkelingen. De praktijk leert ons immers dat intern gevonden lekker vaak weinig prioriteit hebben, zolang het lek nog niet in de media wordt uitgemeten. Hoewel het risico inderdaad beperkter is als niet iedereen er vanaf weet, maakt het feitelijk niet uit voor de oplossing.

(het valt mij dan ook 100% mee hoe snel KPN, toch een vrij grote organisatie met complexe systemen) dit oppakt)

[Reactie gewijzigd door Eagle Creek op 27 juli 2024 09:18]

[Sfynx]

Waarom gebruikt iemand dit eigenlijk nog, het is een onnodige belasting voor de server

[The Zep Man]

Waarom gebruikt iemand dit eigenlijk nog, het is een onnodige belasting voor de server

Zoals de ongeschreven regel in veel bedrijven geldt: als het werkt, zit je er niet aan. Updates worden misschien wel uitgevoerd, maar er wordt niet altijd gekeken naar de veiligheid van werken tussen producten in.

En hoewel PHP via CGI veel onnodige belasting meebrengt, hebben de meeste webservers toch overcapaciteit of er wordt gewoon meer hardware neergezet. Hierdoor werd dit niet als probleem gezien. Wat wel erg is, is dat er ook nooit gekeken is naar de veiligheidsrisico's: FastCGI of en Apache module zijn sowieso veiliger, omdat (om het plat te zeggen) een directere verbinding legt tussen webserver en CGI programma's. Code injectie voor het wijzigen van het aanspreken van (bijvoorbeeld) PHP door de webserver wordt daarmee voorkomen.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 09:18]

[justahuman]

bij sony is het nog steeds niet gefixed. Kpn was redelijk snel toen het gemeld was. Een gedeelte van de kpn websites hadden geen last van de bug.

[Reactie gewijzigd door justahuman op 27 juli 2024 09:18]

[iMars]

Ik heb het gelijk getest op onze Plesk webservers, waar je php support kan instellen als Apache Module, FastCGI application en CGI application. Op geen van beide methodes werkt deze bug...

[Verwijderd]

Er kan tegenwoordig beter 'n bericht geplaatst worden, wanneer er 'ns iets goed gaat bij de KPN! Wat 'n ongelofelijke prutsers! De enige nieuwsberichten die je tegenwoordig over de KPN leest zijn schandalen & mega-blunders.

Zo zie je maar weer dat 'n voormalig staatsbedrijf absoluut niet geprivatiseerd kan worden!

[Verwijderd]

Het gaat niet zozeer om KPN. Ze gebruiken software genaamd 'RightNow' van Oracle. Deze software maakt gebruik van de cgi-wrapper. Iedereen die dus die software draait is dus kwetsbaar voor deze bug. En dat zijn er nogal wat. Gezien hun klantenlijst, maakt zelfs Nasa er gebruik van.

[arjankoole]

Er kan tegenwoordig beter 'n bericht geplaatst worden, wanneer er 'ns iets goed gaat bij de KPN! Wat 'n ongelofelijke prutsers! De enige nieuwsberichten die je tegenwoordig over de KPN leest zijn schandalen & mega-blunders.

Zo zie je maar weer dat 'n voormalig staatsbedrijf absoluut niet geprivatiseerd kan worden!

Dat is rijkelijk overdreven, het werd gisteren pas bekend. Alle sites, incl UPC en KPN die hier gelinkt zijn, zijn nu onschadelijk gemaakt of beveiligd hier tegen.

Bovendien is de fout van php, niet van KPN, KPN maakt gewoon gebruik van php op een ondersteunde wijze.

[PdeBie]

belangrijk is nu de vraag: heeft KPN het probleem verholpen? Anders lijkt me dit een zeer kwalijke zaak.

--edit-- te snel gelezen. 2e alinea gemist.

[Reactie gewijzigd door PdeBie op 27 juli 2024 09:18]

[intel_478]

Epische laatste regel.

[hdtracer]

KPN staat wel erg vaak in de belangstelling de laatste tijd :]