npm ha lanzado una nueva protección esta semana para sus cuentas con más dependencias. Cuando npm detecta una acción sensible en una cuenta de alto impacto, como un cambio de correo electrónico o el uso de un código de recuperación de 2FA, pone esa cuenta en un estado de solo lectura durante 72 horas y envía una alerta a la dirección de correo electrónico anterior. Las instalaciones y descargas de paquetes siguen funcionando con normalidad durante este tiempo, y el bloqueo se levanta automáticamente al final del período de espera.
Esta actualización previene acciones que afectan al registro o a la seguridad de la cuenta, como la publicación, la gestión de tokens, los cambios de visibilidad de paquetes y los cambios de membresía de la organización. Es un control a nivel de registro para detectar rápidamente cuando una cuenta empieza a escapar del control de su propietario.
Esto es genial, y es solo la última de una serie de mejoras de seguridad de npm. Nos proporcionaron la publicación por etapas en mayo y bloquearán los scripts post-instalación por defecto en la v12 en julio. Los valores predeterminados se están inclinando lentamente hacia la prevención y lejos de la reacción. Microsoft ha estado trabajando intensamente últimamente en correcciones de seguridad, probablemente inspirado por una serie de ataques de malware que ocurren en sus plataformas (y a sus plataformas).
npm no ha vuelto a establecer un umbral para esta característica, pero ya ha utilizado el término antes. Su política de aplicación de 2FA define una cuenta de alto impacto como aquella que gestiona paquetes con más de 1 millón de descargas semanales o 500 dependencias, y es probable que el período de enfriamiento utilice los mismos criterios.
El impulso para este cambio
El reciente compromiso de axios en marzo y el ataque de Mastra la semana pasada son los ejemplos más claros en la memoria reciente de por qué esto es necesario. Estos ataques utilizaron campañas de ingeniería social contra las cuentas objetivo para obtener acceso. En el caso de axios, el atacante se hizo pasar por un fundador de la empresa y atrajo a un mantenedor principal a una videollamada. El enlace de la llamada contenía un aviso de "su sistema está desactualizado" que instaló un troyano de acceso remoto (RAT), entregando al atacante el control de la máquina de la víctima y una sesión activa de npm. Cambiaron el correo electrónico de la cuenta y luego publicaron directamente dos versiones maliciosas de axios, evitando todo el sistema de CI. axios realiza aproximadamente 100 millones de descargas a la semana.
Este tipo de ataque es en su mayoría invisible para el registro, al igual que los pasos en Slack y la máquina comprometida. El cambio de correo electrónico es el único paso en la secuencia que npm puede observar. Los atacantes cambian los correos electrónicos porque interrumpe la ruta de recuperación del propietario real y redirige las alertas de seguridad lejos de ellos.
Cómo encaja con otros cambios de seguridad de npm
El período de enfriamiento es aún más útil si se considera junto con las dos correcciones que npm lanzó en el último año aproximadamente.
La publicación de confianza elimina los tokens de larga duración. La publicación se autentica a través de credenciales OIDC de corta duración, con ámbito a un flujo de trabajo de CI, por lo que no hay un token de larga duración en una máquina para que un RAT lo robe. Sin embargo, no sirve de mucho cuando un atacante tiene una sesión activa y publica directamente.
La publicación por etapas, que obtuvimos el mes pasado, añade un paso de aprobación humana. Un paquete preparado desde CI no se activa hasta que un mantenedor lo aprueba con 2FA, por lo que un flujo de trabajo automatizado por sí solo no puede lanzar una versión al mundo. Un atacante que controla la cuenta puede eludir esto aprobando su propio paquete preparado, si el paquete lo tiene habilitado.
Juntas, la publicación de confianza gestiona las credenciales robadas, la publicación por etapas gestiona las versiones automatizadas no revisadas, y el período de enfriamiento gestiona la toma de control de cuentas que las otras dos eluden. Por supuesto, esto no lo resuelve todo, pero si tienes la publicación de confianza solo por etapas y los tokens deshabilitados, estás previniendo una buena parte de las rutas de publicación que los atacantes han estado utilizando.
¿Qué hacer ahora?
Si mantienes un paquete popular, verifica que el correo electrónico de tu cuenta de npm sea uno que controles y monitorees activamente (de lo contrario, te perderás su alerta por correo electrónico). Pásate a FIDO2 donde puedas. Trata un aviso inesperado de cambio de correo electrónico como un incidente de seguridad en lugar de spam o un error. Si publicas desde CI, configura la publicación de confianza solo por etapas y deshabilita los tokens, para que cada versión pase por una aprobación humana y no haya credenciales de larga duración que robar. Si recibes un correo electrónico inesperado sobre un cambio de cuenta, contacta con el soporte de npm.
Si consumes paquetes en lugar de publicarlos, ¡enhorabuena! Te beneficias sin hacer nada. Aun así, algunos paquetes no tendrán todas sus medidas de seguridad habilitadas (muchos todavía no tienen estas configuraciones de seguridad activadas). Safe Chain de Aikido es un wrapper gratuito y de código abierto para npm, npx y yarn que verifica cada paquete en busca de malware antes de la instalación y aplica un período de espera en las nuevas versiones, lo que detecta una buena parte de las versiones comprometidas antes de que lleguen a tu máquina.
Ha sido genial poder escribir últimamente sobre los cambios positivos en los registros de paquetes.
