Al otro lado de las vulnerabilidades de corrupción de memoria: extinción de la seguridad y futuro de la explotación

Chintan Shah · 24 de enero de 2022

Las técnicas modernas de explotación han cambiado la forma que tienen los ciberdelincuentes de ejecutar sus estrategias de ataque y cómo analizan los equipos de seguridad los caminos que van de la vulnerabilidad a la explotación. En la última década, hemos observado un firme interés por reforzar la seguridad tanto en el sistema operativo en general como en las aplicaciones, lo que ha permitido avanzar notablemente e introducir varias mitigaciones de exploits. En algunos casos, este avance ha eliminado gradualmente clases enteras de vulnerabilidades de corrupción de memoria. Por ejemplo, el uso de memoria después de liberación (UAF, Use-After-Free) es un tipo de vulnerabilidades muy habitual en grandes bases de código complejo, como los navegadores web. Debido a su facilidad de explotación, Microsoft introdujo un montón aislado y demoró la liberación de objetos en el motor del navegador (mshtml.dll) para romper la cadena de explotación de UAF y obligar a los ciberdelincuentes a enfrentarse a esas barreras y, por lo tanto, a rediseñar los exploits. La Figura 1 siguiente muestra, allí donde se introdujo, la parte del código que mitiga las vulnerabilidades UAF.

Podemos ver la diferencia entre el código protegido y el no protegido. Aunque esto era solo la punta del iceberg, la explotación de vulnerabilidades UAF se volvió extremadamente difícil, ya que exigía a los atacantes resolver limitaciones de tiempo específicas y también umbrales de memoria. La Figura 2 siguiente es un esquema sencillo de las mitigaciones de exploits de memoria del sistema operativo Windows introducidas más o menos en la última década.

Sin embargo, hemos visto de manera reiterada que estas mitigaciones han sido superadas en poco tiempo tras su introducción, principalmente porque todo el código, incluido el dependiente y el de terceros, no era compatible o no estaba compilado con las mitigaciones activadas en el compilador. Básicamente, esto implica que la mitigación de exploits no se aplicaba en todas las partes del código, o bien que la propia mitigación no se aplicaba en su totalidad, lo que dejaba múltiples deficiencias que a su vez podían explotarse. Por ejemplo, en el esquema anterior puede apreciarse que inicialmente ASLR no se aplicó por completo, sino más bien por etapas, por lo que gran parte del código seguía siendo vulnerable a omisiones.

Vulnerabilidades de corrupción de memoria: ¿llegarán a ser cosa del pasado?

Aunque las vulnerabilidades de corrupción de memoria continúan siendo la clase de errores más denunciada, en los últimos años ha sido difícil convertirlas en auténticos exploits debido a las mitigaciones introducidas en el sistema operativo y en las aplicaciones cliente (por ejemplo, motores de scripts). Para traducir las vulnerabilidades de corrupción de memoria en verdaderos exploits que permitan ejecutar código arbitrario, es preciso eludir múltiples mitigaciones sin activar las funciones de protección y detección de la solución de seguridad de endpoints. Esto significa que ahora los ciberdelincuentes deben invertir considerable tiempo, esfuerzo y dinero para estudiar cómo eludir las mitigaciones de exploits. En varias ocasiones, para poder ejecutar un exploit operativo en el sistema de destino, puede que también tengan que encadenar varias vulnerabilidades, lo cual incrementa significativamente el coste de desarrollo y la dificultad de explotación.

Creemos que esta evolución de las mitigaciones de explotación será crucial para conformar la naturaleza de las clases de vulnerabilidades que interesarán a los adversarios en el futuro. La cuestión de si las vulnerabilidades de corrupción de memoria llegarán a extinguirse es discutible y exige cierta reflexión.

Estrategias de explotación del futuro: ¿qué nos depara el porvenir?

Las vulnerabilidades de corrupción de memoria seguirán existiendo en las aplicaciones mientras en ellas haya código que gestione la memoria de forma incorrecta, pero la intensidad y la frecuencia de explotación de esta clase de vulnerabilidades finalmente se reducirán. En el pasado, vimos muchas veces técnicas de explotación con las que los ciberdelincuentes lograban leer/escribir (R/W) arbitrariamente en la memoria aprovechando un fallo de corrupción de memoria y utilizando esa primitiva para cambiar determinados indicadores o datos en la memoria de la aplicación, lo cual les permitía ejecutar código. Esta serie de métodos denominados "ataques de solo datos" eran estrategias relativamente más fáciles observadas en numerosos exploits. Con el paso del tiempo, la ubicación aleatoria en la memoria de determinadas estructuras de datos críticas acabó por reducir los ataques de esta naturaleza.

