Atac a la cadena de subministrament de repo de Packagist PHP: 3 punts clau

Una vulnerabilitat del repositori PHP va amenaçar milions de llocs. Heus aquí per què heu de fer d’un SBOM el primer pas del vostre viatge de seguretat de la cadena de subministrament de programari.

S’ha corregit una vulnerabilitat que amenaçava la seguretat de milions de llocs web que utilitzaven el llenguatge de script PHP, segons un investigador de seguretat de SonarSource, una empresa suïssa que desenvolupa programari de seguretat i qualitat de codi. Rl’investigador Thomas Chauchefoin va explicar en una publicació al bloc de l’empresa que la fallada permet que un atacant aconsegueixi el control de Packagistque fa servir el gestor de PHP anomenat Composer per determinar i descarregar les dependències de programari incloses pels desenvolupadors en els seus projectes.

Chauchefoin va assenyalar que pràcticament totes les organitzacions que executen codi PHP utilitzen Composer, que ofereix dos mil milions de paquets de programari cada mes. Més de cent milions d’aquestes sol·licituds podrien haver estat segrestades per distribuir dependències malicioses i comprometre milions de servidors, va escriure.

En atacar els servidors que executen Packagist, que associa el nom d’un paquet amb la seva ubicació, els actors de l’amenaça podrien obligar els usuaris a descarregar dependències de programari amb porta posterior la propera vegada que facin una instal·lació nova o una actualització d’un paquet de Composer basant-se en dades del 2021. Com que Composer és el gestor de paquets estàndard per a PHP, va explicar Chauchefoin, la majoria dels projectes PHP comercials i de codi obert s’haurien vist afectats.

Els mantenedors del servei afectat van solucionar la vulnerabilitat en poques hores, va afegir, i es creu que mai es va explotar en estat salvatge.

Chauchefoin va assenyalar que els usuaris de la instància predeterminada, oficial de Packagist o Private Packagist, estan segurs perquè les seves instàncies de producció pública s’han pegat. Per a les organitzacions que integren Composer com a biblioteca i que operen en repositoris no fiables, recomana actualitzar a Composer 1.10.26, 2.2.12 o 2.3.5.

Aquests són els punts clau de l’atac de la cadena de subministrament de programari de Packagist.

[ Get a free SBOM and full supply chain risk analysis report ]

1. Repositoris de programari: un jackpot per als adversaris

Els atacs als dipòsits de programari són especialment perillosos, va observar Henrik Plate, investigador de seguretat d’Endor Labs, una empresa de gestió de dependències. “Poden permetre que el programari maliciós no només infecti projectes únics de codi obert, sinó tots els projectes que distribueixen artefactes binaris a través del dipòsit”, va dir.

“Packagist.org, el dipòsit de paquets per a paquets PHP, allotja un total de 3,6 milions d’artefactes binaris per a 353 mil paquets de codi obert diferents”, va escriure Chauchefoin. “La vulnerabilitat CVE-2022-24828, que s’ha descobert al gestor de paquets PHP anomenat Composer, podria haver donat lloc a l’execució de codi remota a packageagist.org, amb el possible compromís de nombrosos projectes i artefactes allotjats en aquest repositori”.

“Això seria un jackpot per als adversaris de qualsevol tipus, sense importar si tenen la intenció de llançar atacs molt específics contra un únic projecte o una gran campanya a tot l’ecosistema”.
—Thomas Chauchefoin

La dependència de la indústria del programari del codi obert i la seva generalització la converteixen en un objectiu convincent per als atacs a la cadena de subministrament, va afegir. Atacar projectes de codi obert amunt també té l’avantatge considerable d’estendre’s a molts consumidors potencials, va continuar.

“La superfície d’atac combinada de milers de projectes de codi obert és molt més gran que la infraestructura de desenvolupament de qualsevol proveïdor donat. Si un atacant té sort i és capaç d’injectar programari maliciós en un projecte de codi obert de gran èxit, milers d’usuaris directes i indirectes es poden infectar en un instant”.
Thomas Chauchefoin

Ken Arora, un distingit enginyer de ciberseguretat i arquitecte de F5, una empresa de serveis i seguretat d’aplicacions multinúvol, va dir que, a més d’infectar els objectius aigües avall, es poden utilitzar repositoris compromesos per crear un punt de suport per a una varietat de males.

“Aquest punt de peu es pot utilitzar com a plataforma de llançament per al moviment lateral dins de la infraestructura de l’aplicació”.
—Ken Arora

Els components compromesos també es poden utilitzar per accedir a dades protegides d’aplicacions, com ara taules de bases de dades i cubs S3; anul·lació dels fitxers de configuració crítics rellevants per a la seguretat; o ser un conducte per obrir connexions a Internet externa per a l’exfiltració de dades, va afegir.

