Aanvallers plaatsen backdoormogelijkheid in PHP via infectie van Git-server

Aanvallers hebben een achterdeur in de officiële git-repo van PHP weten te plaatsen. Twee commits deden zich voor als kleine aanpassingen, maar zorgen in werkelijkheid voor de mogelijkheid om een remote code execution uit te voeren op websites waar PHP op draait.

De aanval vond op zondag plaats en werd ontdekt door PHP-gebruikers. De makers van de programmeertaal bevestigen inmiddels dat er een aanval plaatsvond. Aanvallers voerden een commit uit op de main repository van PHP waarmee een achterdeur kon worden geopend op geïnfecteerde websites. Die is niet doorgezet naar de release. De commit werd zogenaamd gedaan uit naam van twee hoofdprogrammeurs van PHP, Rasmus Lerdorf en Nikita Popov. De programmeurs zeggen niet te weten hoe dat precies kon gebeuren, maar zeggen dat 'alles erop wijst' dat de Git-server git.php.net is aangevallen, en de commits niet vanuit bijvoorbeeld een geïnfecteerd Git-account zijn gedaan.

De achterdeur maakte het in theorie mogelijk om websites aan te vallen waar PHP op draait. Dat zijn er veel: PHP wordt op 79,1 procent van alle websites gedraaid. De websites zouden dan een PHP-upgrade hebben moeten uitgevoerd nadat de achterdeur werd geplaatst. Aanvallers konden in dat geval op een kwetsbare site een http-request sturen om vervolgens controle over de website te krijgen. Het lek is inmiddels weer gedicht. Aangezien de exploit niet in een productierelease is gekomen is de kans zeer klein dat websites daadwerkelijk getroffen zijn.

Opvallend is dat de exploit alleen kon worden uitgevoerd als een bepaalde http-header een string met de tekst zerodium bevatte. Zerodium is een bekend bedrijf dat geld betaalt voor het aankopen van exploits. Het is niet duidelijk of er echt een link is met Zerodium, maar het lijkt waarschijnlijker dat het gaat om bijvoorbeeld een beveiligingsonderzoeker die de bedrijfsnaam gebruikt om op te vallen.

Volgens het PHP-team is de bestaande Git-server niet meer veilig. Uit voorzorg is daarom alle broncode naar Github verplaatst. De developers benadrukken dat iedere ontwikkelaar daar verplicht tweestapsverificatie moet aanzetten. Daar waren de repo's al als read-only te zien, maar na het incident zijn ze volgens ontwikkelaar Popov ook canonical geworden.

Update: er is verduidelijkt dat het gaat om een commit die niet in de releasecyclus is gekomen.

Reacties (71)

[Henrikop]

Supply-chain attacks on the rise!

Iedere organisatie heeft veel leveranciers. Je kan zelf heel goed op de security zitten, maar nu moet je ook nog opletten dat al je leveranciers goed op de security zitten.

Dit soort aanvallen gaan we meer zien, juist omdat ze zo'n brede impact hebben en zo iedere organisatie een groot attack-surface krijgt.

Ieder bedrijf wat software van derden gebruikt moet zich er nu ook gaan verdiepen hoe diens leveranciers zich beveiligen.

Het adagium is "houd je software up-to-date", maar met deze trend krijg je meer de neiging als het geen zero-day is even te wachten. Hoe weet je dat je de update kunt vertrouwen? Juist omdat updates ook altijd veel privileges krijgen.

Zo wordt het vak er niet makkelijker op en zal software duurder maken.

[etiennebruines]

Het is dan ook goed dat ze (programmeurs in het algemeen, niet per se de PHP devs) eraan werken, dit soort audits te automatiseren. In dit geval is het iemand persoonlijk opgevallen (code-review), maar een tool zou dit net zo goed oppakken.

Daarbij denk ik aan CodeQL, die juist dit soort remote execution varianten op zou pikken. https://github.com/github/codeql

Door te kijken naar hoe de "inputs" (HTTP Header in dit geval) gebruikt worden, kunnen ze vaststellen of daarmee remote execution mogelijk is.

