En la entrada anterior fuimos capaces de generar nuestro payload para explotar un desbordamiento de buffer básico sólo analizando el código asm generado con objdump. Ahora en esta entrada lo que haremos será realizar un análisis dinámico del mismo binario mediante el debugger de facto en Linux: gdb (The GNU Project Debugger) al que añadiremos PEDA (Python Exploit Development Assistance for GDB) para ampliar sus funcionalidades.
Pero antes de empezar con gdb os recomiendo echar un vistazo a algún cheatsheet como los siguientes:
- https://darkdust.net/files/GDB%20Cheat%20Sheet.pdf
- https://github.com/stmerry/gdb-peda-cheatsheet/blob/master/gdb-peda%20cheatsheet.pdf
Continuando con el ejercicio, lo primero que haremos será cargar el debugger simplemente llamando a nuestro programa vulnerable como parámetro:
Lo que se suele hacer en primer lugar es comprobar las protecciones del binario con el comando checksec:
Como se puede observar en el resultado sólo está activado lo siguiente:
- NX (non executable): hace que ningún segmento de la aplicación sea escribible o ejecutable una vez cargado en memoria. Esto significa que aunque logremos alterar el flujo de un programa hacia un shellcode que hayamos cargado en memoria este no se va a ejecutar.
- RELRO (Relocation Read-Only) completo o FULL: mapea toda la GOT (Global Offset Table) a sólo lectura.
Afortunadamente ninguna de estas dos protecciones nos van a impedir desbordar la pila (smash the stack) así que ¡vamos a ello!
Pero antes de empezar con gdb os recomiendo echar un vistazo a algún cheatsheet como los siguientes:
- https://darkdust.net/files/GDB%20Cheat%20Sheet.pdf
- https://github.com/stmerry/gdb-peda-cheatsheet/blob/master/gdb-peda%20cheatsheet.pdf
Continuando con el ejercicio, lo primero que haremos será cargar el debugger simplemente llamando a nuestro programa vulnerable como parámetro:
$ gdb bof2
GNU gdb (Ubuntu 8.0.1-0ubuntu1) 8.0.1
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
Para las instrucciones de informe de errores, vea:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Leyendo símbolos desde bof2...hecho.
Lo que se suele hacer en primer lugar es comprobar las protecciones del binario con el comando checksec:
gdb-peda$ checksec bof2
CANARY : disabled
FORTIFY : disabled
NX : ENABLED
PIE : disabled
RELRO : FULL
Como se puede observar en el resultado sólo está activado lo siguiente:
- NX (non executable): hace que ningún segmento de la aplicación sea escribible o ejecutable una vez cargado en memoria. Esto significa que aunque logremos alterar el flujo de un programa hacia un shellcode que hayamos cargado en memoria este no se va a ejecutar.
- RELRO (Relocation Read-Only) completo o FULL: mapea toda la GOT (Global Offset Table) a sólo lectura.
Afortunadamente ninguna de estas dos protecciones nos van a impedir desbordar la pila (smash the stack) así que ¡vamos a ello!