kpn-ciso/dra_writeupWriteup de la vulnerabilidad de desbordamiento de búfer de pila de Oracle DSR (DRA) CVE-2014-6598
KPN es un operador de telecomunicaciones ubicado en los Países Bajos. El CISO REDteam se introdujo en 2013 y es el equipo de hacking ético de KPN. Este equipo participa en pruebas de seguridad de las aplicaciones y servicios de KPN para garantizar que los datos de nuestros clientes estén a salvo de accesos no autorizados, modificaciones y pérdida de datos.
KPN opera la red móvil más grande de los Países Bajos. Uno de los componentes de la red 4G que opera KPN es la aplicación Diameter Routing Agent denominada Oracle Diameter Signalling Router (DSR). El Diameter Routing Agent (DRA) es un elemento funcional en una red 3G o 4G que proporciona capacidades de enrutamiento en tiempo real para garantizar que los mensajes se enruten entre los elementos correctos de una red. El [3GPP] introdujo el DRA para abordar el creciente volumen de tráfico de señalización Diameter y la creciente complejidad de las redes 4G LTE. Puede implementarse como un enrutador central que enruta el tráfico entre elementos Diameter en la red local, o como un enrutador de puerta de enlace que enruta el tráfico entre elementos Diameter en la red local y de roaming. El 3GPP especifica el uso del protocolo Diameter para varias interfaces, incluida una (S6a) que se utiliza para la comunicación MME-HSS y para el roaming.
La siguiente imagen muestra un despliegue típico de DRA en un entorno LTE. Todas las interfaces entre los elementos son interfaces S6a.
El Oracle DSR es un clúster de máquinas que se ejecutan en CentOS Linux y que realiza la función de DRA. Normalmente está conectado a diferentes MME y a un HSS en la red LTE local, pero también podría conectarse a socios de roaming a través de la red IPX.
Mediante el uso de la plataforma [Codenomicon] DEFENSICS, el KPN REDteam descubrió dos vulnerabilidades importantes en la aplicación Oracle DSR versión 5.0:
La primera vulnerabilidad permite que un atacante remoto no autenticado conectado a la red IPX comprometa por completo el DRA y sus componentes. Cuando un atacante obtiene el control total del sistema DRA, puede monitorizar todo el tráfico enrutado a través del DRA y, posiblemente, infiltrarse más en la red central del operador de telecomunicaciones.
Oracle se tomó en serio las vulnerabilidades notificadas, y el KPN REDteam trabajó en estrecha colaboración con Oracle para resolver estos problemas, como también se indicó en su aviso al cliente:
"Recent security tests have identified two security vulnerabilities in versions of the Oracle Diameter Signaling Router product. To protect your network from potential exploits of these vulnerabilities, Oracle strongly recommends that you apply actions described herein without delay. Oracle acknowledges Frank Cozijnsen, Ethical Hacker, KPN CISO REDteam for discovery of the Diameter Stack vulnerability described below. Special thanks is extended to KPN for their support during the Oracle analysis phase. Note: These findings will be publicly disclosed with Oracle’s next planned CPU scheduled for January 20, 2015."
Los problemas encontrados representan una amenaza grave para los operadores de telecomunicaciones que utilizan el DSR de Oracle y podrían ser explotados por cualquier atacante con acceso a una conexión IPX.
El KPN REDteam prueba productos y servicios antes de que se desplieguen en redes de producción. Como parte de un proyecto de actualización, el KPN REDteam probó el Oracle DSR versión 5.0 desde una perspectiva de seguridad. La prueba de seguridad incluyó fuzzing de la implementación DIAMETER del Oracle DSR mediante la [Codenomicon Diameter Server test Suite]. El mensaje Capabilities Exchange Request (CER), que se utiliza para comprobar las capacidades DIAMETER del servidor receptor, se usó como objetivo inicial de fuzzing. Este mensaje se eligió porque no se reenvía a otros sistemas como el HSS, sino que lo maneja el propio DSR. Durante el fuzzing, se observaron varios bloqueos del proceso "dsr" en los blades del Message Processor (MP) del DSR.
El bloqueo se analizó usando GDB con el complemento [PEDA] y, finalmente, se escribió un exploit remoto. El bloqueo fue causado por una escritura fuera de los límites más allá del final de un búfer ubicado en la pila. La escritura fuera de límites corrompió la pila con datos controlados por el usuario. Además, se sobrescribió el puntero de retorno guardado, que es la dirección a la que el programa retorna tras salir de una función. Cuando este puntero de retorno puede ser controlado por el atacante, puede conducir a la ejecución arbitraria de código.
La razón principal de escribir este blog es explicar cómo el KPN REDteam logró superar las protecciones ASLR y NX implementadas y consiguió crear un exploit funcional de ejecución remota de código. Normalmente, los mecanismos de protección ASLR y NX no son un gran obstáculo para los atacantes, pero el DSR se ejecuta en CentOS de 64 bits. No hay mucha documentación práctica sobre Return Oriented Programming (ROP) en sistemas Linux de 64 bits protegidos con ASLR.
Durante la depuración, se observó que la biblioteca libc siempre se mapeaba en la misma dirección en el proceso dsr, y la dirección no cambiaba tras un reinicio. Otras bibliotecas se mapeaban en direcciones de memoria aleatorias en el proceso dsr. Conocer la dirección de memoria de libc permite usar libc como fuente de los gadgets ROP. Otra opción es usar el propio binario dsr como fuente de gadgets ROP, pero la cantidad de gadgets útiles en ese archivo es limitada.
Para eludir la protección NX, se podría usar la función mprotect() para hacer ejecutable la pila y poder ejecutar nuestro shellcode.
La función mprotect() necesita los siguientes valores en los registros correspondientes:
Si todos estos registros están establecidos, se puede llamar a mprotect() en el desplazamiento 0xe54b0 de la versión objetivo de la biblioteca libc.
La siguiente parte del documento asume conocimientos sobre ROP y su funcionamiento. En [shell-storm.org] hay un buen ejemplo de cómo crear una cadena ROP en un sistema Linux de 32 bits. Debido al ASLR "parcial", la ubicación de la propia pila no era predecible. Se usaron gadgets ROP para almacenar el valor del puntero de pila (%RSP) en el registro %RSI.
El registro %RDI debe contener el desplazamiento de memoria de la región de memoria que debe hacerse ejecutable.
