Estas últimas 3 semanas he estado picado con un bug que me decidí a salsear para seguir aprendiendo más cosas de estas que no se enseñan en la escuela. El bug en cuestión se trata de un clásico stack overflow en la version 3.1 y inferiores de Savant Web Server. A pesar de haber varios exploits ya publicados para este fallo, todos ellos estaban diseñados para funcionar en XP SP2 o inferiores. En mi caso particular se dio la coincidencia de que tengo instalada una maquina virtual de 2003 Server SP1. Este sistema tiene dos peculiaridades. La primera, es que desde Service Pack 1 incluye soporte para tecnologias DEP o lo que los chicos de Microsoft llaman prevención de ejecución de datos. La segunda tiene que ver con las politicas de implantación de DEP. Tal y como MS nos cuenta en su web, existen varias politicas definidas para ello. La que nos interesa es la llamada OptOut, la cual por defecto activa DEP para todos los procesos del sistema que explícitamente no indiquen lo contrario.

Volviendo al tema del bug en cuestión, como ya he dicho se trata de un clásico overflow de buffer en la pila. En este caso la situación se dá cuando un usuario realiza una petición HTTP que no está reconocida, o dicho de otra forma, cuando el usuario tiene ganas de marcha. He dicho que se trata de un clásico overflow en la pila, y eso no es nada nuevo. Cierto. Pero por algo hemos comentado el DEP en Windows 2003 Server SP1. Hablando en plata, lo que no he encontrado en ningún sitio es un exploit público que sobrepase DEP para este bug, y puesto que ya está hecho a lo mejor le sirve de ayuda a alguien para sus futuros planes de dominar el mundo 🙂

Bromas aparte, por motivos éticos, no voy a publicar el codigo del exploit, por dos razones basicas:

• Cualquiera que séa capaz de entender este post, es capaz de escribir su propio exploit.
• El bug sigue sin ser corregido en la última versión del software.

Desgraciadamente, parece ser que el proyecto lleva algún tiempo abandonado y aprovechando esto, con motivos siempre educativos, vamos a ver que se puede hacer. Odio tener que poner disclaimers en los posts, pero es mejor prevenir que curar. El que utilice lo aquí mostrado con cualquier tipo de fin, lo hace bajo su propia responsabilidad y sin ninguna garantía. Accediendo a esta pagina estas de acuerdo con lo aquí mencionado. Ahora al lio.

Si hacemos una traza del flujo de un paquete poniendo unos breakpoints en los tipicos recv() y recvfrom(), veremos que se hace uso de un wrapper en 0x00401023. Una vez recibido el paquete, se procede a analizar la cabecera para comprobar que tipo de petición se ha recibido. Si hemos tenido la mala suerte de hacer una petición que no corresponde a ninguno de los que el servidor reconoce, acabamos llegando a la rutina en 0x0040BFA0, que es donde vamos a exprimir la naranja. Lo primero que se hace en esta función es llamar a una rutina en 0x00401285 que se encarga de encadenar el path que nuestro paquete señala, al path del directorio de trabajo de Savant. A pesar de que se hacen varios usos de nuestro amigo strcpy() el bug reside hacia el final de la rutina, concretamente en:

La cagada ya está hecha. Ahora volvemos al caller que será el encargado de redirigir la ejecución a donde nosotros le hayamos dicho. Ahora vamos a pensar que tipo de petición vamos a construir. Lo que haremos sera algo que guardara un lejano parecido con una correcta petición HTTP:

METODO | <espacio en blanco> | / | <nuestro path>

En cuanto al espacio disponible, conocemos lo siguiente:

• recv() nos permite hasta un máximo de 0x4000 bytes.
• METODO puede tener como máximo 24 bytes.
• <nuestro path> puede albergar un máximo de 250 bytes hasta (sin incluir) el valor ret, más 32 bytes adicionales después de este último.

Como ya he mencionado anteriormente, el jugo en este caso es saltarse la protección DEP. A pesar de que se han planteado varias soluciones, mi favorita es la propuesta por skape y Skywing en este articulo para el 2º Volumen de Uninformed. No voy a entrar en detalles de la tecnica, es una lectura bastante corta y recomendable, pero aquí os haré un resumen. Lo que trataremos de hacer, en vez de redefinir los parámetros de acceso de una región de memoria, será de desactivar DEP completamente para todo el proceso. Para ello haremos un ret2code o dicho en lenguaje llano, reutilizar codigo existente en memoria. En el articulo se demuestra una secuencia de código que yo personalmente no he encontrado en la versión española de la plataforma. Pero tras bucear entre dumps de memoria, encontramos la siguiente secuencia dentro de ntdll.dll:

Y tras el jump:

Ahora nos encontramos con un problema. El leave que se ejecuta justo antes de hacer ret, hace un cambio de frame en una sola instrucción y nos jode el fake frame que necesitamos para encadenar secuencias de ret’s y volver a ejecutar nuestro codigo. Así es como termina la secuencia de ejecución de 0x0040BFA0, que es la que nos da control sobre la ejecución:

Como se puede observar, obtenemos ebp de la pila y aunque a primera vista esto no parezca un problema, lo es. El problema radica en que el fake frame que queremos construir esta en la pila, cuyas direcciones son del tipo 0x00XXXXXX. Así pues, no podemos poner valores de ese tipo en nuestro buffer por que tiene bytes nulos y se nos desmonta la barraca. Que podemos hacer frente a esto? Lo único que se me ha ocurrido ha sido utilizar algún tipo de operador logico para construir nuestro valor en tiempo de ejecución. Lo que nos lleva a la siguiente secuencia de codigo dentro de shell32.dll:

Que termina saltando a:

A pesar de que tenemos un call algo feo ahí, no hay nada de lo que preocuparse porque el ebp que acabamos de construir se salva con el push del prologo y el pop del epilogo. El resto del proceso de explotación no conlleva mayores cábalas. Como controlamos ebp, controlamos el ret de 0x7CA0DF3B. Bastaría con volver a algun codigo como jmp esp, para continuar ejecutando, ahora sin DEP, desde la pila. El ultimo problema que tenemos es que solo tenemos 250 bytes de espacio para albergar nuestro shellcode que, además debe estar con codificación alfanumérica. Por lo tanto, la estructura de nuestro buffer final podría ser algo así:

<padding> + <espacio en blanco> +  / + <padding> + <jmp_esp> + <shellcode> + <valor de ebp> + <primer ret> + <ret2dep> + <referenciable 1> + <referenciable 2> + <referenciable 3> + ‘\r\n\r\n’

Un par de comentarios sobre la estructura. Primero, recordar que el <valor de ebp> debe ser el adecuado para que despues del XOR obtengamos el valor que nos interesa. Segundo, los tres valores que marco como referenciables, son 3 valores de 4 bytes que apunten a una región de memoria con permisos de lectura y escritura, sino el programa no seguirá el camino que nos interesa. Por otro lado, entiendo que esta solución no es la optima y esta lejos de ser una solución universal, pero como ejemplo, pienso que demuestra un caso curioso.

Mención especial para Ruben y Joxean por su paciencia y atención!

La versión original de esto post la podeis encontrar aquí.