VULNERABILIDADES PCMan FTP Server 2.0.

by Gottlieb Leberecht Müller

Versión Documento: 1.0
Fecha: Marzo 2018
Contenidos

1. Alcance del proyecto ........................................ 2

2. Herramientas utilizadas ..................................... 2
2.1. Immunity Debugger v1.85 ............................................. 4
2.2. Kali Linux .......................................................... 7
2.2.1 msfconsole ................................................................ 8
2.2.2 msfvenom .................................................................. 8
2.2.3 Scripts para generación y búsqueda de patrones ........................... 9

3. Exploit para PCMan FTP Server 2.0.7 ........................ 10

3.1. Fuzzing al servidor FTP ............................................ 10
3.2. Esqueleto de ataque inicial ........................................ 15
3.3. Esqueleto con patrones cíclicos .................................... 16
3.4. Badchars ........................................................... 18
3.5. Generación del payload ............................................. 20
3.6. Búsqueda de dirección de salto ..................................... 22
4. Anexos ..................................................... 26

1
1. Alcance del proyecto

La explotación de programas es esencial en el mundo del hacking. Un programa

informático está hecho de un conjunto de reglas complejas que siguen un cierto
orden a la hora de ejecutarse y que, finalmente, le dicen al ordenador lo que
tiene que hacer. La explotación de un programa es simplemente una manera
inteligente de hacer que el ordenador haga lo que tú quieres que haga, incluso
cuando el programa que se está ejecutando se diseñara para prevenir justamente
eso. Puesto que un programa solo puede hacer aquello para lo que fue diseñado,
los agujeros de seguridad son realmente defectos o descuidos en el diseño de
los programas o de los entornos en los que se ejecutan. Es cosa de las mentes
creativas encontrar esos agujeros y escribir programas que traten de
solventarlos. Algunas veces esos agujeros son producto de errores de
programación relativamente obvios, pero hay algunos errores menos obvios que
han dado lugar al nacimiento de técnicas de explotación complejas que se pueden
aplicar en diferentes situaciones1.
Haciéndonos eco de lo que Jon Erickson escribe en su libro Hacking. The Art of
Exploitation, en este proyecto se pretende encontrar vulnerabilidades de
programación en una aplicación concreta que nos faculten para explotar el
funcionamiento de la misma.
Hablando en terminología ISAAF, este proyecto se englobaría dentro de la fase
de Evaluación de un test de penetración, y abordaría las capas de Identificación
de vulnerabilidades, Penetración y Ganar acceso y escalado de privilegios,
ciñéndonos en este caso a una aplicación concreta instalada en un entorno
concreto.

2. Herramientas utilizadas

Para la realización de este proyecto se ha utilizado una máquina virtual con

Windows XP Service Pack 3 sobre el entorno de virtualización de Oracle Virtual
Box 5.2.6 r120293, corriendo sobre un anfitrión Linux Ubuntu 16.04.3 LTS, como
se puede apreciar en la Fig. 1.

1
Extraído literalmente de Hacking. The Art of Exploitation [2nd Edition] [Jon Erickson] [Cap. 3, pág. 115]

2
 Fig. 1. Máquina virtual Windows XP Service Pack 3 sobre VirtualBox

La aplicación cuyas vulnerabilidades se pretenden estudiar es un servidor FTP,

concretamente PCMan FTP Server 2.0.7.

Fig. 2. PCMan’s FTP Server 2.0.7

Para la realización de todas las tareas encaminadas a analizar las

vulnerabilidades de esta aplicación se usarán las herramientas que se
especifican a continuación.

3
2.1. Immunity Debugger v1.85
Immunity Debugger2 es una herramienta pensada para la escritura de exploits,
el análisis de malware e ingeniería inversa con ficheros binarios. Tiene un
interfaz gráfico bastante amigable e integra soporte para A
PI de Python que permite ampliar sus características mediante la ejecución de
scripts en este lenguaje de programación.
Sus características más reseñables son:
 Depurador con funcionalidad diseñada específicamente para tareas de
