Una vulnerabilidad que permitía lanzar una actualización para cualquier paquete en el repositorio de NPM

GitHub ha revelado dos incidentes en su infraestructura de repositorio de paquetes NPM. El 2 de noviembre, investigadores de seguridad externos (Kajetan Grzybowski y Maciej Piechota), como parte del programa Bug Bounty, informaron la presencia de una vulnerabilidad en el repositorio de NPM que le permite publicar una nueva versión de cualquier paquete usando su cuenta. que no está autorizado a realizar dichas actualizaciones.

La vulnerabilidad fue causada por comprobaciones de permisos incorrectas en el código de los microservicios que procesan solicitudes a NPM. El servicio de autorización realizó comprobaciones de permisos de paquetes en función de los datos pasados ​​en la solicitud, pero otro servicio que cargó la actualización en el repositorio determinó el paquete a publicar en función del contenido de metadatos del paquete cargado. Así, un atacante podría solicitar la publicación de una actualización de su paquete, al que tiene acceso, pero especificar en el propio paquete información sobre otro paquete, que eventualmente sería actualizado.

El problema se solucionó 6 horas después de que se informara la vulnerabilidad, pero la vulnerabilidad estuvo presente en NPM durante más tiempo del que cubren los registros de telemetría. GitHub afirma que no ha habido 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 ocurrió el 26 de octubre. Durante el trabajo técnico con la base de datos del servicio replicate.npmjs.com, se reveló la presencia de datos confidenciales en la base de datos accesible a solicitudes 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 puede utilizarse para llevar a cabo ataques de dependencia en proyectos internos (en febrero, un ataque similar permitió ejecutar código en los servidores de PayPal, Microsoft, Apple, Netflix, Uber y otras 30 empresas).

Además, debido al creciente número de casos de secuestro de repositorios de grandes proyectos y promoción de códigos maliciosos a través de cuentas de desarrolladores comprometidas, GitHub ha decidido 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 paquetes incluidos en la lista más popular. Además, se informa sobre la modernización de la infraestructura, en la que se introducirá 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 mantenedores de paquetes utilizan la 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 aparecían en fugas de contraseñas conocidas. Durante una revisión de seguridad de contraseñas, se accedió al 12 % de las cuentas 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 con paquetes descargados más de 50 millones de veces al mes, 40 con 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 una cadena de dependencias, el compromiso de cuentas que no son de confianza podría afectar hasta el 52% de todos los módulos en NPM.

Fuente: opennet.ru

Añadir un comentario