Análisis de tres vulnerabilidades de ejecución remota de código en el tiempo de ejecución de RPC

MS-RPC es un protocolo muy utilizado en las redes de Windows, en el que se basan muchos servicios y aplicaciones. Por lo tanto, las vulnerabilidades de MS-RPC pueden tener graves consecuencias. El grupo de inteligencia de seguridad de Akamai ha participado en investigaciones en torno a MS-RPC durante el último año. Hemos encontrado y aprovechado vulnerabilidades, hemos creado herramientas de investigación y hemos escrito sobre algunos de los aspectos internos no documentados hasta ahora del protocolo. 

Mientras que en las publicaciones anteriores del blog nos centrábamos en las vulnerabilidades de los servicios, en esta publicación se analizarán las vulnerabilidades del tiempo de ejecución de RPC, el "motor" de MS-RPC. Estas vulnerabilidades son similares a las vulnerabilidad que descubrimos en mayo de 2022.

Para detectar una vulnerabilidad, tenemos que entender el origen de la misma, averiguar si existe un flujo de acceso a la función vulnerable y cuánto tiempo tarda en activarse.

Para abreviar, describiremos una de las tres vulnerabilidades: la de la estructura de datos de cola. Como los otros desbordamientos de enteros son de naturaleza similar, se puede utilizar el análisis de las siguientes secciones indistintamente.

Como hemos mencionado anteriormente, la vulnerabilidad se produce al insertar una nueva entrada. Si la matriz dinámica está llena, el código hará lo siguiente:

• Asigna una nueva matriz con el siguiente tamaño:
  CurrentCapacity * 2 * sizeof(QueueEntry).

• Copia los elementos antiguos en la nueva matriz.

• Libera la matriz de elementos antiguos.

• Duplica la capacidad.

Para un sistema de 32 bits, el desbordamiento se producirá en el cálculo del nuevo tamaño de la matriz:

• Llenamos la cola con 0x10000000 (!) elementos. 

• Se produce una expansión. Se calcula el tamaño de la nueva asignación: 0x10000000 * 16.  A medida que se produce el desbordamiento, el nuevo tamaño de asignación es 0. 

• Se asigna una matriz de longitud cero.

• El código copia la matriz de elementos antigua en la nueva matriz más pequeña. Esto dará lugar a una copia brutal (una gran copia lineal).

En un sistema de 64 bits, esta vulnerabilidad no se puede aprovechar porque hay una gran asignación que falla. Por lo tanto, el código sale correctamente sin activar ninguna escritura fuera de los límites. A pesar de que los sistemas de 64 bits no son vulnerables a este problema, son vulnerables a los otros desbordamientos de enteros (en SIMPLE_DICT y SIMPLE_DICT2).

Una conexión de RPC se representa mediante la clase OSF_SCONNECTION. Cada conexión puede gestionar varias llamadas de cliente (OSF_SCALL), pero solo se permite que se ejecute una llamada cada vez en la conexión, mientras que las demás están en cola. 

Por lo tanto, una función interesante que utilizan las colas es OSF_SCONNECTION::MaybeQueueThisCall.  Recibe la llamada como parte de la distribución de una nueva llamada que ha llegado a la conexión. En este caso, la cola se utiliza para "poner en espera" las llamadas entrantes mientras se procesa otra llamada.

Por lo tanto, tenemos una forma controlada por el usuario de llenar una cola (enviando llamadas de cliente una tras otra), pero esta función establece un requisito: la conexión está procesando una llamada. Esto significa que si queremos llenar la cola, necesitamos una llamada que tarde tiempo en completarse. Mientras se procesa la llamada, se envían varias llamadas nuevas para que llenen la cola. 

¿Qué tipo de llamada de función tarda más en completarse? 

• La mejor candidata es una función en la que se pueda crear un bucle infinito.

• La segunda mejor opción es una vulnerabilidad de coacción en la autenticación porque entonces el servidor se conectará a nosotros. De esta forma, tendremos el control sobre el tiempo de respuesta.

• Como último recurso, se podría utilizar una función compleja con una lógica complicada o una función que procese muchos datos y que, por ello, tarde mucho tiempo en completarse.

Decidimos utilizar nuestra propia vulnerabilidad de coacción en la autenticación.

Ya sabemos qué hace falta para llenar la cola y cómo puede hacerse. Pero surge una duda importante: ¿es una forma práctica?

El control que tenemos sobre la variable en la que se produce el desbordamiento de enteros es mínimo (solo podemos hacer que aumente de uno en uno), similar a como ocurre con los desbordamientos de refCount (recuento de referencia). Este tipo de desbordamientos de enteros es menos recomendable que los desbordamientos de enteros en los que se suman o multiplican dos variables que controlamos por completo, o cuando el tamaño añadido se puede controlar de alguna manera (por ejemplo, el tamaño de paquete).

Como se ha comentado anteriormente, debemos asignar 0x10000000 (~268M) elementos. Es decir, muchos.

Al intentar desencadenar la vulnerabilidad en mi equipo, se produjo una tasa de entre unas 15 y 20 llamadas en cola por segundo. Esto significa que se tardaría unos 155 días en activarla en una máquina normal. Esperábamos que causara un número mayor de llamadas en cola por segundo. ¿Hay alguna razón por la que el tiempo de ejecución de RPC es tan lento? ¿No es de varios subprocesos? 

Habíamos supuesto que varios subprocesos procesaban y ponían varias llamadas a la misma conexión en cola simultáneamente. Después de darle algunas vueltas, descubrimos que en la práctica el flujo es un poco diferente.

Justo antes de enviar una llamada, el código inicia un nuevo subproceso (en el caso de que fuera necesario) y llama a OSF_SCONNECTION::TransAsyncReceive. TransAsyncReceive trata de recibir una solicitud en la misma conexión. A continuación, envía la solicitud al nuevo subproceso (mediante una llamada a CO_SubmitRead). 

El otro subproceso recoge la solicitud de TppWorkerThread y finalmente conduce a  ProcessReceiveComplete, que llama a MaybeQueueThisCall para poner SCALL en la cola de distribución. A continuación, se propaga y trata de recibir una nueva solicitud para esta conexión. 

Por lo tanto, aunque podemos tener varios subprocesos en ejecución, en realidad solo se utiliza uno en la conexión. Esto significa que no podemos añadir llamadas a la cola al mismo tiempo desde varios subprocesos.

Intentamos encontrar formas de realizar más llamadas por segundo para minimizar el tiempo que se tarda en desencadenar la vulnerabilidad. Al invertir el código de recepción, hemos observado que si la longitud de un paquete es mayor que la solicitud RPC real en el paquete, el tiempo de ejecución RPC acumula el excedente. Más tarde, al comprobar si hay nuevas solicitudes, no se utiliza inmediatamente el socket. Primero, se comprueba si hay "restos" de paquetes y, de ser así, responde a una nueva solicitud de estos restos.

Esto nos permitió enviar muchos menos paquetes, con el número máximo de solicitudes en cada uno. Al intentar esto, el número de llamadas en cola por segundo apenas cambió, así que tampoco funcionó.