Object Injection

La deserialización de datos que no son de confianza permite la inyección de objetos de Ruby arbitrarios, lo cual puede provocar que el programa ejecute comandos malintencionados en nombre de un usuario malintencionado.

Las vulnerabilidades de inyección de objetos se producen cuando los datos que no son de confianza no se corrigen correctamente antes de transferirlos a la función que deserializa los datos como YAML.load(). Los usuarios malintencionados podrían transferir cadenas serializadas especialmente diseñadas a una llamada YAML.load() vulnerable, dando como resultado la inyección de objetos de Ruby arbitrarios en el programa, siempre y cuando la clase se cargue en la aplicación en el momento de deserialización. Esto puede facilitar un montón de oportunidades de ataques diversos, como omitir la lógica de validación para buscar vulnerabilidades de Cross-Site Scripting, permitir la SQL Injection a través de lo que parecen ser valores codificados o incluso la ejecución de código completa.

Ejemplo 1: El siguiente código muestra una clase de Ruby que crea una consulta SQL con sus atributos que luego se utiliza para consultar en la base de datos. También hay una llamada no segura a YAML.load() con datos proporcionados por el usuario.

...
class Transaction
  attr_accessor :id
  def initialize(num=nil)
    @id = num.is_a?(Numeric) ? num : nil
  end

  def print_details
    unless @id.nil?
      print $conn.query("SELECT * FROM transactions WHERE id=#{@id}")
    end
  end
end

...
user = YAML.load(params[:user]);
user.print_details
...

En el Example 1, la aplicación puede estar esperando a un objeto de User serializado, que también tiene una función llamada print_details, pero un atacante en realidad podría proporcionar una versión serializada de un objeto Transaction con un valor predefinido para su atributo @id. Por lo tanto, una solicitud como la siguiente puede permitir la omisión de la comprobación de validación que intenta asegurarse de que @id es un valor numérico.

GET REQUEST:  http://server/page?user=!ruby%2Fobject%3ATransaction%0Aid%3A4%20or%205%3D5%0A

Si observamos la versión decodificada de esto, vemos que el parámetro user tiene asignado !ruby/object:Transaction\nid:4 or 5=5\n.
Entonces, la deserialización del parámetro de usuario creará un objeto de tipo Transaction y @id se establecerá en "4 or 5=5". Cuando el desarrollador cree que se llamará a User#print_details(), ahora se llamará a Transaction#print_details() y la interpolación de cadena de Ruby significará que la consulta SQL se cambiará para ejecutar la consulta: SELECT * FROM transactions WHERE id=4 or 5=5. Dado que se agregó la cláusula adicional, la consulta se evalúa en true y devolverá todo dentro de la tabla transactions en lugar de la única fila prevista por el desarrollador.

Los atacantes podrían encadenar diferentes clases declaradas cuando se llama al YAML.load() vulnerable mediante una técnica conocida como "Programación orientada a las propiedades", que introdujo Stefan Esser durante la conferencia BlackHat de 2010. Esta técnica permite a un atacante volver a utilizar el código existente para diseñar su propia carga.