Manuel Blanco - GNU/Linux Binary Exploitation I&II [rooted2018]

GNU/Linux Exploiting
Introducción a la explotación de binarios

GNU/Linux Exploiting 2
• Manuel Blanco Parajón
• Jugador habitual de competiciones “CTF”
• w0pr
• ID-10-T
• Estudiante de Ingeniería Informática
• Autodidacta
# whoami
@manuelbp01
manuelbp01@gmail.com

• ¿Qué vamos a ver en este taller?
Introducción a la explotación de vulnerabilidades en software
• Requisitos recomendados
• Nivel básico de programación en C
• Manejo sencillo de la shell GNU/Linux
• Conocimientos básicos de Ingeniería Inversa
• Fundamentos de Computadores
• Resultados
Ser capaz de desarrollar tu primer exploit
Introducción

Motivación

• Bug: Error de software o fallo de programación que causa un
comportamiento anómalo o desencadena un resultado inesperado en la
aplicación.
• Vulnerabilidad: Clase particular de bug que puede ser aprovechado por
un atacante para comprometer la seguridad, integridad, disponibilidad y
confidencialidad de un sistema.
• Exploit: Fragmento de software utilizado para aprovechar una
vulnerabilidad de un sistema, con el fin de conseguir un comportamiento
no deseado para el mismo.
• Payload: Efecto que se desea lograr al explotar una vulnerabilidad.
Términos

• Ingeniería Inversa: Proceso llevado a cabo con el objetivo de obtener
información a partir de un producto final.
• Análisis estático
• Análisis dinámico
Ingeniería Inversa

• Análisis estático: Tipo de análisis de software que se realiza sin ejecutar
el programa.
• Ejemplo: Podemos utilizar objdump como un desensamblador
(traduce código máquina a ensamblador)
Ingeniería Inversa

• Análisis dinámico: Tipo de análisis de software que se realiza
ejecutando el programa.
• Ejemplo
• strace: Permite monitorear las llamadas al sistema y las señales.
• ltrace: Permite monitorear las llamadas a las librerías compartidas.
Ingeniería Inversa

• IDA 7.0 Freeware Version
https://www.hex-rays.com/products/ida/support/download_freeware.shtml
Herramientas útiles

• radare2
https://github.com/radare/radare2

• GDB (GNU Debugger)

• PEDA (Python Exploit Development Assistance for GDB)
https://github.com/longld/peda

• Los depuradores son muy útiles!!
Primer ejercicio

• Estructuras de datos (tablas) que muestran la distribución de la
memoria
Mapa de memoria

• Segmentación de memoria: División de la memoria primaria en segmentos
o secciones
• Los segmentos normalmente corresponden a las divisiones naturales de un
programa, como las rutinas o las tablas de datos.
• data: rw-
• code: r-x
• stack: rw-
• heap: rw-
Segmentación de memoria

• ¿Qué sucede cuando ejecutas un archivo ELF?
• $ ./test
• Normalmente el programa estará en el disco, y el kernel será el encargado de
realizar una serie de procedimientos para el mapeo de la memoria del
programa.
Flujo de ejecución

Flujo de ejecución
./test
fork()
execve(“./test”, *argv[], *envp[])
sys_execve()
do_execve() search_binary_handler()
load_elf_binary()
ld.so
_start
__libc_start_main _init
main
user mode
kernel mode

Cómo se realiza el mapeo del programa a la memoria virtual
• En el encabezado del programa
• Se guardan qué segmentos se deben mapear y sus respectivas
ubicaciones
• También se guarda qué secciones pertenecen a qué segmentos
• Durante el mapeo la memoria se dividirá en distintos segmentos
dependiendo de sus respectivos permisos
• Un segmento puede contener 0 o varias secciones
Flujo de ejecución

Flujo de ejecución

Flujo de ejecución
otra sección
.data
.bss
.got.plt
.rodata
.text
.init
ELF encabezado
RW
R o RX
kernel space
DATA VMA
CODE VMA
stack
heap
En disco En memoria

Registros
• Registros de propósito general
• EAX EBX ECX EDX – 32 bit
• AX BX CX DX – 16 bit
• AH BH CH DH – 8 bit (parte alta)
• AL BL CL DL – 8 bit (parte baja)
Ensamblador x86
AH AL
EAX
AX

Registros
• Stack Pointer
• ESP – 32 bit
• Apunta a la cima de la pila
• Base Pointer
• EBP – 32 bit
• Apunta a la base de la pila
• La pila es una estructura de datos (cola LIFO) que permite almacenar y
recuperar datos
Ensamblador x86

EBP: 0xffffcfd8
0x804871c
???
???
0x804871c
???
???
0xffffcfd8
Funcionamiento CPU
Prólogo de la función
Llamada a get_flag
RET addr
RET addr
Frame pointer
* La representación real de la pila sería al revés