Als toevoeging op je vraag, hoe weet je dat je de update kunt vertrouwen: dat zal voor veel mensen een hele opgave zijn. Het gebruik van zulke automatische tools kan een reden zijn om software A te nemen ipv software B, omdat je daar meer vertrouwen hebt in de updates.

[Reactie gewijzigd door etiennebruines op 23 juli 2024 01:26]

[Mellow Jack]

Toch zou dit topic al jaren hoog op de agenda moeten staan

Elke script/programmeer taal kan sinds de afgelopen 10 jaar externe libraries laden (programmeertalen doen dit al veel langer).

Zo updaten wij onze Jenkins omgeving maandelijks, de plugins wekelijks en gebruiken we zo min mogelijk third party libraries. Deze omgeving gebruiken we alleen voor wat scripting jobs en als je ziet hoevaak iets geüpdatet wordt vanwege een vurnability is best bizar.

Ergens ben ik wel blij met deze supplychain attacks want het levert wat focus op dit topic

[divvid]

Externe libs zijn bijna niet te vermijden. Een simpele npm install <je favoriete framework> installeert zomaar 500-1000! dependencies. Die ga je nooit kunnen nalopen. Dit geldt ook voor heel veel andere tools.
Ik hoor net op BNR de term infobesitas. In de context van deze post zou je ook de term libbesitas kunnen gebruiken voor de overdaad van libraries die nodig is voor vaak simpele funties, met de nodige risico’s van dien

[Reactie gewijzigd door divvid op 23 juli 2024 01:26]

[CodeCaster]

overdaad van libraries die nodig is voor vaak simpele functies,

Tsja, wat heet "overdaad" en wat heet "simpel"? Als je voor het left-padden van strings of bijvoorbeeld het parsen van ISO 8601-geformatteerde datums nog libraries nodig hebt, dan is je runtime/framework/base class library wellicht te ... laat ik "eenvoudig" zeggen, voor de taken waarvoor het heden ten dage wordt ingezet. Verder wil je ook niet dat developers hun tijd verdoen aan het al zeventig keer opnieuw uitgevonden wiel nógmaals uitvinden; het kost tijd, en ze gaan in valkuilen stappen waar hun voorgangers in liggen opgestapeld.

Daarnaast zijn lekken echt niet voorbehouden aan "simpele" libraries, of zijn we Heartbleed van OpenSSL alweer vergeten (is dat echt al zeven jaar geleden?). Je gaat niet voor iedere HTTP-server opnieuw TLS zelf programmeren; je gebruikt daar libraries voor, want je hebt geen mensjaren te verbranden. Ook compressie (deflate, zlib, brotli) laat je door anderen programmeren, net als het parsen van XML, Office-formaten en het lezen en schrijven van afbeeldingen en PDF-bestanden.

Al die functionaliteiten gaat een gemiddeld bedrijf niet even zelf opnieuw schrijven, en daarmee haal je dus de facto populaire libraries en dus populaire attack surfaces naar binnen.

[Reactie gewijzigd door CodeCaster op 23 juli 2024 01:26]

[divvid]

Ik zeg dan ook niet dat je het wiel zelf uit moet vinden (doe ik zelf ook niet), maar het kan geen kwaad je er van bewust te zijn.

[Nystran]

Deze commit werd gevonden, en moet redelijk verdacht geweest zijn met zijn "zerodium" als string in de code. Maar hoeveel van deze pogingen worden niet opgespoord? Hoeveel zijn qua code net zo subtiel als de heartbleed bug / exploit?

Een goede puzzelaar zou een mooi jaarsalaris kunnen verdienen met het schrijven van open source software met af en toe een achterdeurtje.

[Cerberus_tm]

Het wachten is op een inbraak bij Microsoft, waardoor Windows een update met malware krijgt...

Wat mij betreft zijn automatische updates uiteindelijk fundamenteel incompatibel met veiligheid.

Maar zonder updates kun je ook weer geen bekende kwetsbaarheden dichten. Een lastig dilemma.

Overal read-only back-ups van maken, het uitvoeren van uitvoerbare bestanden blokkeren (behalve handmatig toegevoegde uitzonderingen), browsers extreem beveiligen: dat soort dingen moet je doen.