Cuando las aplicaciones tienen gran número de funciones, los agresores siempre buscan las estrategias más fáciles para conseguir ejecutar código en el sistema de destino. Siempre hay sistemas heredados expuestos a Internet que les ofrecen la vía de menor resistencia, ya que carecen de las nuevas mitigaciones. Sin embargo, una de las formas de avanzar en esta dirección es aprovechar los fallos de funciones o diseño de la aplicación o el protocolo de red. Por ejemplo, si los adversarios pueden averiguar cómo utilizar ilícitamente las funciones o el diseño inherente de la aplicación de destino para que esta o un servicio se conecte al equipo que controla el agresor sin organizar la memoria de forma explícita, es relativamente más fácil ejecutar código de forma remota y, a la vez, causar estragos en el equipo de destino, ya que la funcionalidad del código arbitrario que ejecuta el proceso intervenido queda completamente a la imaginación del agresor. La Figura 3 siguiente es una vista simplificada de la evolución de las estrategias de explotación en los últimos años.

En los últimos años, han sido varias las ocasiones en que hemos presenciado ataques solo de datos y el uso ilícito de fallos de funciones/diseño de aplicaciones. Ofrecen múltiples ventajas frente a los exploits tradicionales de corrupción de memoria, y creemos que esta va a ser la estrategia de explotación del futuro por algunos de estos motivos:

• Tienen el potencial de eludir las mitigaciones de exploit aplicadas, por lo que los ciberdelincuentes no tienen que diseñar el exploit específicamente para sortear estas barreras.
• El código arbitrario se ejecuta con los privilegios del proceso explotado, lo cual contribuye a elevar los privilegios.
• Los exploits que aprovechan los fallos de funciones integradas o diseño de la aplicación no tienen que enfrentarse a la manipulación de memoria explícita ni a limitaciones de espacio para aprovechar la vulnerabilidad. Como consecuencia, evitan la inyección de código shell en la memoria y las antiguas técnicas de inversión de pilas.
• Son relativamente más fáciles de explotar con menos coste y tiempo de desarrollo/mantenimiento para utilizarlos de forma maliciosa.

El análisis retrospectivo de las vulnerabilidades críticas de los dos últimos trimestres nos puede dar la pista definitiva sobre la forma que adoptarán los ataques del futuro. En las secciones siguientes, examinamos algunas de las vulnerabilidades recientes de mayor impacto y comprobamos cómo los fallos de funciones o diseño del servicio o la aplicación se aprovecharon de forma ilícita para conseguir ejecutar código o filtrar información confidencial con una resistencia mínima.

CVE-2021-44228: Vulnerabilidad en la biblioteca de registro Log4j2 de Apache que podría permitir la ejecución remota de código (RCE)

Esta vulnerabilidad RCE denunciada en la biblioteca de registro Log4j de Apache es uno de los fallos más críticos denunciados en los últimos años y permite a los agresores ejecutar código arbitrario en el servidor vulnerable que utiliza la biblioteca Log4j para registrar mensajes de texto. En nuestro anterior blog, ya explicamos a fondo que el software de código abierto sirve de elemento básico para el desarrollo de software moderno y que es muy importante revisarlo, pues cualquier vulnerabilidad tendrá un impacto considerable en el producto que lo utilice.

La vulnerabilidad está en el método de "búsquedas" de la clase "jndimanager". When the JNDI URL is included in the request message parameter to be logged by log4j, the apache\logging\log4j\core\lookup\JndiLookup.lookup () method is called with the JNDI URL which in turn calls the net\JndiManager.lookup () method as shown in figure 3 below, leading to the initiation of the remote JNDI lookup to the attacker controlled server. Ahora este servidor puede enviar como respuesta la referencia JNDI maliciosa, lo que permite ejecutar código arbitrario en el servidor vulnerable.

La ejecución remota de código fue posible porque Java admite varios proveedores de servicios JNDI (Java Naming and Directory Interface), como LDAP, DNS, RMI y CORBA; también fue posible cargar clases remotas, dependiendo de las propiedades predeterminadas del sistema.

