Hace poco se dio a conocer la noticia de que se identificó una vulnerabilidad crítica en el repositorio de paquetes de RubyGems.org (la vulnerabilidad ya está catalogada bajo el CVE-2022-29176), que permite sin la debida autorización, reemplazar los paquetes de otras personas en el repositorio al iniciar el retiro (yank) de un paquete legítimo y cargar otro archivo con el mismo nombre y número de versión en su lugar.

Se menciona que la vulnerabilidad se debe a un error en el controlador de acciones «yank», que trata la parte del nombre después del guion como el nombre de la plataforma, lo que hizo posible iniciar la eliminación de paquetes externos que coinciden en la parte del nombre hasta el carácter de guion.

En particular, en el código del controlador de la operación «yank», la llamada ‘find_by!(full_name: «#{rubygem.name}-#{slug}»)’ se usaba para buscar paquetes, mientras que el parámetro «slug» se pasaba el propietario del paquete para determinar la versión que se eliminará.

El propietario del paquete «rails-html» podría haber especificado «sanitizer-1.2.3» en lugar de la versión «1.2.3», lo que haría que la operación se aplicara al paquete «rails-html-sanitizer-1.2.3″ de otra persona. »

Ayer se publicó un aviso de seguridad para Rubygems.org.

El aviso se refería a un error que permitía a un usuario malicioso extraer ciertas gemas y cargar diferentes archivos con el mismo nombre, el mismo número de versión y una plataforma diferente.

Echemos un vistazo más profundo para ver qué salió mal al pasar por el proceso de extracción. Como pretexto, imaginemos un escenario en el que creamos una gema llamada «rails-html» con la intención de obtener acceso no autorizado a la gema «rails-html-sanitizer», ampliamente utilizada.

Se menciona que se deben cumplir tres condiciones, para poder explotar con éxito esta vulnerabilidad:

• El ataque solo se puede realizar sobre paquetes que tengan un carácter de guión en su nombre.
• Un atacante debe poder colocar un paquete de gemas con parte del nombre hasta el carácter de guión. Por ejemplo, si el ataque es contra el paquete «rails-html-sanitizer», el atacante debe colocar su propio paquete «rails-html» en el repositorio.
• El paquete atacado debe haber sido creado en los últimos 30 días o no haber sido actualizado durante 100 días.

El problema fue identificado por un investigador de seguridad como parte del programa de recompensas de HackerOne para encontrar problemas de seguridad en proyectos de código abierto conocidos.

El problema se solucionó en RubyGems.org el 5 de mayo y según los desarrolladores, aún no han identificado rastros de explotación de la vulnerabilidad en los registros durante los últimos 18 meses. Al mismo tiempo, hasta ahora solo se ha llevado a cabo una auditoría superficial y se planea una auditoría más profunda en el futuro.

En la actualidad, creemos que esta vulnerabilidad no ha sido explotada.

RubyGems.org envía un correo electrónico a todos los propietarios de gemas cuando se publica o elimina una versión de gema. No hemos recibido ningún correo electrónico de soporte de propietarios de gemas que indiquen que su gema haya sido extraída sin autorización.

Una auditoría de cambios de gemas durante los últimos 18 meses no encontró ningún ejemplo de uso malicioso de esta vulnerabilidad. Una auditoría más profunda para cualquier posible uso de este exploit no encontró ningún ejemplo de este exploit utilizado para apoderarse de una gema sin autorización en la historia de RubyGems. No podemos garantizar que nunca sucedió, pero no parece probable.

Para verificar sus proyectos, se recomienda analizar el historial de operaciones en el archivo Gemfile.lock La actividad maliciosa se expresa en presencia de cambios con el mismo nombre y versión, o un cambio de plataforma (por ejemplo, cuando un paquete xxx-1.2.3 se actualiza a xxx-1.2.3-xxx).

Como solución contra la suplantación de identidad de paquetes ocultos en sistemas de integración continua o al publicar proyectos, se recomienda a los desarrolladores que utilicen Bundler con las opciones «–frozen» o «–deployment» para confirmar dependencias.

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