[FvdM]

Ik verwacht dat dit gaat doorontwikkelen naar trusted update repositories, zoals in de linux wereld gebruikelijk is, maar dan overal. In een trusted repo kan echter ook vanalles mis gaan dus het dilemma zal blijven. Het past wel in het huidige vertrouwenstijdperk.

Edit: ik bedoel hiermee dat er meerdere 'trusted' PHP forks kunnen gaan ontstaan.

[Reactie gewijzigd door FvdM op 23 juli 2024 01:26]

[Cerberus_tm]

Dat zou op zich wel positief kunnen zijn. Daar kan ook van alles misgaan, maar dan heb je een veel kleinere groep te pakken in één keer.

[Patrick_Wolf]

Totdat er een backdoor in je 'controle tool' zit, waardoor hij andere stukken software gewoon als 'akkoord' gaat aanvinken ;-)

[elmuerte]

Oud nieuws, zie de Ken Thompson Hack: http://wiki.c2.com/?TheKenThompsonHack

[kodak]

Alleen is deze software al tientallen jaren algemeen gebruik voor miljoenen gebruikers. Je toont daarbij geen verband dat die afhankelijkheid, vergeleken met voor deze aanval, duidelijk groter is geworden om het interessanter te vinden om aan te vallen.
Daarbij toon je niet aan dat dit een toename in supplychains laat zien. Aanvallen op software libraries, frameworks, applicaties en zelfs distributies en os bestaat al jaren, ook al komt dat lang niet altijd in het nieuws.

[Reactie gewijzigd door kodak op 23 juli 2024 01:26]

[Xanaroth]

Alle contacten; zowel leverencier én klanten! Niet slechts 1 kant op kijken, dat doet dataverkeer ook niet - onderscheid maken tussen waar het zit in de keten.

Dat laatste wordt vaak onderschat. Je accountmanager gaat even op de lokale wifi met laptop of mobiel tijdens een presentatie. Je service engineer plugt zn laptop in op 'jouw' hardware voor troubleshooten. Voor je het weet komt er zo direct contact tussen de 2 bedrijfsnetwerken en kan virus/worm/whatever vrolijk doorgegeven worden.
Als je dan alleen naar je leveranciers kijkt voor de IT beveiliging en huishouding, is het wachten tot zo'n contact iets meebrengt vanaf een klant.

Zo zie ik al langzaam door de ketting heen een beweging richting niet functionele leveringen (aankopen exclusief modems/routers/switches, dat wordt door elke afnemer weer zelf ingekocht en geprogrammeerd om de toegang volledig te kunnen controleren; zelfs contract onderhoud kan niet zonder aanwezigheid&toestemming&leen laptop).
Ook stand-alone of interne netwerken, waarbij apparatuur weer bewust hardwarematig offline gaat van het 'echte' internet om problemen voor te zijn.

Idem opkomst van guest netwerken enerzijds (salesman kan rustig inloggen, fysiek gescheiden van de rest) en fysieke blokkades (niet-bedrijfslaptop komt uberhaupt gebouw niet meer binnen) tot restricties anderzijds (salesman kán niet meer inloggen op onbekende netwerken, en USB poorten ook geblokkeerd dus helaas voor je presentaties).
Gevolg is dat dingen weer terug naar hardcopy gaan, of vooraf over de mail gestuurd worden.


Dat soort dingen zijn nog heel beperkt in opkomst, uiteindelijk is de volledige supply chain tegenwoordig digitaal verweven. Er hoeft vanaf de eindgebruiker tot de delver van grondstof (en bij elke stap geld weer "en diens klant/leverancier volledige supply chain") maar ergens 1 lek te zitten, en via via kan een kwaadwillende heel snel alles en overal bij.

Zie ook de recente Microsoft Exchange Server en Solarwinds hack, waarbij het er op lijkt die die een oorzaak-gevolg relatie kunnen hebben (MS gebruikte SolarWinds, en de hackers waren actief bij MS wezen rondkijken). Vanuit de ene weakest link in een supply chain kom je in de volgende supply chain terecht.

