L’intent de porta posterior de PHP mostra la necessitat d’una millor verificació de l’autenticitat del codi

Els atacants desconeguts van aconseguir entrar al dipòsit de codi central del projecte PHP i afegir codi maliciós amb la intenció d’inserir una porta posterior al temps d’execució que alimenta la majoria de llocs web a Internet. Els pirates informàtics es van suplantar a dos desenvolupadors PHP d’alt perfil, però els compromisos de codi no eren gaire subtils i es van detectar en poques hores quan altres desenvolupadors els van revisar.

L’incident no va tenir un impacte generalitzat com el recent compromís de SolarWinds o altres atacs a la cadena de subministrament on les portes del darrere van convertir-se en versions estables de productes de programari i es van transmetre als usuaris habituals. Tanmateix, va fer que el Grup PHP, l’organització que manté PHP, reconsiderés com s’executa la seva infraestructura de codi.

El codi de codi obert es troba al nucli dels serveis crítics d’Internet i representa la majoria de la base de codis de les aplicacions modernes. El nombre d’atacs a la cadena de subministrament contra projectes de codi obert, que generalment són dirigits per voluntaris amb recursos limitats, ha augmentat considerablement durant els últims anys i els experts esperen que aquest vector d’atac creixi en popularitat entre els atacants, ja que és difícil de defensar.

Què va passar amb el repositori PHP?

El diumenge, un codi compromès amb el nom “[skip-ci] Corregir errors ortogràfics” es va enviar al repositori php-src a git.php.net. La confirmació es va fer en nom del fundador de PHP i desenvolupador principal Rasmus Lerdorf. Dues hores després, un altre col·laborador de PHP va comentar que el codi tenia una errada d’ortografia i una altra. preguntar sobre què feia el codi.

Bàsicament, el codi era una porta del darrere que hauria permès a un atacant executar codi arbitrari en qualsevol servidor web que executés aquesta versió troianitzada de PHP simplement enviant-li sol·licituds amb una cadena específicament dissenyada a la capçalera HTTP. Afortunadament, el codi maliciós es va detectar ràpidament gràcies a les bones pràctiques de revisió del codi i només va afectar la branca de desenvolupament de PHP 8.1 que no es preveu llançar fins al novembre i encara no s’utilitza en producció.

El que va passar a continuació va ser encara més intrigant: el desenvolupament del nucli de PHP, Nikita Popov, va revertir ràpidament el compromís de pícar realitzat en nom de Lerdorf, però poc després, la reversió de Popov es va revertir del que semblava ser el seu propi compte. En realitat, aquest va ser el pirata informàtic que va suplantar Popov i va restablir el codi maliciós.

Després que un tercer desenvolupador principal va intervenir i va revertir la confirmació maliciosa i el servidor es va deixar fora de línia, Popov va fer un anunci a la llista de correu PHP que deia: “Ahir (28/03/2021) es van enviar dues confirmacions malicioses al php-src. repo dels noms de Rasmus Lerdorf i jo. Encara no sabem com va passar això exactament, però tot apunta a un compromís del servidor git.php.net (en lloc d’un compromís d’un compte git individual).”

Segons Popov, després de l’atac, l’equip va decidir interrompre el seu propi servidor git i traslladar el desenvolupament a GitHub perquè mantenir la seva pròpia infraestructura git que utilitzava un sistema de karma de producció pròpia per al control d’accés era “un risc de seguretat innecessari”. El grup PHP ja utilitzava GitHub com a mirall per al seu repositori git autogestionat, però ara l’ha convertit en el dipòsit principal i està en procés de migrar tots els col·laboradors a l’organització PHP de GitHub, que requereix una autenticació de dos factors. per als comptes.

Va ser un atac de prova de concepte d’un hacker de barret gris?