0x804871c
???
???
0xffffcfd8
???
???
Funcionamiento CPU
???
???
???
Stack Frame
Marco de pila: Estructura de datos que contienen la información de estado de la
subrutina, son utilizados para almacenar variables locales y cálculos.

Funcionamiento CPU
Epílogo de la función
0x804871c
???
???
0xffffcfd8
0x804871c
???
???
0x804871c
???
0xffffcfd8
???

Registros
• Registro contador del programa
• EIP
• Apunta a la siguiente instrucción a ejecutar
• Registro flag
• eflags
• Almacena los resultados de ejecución
• Registro de segmento
• cs ss ds es fs gs
Ensamblador x86

Buffer: Espacio de memoria reservado para almacenar datos de
manera temporal.
Si se introducen más datos que los que el buffer puede almacenar,
entonces se produce un desbordamiento.
Buffer Overflow

Stack Smash
gcc -fno-stack-protector stack-smash.c –o stack-smash

Stack Smash
buffer (64 bytes)
variable
EBP
RET
argc
argv
envp
variable
EBP
RET
argc
argv
envp
A AA A
A A A A
A … … …
buffer (64 bytes)
AAA
A A A …
…
A A A A
Recordemos que la pila crece desde las
direcciones altas hacia las bajas, la
representación real sería al revés.

Stack Smash
• r <<< $(python -c 'print "A" * 64 + "B" * 4')

Stack Smash
• r <<< $(python -c 'print "A" * 64 + "xefxbexadxde"')

Stack Smash
El buffer podía almacenar 64 bytes, lo hemos desbordado y a
continuación hemos sobrescrito la variable correctamente.
Recordemos que en el formato little-endian el orden es del byte
menos significativo hasta el byte más significativo.

Return to Text
gcc -fno-stack-protector return-to-text.c -o return-to-text

Return to Text
La representación de la pila sería:
Nuestro objetivo es sobrescribir la dirección de retorno con la dirección de la función win()
buffer (64 bytes)
EBP
RET

Return to Text
Procedemos a calcular el desplazamiento necesario para llegar a
sobrescribir la dirección de retorno. Para este proceso podemos
utilizar un patrón cíclico (una secuencia única que nos permitirá
calcular dicho offset).

Return to Text
Tras generar un patrón de 100 bytes, obtenemos el desplazamiento

Return to Text
Procedemos pues a obtener la dirección de la función win()
objdump -M intel -D ./return-to-text

Return to Text
Verificamos que podemos alterar el flujo correctamente:

Return to Shellcode
gcc -fno-stack-protector -z execstack return-to-shellcode.c -o return-to-shellcode

Return to Shellcode

Return to Shellcode
A partir de 264 bytes, sobrescribimos el saved EBP (frame pointer) y
RET

Return to Shellcode
Esta ocasión nuestro fin es lograr ejecutar código arbitrario en el
sistema, para dicha labor utilizaremos un shellcode.

Return to Shellcode
Un shellcode es un conjunto de instrucciones normalmente programadas en
lenguaje ensamblador y representadas en forma de códigos de operación, su
propósito es ejecutar la operación que se haya programado.
Shellcode que ejecuta /bin/sh con execve()

Return to Shellcode
El buffer podía almacenar 64 bytes, lo hemos desbordado y a
continuación hemos sobrescrito la variable correctamente.
Recordemos que en el formato little-endian el orden es del byte
menos significativo hasta el byte más significativo.

Return to Shellcode
Procedemos a desactivar la ASLR:
echo 0 | sudo tee /proc/sys/kernel/randomize_va_space
A continuación ponemos un punto de ruptura en la llamada a gets() y observamos
los parámetros que recibe:

Return to Shellcode
Ahora que sabemos cual es la dirección de inicio de nuestro buffer, podemos
alojar nuestro shellcode en el mismo y saltar a el:

Return to Shellcode
Vamos a probar a ejecutarlo fuera del depurador
Vemos que algo no va bien, habilitaremos la generación de core dumps (crasheos)
y procederemos con un análisis post mortem.
ulimit -c unlimited

Return to Shellcode
Analizamos un poco el core dump y rápidamente localizamos el shellcode
gdb -q --core core

Return to Shellcode
Modificamos el exploit con la nueva dirección y ejecutamos de
nuevo…
¿Dónde está mi shell?

Return to Shellcode
Utilicemos strace para ver las llamadas al sistema

Return to Shellcode
Parece ser que estamos perdiendo el contexto de la entrada estándar, debemos mantener stdin
abierto.
(python exploit.py; cat) | ./return-to-shellcode
cat exploit - | ./return-to-shellcode