[Reactie gewijzigd door Xanaroth op 23 juli 2024 01:26]

[Henrikop]

Inderdaad een hele goede. De hele keten meenemen twee kanten op.
Tot slot zie je nog dat de "insider risk" incidenten (bijv. GGD) ook steeds relevanter worden.

Uitdagend.

[etiennebruines]

Lijkt me een goede reden om signed commits te gebruiken.

[RxTweak]

Hoe werkt een signed commit dan en hoe had het dit probleem voorkomen?

[etiennebruines]

Je hebt een GPG-Key waarvan je het private-deel zelf behoudt, en het publieke-deel upload je naar je VCS(*). Met deze key wordt de commit zelf voorzien van een cryptografische signature, waardoor je vast kunt stellen of iemand daadwerkelijk de commit heeft gedaan of niet.

(*) Okay, ja... Als iemand toegang heeft tot je VCS helpt dit natuurlijk niet, ze kunnen net zo goed je public-key veranderen en dan signen met een valse key.

Voorbeeld:
https://github.com/php/php-src/commits/master
Je ziet hier soms "verified". Dat zijn ondertekende commits; je kunt erop klikken voor details.

Bron: https://docs.github.com/e...to-github/signing-commits

[aequitas]

Als je in de CI systemen zorgt dat de signature ook wordt gecontroleerd, apart van je VCS dan voorkom je in ieder geval dat nieuwe packages gebouwd worden met malicious commits.

Daarnaast is je public key... public. Je zorgt dat het op een publiek bekende plek staat zodat iedereen er bij kan. Als die key dan opeens verandert dan moeten er wel belletjes gaan rinkelen.

[Oon]

Is dit ook mogelijk met de 'gewone' git server? Ik kan wel docs van Github, GitLab, en Gitea vinden, maar niet van het Git protocol zelf

[etiennebruines]

Het signen zit in de git-cli zelf; je VCS of build-server kan dan zelf besluiten daar wat mee te doen of niet. Het is uiteindelijk deel van de daadwerkelijke commit en het "valideren" ervan is optioneel.

Het ligt er dus maar net aan, wat je "gewone" git server is, en of deze is ingesteld er wat mee te doen.

[Mellow Jack]

Toch vind ik key's altijd een lastig iets... een account gebonden key is al iets fijner, een tijdelijke key voelt alweer iets beter maar is niet zo gebruiksvriendelijk.

MFA voelt voor mij persoonlijk nog het beste in een zakelijke omgeving. Sinds kort is dat zelfs voor kleine bedrijven relatief gemakkelijk om te gebruiken. Dan kan je relatief makkelijk ervoor zorgen dat de gebruiker zichzelf wat vaker moet valideren en is het switchen tussen devices wat makkelijker

Hoe denk jij hierover?

[divvid]

MFA kan ook in de weg gaan zitten. Bij ons stond de logout voor vmware op een paar minuten. Even koffie halen of naar de wc tijdens je thuiswerk sessie leverde al een MFA actie op, heel irritant en levert helemaal niets op kwa veiligheid. Nu staat de timeout op een uur. Een stuk prettiger

[Rannasha]

Hoe werkt een signed commit dan en hoe had het dit probleem voorkomen?

Met een signed commit zet je als ontwikkelaar je digitale handtekening onder de inhoud van de commit. Deze digitale handtekening wordt gemaakt met behulp van een privé-sleutel die je veilig dient te bewaren (bijvoorbeeld op een USB stick die je alleen in de computer stopt wanneer je deze nodig hebt).

Met zo'n aanpak is het meteen duidelijk wanneer een commit van een bekende ontwikkelaar echt is of niet. Het versiebeheersysteem zou je zelfs zo kunnen instellen dat niet ondertekende commits simpelweg geweigerd worden.

Een bijkomend voordeel is dat het voor anderen altijd mogelijk is om de handtekening te verifieren en dat deze afhankelijk is van de inhoud van de commit. Een aanvaller kan dus niet een oude handtekening stelen en deze hergebruiken voor een nieuwe commit.

[Verwijderd]