seguridad.
 Reduce significativamente el tipo de desarrollo de exploits.
 Interfaces simples y comprensibles.
 Permite depuración rápida y liviana que previene la corrupción de datos
en un análisis complejo.
 Conectividad con fuzzers y herramientas para el desarrollo de exploits.
Su interfaz incluye una GUI (Graphical User Interface) y una línea de comando.
La línea de comando está siempre disponible sobre cualquiera de las vistas de
la GUI que se tenga habilitado (en la parte inferior por defecto). Esto permite
al usuario la ejecución de comandos como si se estuviese en un depurador basado
en texto, como WinDBG o GDB.

Fig. 3. Interfaz de Immunity Debugger

2
Fuentes:
- http://www.immunityinc.com/products/debugger/
- http://www.reydes.com/d/?q=Immunity_Debugger

4
En la Fig. 3 se puede apreciar la vista de la ventana de CPU, que permite la
visualización en una misma pantalla de 4 funciones de interés a la hora de
realizar los exploits.

DESENSAMBLADO
Muestra el código en ensamblador de la aplicación que se está analizando. La
información se muestra en cuatro columnas. En la primera se visualizan las
direcciones de memoria. La segunda muestra los códigos de operación de la
instrucción (vista hexadecimal de la instrucción) localizada en la dirección.
La tercera columna es código ensamblador (puesto que Immunity es un depurador
dinámico, se puede hacer doble clic sobre cualquier instrucción ensamblador y
cambiarla; el cambio será visible inmediatamente y se podrá ver como esto
afecta el programa). La última columna contiene comentarios (el depurador
intenta adivinar algunos detalles sobre las instrucciones y si es satisfactorio
pondrá los detalles en los comentarios. Si no se está satisfecho con lo
adivinado por el depurador se puede borrar y escribir los comentarios propios
haciendo doble clic).

REGISTROS
Este cuadro permite visualizar los registros del CPU y sus valores. La sección
superior son registros de propósito general, que contienen valores temporales,
y registros que son utilizados para controlar el flujo del programa. La sección
intermedia contiene registros bandera que la CPU cambia cuando algo de
importancia ha ocurrido en el programa. La sección inferior contiene registros
que se usan en la ejecución de operaciones de punto flotante.
Estos registros pueden variar su color desde negro hacia rojo cuando se produce
algún cambio, lo que facilita la visualización de esos cambios. Asimismo, se
puede hacer doble clic sobre cualquier registro y cambiar su valor. Se puede
también seguir un valor almacenado en el registro si es una dirección de memoria
válida haciendo clic derecho sobre este y seleccionando “Follow in dump”.

VOLCADO DE MEMORIA
La ventana de volcado muestra una vista hexadecimal del programa completo. Se
divide en tres columnas: La primera muestra la dirección, La segunda caracteres
hexadecimales localizados en la dirección y en la tercera se puede ver la
representación ASCII de los datos hexadecimales. Se pueden buscar valores
haciendo clic derecho sobre la ventana y seleccionando “Search for -> Binary.
String”.

5
PILA
La localización de memoria hacia la que apunta el ESP (Stack Pointer Register)
o Registro Puntero de Pila se muestra en la parte superior de la ventana de
pila. La información se divide en tres columnas. La primera muestra la
dirección, la segunda los datos localizados en esa dirección y la tercera
contiene comentarios. Se pueden cambiar los datos en la pila haciendo doble
clic.

Aparte de lo dicho, Immunity Debugger contiene muchas más vistas, que se pueden
habilitar desde el menú View.
Una de las características más interesante de esta aplicación es que permite
la integración de scripts desarrollados en Python, sin más que instalarlos en
la carpeta PyCommands dentro de la carpeta donde se haya instalado el programa
(en la instalación por defecto C:\Archivos de Programa\Immunity Inc\Immunity
Debugger\PyCommands), como se ve en la Fig. 4.

Fig. 4. Scripts en Python incorporados a Inmmunity Debugger

De todos estos scripts, mención especial tiene uno que se utilizará

