Y lo que pasa en las mejores familias,

tenemos que hablar de los ataques en el

ecosistema de PHP. PHP, sí, muchas veces

hablamos de JavaScript, mucha gente se

queja de JavaScript. De hecho, me hizo

mucha mucha gracia el comentario de

Damián Catanzaro, no me salía el nombre

del chico este. Damián Catanzaro me hizo

mucha gracia porque, a ver si os lo

encuentro a este este comentario, porque

el otro día, por todos los ataques que

había en el ecosistema de JavaScript

comentaba esto, no estoy para volver a

PHP con jQuery y luego dice, "No se está

salvando un solo framework, se cancela

volver a PHP. Nos quedamos en HTML con

GQuery. ¿Y por qué? Porque resulta que

hemos tenido un nuevo ataque, la cadena

de suministro en la organización del

Arabel. Más de 700 versiones históricas

entre diferentes paquetes mantenidos por

la comunidad del Arabel fueron

comprometidos con puertas traseras para

ejecución de código en remoto. algunos

paquetes bastante importantes que son

descargados cientos de miles de veces en

el ecosistema de PHP, en Lara, Lara,

Lang L, http statuses, attributes,

actions, un montón y ha sido pues

bastante bastante preocupante, bastante

preocupante. Así que sí, esto es del

otro día, algunas versiones que

afectaban a la 12, 13, 14x, 15x, un

montón de versiones y con un impacto

bastante bastante bestia. Así que nada,

ahí lo tenéis. Todas las versiones

publicadas publicaron un montón, más de

700 versiones. O sea, una verdadera

salvajada lo que hicieron de publicar

versiones. Obviamente si instalaste una

de estas, estás bien [ __ ] Pero lo

peor es que no solo pilló el Arabel,

sino que también pilló Composer, PHP

Composer. Y en este caso el ataque de

estos ocho paquetes fue por culpa, no

por culpa, sino que utilizaron pack

Jason. El tema es que Composer utiliza

los packagons para ejecutar algunos

scripts y a partir de eso aquí podéis

ver los post install que estaba

utilizando para inyectar el script y

también poder infectarte. De hecho, aquí

podemos ver, a ver si lo encuentro,

githaub.com.

Esto es lo que estaba ejecutando. Vamos

a ver si lo podemos buscar por aquí. A

ver si hay alguno infectado todavía.

Aquí está. Aquí lo tenéis. ¿Ves este

tracking expos de Facebook? Aquí podéis

ver que lo tiene infectado. Todo esto

está infectado. Todo esto está

infectado. O sea, tú te descargas uno de

estos repositorios, cualquiera de estos

repositorios y ya está [ __ ] Está

[ __ ] directamente. Y a lo mejor es un

repositorio que, yo que sé. Mira, Travel

Guide. Pues en este Travel Guide, en

este package Jason, pues han metido aquí

este package Jason, han metido aquí este

post install y ahí está [ __ ]

Entonces, ¿podemos probarlo? Claro que

sí, Mateo. Puedes hacer un pmstol, pero

por suerte tenemos una buena noticia,

algo que me alegro ya que ya hace falta.

Todos estos ataques son siempre los

mismos, que es que con npm install se

ejecuta por defecto el post install y es

un rollo. Bueno, pues por suerte van a

hacer por fin hay un RFC, es un request

for changes para npm para que por fin

por defecto no se ejecuten scripts, los

preinstall, los install y los post

install y que tengas manualmente que

aprobar los scripts. Esto llegaría a npm

por fin, ¿vale? para que no se ejecute

automáticamente. ¿Qué es lo que ocurre

hoy? Y es que, como ya sabéis, tanto los

ataques de Shai Hulut, que es muy

parecido a lo que estamos viendo ahora,

como el ataque en Axios, en chalk, en

the back y un montón de paquetes que han

sido afectados, ha sido exactamente por

lo mismo y parece ser que va a llegar

eventualmente a MPM. Así que nada, vamos

a ver si por fin ocurre, porque ya hace

falta que esto pase para que por defecto

sea seguro en PM. O sea, es un vector de

ataque que hace demasiado tiempo que

están utilizando, que están que están

aprovechándose. Ya yo creo que es el

momento de dejar esto atrás. Y lo peor,

amigos, es que sé que mucha gente dice,

"No, es que esto es el ecosistema de

JavaScript, que no sé qué, no sé

cuánto." Bueno, pues tenemos no ataque

solo a PM, sino que también en PP, el

Python Package Index, el sitio donde

puedes encontrar paquetes de Python,

pues también tienes. Y también en

crates.Oio en el registro de paquetes de

Rust. En todos, en todos, en todos han

estado metiendo un montón de paquetes,

más de 384 paquetes, que lo que hacían

era robarte los cryptoallets, los las

llaves SSH, credenciales AWS, tokens de

GitHub y tal, o sea, tanto en el

registro de Rust, en el de Python y como

hemos visto también en el de PHP. O sea,

que al final tienes que tener cuidado.

Muchas veces lo hacen con paquetes que

se parecen a paquetes que son paquetes

conocidos. En otros pues paquetes

utilizando paquetes que son conocidos y

que les roban los tokens. Así que nada,

ha llegado a todos, a Python, a Rust y

también a MPM. Tengan mucho, pero mucho

cuidado. ¿Y cómo pueden tener cuidado?

Pues lo responde el Team PCP. El Team

PCP es este grupo de hackers que ha

estado hackeando un montón el ecosistema

de de JavaScript y de Python. y le han

hecho una entrevista donde le han

preguntado qué deberían hacer los

defensores para detener los ataques a la

cadena de suministro, que son todos los

ataques que han estado pasando estas

semanas. Y su consejo es fijar versiones

a un hash específico. Esto, por cierto,

es una cosa que yo os he comentado

muchas veces. Usar tokens de privilegio

mínimo. Esto es de cajón. En lugar de

utilizar un token que tenga eh

superpoderes, utilizar tokens que sean

muy específicos en concreto. Restringir

extensiones del IDE, de esto también os

comenté el otro día. Y luego

textualmente dijeron, "La empresa Socket

detectará el Marwell antes de que el

paquete siquiera llegue a tu máquina." Y

esto es porque Socket Security, esta

gente de aquí, son los que siempre están

detectando rápidamente el malware que

llega a un montón de ecosistemas. tienen

una herramienta que se llama SFW

que te puede ayudar a detectar este tipo

de paquetes para evitar que lleguen. No,

no vamos a poner esto en la página de

testimonios porque Feroz trabaja en

Socket Security, pero al mismo tiempo si

aún no estás utilizando Socket Security

para proteger tu cadena de suministro,

¿a qué estás esperando? Curioso que han

hecho una entrevista a los hackers y que

encima te den consejos para no

infectarte. Ya es el colmo del colmo.