“Això sembla tenir tots els distintius d’algú que intenta enviar un missatge”, diu a CSO per correu electrònic Ilkka Turunen, CTO de camp de l’empresa d’automatització DevOps i de govern de codi obert Sonatype. “Tot i que definitivament travessa el límit de la pirateria ètica de molt lluny, tenia un codi força evident i errors d’ortografia. […] El missatge, sembla, és que hi ha una superfície d’atac innecessària present a causa d’una infraestructura obsoleta com el servidor git autoallotjat, i això pot tenir conseqüències desastroses”.

Segons molts comentaristes de Twitter i Hacker News, el compromís no va ser gens subtil. Tenia [skip-ci] al nom, una cadena que fa que moltes eines de CI es saltin els seus fluxos de treball de creació i prova. Tot i que skip-ci és una convenció coneguda a la comunitat de desenvolupadors, el seu ús cridaria l’atenció si un projecte no l’utilitza sovint.

El codi maliciós també incloïa la cadena “zerodium” com a activador de la porta del darrere i el missatge “REMOVETHIS: venut a zerodium, mitjan 2017”. Zerodium és una empresa que compra exploits zero-days per a una varietat de sistemes operatius i aplicacions d’escriptori i web populars, inclòs el mateix PHP. Segons el seu lloc web, l’empresa ofereix fins a 250.000 dòlars per a una vulnerabilitat d’execució de codi remota en PHP.

Chaouki Bekrar, fundador i CEO de Zerodium, va dir a Twitter que l’empresa no va tenir res a veure amb l’incident i va descriure els pirates informàtics com a trolls.

Tant si pretenien com si no que el compromís de canalla fos fàcilment descobert, el nivell d’accés que tenien els atacants es podria haver utilitzat per introduir una vulnerabilitat més subtil al codi, com en l’intent de la porta del darrere de Linux del 2003, potser suplantant la identitat d’un desenvolupador que no és tan visible com Lerdorf o Popov a la comunitat PHP. De fet, Popov va assenyalar en el seu anunci que la investigació del projecte continua i inclourà una revisió de tots els dipòsits per a qualsevol “corrupció” addicional. No va respondre preguntes addicionals enviades per correu electrònic per CSO.

Validació de la font de commits de codi

Git admet la signatura de commits de codi amb claus GPG i aquesta funció també està present a GitHub tant per al codi compromès a través de la interfície basada en web com des d’una màquina local. L’objectiu de signar compromisos de codi és assegurar-se que el codi prové de comptes o persones en què l’organització confia. És una forma de verificació d’identitat que es basa en la criptografia de clau pública i GitHub adjuntarà un indicador verd “Verificat” als compromisos signats digitalment.

Tot i que alguns col·laboradors de PHP ja signen els seus commits, el projecte no va fer complir la verificació de la signatura com a requisit per a tots els commits. Això no és necessàriament inusual quan es tracta de grans projectes col·laboratius, ja que hi ha hagut un debat de llarga durada a la comunitat de codi obert sobre si cal signar tots els compromisos o només etiquetes (el codi es congela que normalment significa un llançament). Tanmateix, després de l’atac, els desenvolupadors de PHP estan considerant fer complir les confirmacions signades per almenys el dipòsit php-src.

“Des d’una perspectiva de verificació, com els administradors de la [Maven] Repositori central, Sonatype ha estat requerint codi de signatura com a mètode per verificar la identitat des del principi, exactament a causa de la pregunta de verificació d’identitat”, diu Turunen. “De cap manera és una bala de plata per a aquest tipus de problemes, ja que Central també utilitza. altres mètodes per verificar la identitat, però s’hauria de considerar seriosament com a part d’un esmorzar complet. Afegeix una capa de fricció i sens dubte no estarà exempt dels seus reptes d’enginyeria i, en última instància, cada projecte ha de decidir el nivell d’integritat que necessita, però com que estem parlant d’una infraestructura digital crítica, defensaríem una forta identificació dels committers”.