CVE-2021-44228 es un ejemplo clásico de explotación de funciones. Aquí la función explotada es la de sustitución de búsqueda que permite las búsquedas. Las búsquedas son una manera de añadir valores a los mensajes del registro, normalmente nombres de variables resueltas mediante un mapa definido o en tiempo de ejecución a través de interfaces implementadas, como las clases StrSubstitutor y StrLookup.

Log4j admite la sintaxis de propiedad "${prefix:name}", donde prefix indica a Log4j que el nombre de variable debe evaluarse en el contexto específico. El contexto de JNDI se incorpora en Log4j como se muestra a continuación.

Como las búsquedas JNDI estaban activadas de forma predeterminada en la versión 2.14.1 de Log4j y en versiones anteriores (consulte la Figura 6 anterior), la biblioteca podía identificar las referencias JNDI pasadas como valor de parámetro en los encabezados de solicitudes HTTP registradas en el servidor, de manera que los ciberdelincuentes podrían inyectar referencias JNDI maliciosas en los parámetros de la solicitud HTTP y provocaba la ejecución remota de código Java.

CVE-2021-34527: Vulnerabilidad en el servicio Print Spooler que provoca la ejecución remota de código

La vulnerabilidad de ejecución remota de código con privilegios en spoolsv.exe, denominada PrintNightmare, es otra vulnerabilidad crítica denunciada el año pasado que ilustra bien cómo un fallo de diseño del protocolo puede utilizarse de forma ilícita para ejecutar código arbitrario en el equipo de destino sin necesidad de actuar en la memoria.

La vulnerabilidad se explotaba en los protocolos Print System Remote Protocol (MS-RPRN) y Print System Asynchronous Remote (MS-PAR) mediante llamadas RPC en SMB. El exploit aprovecha un fallo de diseño clásico en la implementación del componente servidor de impresión del servicio de administración de colas de impresión, cuando se realizan solicitudes RPC a las interfaces MS-RPRN y MS-PAR para instalar los controladores de impresora en el sistema de destino. Para hacer la llamada RPC a RpcAddPrinterDriverEx (MS-RPRN Opnum 89) o RpcAsyncAddPrinterDriver (MS-PAR Opnum 39), es preciso pasar como argumento una estructura DRIVER_CONTAINER.

Como muestran los detalles de la estructura anterior, DRIVER_CONTAINER contiene pDriverPath y pConfigFile, que forman la ruta completa del nombre de archivo que contiene el controlador de impresora y el módulo de configuración, respectivamente. Tanto pDriverPath como pConfigFile se comprueban para asegurar que no son rutas UNC y evitar que se cargue código arbitrario.

Aquí, el fallo de diseño o lógica del código es que esa misma comprobación de ruta UNC no se aplica a pDataFile, que es la ruta completa del archivo que contiene los datos de la impresora. Un ciberdelincuente podría realizar múltiples llamadas a RpcAddPrinterDriverEx con:

1. pDataFile como ruta UNC del DLL malicioso accesible al equipo de destino que, si logra su objetivo, copia el DLL malicioso en el equipo de destino de forma local.
2. La misma API con el nombre de archivo copiado asignado a pConfigFile (esta vez, el DLL malicioso se convierte en la ruta local), lo que provoca que el servicio de administración de colas de impresión cargue código malicioso.

CVE-2021-36942: Vulnerabilidad de suplantación de identidad en Windows LSA que provoca filtraciones de credenciales

Las llamadas RPC en SMB siempre han estado en primera línea de numerosos métodos de explotación. Una vez más, esta vulnerabilidad podía explotarse utilizando de forma ilícita el protocolo MS-EFSRPC, que en Windows sirve para administrar los archivos del sistema remoto y cifrarlos con el Sistema de cifrado de archivos (EFS).