Protecciones
ASLR (Address Space Layout Randomization)
La aleatoriedad en la disposición del espacio de direcciones es una técnica que intenta mitigar o
dificultar la explotación de vulnerabilidades basadas en la corrupción de memoria (originalmente
se implementó en PaX).
En 32 bits la entropía no es muy alta pues 12 bits quedan estáticos, es posible realizar un ataque
de fuerza bruta. Luego se verán maneras de sortear esta mitigación.
En este caso tendríamos una probabilidad de
1
165 para adivinar la dirección del buffer.

Protecciones
NX (No eXecute)
Normalmente las páginas de memoria suelen estar marcadas como no ejecutables gracias a la
protección NX (non-execute).
Esto significa que aunque logremos inyectar un shellcode en la memoria y logremos alterar el flujo
del programa para que salte a nuestra zona controlada, no podremos ejecutarlo.

Protecciones
PIE/PIC (Position Independent Execution)
Este mecanismo de protección permite realizar una aleatorización en los segmentos de texto y
datos.
Es decir, se realiza un direccionamiento relativo, en cada ejecución se generará de manera pseudo
aleatoria una dirección base y se irán calculando el resto de direcciones mediante sumas de
desplazamientos.
Por defecto gcc no compila con PIE, para utilizar esta protección se deben utilizar las flags -fPIC -
pie

Protecciones
StackGuard
Este mecanismo de protección consiste en generar un valor aleatorio (canario) en el prólogo de
una función, salvaguardarlo justo antes del frame pointer y dirección de retorno en la pila.
En el epílogo de la función realizará la operación lógica de disyunción exclusiva con el valor actual
y el generado anteriormente, de manera que detectará si ha sido modificado o no.
buffer
EBP
canario
RET

PLT/GOT
La PLT (Procedure Linkage Table) es usada para llamar a
procedimientos/funciones cuya dirección no se conoce durante el
enlazado, es el enlazador dinámico el encargado de resolverla durante
la ejecución.
La GOT (Global Offsets Table) es otra tabla que contiene direcciones
absolutas los procedimientos/funciones que serán utilizados, se utiliza
de manera similar a la PLT.

Enlace perezoso (Lazy Binding)
En el enlace perezoso (procesos llevado a cabo por el cargador de ELF) cuando un
binario está cargado en memoria y una función es llamada por primera vez, la PLT
realiza un salto a la GOT donde resolverá la entrada que aún no ha sido resuelta.
En ese momento el enlazador dinámico es invocado, este resolverá y almacenará
en la GOT la dirección del símbolo correspondiente a la función invocada.
Las siguientes llamadas a la función no volverán a pasar por dicho proceso, pues
su dirección ya estará resuelta en la GOT.

Protecciones
RELRO (Relocation Read-Only)
RELRO Parcial: Reordena las secciones ELF de manera que las
secciones internas de datos (.got, .dtors, etc.) precedan las secciones
de datos del programa (.data y .bss), la problemática es que la GOT es
escribible.
RELRO Completo: Remapea toda la GOT como solo lectura. Es la única
manera de mitigar cualquier tipo de técnica que trate de modificar la
GOT, pues protege las secciones de datos internos en el ELF para que
no se sobrescriban (a medida que se reordenan las secciones ELF).
Flags para compilar con Full RELRO: gcc -Wl,-z,relro,-z,now

GOT
Cómo encontrar la GOT
objdump -R elf

GOT Hijacking
Para poder implementar el enlazado perezoso la GOT debe ser escribible.
El objetivo sería sobrescribir alguna entrada de la GOT, de manera que afecte al
flujo del programa.
…
…
call foo@plt
…
…
printf
system
…
.text
.got.plt
jmp *(foo@GOT)
push index
jmp PLT0
foo@plt
push *(GOT + 4)
jmp *(GOT + 8)
PLT0
Cuando se produce un call foo, se realizará un jmp a la
función system.

Return to Library
El objetivo de esta técnica es sortear la protección NX.
Para lograr dicho fin, debemos sobrescribir la dirección de retorno con
una llamada de librería del sistema.
Uno de los problemas sería la ASLR, para poder realizar esta
metodología en dicho escenario sería necesaria alguna fuga de
información que nos permitiese calcular la dirección base de la
librería del sistema.

Return to Library
gcc -fno-stack-protector return-to-library.c -o return-to-library

Return to Library
Procederemos a ejecutar system("/bin/sh"), debemos situar los
argumentos en la pila de manera que cuando se ejecute system estos
sean interpretados como tal.
AAAAAAAAAA
AAAAAAAAAA
AAAAAAAAAA
AAAAAAAAAA
AAAAAAAAAA
system
fake RET
& /bin/sh

Return to Library
Procederemos a buscar las direcciones de los argumentos requeridos.

Return to Library
Ponemos un punto de ruptura en la instrucción ret y verificamos que
todo se encuentra en el lugar correcto