Niet op een USB-stick. Wel op een USB-token of smartcard bijvoorbeeld. Het belangrijkste hiervan is dat de key niet exportable moet zijn. Anders heeft het niet zoveel nut.

[cricque]

Ja maar als je bij de bron kan (dus git server) dan kan ik jouw authenticatie ook wel wijzigen, en tijdelijk vervangen door mij key. Dit maakt het uiteraard wel moeilijker, maar het is niet dat het niet kan. En als iemand jou wilt hacken of iets doen, dan zal hij dat ook doen. Het is niet dat het niet mogelijk is, het is alleen hoeveel tijd wil je er in steken. En als het je dan (uiteindelijk) lukt, dan is het 2de issue, niet gepakt worden.

Ok jij zegt dat iemand anders kan verifiëren ? Maar hoe gaan zij die handtekening nakijken, of ze moeten ook het publieke deel hebben. Maar dat zou zeggen, dat jij lokaal ook elke handtekening moet hebben. Dat is op zich geen probleem. Maar stel ik wijzig mijn key (als de echte programmeur), dat moet ook kunnen. En dit zal dan ook via een git pull ofzo moeten meekomen. Dus de lokale keys krijgen ook een update, dus kan ik als aanvaller nog altijd jouw key wijzigen en krijg jij die ook mee. Het enige wat dan een extra zou kunnen zijn is dat er een dikke waarschuwing komt ... hey persoon X zijn key is gewijzigd. Maar dat moet zeker kunnen, want ... hey ik ben mijn sleutel kwijt, kan de backup niet vinden etc. En een email versturen naar het hele team ... mijn key is gewijzigd, kan zeker. Maar dat zal die aanvaller ook best wel kunnen. En in "drukke" projecten zal je al zoveel mail binnenkrijgen dat dit dikwijls "autoaccept" zal zijn. Bij code binnen een bedrijf is dit anders, omdat je daar meestal de personen wel kent. Maar opensource met mensen over de hele wereld, ga je niet effe iedereen opbellen, hey ik heb mijn key gewijzigd en ik ben het wel echt geweest.

[Rannasha]

Ja maar als je bij de bron kan (dus git server) dan kan ik jouw authenticatie ook wel wijzigen, en tijdelijk vervangen door mij key.

Ik ken de precieze implementatie van het systeem van signed commits niet, maar bij andere crypto-systemen zoals PGP hebben gebruikers op hun eigen systeem een verzameling "fingerprints" van de publieke sleutels van mensen met wie ze regelmatig interacties hebben. Met deze fingerprints is het mogelijk om te verifieren dat de publieke sleutel inderdaad de juiste is. Als een aanvaller de commits opeens met een andere sleutel gaat ondertekenen, dan zouden er dus allerlei alarmbellen moeten afgaan bij de andere partijen die de code nakijken.

Ok jij zegt dat iemand anders kan verifiëren ? Maar hoe gaan zij die handtekening nakijken, of ze moeten ook het publieke deel hebben. Maar dat zou zeggen, dat jij lokaal ook elke handtekening moet hebben. Dat is op zich geen probleem. Maar stel ik wijzig mijn key (als de echte programmeur), dat moet ook kunnen. En dit zal dan ook via een git pull ofzo moeten meekomen. Dus de lokale keys krijgen ook een update, dus kan ik als aanvaller nog altijd jouw key wijzigen en krijg jij die ook mee. Het enige wat dan een extra zou kunnen zijn is dat er een dikke waarschuwing komt ... hey persoon X zijn key is gewijzigd. Maar dat moet zeker kunnen, want ... hey ik ben mijn sleutel kwijt, kan de backup niet vinden etc. En een email versturen naar het hele team ... mijn key is gewijzigd, kan zeker. Maar dat zal die aanvaller ook best wel kunnen. En in "drukke" projecten zal je al zoveel mail binnenkrijgen dat dit dikwijls "autoaccept" zal zijn. Bij code binnen een bedrijf is dit anders, omdat je daar meestal de personen wel kent. Maar opensource met mensen over de hele wereld, ga je niet effe iedereen opbellen, hey ik heb mijn key gewijzigd en ik ben het wel echt geweest.

