NPM continua con los problemas de seguridad y ahora uno afectaba al sistema de actualizaciones

Hace algunos dias GitHub revelo dos incidentes en la infraestructura del repositorio de paquetes de NPM, de los cuales detalla que el 2 de noviembre, investigadores de seguridad de tercero como parte del programa Bug Bounty encontraron una vulnerabilidad en el repositorio de NPM que permite publicar una nueva versión de cualquier paquete utilizando aunque no está autorizado para realizar dichas actualizaciones.

La vulnerabilidad fue causada por verificaciones de autorización incorrectas en el código de microservicios que procesan solicitudes a NPM. El servicio de autorización realizó una verificación de permisos en los paquetes en función de los datos pasados ​​en la solicitud, pero otro servicio que cargaba la actualización en el repositorio determinó el paquete a publicar en función del contenido de metadatos en el paquete cargado.

Así, un atacante podría solicitar la publicación de una actualización para su paquete, al que tiene acceso, pero indicar en el propio paquete información sobre otro paquete, que eventualmente sería actualizado.

Durante los últimos meses, el equipo de npm ha estado invirtiendo en mejoras de infraestructura y seguridad para automatizar el monitoreo y análisis de las versiones recientemente publicadas de paquetes con el fin de identificar malware y otros códigos maliciosos en tiempo real.

Hay dos categorías principales de eventos de publicación de malware que ocurren en el ecosistema npm: malware que se publica debido a la apropiación de cuentas y malware que los atacantes publican a través de sus propias cuentas. Aunque las adquisiciones de cuentas de alto impacto son relativamente poco frecuentes, en comparación con el malware directo publicado por atacantes que utilizan sus propias cuentas, las adquisiciones de cuentas pueden tener un gran alcance cuando se dirigen a los mantenedores de paquetes populares. Si bien nuestro tiempo de detección y respuesta a las adquisiciones de paquetes populares ha sido tan bajo como 10 minutos en incidentes recientes, continuamos evolucionando nuestras capacidades de detección de malware y estrategias de notificación hacia un modelo de respuesta más proactivo

El problema se solucionó 6 horas después de que se informó de la vulnerabilidad, pero la vulnerabilidad estuvo presente en NPM más tiempo de lo que cubren los registros de telemetría. GitHub afirma que no se han registrado rastros de ataques que utilicen esta vulnerabilidad desde septiembre de 2020, pero no hay garantía de que el problema no haya sido explotado antes.

El segundo incidente tuvo lugar el 26 de octubre. En el curso del trabajo técnico con la base de datos del servicio replicant.npmjs.com, se reveló que había datos confidenciales en la base de datos disponibles para consultas externas, revelando información sobre los nombres de los paquetes internos que se mencionaron en el registro de cambios.

La información sobre dichos nombres se puede utilizar para llevar a cabo ataques a dependencias en proyectos internos (en febrero, tal ataque permitió que se ejecutara código en los servidores de PayPal, Microsoft, Apple, Netflix, Uber y otras 30 empresas).

Además, en relación con la creciente incidencia de incautación de repositorios de grandes proyectos y la promoción de código malicioso a través del compromiso de las cuentas de los desarrolladores, GitHub decidió introducir la autenticación obligatoria de dos factores. El cambio entrará en vigor en el primer trimestre de 2022 y se aplicará a los mantenedores y administradores de los paquetes incluidos en la lista de los más populares. Adicionalmente, se informa sobre la modernización de la infraestructura, en la que se introducirá el monitoreo y análisis automatizado de nuevas versiones de paquetes para la detección temprana de cambios maliciosos.

Recordemos que según un estudio realizado en 2020, solo el 9.27% ​​de los administradores de paquetes usan autenticación de dos factores para proteger el acceso, y en el 13.37% de los casos, al registrar nuevas cuentas, los desarrolladores intentaron reutilizar contraseñas comprometidas que aparecen en contraseñas conocidas.

Durante el chequeo de la solidez de las contraseñas utilizadas, se logró acceder al 12% de las cuentas en NPM (13% de los paquetes) debido al uso de contraseñas predecibles y triviales como «123456». Entre las problemáticas se encontraban 4 cuentas de usuario de los 20 paquetes más populares, 13 cuentas cuyos paquetes se descargaron más de 50 millones de veces al mes, 40 – más de 10 millones de descargas al mes y 282 con más de 1 millón de descargas al mes. Teniendo en cuenta la carga de módulos a lo largo de la cadena de dependencias, comprometer cuentas que no son de confianza podría afectar hasta el 52% de todos los módulos en NPM en total.

Finalmente, si estás interesado en poder conocer más al respecto puedes consultar los detalles en el siguiente enlace.


El contenido del artículo se adhiere a nuestros principios de ética editorial. Para notificar un error pincha aquí.

Sé el primero en comentar

Deja tu comentario

Tu dirección de correo electrónico no será publicada.

*

*

  1. Responsable de los datos: AB Internet Networks 2008 SL
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.