Return to Library
Podemos utilizar exit como dirección de retorno, para evitar generar
un core dump al finalizar e intentar ejecutar "0x41414141".

Condición de carrera (Race Condition)
Son un tipo de error lógico donde dos flujos de código se ejecutan de
forma concurrente y el resultado final depende del orden de
ejecución, como consecuencia las acciones de uno sobre los datos
puede influir en los resultados del otro.

Nuestro objetivo será aprovecharnos del sleep, para poder leer el
fichero temporal.

Hemos logrado el objetivo!

Format String
Este tipo de bug ocurre cuando una entrada de datos se evalúa por
una función de manera incorrecta (normalmente la función
pertenecerá a la familia *printf()).
Explotando dicha vulnerabilidad se puede lograr desde una fuga de
memoria hasta una escritura.

Format String

Format String
Este tipo de bug ocurre cuando una entrada de datos se evalúa por
una función de manera incorrecta (normalmente la función
pertenecerá a la familia *printf()).
Explotando dicha vulnerabilidad obtenemos una primitiva de lectura y
escritura.

Format String
Procedemos pues a introducir algún testigo de formato e intentamos
volcar valores de la pila.

Format String
Utilicemos un depurador, para visualizar mejor lo que sucede.
Vemos como los valores examinados coinciden con el volcado.

Format String
Vamos a escribir los dos bytes inferiores (LOB) del objetivo:
• r <<< $(python -c 'print "x34xa0x04x08" + "%16701d%7$hn"')
Ahora vamos a escribir los dos bytes superiores (HOB):
• r <<< $(python -c 'print "x36xa0x04x08" + "%16701d%7$hn"')

Format String
• Reglas de escritura:
• Si HOB > LOB
• [dirección+2] [dirección] [LOB - 8] [offset+1] [HOB-LOB] [offset]
• Si HOB < LOB
• [dirección+2] [dirección] [HOB - 8] [offset] [LOB-HOB] [offset+1]

Format String
Vamos a aprovechar esta fuga de información (infoleak), para
bypassear el StackGuard

Format String
Vamos a ver el canario que genera, poner un punto de ruptura en la
llamada al sistema y buscar dicho valor en la pila

Format String
Vemos que la posición del canario es $esp + 540, como las
direcciones son de 4 bytes:
540
4
= 135. Podemos utilizar el testigo de
acceso directo: %135$p

ROP (Return-oriented programming)
Esta técnica comúnmente nos permitirá evadir la protección NX.
El objetivo consiste en lograr ejecutar una secuencia de instrucciones
máquina llamadas gadgets (presentes en la memoria de la máquina)
con el fin de lograr ejecutar operaciones arbitrarias en la máquina.
Cada gadget generalmente termina en una instrucción de retorno y se
suelen encontrar en subrutinas del programa y/o bibliotecas
compartidas.
Utilizaremos una herramienta para localizar los gadgets fácilmente:
• https://github.com/sashs/Ropper

ROP
gcc -static -fno-stack-protector rop.c -o rop

ROP
http://syscalls.kernelgrok.com/

ROP
Nuestro objetivo será hacer ejecutable el stack, para esta labor
utilizaremos la syscall mprotect:

ROP
Ahora que sabemos los argumentos que recibe, buscaremos los
gadgets necesarios para controlar los registros y efectuar la llamada al
sistema.
La instrucción int 0x80 provoca una interrupción software (llamada al
sistema), es una instrucción especial que causa que el procesador
transfiera el control a un código privilegiado (núcleo).

ROP
Desactivemos la ASLR y veamos cual es la dirección del stack:
Ahora tracearemos nuestro rop-chain y verifiquemos que la pila
queda con permisos de ejecución.

ROP
Automatizaremos un poquito el proceso

ROP
Vemos que controlamos perfectamente la pila

ROP
Y finalmente hemos logrado nuestro fin
Ahora que tenemos control de la pila, podemos alojar nuestro
shellcode al inicio del buffer y hacer un exploit en condiciones

ROP
Verifiquemos que la shellcode se ejecuta correctamente
r < <(python exploit.py)

ROP
Habilitamos los core dumps y ajustamos el exploit con la dirección del
buffer fuera del depurador.
Y finalmente hemos logrado nuestro objetivo!

Feel like a pirate

Manuel Blanco - GNU/Linux Binary Exploitation I&II [rooted2018]

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a Manuel Blanco - GNU/Linux Binary Exploitation I&II [rooted2018]

Similar a Manuel Blanco - GNU/Linux Binary Exploitation I&II [rooted2018] (20)

Más de RootedCON

Más de RootedCON (20)

Último

Último (20)

Manuel Blanco - GNU/Linux Binary Exploitation I&II [rooted2018]