profusamente: mona.py, desarrollado por Corelan Team3, que incluye una serie
de funciones muy útiles para la generación y la búsqueda de patrones de
caracteres variados que se usarán en el desarrollo de exploits que atacan una
vulnerabilidad del tipo buffer overflow.

3
https://www.corelan.be/index.php/2011/07/14/mona-py-the-manual/

6
2.2. Kali Linux
Dado que la aplicación para la que se va a desarrollar un exploit es un servidor
FTP, corriendo en un entorno Windows XP, se quiere lanzar dicho exploit desde
un cliente remoto. Por ello, en otra máquina virtual haremos correr una
distribución Kali Linux que integra una serie de herramientas que se utilizarán
en el desarrollo y en la posterior ejecución del exploit.
Concretamente, se usa la distribución Kali 2017.1 corriendo sobre el mismo
entorno de virtualización usado para la máquina Windows XP que alojará la
aplicación a atacar (VirtualBox 5.2.6), y todo ello sobre el mismo anfitrión
Ubuntu 16.04.3 LTS reseñado ya al inicio del apartado 2.
Las dos máquinas virtuales (Windows XP y Kali) se ejecutarán simultáneamente
en una configuración de red que les permita verse. En este caso se ha utilizado
un adaptador puente sobre la tarjeta física del equipo que permite la asignación
de direcciones IP en la misma red que la máquina anfitrión. En concreto, el
anfitrión (Linux Ubuntu) está en la dirección 192.168.1.200/24, la máquina
Windows XP SP3 con la aplicación a atacar estará en 192.168.1.250/24 y la
máquina con Kali Linux en la 192.168.1.251/24.

Fig. 5. Configuración de red en máquinas virtuales

Kali incluye una gran variedad de herramientas para realizar ataques de

explotación. No obstante, en este proyecto se va a hacer uso fundamentalmente
de dos.

7
2.2.1 msfconsole

Posiblemente, msfconsole sea la interfaz más popular del framework Metasploit

(MSF)4. Implementa una consola centralizada que permite un acceso eficiente a
prácticamente todas las opciones disponibles en MSF. Aunque al principio puede
una herramienta que intimida, una vez que se maneja la sintaxis básica de los
comandos realmente se aprecia la potencia de utilizar esta interfaz.

Fig. 6. Herramienta msfconsole

En este proyecto se usará esta herramienta para lanzar un fuzzer contra el

servidor FTP, de cara a descubrir sus posibles vulnerabilidades.

2.2.2 msfvenom

MsfVenom es una combinación de las herramientas Msfpayload y Msfencode,

integradas dentro del framework de Metasploit5. Con esta herramienta seremos
capaces de genera payloads para distintas plataformas y de codificarlas al
objeto de evadir la detacción mediante el uso de antivirus. Según se detalla
en la web de Offensive Security, esta herramienta reemplaza a msfpayload y
msfenconde desde el 8 de junio de 2015.

4
https://www.metasploit.com/
5
https://www.offensive-security.com/metasploit-unleashed/msfvenom/

8
 Fig. 7. Herramienta msfvenom

En este proyecto se utilizará msfvenom para generar un payload para sistemas

Windows x86 que consistirá en una pequeña ventana con un mensaje que avisa de
que el sistema ha sido hackeado. Como se ha dicho, la herramienta se puede
utilizar para generar payloads en múltiples plataformas: Linux, Unix, Windows,
Android, OSX… Y algunos de estos payloads permiten incluso formatear las
unidades con que cuente un sistema Windows, o tomar el control remoto de la
máquina, por ejemplo. Por tanto, es una herramienta muy potente con la que se
pueden generar códigos peligrosos para sistemas vulnerables. Además, y usando
los encoders integrados en la misma, se puede codificar el payload para evitar
la detección de programas antivirus.

2.2.3 Scripts para generación y búsqueda de patrones