2. Seguretat de la cadena de subministrament de programari: la complexitat crea reptes

La vulnerabilitat de Packagist il·lustra un problema creixent amb les cadenes de subministrament de programari: complexitat, va dir Ed Moyle, director de seguretat de sistemes i programari de Drake Software, fabricant de solucions fiscals i comptables i membre del grup de treball de tendències emergents d’ISACA.

Ja estem en el punt que la gestió de la dependència s’ha d’automatitzar en molts casos per ser viable, va dir. Els gestors de paquets i similars s’utilitzen per necessitat, és a dir, per tal de garantir que els mòduls adequats i les versions correctes d’aquests mòduls estiguin allà on han d’estar, es requereix automatització, va explicar Moyle.

“A causa de la complexitat de gestionar-ho, el propi gestor de paquets pot ser un objectiu molt temptador. Per què? Com que podeu comprometre múltiples víctimes alhora, podeu fer-ho d’una manera sigilosa que no requereixi atacar activament l’objectiu aigües avall, i ho podeu fer d’una manera per a la qual la majoria de les organitzacions no estaran preparades”.
—Ed Moyle

Daniel Kennedy, director d’investigació de seguretat de la informació i xarxes de 451 Research, que forma part de S&P Global Market Intelligence, va dir que els pirates informàtics no estan sols a explotar la complexitat de la cadena de subministrament per inserir codi no desitjat en projectes de codi obert.

Mantenidors destacats estan afegint codi contraproduent per motius de protesta per qüestions geopolítices, va dir.

La complexitat d’alguns d’aquests components, i els subcomponents que utilitzen, dificulta veure on s’ha afegit codi contraproduent durant una actualització. Normalment, fer una revisió completa del codi de les actualitzacions de codi obert no ho és factible per a un empresai d’alguna manera derrota el propòsit d’aprofitar el codi font obert en primer lloc”.
—Daniel Kennedy

3. El cas dels SBOM: cal avaluació contínua

Una de les maneres en què les organitzacions intenten reduir els riscos del programari de codi obert és mitjançant l’ús d’una llista de materials de programari (SBOM), va dir Ed Skoudis, president de l’Institut Tecnològic SANS.

SBOM exigeix ​​als venedors de programari una llista de paquets de programari i biblioteques que van utilitzar per crear el seu programari. “Totes les organitzacions no tenen el temps ni els mitjans per veure si cada component té problemes, però tenint aquesta informació a mà, tenir aquesta llista de ingredientsempeny els venedors a estar oberts i mostrar què passa amb els seus productes”, va dir Skoudis.

“Una llista de materials del programari treu una gran mossegada al problema”.
—Ed Skoudis

La clau per protegir-se dels atacs de la cadena de subministrament als components de codi obert amunt és seleccionar i avaluar acuradament les dependències, no només una vegada, quan les inclouen per primera vegada, sinó de manera contínua, va dir Henrik Plate, investigador de seguretat d’Endor Labs.

“Les organitzacions han de decidir i controlar un conjunt de mètriques o indicadors clau durant el cicle de vida de les seves dependències de programari, no només per a les dependències directes sinó també per a les indirectes”.
—Henrik Plate

Ratan Tipirneni, president i conseller delegat de Tigera, un proveïdor de seguretat i observabilitat per a contenidors, Kubernetes i núvol, va assenyalar que si bé Log4j era la vulnerabilitat que va cridar l’atenció de tothom i va fer notícia nacional, el 2021 es van anunciar més de 4.000 vulnerabilitats d’alta gravetat. El recent descobriment de la fallada de seguretat d’alta gravetat al dipòsit de programari Packagist, demostra encara més que es continuen descobrint vulnerabilitats greus.

A mesura que augmenta el ritme d’innovació combinat amb l’ús de biblioteques de codi obert, seguirem veient un augment de les vulnerabilitats i les amenaces, va dir Tipirneni. “Aquest és un signe nefast per als equips de seguretat i DevOps molt restringits”.

“És gairebé impossible que cap DevOps o equip de seguretat estigui al dia amb els atacants. Per tancar la bretxa de seguretat, les empreses hauran d’apropar en profunditat els principis de confiança zero i defensa a tot el pipeline CI/CD per mitigar activament els riscos amb una combinació de mesures preventives i defensa activa”.
—Ratan Tipirneni

Segueix aprenent

Imatge cortesia de Pàgina de Twitter de Packagist.

*** Aquest és un bloc sindicat de Security Bloggers Network de ReversingLabs Blog escrit per John P. Mello Jr.. Llegeix la publicació original a: https://blog.reversinglabs.com/blog/packagist-php-repo-supply-chain -amenaça-el-que-necessites-saber

Leave a Comment

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