Het verspreiden van je public key fingerprint doe je het liefst via een ander kanaal dan het kanaal waar je de public key wil gebruiken. Gebruik je hem voor de versleuteling van je email? Plaats hem dan op je website. Gebruik je hem voor zaken die je per USB stick overdraagt? Stuur hem dan per email. Zo voorkom je dat er een single point of failure is.

Voor een key die je gebruikt voor het ondertekenen van commits kun je iets dergelijks doen: Alleen verspreiden via de email mailinglist van je project, bijvoorbeeld. Het wijzigen van een public key hoort zeer zeldzaam te zijn, want dit is de sleutel tot je digitale identiteit en zeker iemand als de leider van een project zo groot als PHP zou voldoende voorzorgsmaatregelen moeten kunnen treffen dat het niet zomaar gebeurt dat hij z'n key kwijtraakt.

Bovendien is het, in eerste instantie, niet nodig dat alle contributors van het project direct de nieuwe key verifieren. Als er een paar mensen goed op letten en alarm slaan wanneer er iets niet klopt, dan ben je er al. Hoewel een open source project soms honderden of duizenden contributors heeft, is er vaak een relatief hechte kern van ontwikkelaars die de meeste bijdragen leveren. Vaak zijn dat ook de mensen die commit-toegang hebben op de main repository (anderen moeten middels pull requests hun bijdrage leveren) Zolang die kern elkaar controleert en meteen wantrouwig worrdt als een van hen een nieuwe public key publiceert, dan komt het wel goed.

[StefanJanssen]

Het betekend dat de maker het heeft ondertekend met een private key. Dit kan door middel van de public key gecontroleerd worden. Iemand kan relatief makkelijk onder een andere naam/email een commit doen. Alleen de eigenaar van het account kent de private key en dus kan niet iemand anders onder die naam een commit doen.
Er zijn dan verschillende niveaus van beveiliging. Je kan alle commits toestaan (ook die niet ondertekend zijn) of je kan alleen ondertekende commits toestaan. Dit zorgt er voor dat bovenstaande commit niet geplaatst had kunnen worden (tenzij de private key gelekt is)

[Verwijderd]

Edit: laat maar, anders dan bedoeld blijkbaar

[Reactie gewijzigd door Verwijderd op 23 juli 2024 01:26]

[kwaakvaak_v2]

Dat zijn ze ook, maar als de signing ook compromised is heeft dat geen nut meer.

Eigenlijk had PHP al veel eerder moeten besluiten dat ze de repo's bij een dienst als github/gitlab onder brengen en niet op een eigen gemaakt GIT systeem moeten hosten.

Goed dat Nikita gelijk de wond heeft afgesloten en per direct github als main repo in te zetten.

[D11]

De signing is alleen compomised als de private key (van de ontwikkelaar) bekend is bij de aanvaller. Is dat niet het geval dan kan de aanvaller de commit niet ondertekenen met de juiste handtekening. Dit is voor iedereen controleerbaar die over de public key van de ontwikkelaar beschikt waarvan geclaimed wordt dat deze de commit heeft gedaan.

[Kees]

Zo te zien op de mailinglist gaan ze dat ook doen (iig voor de php-src repository).

[Scriptkid]

Volgensmij werken signed commits alleen in closed development met kleine teams waar je iedereen kent en weet welke key hij gebruikt.

In large audiance development waar duizenden mensen aan een repo werken is het onmogelijk om te bepalen of een signing wel valid is of van een persoon met kwade bedoelingen,

Enige dat dit probleem op lost is validatie door een kleine club van pull requests die naar master gaan en dat is volgensmij wat hier ook is gebeurd.

[kodak]

Een signed commit heeft weinig waarde zolang de gewijzigde code niet eerst gecontroleerd is en dit soort beveiligings bugs niet worden gevonden. Het signen zorgt niet voor die controle, hooguit dat je achteraf kan weten welke code je hebt. En hier had het waarschijnlijk niets uitgemaakt omdat de controle al is gedaan, waardoor het probleem duidelijk werd, en er nog geen release van was gemaakt.