Les confirmacions de codi de signatura no evitaran tots els atacs de suplantació d’identitat. Per exemple, si la màquina d’un desenvolupador individual està compromesa i té la seva clau GPG privada, l’atacant podria signar codi maliciós localment i després cometre-lo des de la seva màquina. Hi ha maneres de mitigar aquests riscos mitjançant l’ús de mecanismes de seguretat addicionals, com ara l’emmagatzematge de claus en fitxes de maquinari externs o mòduls de seguretat de maquinari, però això pot crear complexitat i els projectes de codi obert generalment es mostren inquiets quan es tracta d’obstacles potencials que poden desanimar les contribucions dels voluntaris. Dit això, els grans projectes acostumen a donar privilegis de confirmació només a un nombre reduït de col·laboradors habituals i de confiança, no a tots els que enviïn codi per ser revisat per incloure’l.

“Aquest és un equilibri difícil d’assolir, amb la facilitat d’accés i de contribució, ja que els inquilins bàsics de l’ethos de codi obert es van comparar amb la necessitat de seguretat i aplicació”, diu Turunen. “No hi ha seguretat a prova de bales i, per naturalesa, els ecosistemes de codi obert continuaran sent objectiu d’intents d’atac a la cadena de subministrament, com hem vist en tots els ecosistemes principals una i altra vegada. Defensem qualsevol mesura que es pugui prendre per garantir i verificar. la identitat dels committers almenys per a les parts crítiques de la infraestructura i el codi hauria de ser una, tal com hem triat fer amb Maven Central”.

Servei d’allotjament propi i de tercers

Tot i ser àmpliament utilitzats i confiats, molts projectes de codi obert pateixen una escassetat de recursos humans i financers. Mantenir la infraestructura d’un gran projecte de desenvolupament i assegurar-se que sigui segur a més d’això és una gran empresa que fins i tot les grans empreses comercials sovint fracassen. Molts projectes de codi obert estan dirigits per voluntaris que tenen altres treballs a temps complet. Per exemple, quan el 2014 es va trobar l’error crític Heartbleed a OpenSSL, la gent es va sorprendre al saber que el projecte OpenSSL només tenia dos desenvolupadors a temps complet encarregats de la seva enorme i complexa base de codi que utilitzaven milers de milions de dispositius, servidors i aplicacions. . Després d’aquest incident, la Fundació Linux, en col·laboració amb les principals empreses d’Internet, va llançar la Core Infrastructure Initiative (CII) per finançar projectes que són crítics per a Internet.

En traslladar la seva infraestructura de codi a un servei de tercers com GitHub, els projectes de codi obert poden subcontractar l’administració i la seguretat del servidor a un proveïdor de serveis que hagi pagat empleats a temps complet amb l’experiència per fer aquestes tasques raonablement bé des de l’èxit del seu negoci. i la reputació en depèn. Decisions com la que va prendre el Grup PHP per retirar alguns dels seus serveis autoallotjats poden ser inevitables per a projectes similars, ja que busquen protegir millor els seus usuaris de possibles compromisos de la cadena de subministrament.

“Allotjar qualsevol infraestructura és un compromís de manteniment que va més enllà d’actualitzar el programari o els serveis”, diu Turunen. “Veiem regularment que s’exploten vulnerabilitats conegudes menys de 24 hores després de la divulgació, cosa que exerceix una pressió immensa sobre la infraestructura autoallotjada perquè es mantingui actualitzada. En aquest cas, els proveïdors més grans poden oferir una economia d’escala en la infraestructura i el manteniment de programari per a un manteniment més petit. els equips simplement no poden arribar, ja que no està en la seva competència bàsica. Cal dir-ho, però, de vegades aquestes decisions es prenen tenint en compte la filosofia i l’ethosis de codi obert més ampli. No hi ha una resposta general, però una cosa que qualsevol projecte important hauria de tenir en compte definitivament. com a opció per al futur”.

Copyright © 2021 IDG Communications, Inc.

Leave a Comment

Your email address will not be published. Required fields are marked *