Las mismas funciones que se integran dentro del script en Python mona.py, ya
comentado en el apartado 2.1, están también presentes dentro de la distribución
de Kali, lo que nos permitirá usarlos para la generación de patrones de
caracteres aleatorios que nos permitan determinar, en su caso, el punto exacto
en el que se produce el desbordamiento de buffer. Concretamente, usaremos los
scripts pattern_create.rb y pattern_offset.rb para la generación de un patrón
de caracteres de cierto tamaño y la posterior búsqueda del offset en el que se
produce el desbordamiento del buffer. En Kali, estos scripts también se engloban
dentro de las herramientas que aporta MSF y están localizados en la ruta
/usr/share/metasploit-framework/tolos/exploits, como se ve más en la siguiente
figura.

9
 Fig. 8. Ubicación de los scripts pattern_create.rb y pattern_offset.rb

3. Exploit para PCMan FTP Server 2.0.7

Se van a realizar a continuación una serie de pasos sistemáticos encaminados a

la obtención de un exploit para atacar a la aplicación PCMan FTP Server 2.0.7.

3.1. Fuzzing al servidor FTP

Para determinar si PCMan FTP Server 2.0.7 es vulnerable a un ataque de
desbordamiento de buffer, puesto que no disponemos de su código fuente, vamos
a empezar lanzando un fuzzer contra el mismo. Este tipo de herramienta permite
Enviar grandes cantidades de caracteres a las aplicaciones, intentando provocar
el fallo de las mismas.
MSF dispone de algunos fuzzers entre sus módulos auxiliares, en concreto, en
el módulo auxiliary > fuzzers. Uno de ellos, desarrollado por Corelan Team, se
usa para realizar un testeo de buffer overflow en servidores FTP. Introduce
tantos caracteres como se le indique 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.
Empezamos lanzando la aplicación PCMan FTP Server 2.0.7 en la máquina virtual
Windows XP SP3, con IP 192.168.1.250 (ver Fig. 9). Inicialmente, pretendemos
realizar una aproximación burda de si la aplicación es vulnerable a un rango
de fuzzer bastante amplio.

10
 Fig. 9. Se lanza la aplicación PCMan FTP Server en la máquina virtual Windows XP SP3

Desde la máquina virtual de Kali, utilizamos mfsconsole para lanzar el fuzzer