[UPPERKEES]

Ik heb me niet echt verdiept in deze hack. Maar het lijkt dat de Git server zelf compromised is geweest. In dat geval kan je in wezen de commit zelf singen en die public key toevoegen aan die user. Ligt natuurlijk aan hoeveel controle ze hadden over de Git server. Het signen van commits moet natuurlijk iedereen wel gewoon doen. Want het helpt inderdaad wel. Maar wanneer de sever zelf niet meer te vertrouwen is neemt dat vertrouwen in de commit signatures ook af.

[etiennebruines]

Wel handig om te vermelden, dat de betreffende commit niet in een "tagged release" is gekomen. Het is dan ook onwaarschijnlijk dat iemand dit via een "update" op z'n production server heeft draaien.

[Drardollan]

Die informatie mistte ik inderdaad ook in het artikel, hoe moet ik nu weten of mijn webservers kwetsbaar zouden zijn. Niet dat ik verwacht dat een commit bij PHP.net direct zorgt voor bijgewerkte repositories van de diverse distributies.

Maar met SolarWinds in het achterhoofd is het wel van belang om te weten of deze aanpassing ook naar productieversies gestuurd is.

[kimborntobewild]

Die informatie mistte ik inderdaad ook in het artikel, hoe moet ik nu weten of mijn webservers kwetsbaar zouden zijn.

De hack in dit artikel even daargelaten: ga er maar vanuit dat alle webservers kwetsbaar zijn; er zijn vast honderden zero-days beschikbaar op je server...

[Jan-E]

Daarnaast worden tagged releases altijd gebaseerd op de voorgaande RC1 releases. Morgen of overmorgen worden 8.0.4 en 7.4.17 getagged. Die bevatten slechts enkele tekstuele wijzigingen ten opzichte van de RC1 releases. En die zijn nu al 13 dagen oud.

[Niet Henk]

Ik mag hopen dat Zerodium €0 betaalt voor dergelijke supply-chain attacks. Degelijk beveiligingsonderzoek is een vak apart waarbij ik me nog kan voorstellen dat als de auteurs van een product dit niet voldoende belonen, je toch naar een dienst als Zerodium stapt, die het ook enkel aan overheden verkoopt.

Echter opzettelijk zwakheden open-source producten aanbrengen om dit dan te verkopen, dat is gewoon triest natuurlijk. Heel fijn dat deze tijdig gedetecteerd is.

Ik vind dat deze persoon als "beveiligingsonderzoeker" benoemen in het artikel niet terecht is. Het is een hacker die dus zichzelf op onbekende wijze toegang heeft verschaft tot de PHP Git server, en niet om dit te bewijzen een "hacked" comment commit, maar gewoon opzettelijk de beveiliging van een product ondermijnd. Dat is op geen manier white- of grey-hat. Iedereen begrijpt dat als je commits kan maken op de Git-server, dit ook een malicious commit had kunnen zijn.

[dbzokphp]

Aangezien de commit pas van gisteren was, is deze commit neem ik aan niet in een release meegenomen, en dus nog niet actief in gebruik? Tenzij je PHP toevallig gisteren zelf vanaf de master repo hebt gebuild.

[kwaakvaak_v2]

klopt, zit niet in een officiële release. En dat laatste is voor een productie omgeving nooit een goed idee

[ACM]

Bugfix-releases zijn normaal gesproken wel redelijk handig om snel door te voeren...

[kwaakvaak_v2]

zeker wel, maar omdat nu direct vanuit de master te doen ipv een tagged release.

[ACM]

oh eens, je moet inderdaad niet de master gaan zitten compilen voor productie. Dacht dat ik dit ergens anders had geplaatst of willen plaatsen

[batjes]

Welke PHP versies zijn hierdoor dan geraakt?

Kan het niet terug vinden, ik gok PHP 8? Scheelt dan denk ik dat ik (net als de meeste volgens mij) nog op PHP7 zitten en op vele servers de autoupdate niet draait of iig niet dagelijks.

EDIT: Oh het is nooit in een release gekomen, betwijfel of mensen hun PHP op productie servers van de GIT trekken.