Al realizar llamadas RPC específicas, como EfsRpcOpenFileRaw, en la interfaz LSARPC, el agresor puede autenticar un host Windows en otro servidor, lo que básicamente significa que es posible obligar a un servidor de destino a autenticarse en un servidor controlado por un adversario mediante autenticación NTLM. Y lo más importante, significa que es posible utilizar LSARPC con llamadas RPC sin autenticación previa; además, si este servidor de destino es Active Directory (AD), el adversario puede forzar a AD a conectarse al servidor arbitrario utilizando la cuenta del equipo para la autenticación NTLM. Este protocolo EFSRPC puede emplearse ilícitamente para encadenar múltiples vulnerabilidades en la red empresarial y transmitir credenciales NTLM a un servidor controlado por el agresor, que podría utilizarlas para realizar desplazamientos laterales y, en última instancia, comprometer el dominio por completo.

Si el adversario controla un servidor web IIS con la función Active Directory Certificate Services (AD CS) instalada y configurado para utilizar autenticación NTLM en HTTP, la autenticación de Active Directory en IIS provoca la filtración de las credenciales NTLM al adversario y permite que el dominio quede totalmente comprometido. Si bien los ataques de retransmisión NTLM no son nuevos, es recomendable utilizar un mecanismo de autenticación más seguro, como Kerberos, para prevenir el uso indebido del protocolo, como en este caso.

En resumen, el uso ilícito de un protocolo o una función para conseguir que un activo crítico se conecte a un servidor externo controlado por un agresor tiene consecuencias peligrosas, como demuestra la vulnerabilidad CVE-2021-44228 de Log4j.

CVE-2021-40444: Vulnerabilidad en Windows MSHTML que provoca la ejecución remota de código

Esta es otra vulnerabilidad crítica explotada el año pasado y un buen ejemplo de cómo el mero uso indebido de una función puede encadenarse con un fallo lógico para lograr la ejecución de código arbitrario. En primer lugar se utilizó la vinculación e incrustación de objetos (OLE) para vincular el documento al objeto OLE externo. Tradicionalmente, OLE ha desempeñado un papel importante en la creación de exploits maliciosos para Office, algo que seguirá ocurriendo porque se trata de una de las principales funciones del formato de archivo de Microsoft Office, diseñada específicamente para facilitar la interoperabilidad.

Las especificaciones de Microsoft Office Open XML permiten incrustar o vincular un documento a objetos internos o externos y, en particular, especifican la vinculación a objetos OLE externos mediante relaciones. Como se muestra a continuación en el documento del exploit diseñado, el archivo document.xml.rels define el atributo Type como "oleObject", el atributo Target como el enlace del objeto OLE y TargetMode como externo. Esto permite vincular el documento diseñado al objeto malicioso alojado externamente e invocar los controladores de los respectivos protocolos/recursos para renderizar el objeto y explotar un posible fallo lógico o de diseño en el controlador. Son las típicas técnicas de inyección en plantillas OOXML utilizadas en muchos exploits de OOXML en el pasado. Ya analizamos a fondo los exploits OLE en una publicación de nuestro anterior blog.

El código HTML se procesa en mshtml.dll, mientras que en urlmon.dll se comprueba la fiabilidad y se gestionan las descargas del protocolo HTTP y MSHTML. El fallo de diseño del código de urlmon.dll estaba relacionado con la extracción y la comprobación de fiabilidad del archivo CAB descargado. El archivo CAB se descargaba mediante el código Javascript (JS) incrustado en la página side.html, como muestra la Figura 11 anterior. Al no haber verificaciones de escape durante la extracción del archivo CAB, permitía al exploit extraer el archivo contenido en el CAB con la ruta relativa de la Figura 12 siguiente. Como resultado, la carga útil maliciosa se distribuía fuera del directorio TEMP creado, lo que finalmente permitía su ejecución.

Conclusión

En los últimos años, hemos observado una tendencia a la explotación de vulnerabilidades como CVE-2021-44228, CVE-2021-34527, CVE-2021-36942 y CVE-2021-40444, aquí descritas, que aprovecha fallos de procesamiento inherentes y se basa en el uso ilícito de funciones. Aunque los fallos de corrupción de memoria seguirán proliferando mientras exista código no seguro en lenguajes no seguros para la memoria distintos de Rust, creemos que la tendencia de explotación acabará centrándose en fallos de diseño o lógica y en el uso indebido de protocolos. Tanto consumidores como desarrolladores de software de código abierto deben estar más atentos, ya que estos fallos permitirán a los ciberdelincuentes alcanzar su objetivo inicial de moverse lateralmente en la red en el nivel del sistema, sin preocuparse de la defensa en profundidad de las mitigaciones recientemente desarrolladas para exploits de memoria.