ftp_pre_post, desarrollado por Corelan Team como se dijo anteriormente, donde
especificamos como parámetros de esa aplicación en una primera aproximación:
- rhost: 192.168.1.250 (máquina donde está corriendo PCMan FTP Server
- endsize: 3000 (definimos el tamaño máximo de la entrada de texto)
- startsize: 500 (empezaremos con un texto de 500 caracteres)
- stepsize: 100 (los saltos hasta provocar el fallo serán de 100 en 100
caracteres)

Fig. 10. Lanzando mfsconsole

11
 Fig. 11. Parámetros iniciales del fuzzer ftp_pre_post
Tras lanzar el exploit, se puede apreciar que el servidor FTP acepta sin
problemas peticiones de texto hasta unos 2000 caracteres, pero a partir de ahí
el fuzzer va más lento, y acaba reportando un fallo de la aplicación, que se
hace evidente cuando se observa que en Windows, efectivamente, la apliación se
ha caído. Viendo los datos del informe de errores en Windows se observa que se
reporta una dirección de memoria en la que parece ocurrir el fallo: 7043396f.

Fig. 12. Fuzzing inicial

12
 Fig. 13. Fallo en la aplicación

Sabiendo ya de antemano en qué tamaño estamos provocando un desbordamiento de

buffer en la aplicación, realizamos otro fuzzing pero ahora intentando afinar
más, y además, observando el comportamiento de la aplicación enlazándola con
el depurador.
Así pues, Ejecutamos el depurador y lo enlazamos con esta aplicación con File-
>Attach (Fig. 14). Tras esto, podemos ver en Immunity Debugger el código de la
aplicación en ensamblador, así como el valor que tienen en ese momento los
registros del sistema y el estado de la pila (Fig. 15).

Fig. 14. Enlazando Immunity Debugger con PCMan FTP lanzado

13
 Fig. 15. Servidor FTP enlazado con Immunity Debugger
Reacondicionamos los parámetros de ftp_pre_post para afinar en torno al tamaño
de cadena que ha provocado el fallo:
- endsize: 2200 (definimos el tamaño máximo de la entrada de texto)
- startsize: 1900 (empezaremos con un texto de 1900 caracteres)
- stepsize: 20 (los saltos hasta provocar el fallo serán de 20 en 20
caracteres)
En la siguiente figura se presenta una captura de pantalla de cuándo se reporta
el fallo en el debugger, mientras el fuzzer está lanzando un texto de entre
2000 y 2020 caracteres. Se puede observar que el registro EIP, que apunta a la
siguiente instrucción a ejecutar, se queda marcando la misma dirección de
memoria que reportaba el informe de errores de Windows: 7043396f.

Fig. 16. Fallo reportado en el debugger

14
3.2. Esqueleto de ataque inicial
En el apartado anterior se ha visto que el servidor FTP es vulnerable a un
desbordamiento de buffer con una cadena entre 2000 y 2020 caracteres. El fuzzing
no ha reportado ningún comando específico para usar con el servidor FTP, pero
inicialmente vamos a intentarlo con el comando USER, con el que se especifica
en el protocolo FTP el usuario que accede al servidor.
Para cerciorarnos de que se produce el desbordamiento de buffer, preparamos un
esqueleto inicial (ver Anexo I) que mande un login de usuario de 2020
caracteres. Simplemente inicia una sesión FTP con un nombre de usuario compuesto
de 2020 caracteres A a la dirección IP que se le pasa como argumento y al
puerto 21.

Fig. 17. Esqueleto inicial

Ejecutando el script anterior con el debugger lanzado, se puede apreciar que
efectivamente existe desbordamiento de buffer con una cadena de 2020 caracteres
y utilizando el comando USER.

Fig. 18. Ataque con esqueleto inicial

15
 Fig. 19. Desbordamiento de buffer con esqueleto inicial

3.3. Esqueleto con patrones cíclicos

Con el propósito de averiguar exactamente en qué carácter se produce el
desbordamiento de buffer, generamos un patrón de 2020 caracteres cíclicos
utilizando para ello el script pattern_create.rb (ver Anexo II).

Fig. 20. Generación de patrón cíclico

Y modificamos el esqueleto para que ahora incluya en lugar de los 2020
caracteres A, este nuevo patrón con caracteres cíclicos (ver Anexo III).

16
 Fig. 21. Esqueleto con el patrón cíclico
Ejecutamos nuevamente el script de este nuevo esqueleto con el debugger
funcionando. Cuando ocurre el desbordamiento de buffer, el debugger marca un
valor para el registro EIP: 386F4337.

Fig. 22. Desbordamiento de buffer con esqueleto patrón

Utilizando ahora el script patter_offset.rb, con el valor del EIP registrado,
podemos averiguar cuál es el carácter exacto que provoca el desbordamiento de
buffer. Se observa que a partir de 2003 bytes es cuando se produce dicho
desbordamiento.

Fig. 23. Tamaño exacto que genera desbordamiento

17
3.4. Badchars
Existen una serie de caracteres que pueden limitar el funcionamiento de los
exploits, debido a que las funciones que implementan las aplicaciones pueden
reaccionar a la presencia de esos caracteres de formas varidadas impidiendo
que ocurra el desbordamiento de buffer. Estos caracteres reciben el nombre de
badchars. Comprobaremos a continuación manualmente si alguno de estos
caracteres inválidos afecta a la ejecución de nuestro exploit. Para ello,
utilizaremos un script en Python que es capaz de generar todo el conjunto de
caracteres posibles (ver Anexo IV). Hay un total de 206 caracteres generados
por este script.

Fig. 24. Lista de badchars posibles

Como se ha dicho, el EIP se sobreescribe con 2003 caracteres. Más adelante
prepararemos un exploit que utilizará el método de salto JMP ESP para la
ejecución del payload. Conformamos ahora un esqueleto donde en lugar del payload
que generaremos después metemos los caracteres de la Fig. 24, con la intención
de ver si aparecen esos caracteres donde posteriormente estará el payload. En
caso de que no aparezca deberemos entender que, efectivamente, es un badchar y
lo tendremos que descartar posteriormente en la generación del payload. En la
Fig. 25 se muestra el esqueleto generado (ver Anexo V).

18
 Fig. 25. Esqueleto para ir probando los diferentes badchars
La primera ejecución de este esqueleto sobre el servidor FTP genera la pila
que se muestra en la Fig. 26, en la que el EIP se escribe con BBBB
(\x42\x42\x42\x42) –una dirección que no contiene ninguna instrucción legigle
y que posteriormente usaremos para buscar el salto-, luego aparecen los 30 nops
programados (\x90) y tras ellos no se ve el primer badchar (\x00), de lo que
se deduce que es un carácter inválido para esta aplicación.

Fig. 26. \x00 es un badchar

Modificamos el esqueleto anterior descartando el primero de los caracteres que
se ha mostrado como un badchar (\x00) y volvemos a ejecutarlo, obteniendo la
pila de la Fig 27. Se puede ver ahora que tras los nops aparecen los caracteres
\x01, \x02, \x03, \x04, \x05, \x06, \x07, \x08 y \x09 pero el \x0a no aparece,
por lo que es el siguiente badchar a descartar.

19
 Fig. 27. \x0a es un badchar
Una nueva iteración con el esqueleto modificado para descartar este badchar
genera la pila de la Fig. 28, que de nuevo muestra que \x0d es el siguiente
badchar a descartar.

Fig. 28. \x0d es un badchar

Eliminando del esqueleto el carácter \x0d volvemos a ejecutarlo y en este caso
ya insertan el resto de los caracteres que forman la cadena chars del esqueleto,
ya que se puede apreciar que el último (\xff) aparece antes de los siguiente
100 nops programados.

Fig. 29. El resto de los caracteres se insertan sin problema

En conclusión, los badchars a descartar en la generación del payload serán
\x00, \x0a y \x0d.

3.5. Generación del payload

Para la generación del payload utilizaremos la herramienta msfvenom. Como ya
se dijo en 2.2.2, es una herramienta que permite la generación de múltiples
payloads para diferentes sistemas y además se pueden utilizar encoders para
hacerlos permeables a los antivirus.

20
En este proyecto se va a utilizar un payload que consiste en la ejecución de
una ventana que muestra un mensaje (ver Anexo VI). Obviamente, se genera la
carga para un sistema Windows de 32 bits y, además, se evitan los badchars
identificados en el apartado anterior. Las opciones pasadas a msfvenom para
ello son:
 -p windows/messagebox: especifica el payload a usar, en este caso una
pequeña ventaña mostrando un mensaje. Con msfvenom –l payloads se puede
ver un listado de todos los payloads que permite generar esta aplicación.
 TEXT=’TE HE PILLADO DESPREVENIDO!’: es el texto que se mostrará en la
ventana.
 TITLE=HackeoEtico: se mostrará ese texto en la parte superior de la
ventana.
 -f c: especifica el formato de salida; msfvenom permite generar payloads
en múltiples formatos (msfvenom --help-formats para verlos todos). En
este caso se genera en C.
 -a x86: especifica la arquitectura en la que se ejecutará el payload.
 -b ‘\x00\x0a\x0d’: Lista de badchars a evitar en la codificación.

Fig. 30. Payload generado

Con esto, creamos una primera versión del exploit incorporando el payload al
mismo, tal y como se ven en la Fig. 31 (ver Anexo VII).

21
 Fig. 31. Exploit inicial

3.6. Búsqueda de dirección de salto

Para la dirección de EIP vamos a utilizar un salto indirecto, buscando una
instrucción que sea capa de saltar a nuestro payload. Usaremos la solución de
saltar a una instrucción ‘JMP registro’, localizada en alguna librería del
sistema o de la aplicación para situar nuestro payload en la dirección a la
que apunte, siguiendo el siguiente esquema.

Fig. 32. Esquema de salto

Se buscará una dirección que no contenga ninguno de los badchars localizados
anteriormente. Además, como hemos visto en los ejemplos donde buscábamos los
badchars, en la cabeza de la pila se escribían los caracteres candidatos a ser
badchars una vez que se desbordaba el buffer, lo que significa que el registro

22
ESP (Extended Stack Pointer, que almacena un puntero a la parte inferior de la
pila) apunta a una parte del buffer desbordado. Por tanto, usaremos ese registro
para apuntar a nuestro payload.
Usamos el exploit inicial de la Fig. 31 para provocar el desbordamiento y
buscamos en las librerías del sistema o de la aplicación alguna instrucción
JMP ESP a la que saltar para que redirija el flujo al payload. Para ello,
usaremos el plugin mona y el comando find en Inmmunity Debugger.

Fig. 33. Búsqueda de JMP ESP

El comando introducido buscará instrucciones con el texto jmp esp y además
evitará aquellas que tengan el carácter nulo (‘-n’). Los veinte primeros
resultados aparecen en una ventana de Log como se ve en la siguiente figura.

Fig. 34. 20 primeras direcciones de salto encontradas

En el archivo find.txt dentro de C:\Archivos de programa\Immunity Inc\Immunity
Debugger se podrán ver todos los resultados obtenidos (Ver Anexo VIII).

23
 Fig. 35. Todas las direcciones de salto encontradas
Ya lo único que resta es elegir una de esas direcciones, para lo que se seguirán
los siguientes criterios:
 Que no tenga ninguno de los badchars en su dirección.
 Que no tenga protección ASLR (Address Space Layout Randomization), lo
que mantendrá fija la referencia en memoria.
En este caso todas las direcciones cumplen lo anterior, porque en Windows XP
no existía la característica ASLR. También se ve que los saltos que salen en
el fichero find.txt dependen todos del sistema operativo, por lo que el exploit
solo se podrá ejecutar con el servidor FTP corriendo bajo Windows XP.
Elegimos por ejemplo la tercera de las direcciones que aparecen en la Fig. 35,
que llama a la librería dinámica kernel32.dll: 0x7c86467b. Con ella,
modificaremos el exploit inicial para cargar en el EIP dicha dirección. A la
hora de hacerlo, utilizamos el formato Little Endian, como se ve en la siguiente
figura (Ver Anexo IX).

Fig. 36. Exploit final con salto

24
Ejecutando el exploit anterior sobre la máquina Windows con el servidor FTP
funcionando veremos el efecto que tiene nuestro payload, como se muestra en
las siguientes figuras.

Fig. 37. Ejecución del exploit desde Kali

Fig. 38. Resultado del exploit sobre la aplicación

25
4. Anexos

En los anexos a este proyecto se incluyen los ficheros que se han ido
generando en los pasos anteriores, a saber:
I. esqueleto_inicial.py: Contiene un buffer de 2020 caracteres A que
provocan desbordamiento de buffer en la aplicación PCMan FTP Server
2.0.7.
II. patron: Contiene un patrón de 2020 caracteres cíclicos generado con
pattern_create.rb.
III. esqueleto_patron.py: Modificación del esqueleto inicial incorporando el
patrón generado anteriormente, para detectar el punto exacto en el que
se produce el desbordamiento.
IV. badchars.py: Script que permite la generación de una lista de caracteres
que pueden ser inválidos para una aplicación.
V. Badchars_ftp.py: Esqueleto que incluye los caracteres generados en IV
como si fuera el payload del exploit a partir del punto en el que se
produce el desbordamiento, de cara a ver si la aplicación no puede
insertar alguno de esos caracteres y evitarlos así en la generación del
payload.
VI. payload_windows_messagebox: Payload generado con msfvenom que genera una
ventana con un mensaje en la aplicación a la que ataca.
VII. exploit_inicial.py: Versión inicial del exploit que escribe en EIP un
valor basura (BBBB) para comprobar la inyección del payload tras el
desbordamiento del buffer.
VIII. find.txt: Fichero que contiene todas las direcciones JMP ESP encontradas
con el plugin mona.py.
IX. exploit_ftp.py: Exploit final del proyecto, incluyendo salto indirecto.

26