[Reactie gewijzigd door batjes op 23 juli 2024 01:26]

[dcm360]

Er is geen enkele release geweest tussen de commit en dat het opgemerkt is. Alleen als je zelf een build maakt vanuit de git-repository zou je een versie kunnen draaien met de backdoor er in, maar dat is nogal onwaarschijnlijk.

[The Zep Man]

Alleen als je zelf een build maakt vanuit de git-repository zou je een versie kunnen draaien met de backdoor er in, maar dat is nogal onwaarschijnlijk.

De (on)waarschijnlijkheid wordt bepaald door de tijd dat de backdoor in Git aanwezig was. Als je net de broncode in die tijd downloadde en gebruikte, dan ben je kwetsbaar. Die code zou sowieso niemand ooit in productie (of op iets dat aangesloten is op het internet) moeten gebruiken.

Zoals je al noemt, de code is geen onderdeel van een release en stond er minder dan een dag op. De kans op misbruik lijkt daarmee minimaal.

[TheBnl]

Is er bekend welke versies van php gebuild zijn met deze backdoor?

[Wiejeben]

De commits zijn op 28 maart uitgevoerd. De nieuwste stabiele PHP release was 8.0.2 op 4 februari, dus je hoeft je geen zorgen te maken.

[Tazzios]

Update: PHP 8.0.3 op 4 maart

[Wiejeben]

Oei dan wordt https://www.php.net/releases/index.php niet goed bijgehouden, had ik kunnen weten.

Edit: Sorry ja dat zijn dus de "unsupported releases" tijd om een bril te kopen haha.

[Reactie gewijzigd door Wiejeben op 23 juli 2024 01:26]

[Tazzios]

Die pagina kon ik niet. Er staat wel "Unsupported Historical Releases" boven maar als je op de url /releases zit zou je de meest recente verwachten, best listig.

[Wiejeben]

Blijkbaar moet je zijn op https://www.php.net/ChangeLog-7.php of https://www.php.net/ChangeLog-8.php. 4 maart inderdaad laatste release.

[DennusB]

Oei, heftig wel. Misschien is hun werkstation wel overgenomen en deden ze vanaf daar de commits. Lijkt me een goede actie dat ze de broncode gelijk hebben verhuisd!

[phjk]

Volgens het artikel ging het juist om de git.php.net server die aangevallen zou zijn, maar ben ook wel benieuwd hoe ze dit nu voor elkaar hebben gekregen.

[DennusB]

Dat was een vermoeden volgens het artikel, omdat ze niet exact weten hoe dit kon gebeuren.

[Scriptkid]

Tijd voor een PAW of SAW dan als dat waar is.

[Mitsuko]

Gingen de commits ook met een nieuwe release gepaard? Kan me niet voorstellen dat veel PHP servers ingesteld zijn om via een git pull (of fetch+merge/rebase) automatisch de software te updaten, maar misschien zie ik dat verkeerd.

[kwaakvaak_v2]

dat zie je verkeerd idd

Ik denk dat er weinig productie servers de main branch gebruiken ipv de tagged releases.

[Mitsuko]

Nou precies, dus ik verwacht niet dat dit er op veel plekken in is gekomen (gelukkig!)

[Veneus]

Dan ziet @Mitsuko het toch goed?

[Mopperman]

opvallend: er staat zelfs in de code:

Sold to Zerodium, mid 2017

Lijkt er bijna op dat de "aanvaller" wil aantonen dat er in mid 2017 een "lek" verkocht is, wat hiervoor gebruikt is, en blijkbaar niet gedicht was op de git server of in PHP?

[Reactie gewijzigd door Mopperman op 23 juli 2024 01:26]

[kwaakvaak_v2]

Of de HTTP header exploit client software is verkocht in 2017?

kan mij voorstellen dat iemand een exploit methode verzint, daar een client voor schrijft om vervolgens op zoveel mogelijk systemen die header exploit geinjecteerd te krijgen. Niet alleen voor PHP, maar ook voor andere server side talen/systemen zoals bijv Express.js of een GO-Lang HTTP server.