israeltorresTFM0123memoria

•

SIN SIGLA

Juan Ignacio Niveiro

23/4/2024

¡Este material tiene más páginas!

Vista previa del material en texto

Pentesting & Hacking Ético mediante
resolución de un Capture The Flag (CTF)

Nombre Estudiante: Israel Torres Gonzalo

Programa: Máster Universitario en Ciberseguridad y Privacidad

Nombre Profesores: Pablo González Pérez & Jordi Serra Ruiz

Fecha entrega: Curso 2022/2023 – 1º Semestre
ii

Dedicado a mi mujer y a mis dos hijos por darme la fuerza necesaria
para trabajar y aprender cada día.

Esta obra está sujeta a una licencia de Reconocimiento-NoComercial-CompartirIgual
3.0 España de Creative Commons

http://creativecommons.org/licenses/by-nc-sa/3.0/es/
iii

FICHA DEL TRABAJO FINAL

Título del trabajo:

Pentesting & Hacking Ético mediante resolución
de un Capture The Flag (CTF)

Nombre del autor: Israel Torres Gonzalo
Nombre del consultor: Pablo González Pérez
Fecha de entrega (mm/aaaa): 01/2023
Área del Trabajo Final: Seguridad en redes y sistemas
Titulación:
Máster Universitario en Ciberseguridad y
privacidad
Resumen del Trabajo (máximo 250 palabras):

La finalidad de este trabajo es conocer la metodología utilizada para realizar un
pentesting o test de intrusión en un sistema informático. Una vez aplicada con éxito esta
metodología sobre un sistema, se pueden conocer y resolver las configuraciones
incorrectas que ponen en riesgo este activo para protegerlo ante los futuros ataques
que pueda sufrir. Es una metodología relativamente nueva pero crítica para los activos
expuestos a redes públicas como Internet, ya que permite a las corporaciones
adelantarse a lo que un atacante realizaría sobre sus activos y equipar las medidas que
evitarán que esto suceda.

Este trabajo de fin de máster se inicia con un repaso al estado de arte que nos ha llevado
al uso normalizado de retos CTF (Capture The Flag) como metodología de enseñanza
para pentesting. Continúa con la exposición del entorno elegido para la realización de
los tres escenarios planteados, tanto a nivel hardware como a nivel software.
Posteriormente se realiza la resolución de los tres escenarios en cinco fases
diferenciadas y con multitud de información adicional como descripción de comandos
de consola shell o capturas de pantalla con los resultados obtenidos en cada paso
realizado. Posteriormente se revisan las conclusiones motivadas por la realización de
este trabajo de fin de máster.

Abstract (in English, 250 words or less):
The purpose of this paper is to learn about the methodology used to perform a pentesting
or penetration test on a computer system. Once this methodology has been successfully
applied to a system, we can identify and resolve the incorrect configurations that put this
asset at risk in order to protect it against future attacks. This is a relatively new but critical
methodology for assets exposed to public networks such as the Internet, as it allows
companies to anticipate what an attacker could do to their assets and provide them with
the measures to prevent it.

This master's thesis begins with a review of the state of the art that has led to the
standardised use of CTF (Capture The Flag) challenges as a didactic methodology for
pentesting. It continues with a presentation of the environment chosen to perform the
three proposed scenarios, both at hardware and software level. Subsequently, the
resolution of the three scenarios is conducted in five different phases and with a
multitude of additional information such as a description of shell console commands or
screenshots with the results obtained in each step. Subsequently, the conclusions drawn
from the completion of this master's thesis are reviewed.

Palabras clave (entre 4 y 8):

CTF CVE CWE Ciberseguridad Sistemas Pentesting Flag

Índice

1. Introducción ............................................................................................................................... 1
1.1 Contexto y justificación del Trabajo ..................................................................................... 1
1.2 Objetivos del trabajo ............................................................................................................ 2
1.3 Objetivos personales del trabajo ......................................................................................... 2
1.4 Requerimientos del proyecto ............................................................................................... 3
1.5 Enfoque y método seguido .................................................................................................. 3
1.6 Riesgos del proyecto ........................................................................................................... 4
1.7 Planificación del Trabajo ...................................................................................................... 4
1.7.1 Diagrama Gantt del TFM............................................................................................ 6
1.8 Breve descripción de los otros capítulos de la memoria ..................................................... 7
2. Estado del arte .......................................................................................................................... 8
3. Configuración del entorno ....................................................................................................... 11
3.1 Sistema anfitrión: Windows 11 Pro .................................................................................... 12
3.2 Sistema hipervisor: VMWare Workstation Pro v16 ........................................................... 12
3.3 Sistema contenedor: KALI Linux 2022.3 ........................................................................... 13
3.3.1 NMap ........................................................................................................................ 15
3.3.2 WhatWeb & Nikto & Wappalyzer ............................................................................. 17
3.3.3 DirBuster .................................................................................................................. 18
3.3.4 Metasploit Framework .............................................................................................. 18
3.3.5 Hydra ........................................................................................................................ 19
3.3.6 SQLMap ................................................................................................................... 20
3.4 Contenedores Docker CTF ................................................................................................ 20
4. CTF .......................................................................................................................................... 21
4.1 Escenario 1 – OoOps machine .......................................................................................... 21
4.1.1 Enumeración Escenario 1 ........................................................................................ 21
4.1.2 Análisis de vulnerabilidades Escenario 1................................................................. 24
4.1.3 Explotación de vulnerabilidades Escenario 1 .......................................................... 27
4.1.4 Post-Explotación Escenario 1 .................................................................................. 29
4.1.5 Reporte y mitigaciones Escenario 1 ........................................................................ 29
4.1.6 Resumen de Flags Escenario 1 ............................................................................... 30
4.2 Escenario 2 - Odyssey_v2 ................................................................................................. 31
4.2.1Enumeración Escenario 2 ........................................................................................ 31
4.2.2 Análisis de vulnerabilidades Escenario 2................................................................. 36
4.2.3 Explotación de vulnerabilidades Escenario 2 .......................................................... 37
4.2.4 Post-Explotación Escenario 2 .................................................................................. 39
4.2.5 Reporte y mitigaciones Escenario 2 ........................................................................ 40
4.2.6 Resumen de Flags Escenario 2 ............................................................................... 41
4.3 Escenario 3 – jump_force .................................................................................................. 42
4.3.1 Enumeración Escenario 3 ........................................................................................ 42
4.3.2 Análisis de vulnerabilidades Escenario 3................................................................. 45
4.3.3 Explotación de vulnerabilidades Escenario 3 .......................................................... 46
4.3.4 Post-Explotación Escenario 3 .................................................................................. 53
4.3.5 Reporte y mitigaciones Escenario 3 ........................................................................ 53
4.3.6 Resumen de Flags Escenario 3 ............................................................................... 54
5. Conclusiones ........................................................................................................................... 55
6. Glosario ................................................................................................................................... 57
7. Bibliografía............................................................................................................................... 59
8. Anexos ..................................................................................................................................... 61
8.1 Scripts para Escenario 1 .................................................................................................... 61
8.2 Scripts para Escenario 3 .................................................................................................... 62
vi

Índice de figuras

Figura 1. Cronograma del Proyecto .............................................................................................. 4
Figura 2. Diagrama Gantt del Proyecto ......................................................................................... 6
Figura 3. Token físico RSA SecurID para 2FA ............................................................................. 8
Figura 4. Red Team vs Blue Team (texto en Inglés) .................................................................. 10
Figura 5. Esquema del entorno virtualizado utilizado para el TFM ............................................. 11
Figura 6. Configuración adaptadores de red en VMWare .......................................................... 13
Figura 7. Selección de edición KALI para descarga ................................................................... 14
Figura 8. Ventana de acceso al sistema KALI Linux................................................................... 14
Figura 9. Salida a pantalla del comando NMap .......................................................................... 16
Figura 10. Ejemplo de salida a pantalla de WhatWeb ................................................................ 17
Figura 11. Ejemplo de salida a pantalla de Nikto ........................................................................ 17
Figura 12. Ejemplo de información Wappalyzer ......................................................................... 18
Figura 13. DirBuster, configuración recomendada ...................................................................... 18
Figura 14. Inicio de utilidad Metasploit Framework ..................................................................... 19
Figura 15. Ejemplo de uso de Hydra ........................................................................................... 19
Figura 16. Ejemplo de uso de SQLMap ...................................................................................... 20
Figura 17. [ESC1] Inicio de Escenario 1 (output de Docker) ...................................................... 21
Figura 18. [ESC1] Resultado de enumeración NMap ................................................................. 21
Figura 19. [ESC1] Análisis acceso FTP ...................................................................................... 22
Figura 20. [ESC1] Acceso SSH ................................................................................................... 22
Figura 21. [ESC1] Análisis web WhatWeb .................................................................................. 23
Figura 22. [ESC1] Análisis web Nikto ......................................................................................... 23
Figura 23. [ESC1] Ejecución de DirBuster .................................................................................. 23
Figura 24. [ESC1] Acceso HTTP en TCP8080 ........................................................................... 24
Figura 25. [ESC1] Contenido de test.php generado para prueba PHPInfo ................................ 24
Figura 26. [ESC1] Carga de test.php por FTP ............................................................................ 25
Figura 27. [ESC1] Carga de fichero PHPInfo .............................................................................. 25
Figura 28. [ESC1] Carga de PHP para mostrar /home ............................................................... 26
Figura 29. [ESC1] Carga de PHP para mostrar /home/hacker ................................................... 26
Figura 30. [ESC1] Comando PS -AUX ........................................................................................ 26
Figura 31. [ESC1] Acceso SSH con usuario hacker ................................................................... 27
Figura 32. [ESC1] Versión SUDO instalada ................................................................................ 28
Figura 33. [ESC1] Explotación de vulnerabilidad en SUDO ....................................................... 28
Figura 34. [ESC2] Inicio de Escenario 2 (output de Docker) ...................................................... 31
Figura 35. [ESC2] Resultado de enumeración NMap ................................................................. 31
Figura 36. [ESC2] Acceso SSH ................................................................................................... 32
Figura 37. [ESC2] Resultados de DirBuster ................................................................................ 32
Figura 38. [ESC2] Representación gráfica de recursos encontrados ......................................... 33
Figura 39. [ESC2] PHPInfo del servidor web (TCP8080) ........................................................... 34
Figura 40. [ESC2] Ejemplo de una de las imágenes (0.jpg) ....................................................... 34
Figura 41. [ESC2] Descifrar fichero base64 en KALI .................................................................. 35
Figura 42. [ESC2] Descifrar fichero base64 en KALI .................................................................. 35
Figura 43. [ESC2] Confirmación de la vulnerabilidad analizada (1) ........................................... 36
Figura 44. [ESC2] Confirmación de la vulnerabilidad analizada (2) ........................................... 36
Figura 45. [ESC2] Explotación de la vulnerabilidad (whoami) .................................................... 37
Figura 46. [ESC2] Explotación de la vulnerabilidad (ls-lha) ....................................................... 37
Figura 47. [ESC2] Explotación de la vulnerabilidad (cat /etc/passwd)........................................ 37
Figura 48. [ESC2] Búsqueda de módulo en Metasploit .............................................................. 37
Figura 49. [ESC2] Selección de módulo en Metasploit ............................................................... 37
Figura 50. [ESC2] Parámetros requeridos en Metasploit ........................................................... 38
vii

Figura 51. [ESC2] Shell Meterpreter mediante Metasploit .......................................................... 38
Figura 52. [ESC2] Obtención de flag de usuario ......................................................................... 38
Figura 53. [ESC2] Imágenes 1.jpg, 3.jpg y 11.jpg....................................................................... 39
Figura 54. [ESC2] Cálculo de hash de imágenes similares ........................................................ 39
Figura 55. [ESC2] Información oculta en imágenes.................................................................... 39
Figura 56. [ESC2] Acceso y captura de segunda flag ................................................................ 40
Figura 57. [ESC3] Inicio de Escenario 3 (output de Docker-Compose)...................................... 42
Figura 58. [ESC3] Resultado de enumeración NMap ................................................................. 42
Figura 59. [ESC3] Resultados de DirBuster ................................................................................ 43
Figura 60. [ESC3] Mensaje en index.php ................................................................................... 43
Figura 61. [ESC3] Formulario password.php .............................................................................. 43
Figura 62. [ESC3] Formulario password.php (id=0) .................................................................... 44
Figura 63. [ESC3] Formulario password.php (id=1) .................................................................... 44
Figura 64. [ESC3] Formulario backup.php .................................................................................. 44
Figura 65. [ESC3] Respuesta de formulario backup.php ............................................................ 44
Figura 66. [ESC3] Acceso a /icons/ desde navegador ............................................................... 44
Figura 67. [ESC3] Prueba de validación de inputs ..................................................................... 45
Figura 68. [ESC3] SQLMap sobre password.php ....................................................................... 45
Figura 69. [ESC3] Análisis de formulario backup.php................................................................. 46
Figura 70. [ESC3] Explotación SQLi en password.php .............................................................. 46
Figura 71. [ESC3] Reverse Shell mediante backup.php ............................................................. 47
Figura 72. [ESC3] Edición de fichero PHP .................................................................................. 48
Figura 73. [ESC3] Correcta activación del servidor HTTP .......................................................... 48
Figura 74. [ESC3] Descarga de chisel ........................................................................................ 48
Figura 75. [ESC3] Configuración IP de jump1 ............................................................................ 49
Figura 76. [ESC3] Ejecución de Chisel servidor invertido en KALI ............................................. 49
Figura 77. [ESC3] Conexión Chisel cliente-servidor ................................................................... 49
Figura 78. [ESC3] Configuración en /etc/proxychains4.conf ...................................................... 50
Figura 79. [ESC3] Resultado de NMap en red 172.18.0.1/24 (proxyxhains) ............................. 50
Figura 80. [ESC3] Uso de NC para detectar protocolo en puerto ............................................... 51
Figura 81. [ESC3] Ataque fuerza bruta con Hydra en SSH ........................................................ 52
Figura 82. [ESC3] Acceso y lectura de última flag ...................................................................... 52

1. Introducción

1.1 Contexto y justificación del Trabajo

Actualmente se pueden encontrar multitud de noticias sobre ciber-ataques a empresas
con distintas finalidades: obtener un beneficio económico con la venta de los datos
obtenidos, extorsión a las empresas afectadas, disminuir la credibilidad, etc. Estos
ataques, lejos de ser una moda pasajera o de caer en desuso, se están incrementando.
Según los últimos datos a cierre de año, en el 2021 hubo un crecimiento notable [1], de
casi un 125%, en el área de ciberataques.

Ante esta situación, las empresas han creado nuevos departamentos/grupos de trabajo
con la misión de proteger sus activos (datos) de los delincuentes y sus ciber-ataques.
Uno de estos equipos sería el denominado Blue Team que es el encargado de diseñar
e implementar las defensa que detengan los ataques y protejan los sistemas al tiempo
que monitorizan de forma preventiva.

Por otro lado, aparece en las empresas otro equipo de trabajo: el Red Team, el cual
tiene la misión de evitar las medidas de seguridad implantadas para certificar su
validez. Las misiones del Red Team pueden ser planificar y ejecutar pentesting sobre
los activos protegidos, evaluar otros riesgos como el phishing e intentar explotarlo con
los empleados, efectuar ataques de ingeniería social, etc.

Realizar un pentesting es intentar el acceso a una máquina sobre la cual no se tiene
permisos ni credenciales gracias a vulnerabilidades encontrados en el sistema o errores
en la configuración. Este TFM está dedicado a escenarios CTF que se pueden definir
como ejercicios de pentesting enfocados a instruir y formar a los futuros técnicos del
Red Team. Se basan en el aprendizaje a través del reto puesto que presentan
escenarios similares a los reales y para cuya resolución es necesario adquirir
habilidades o conocimientos concretos de seguridad y ponerlos en práctica. Esta
combinación de resolución de retos bajo cierta presión y la búsqueda de los
conocimientos necesarios para ello, hace que se interioricen las habilidades puestas en
práctica y sean unos métodos de aprendizaje muy productivos.

En el ámbito personal me atrae mucho la ciberseguridad en redes y sistemas y me
gustaría especializarme profesionalmente en esta rama. Poseo conocimientos de
seguridad y pentesting, y mi intención es ampliarlos y conseguir certificaciones que lo
avalen. Es por esto por lo que me he decidido a afrontar este TFM compuesto por retos
CTF como una etapa más en mi camino formativo. De esta forma aprenderé cómo
realizar ataques de intrusión a equipos y a través de su estudió comprenderé cómo
identificarlos, mitigarlos y/o solucionarlos.

[1] El Mundo PIXEL, 2022, El año de los grandes ciberataques en España
URL: https://www.elmundo.es/tecnologia/2021/12/01/61a63b4ae4d4d8db5a8b4577.html
https://www.elmundo.es/tecnologia/2021/12/01/61a63b4ae4d4d8db5a8b4577.html
2

1.2 Objetivos del trabajo

El objetivo general de este TFM es planificar y documentar la metodología necesaria
para identificar, explotar y solucionar las vulnerabilidades que comprometan las
máquinas de los retos CTF que lo componen. Estas vulnerabilidades permiten el acceso
a datos protegidos (denominados flags) en los sistemas objetivo, esto evidencia que no
se cumple el principio de confidencialidad de datos. Tampoco se cumplirían los
principios de integridad ni disponibilidad al poder modificar y borrar dichos datos.

La parte funcional del trabajo se resolverá mediante pruebas de penetracióno
pentesting a las máquinas objetivo que revelarán la información necesaria para
desarrollar el resto de las tareas del TFM. Por tanto, se puede desgranar el objetivo
principal en los cuatro siguientes subobjetivos:

A. Enumerar los servicios, puertos y software que se ejecuta en cada uno de los
contenedores puestos a disposición del alumno a través de un entorno de
contenedores Docker. Para ello se utilizarán diferentes utilidades disponibles
públicamente, sus manuales de uso y ejemplos extraídos de fuentes públicas.

B. Lograr la explotación de vulnerabilidades en las máquinas propuestas y
conseguir las 3 flags de usuario. Para ello se analizarán los datos conseguidos
en la fase enumeración, se identificarán posibles puntos de intrusión a los
sistemas y se pondrán en práctica las técnicas necesarias (exploits) para
aprovechar estos puntos de entrada y confirmar la intrusión. De esta manera se
tendrá acceso a parte de los datos protegidos por el sistema objetivo.

C. Lograr una escalada de privilegios en cada una de las máquinas propuestas y
conseguir así las 3 flags de administración. En este subobjetivo se utilizarán
nuevas técnicas, basadas en vulnerabilidades detectadas en los sistemas, para
lograr el acceso a la totalidad de los datos del sistema (acceso root) u a otro
contendor de datos únicamente accesible desde la máquina objetivo.

D. Ofrecer soluciones para las vulnerabilidades y escaladas de privilegios
utilizadas para la resolución de cada máquina del CTF para configurar un posible
escenario en el que la información estuviera segura y se cumpliera con los
principios de confidencialidad, integridad y disponibilidad.

1.3 Objetivos personales del trabajo

Mi objetivo al elegir la temática de CTF para la realización de mi TFM es ampliar mis
conocimientos en las técnicas utilizadas en los desafíos CTF. Antes de iniciar este
TFM tenía conocimientos sobre cómo realizar reconocimiento de servicios y puertos
abiertos en hosts, pero no conocía la metodología necesaria para explotar estos
servicios y conseguir acceder a la información de los sistemas. Además, contaba con
experiencia en hardening de hosts, pero sin tener claro el papel del Red Team y cómo
se realizan sus trabajos.
3

Por esto, se pueden enumerar los objetivos personales que me han traído hasta la
elaboración de este TFM de la siguiente manera:

• Adquirir conocimiento sobre enumeración de posibles puntos de acceso a
los sistemas basándonos en los puertos/servicios activos, las versiones de
aplicativo que se ejecutan en estos, etc.
• Afianzar conocimientos sobre metodologías estudiadas en otras
asignaturas de este máster: SQL Injection, Path traversal¸ reverse hashing, etc.
• Ampliar mi conocimiento acerca de explotación de vulnerabilidades
manualmente para poder acceder a un sistema.
• Ampliar mi conocimiento sobre las herramientas que se pueden utilizar para
facilitar las tareas de reconocimiento y explotación de vulnerabilidades.
• Ampliar mi conocimiento sobre cómo limitar la superficie de ataque realizando
tareas de hardening en los sistemas para evitar o mitigar los posibles ataques.

En términos generales mi objetivo es conseguir una base en conocimientos Red Team
y afianzar los conocimientos Blue Team que poseo.

1.4 Requerimientos del proyecto

• Conexión a Internet para descargar desde GitHub los contenedores Docker que
contienen los retos CTF.
• Un ordenador capaz de ejecutar los contenedores Docker con los retos CTF, en
este TFM se utiliza Kali Linux 22.3 [2] con Docker para su ejecución.
• Un ordenador capaz de ejecutar Kali Linux o similar para los trabajos de
pentesting, se utiliza Kali Linux 22.3 [2] en este TFM.

1.5 Enfoque y método seguido

El enfoque de este TFM es práctico, se basa en la explotación de vulnerabilidades
para conseguir acceso al sistema que permita lectura de distintos tipos de información
confidencial en tres escenarios presentados por el equipo docente como retos CTF.

El método utilizado para conseguir la explotación se divide en las cuatro fases estándar
de un pentesting que se documentarán para cada escenario:

• Enumeración de los servicios y datos de los escenarios.
• Análisis de vulnerabilidades que podrían aplicar a cada sistema.
• Explotación de las vulnerabilidades encontradas en la fase anterior.
• Post-Explotación: confirmar acceso a la información confidencial buscada,
escalar privilegios o realizar pivoting a otro equipo.

[2] KALI, 2022, Kali Linux 2022.3 Release
URL: https://www.kali.org/blog/kali-linux-2022-3-release/
https://www.kali.org/blog/kali-linux-2022-3-release/
4

La resolución de retos CTF necesita de conocimientos en cuanto a qué técnicas y
herramientas se pueden utilizar para cada una de estas cuatro fases. Estas
herramientas son actualizadas frecuentemente al tiempo que aparecen otras que
mejoran o cambian la metodología por lo que es necesario estar actualizado sobre las
últimas metodologías, vulnerabilidades y la explotación de estas.

Tras estas cuatro fases se realizará un informe exponiendo los pasos que se han
seguido, herramientas, dificultades, etc. y explicando cuáles mejoras se podrían aplicar
a los sistemas para que estos dejaran de ser vulnerables

1.6 Riesgos del proyecto

• No localizar el modo de resolver alguna de las máquinas propuestas.
• No efectuar una correcta memoria en cuanto a correcciones a implantar para
evitar que las máquinas afectadas sean vulnerables.
• No seguir las guías de formato y contenido de TFM propuestas en el aula.

1.7 Planificación del Trabajo

Para mostrar y justificar los tiempos estimados se utilizado un cuadro esquemático a
modo de cronograma con una asignación de dificultad para cada tarea basada en la
experiencia del autor en cada una de las áreas:

ACTIVIDAD
FECHA
INICIO
ESTIMACIÓN
DÍAS
FECHA
FIN
ESTIMACIÓN
DIFICULTAD
Planificación 03-oct 9 12-oct
Configuración del Entorno 05-oct 5 10-oct
Enumeración de puertos servicios y
software en cada contenedor
12-oct 20 01-nov
Resolución flags contenedor 1 12-oct 10 22-oct
Resolución flags contenedor 2 22-oct 12 03-nov
Resolución flags contenedor 3 03-nov 15 18-nov
Documentación de detalles y mitigaciones 15-nov 15 30-nov
Preparación de la entrega final y
correcciones
03-dic 35 07-ene
Elaboración de presentación TFM (slides
+ presentación)
20-dic 25 14-ene
Preparación de defensa síncrona TFM 07-ene 15 22-ene

INICIO PROYECTO 03-oct

FIN PROYECTO 22-ene

Figura 1. Cronograma del Proyecto
5

Se detalla cada uno de los puntos:

• Planificación: elaboración de este punto (1.7) del trabajo fin de máster con la
previsión de fechas para cada tarea.

• Configuración del Entorno: se exponen los sistemas hardware y software que
se utilizan para la consecución de los retos CTF incluidos en este TFM. Se
detallan las versiones de software utilizadas, aplicaciones y herramientas
instaladas, así como los comandos necesarios para la ejecución de cada
escenario CTF y toda la información relacionada y relevante para estos procesos
iniciales.

• Enumeración de puertos servicios y software en cada contenedor: se
explican las metodologías y herramientas utilizadas para obtener el máximo de
información de los contenedores que se ejecutan en cada escenario. De esta
forma se puede focalizar la siguiente fase de resolución.

• Resolución flags en contenedores: se utiliza la información del punto anterior
para analizar cómo se puede conseguir acceso a los contenedores de cada
escenario. Se comprueba si es posible utilizar las vulnerabilidades encontradas
en los sistemas del CTF y si mediante estas vulnerabilidades se puede leer la
información confidencial objetivo de cada CTF (flags).

• Documentación de detalles y mitigaciones: en estepunto se toma un tiempo
adicional para aumentar el detalle de la información aportada en la resolución de
cada máquina y exponer las mitigaciones que se podrían aplicar para evitar que
los escenarios sean vulnerables.

• Preparación de la entrega final de la memoria y correcciones: este punto se
incluye para corregir todo aquello que se comente por el equipo docente e
intentar mejorar y ampliar la información aportada en este TFM.

• Elaboración de presentación TFM (slides + presentación): se elabora una
presentación, previsiblemente en PowerPoint, sobre la resolución de los
escenarios CTF de este TFM. Posteriormente se graba un video en el que se
expone la presentación y se detalla cada una de las slides.

• Preparación de defensa síncrona TFM: se dedica este tiempo a repasar los
puntos de este TFM, así como la estructura y resolución de cada uno los
escenarios para poder defender de forma competente el TFM ante el tribunal
UOC.

1.7.1 Diagrama Gantt del TFM

Figura 2. Diagrama Gantt del Proyecto
7

1.8 Breve descripción de los otros capítulos de la memoria

En esta memoria de TFM se va a utilizar una organización basada en los tres escenarios
a resolver como objetivo. Por ello los puntos dedicados a las distintas fases de
pentesting están divididos en subpuntos dentro de cada escenario CTF.

A continuación, se enumeran los siguientes capítulos de este TFM:

• Capítulo 2: Estado del arte, donde se exponen los aspectos tecnológicos
relevantes que han llevado a nuestra sociedad al punto que ha motivado la
realización de este trabajo fin de máster y a considerarlo como parte de
tecnología punta aplicada.

• Capítulo 3: Configuración del entorno, donde se detallan las configuraciones
y sistemas hardware y software que se utilizan para la realización de los retos
CTF: el objetivo principal de este TFM.

• Capítulo 4: CTF, donde se realizan las cinco fases correspondientes a un
pentesting sobre cada uno de los tres escenarios planteados por el equipo
docente. En primer lugar, se divide este capítulo en tres subcapítulos, uno por
escenario, y posteriormente se subdivide cada subcapítulo en seis más, uno por
cada fase de la metodología de pentesting que se aplica sobre cada escenario y
otro adicional con un resumen de las flags obtenidas. Se considera que es la
manera adecuada de dividir el CTF en las distintas las fases del pentesting, pero
focalizándonos en cada uno de los escenarios.

• Capítulo 5: Conclusiones, donde se realiza una revisión sobre el cumplimiento
de los objetivos generales y personales tras la realización del TFM, un
seguimiento de los hitos propuestos inicialmente y sus fechas tope y se definen
posibles tareas a realizar como mejoras a implementar en futuros trabajos.

• Capítulo 6: Glosario, donde aparecen definidos los términos específicos del
lenguaje técnico utilizado en la temática de este TFM.

• Capítulo 7: Bibliografía, donde se detallan las fuentes consultadas para la
elaboración de este TFM.

• Capítulo 8: Anexos, donde se recogerá la documentación adicional que no
tenga cabida dentro de otro apartado del CTF o sea demasiado amplia para
incluirla directamente dentro de un capítulo.

2. Estado del arte

El mundo de los sistemas de la información siempre ha estado en constante
evolución. Comenzando por el cambio en los sistemas de almacenamiento pasando a
través de la democratización del uso de los sistemas informáticos (en lo profesional y
en lo personal) y llegando al primer cambio disruptivo que fue la interconexión de
sistemas de información a través de redes para el trabajo en empresas y
posteriormente Internet que unificó la mayoría de las redes empresariales.

En cada salto o innovación tecnológica asociada a los sistemas de información,
aparecían nuevas ramas de estudio y nuevas figuras asociadas a ellas. Esto
sucedió cuando aparecieron los primeros compiladores y con ellos la figura del
programador dedicado o cuando la interconexión de sistemas ya era algo necesario
para trabajar con computadores y apareció la figura del especialista en interconexiones
o redes de computadores. Esto provocó que la figura del mantenedor del sistema como
rol único desapareciera y en su lugar aparecieran distintos perfiles especializados en
cada una de las funciones necesarias para la explotación de los sistemas de la
información.

Con la interconexión masiva de sistemas de Internet aparecieron multitud de
nuevas amenazas y nuevos roles empresariales destinados a evitarlas. Esta
conectividad global supuso que la mayoría de los sistemas de la información ya no se
encontraban ubicados en instalaciones de acceso restringido y sin posibilidad de acceso
remoto. A partir de ese momento cualquier usuario conectado a Internet tenía la
posibilidad de conectarse a cualquier sistema de la red, público o privado. Es por
esto por lo que fue crítico mejorar las protecciones de la información que no debía ser
publicada, alterada, borrada, etc. y, por otra parte, garantizar que la información
estuviera accesible en todo momento para los usuarios legítimos que necesitaran
acceso a ella desde la red.

La interconexión de sistemas corporativos a Internet también introdujo el uso de
nuevos elementos destinados a mejorar la seguridad como firewalls y la puesta en
práctica de nuevas metodologías que hasta ese momento no eran críticas (por la
limitación de la superficie de ataque en equipos no conectados a redes globales) como,
por ejemplo, la identificación única y segura de usuarios, el uso de antivirus como norma,
la obligación de establecer políticas de contraseñas robustas, las políticas de bloqueo
de cuentas en fallos de autenticación, los dobles controles de autenticación como
sistemas 2FA, así como la limitación de la exposición de los diferentes servicios
corporativos o asegurar el correcto bastionado de los equipos corporativos en red.

Figura 3. Token físico RSA SecurID para 2FA
9

En los siguientes años los equipos frontera fueron evolucionando y pasaron de ser
firewalls que actuaban en capa 3 a ser capa 4 para evitar nuevos tipos de ataques.
Poco a poco la figura del técnico o ingeniero de redes se quedaba obsoleta al tener
que enfrentarse a diferentes situaciones con multitud de especializaciones. Es por esto
por lo que esta posición necesitaba dividirse y combinarse con otros roles para originar
nuevas oportunidades como, por ejemplo, los roles focalizados en seguridad de la
información, roles de desarrollo seguro, roles centrados en el control de identidad, etc.
Las figuras atacantes también evolucionaron, no sólo se aprovechaban de puertos
abiertos, contraseñas inseguras o realizaban ataques de phishing dirigidos, pasaron a
aprovechar, masivamente los errores de programación de las aplicaciones y del
equipamiento corporativo más común para tener nuevos puntos de entrada y a
desarrollar nuevas formas de malware hechas a la medida de cada objetivo. Las
corporaciones tuvieron que lanzar indexadores para identificar estos errores que
permitían accesos no permitidos a sus sistemas y asegurarse de que estaban exentos
de riesgos conocidos con las versiones de software que manejaban.

Estos índices de errores o debilidades en los sistemas se llamaron:
• CWE: definen debilidades generales que pueden aplicar a múltiples sistemas.
• CVE: definen debilidades o errores específicos de un sistema o software.

Aparecían nuevas técnicas que permitían a los atacantes acciones que no se
contemplaban en la mayoría de los simulacros de incidentes coetáneos como:
pivoting entre redes para llegar a equipos críticos sin conexión directa a Internet o
intentos de intrusión en equipos IoT y sistemas industriales (OT) críticos y normalmente
poco protegidos y actualizados.

La industria tuvo que avanzar y se generalizóel uso de nuevos sistemas para
evitar los ataques a la información como Firewalls capa 7 o sistemas UTM y NGFW
que unificaban Firewall, IDS e IPS y que controlaban el acceso a redes corporativas a
nivel de sesión. En lo relativo al personal a cargo de la seguridad corporativa también
se inició una nueva especialización que originó, entre otros, los roles dentro de los
llamados red team y blue team encargados de, entre otras funciones, buscar fallos
en los sistemas corporativos mediante pentesting y asegurar los sistemas
corporativos frente ataques dirigidos.

Era necesaria una definición formal para estos nuevos perfiles red y blue team:
eran perfiles técnicos con conocimientos en sistemas de la información, sistemas
operativos, funcionamiento y arquitectura de redes, comunicaciones TCP/IP con
nociones de programación o incluso con grades conocimientos en esta rama para crear
o defenderse frente a malware dedicado.

Al ser perfiles con un alcance tan amplio y con cierta profundidad en algunas
áreas de conocimiento, estos no contaban con un plan de formación formal y
muchos de ellos eran autodidactas que venían de otras áreas del SGSI o de la
administración de sistemas y redes.

Figura 4. Red Team vs Blue Team (texto en Inglés)
(imagen extraída de: https://www.crowdstrike.com/cybersecurity-101/red-team-vs-blue-team/)

Como medio para conseguir la unificación de la formación, la verificación del
conocimiento adquirido y poder mantener una fuente de aprendizaje comenzaron
los retos CTF (Capture The Flag). Estos retos informáticos suelen ser pruebas de
intrusión a sistemas, aunque puede haber otros basados únicamente en esteganografía,
en inteligencia OSINT y otros. Pueden ser utilizados por aspirantes o miembros de
perfiles Red Team para valorar sus conocimientos sobre pentesting de sistemas.

Poco a poco aparecen plataformas online que presentaban retos CTF como:
• Hack The Box [3]
• Try Hack Me [4]
• VulnHub [5]

Las cuales se pueden utilizar para iniciar o perfeccionar los conocimientos en este
ámbito. Hack The Box y Try Hack Me se basan en un sistema cloud de máquinas
objetivos al cual se conecta el usuario por VPN para realizar el pentesting. Mientras que
en VulnHub se permite la descarga de las máquinas objetivo para ejecutarlas
localmente con un hipervisor y entonces comenzar las tareas de pentesting.

Estas plataformas CTF representan un punto relevante y actual en la historia de
la seguridad de sistemas y redes. Por tanto, se puede afirmar que los ejercicios
CTF son una formación de referencia para los nuevos perfiles Red Team
necesarios en seguridad de sistemas de la información.

Este TFM trata sobre la resolución de 3 escenarios CTF a modo de ejercicios Red
Team y expone el equipamiento necesario y la metodología utilizada.

[3] Hack The Box, 2022, Hack The Box: Hacking Training For The Best
URL: https://www.hackthebox.com/
[4] Try Hack Me, 2022, TryHackMe | Cyber Security Training
URL: https://tryhackme.com/
[5] VulnHub, 2022, Vulnerable By Design ~ VulnHub
URL: https://www.vulnhub.com/
https://www.crowdstrike.com/cybersecurity-101/red-team-vs-blue-team/
https://www.hackthebox.com/
https://www.hackthebox.com/
https://tryhackme.com/
https://www.vulnhub.com/
11

3. Configuración del entorno

El entorno que se va a utilizar para realizar este CTF está basado en KALI Linux. Para
facilitar el análisis de los escenarios se ha decidido ejecutar KALI Linux en una
máquina virtual sobre un hipervisor VMWare Workstation en una máquina con
sistema operativo Windows 11.

Al ejecutarse KALI Linux dentro de un entorno virtualizado por VMWare, es posible
realizar snapshots que faciliten volver a un estado anterior concreto en la propia
máquina contenedora. Los distintos contenedores Docker se ejecutarán dentro de
la máquina KALI Linux mediante la instalación de Docker que se detallará más
adelante dentro de esta sección del TFM.

La conectividad de la máquina contenedora KALI Linux se ha resuelto utilizando
conectividad bridge sobre el interfaz ethernet de la máquina física. De esta manera la
máquina contenedora KALI Linux y sus respectivos contenedores estarán directamente
expuestos a la red LAN:

Figura 5. Esquema del entorno virtualizado utilizado para el TFM

Debido a esta estructura de comunicación con la red LAN mediante un interfaz en modo
bridge compartido con la máquina anfitriona, la máquina virtual KALI Linux tendrá una
dirección IP asignada por el router con servidor DHCP instalado en la red LAN (rango
10.10.10.1/24). Esta dirección IP será del mismo rango que la del sistema anfitrión
Windows 11 y tendrá conectividad directa con éste y con el resto de los hosts de esta
red y salida a Internet mediante el router/gateway de la red (GTW con IP 10.10.10.1).

De esta manera los contenedores Docker serán los encargados de ejecutar las
máquinas vulnerables objetivos del CTF en el que se basa este TFM, mientras que
la máquina virtual KALI Linux que ejecuta esos contenedores será la utilizada para
las tareas de pentesting.
12

3.1 Sistema anfitrión: Windows 11 Pro

El sistema anfitrión elegido para ejecutar la máquina virtual KALI Linux mediante
un hipervisor VMWare es Windows 11 Pro. Se ha utilizado el mismo equipo
(hardware) y sistema operativo que utiliza el autor de este TFM para su uso personal.

Se debe aclarar que para el uso del hipervisor de VMWare Workstation Pro v16 es
necesario que no esté habilitada en el sistema la aplicación de virtualización nativa de
Windows llamada Hyper-V. Esto se debe a incompatibilidades entre ambos hipervisores.

La computadora física utilizada para el sistema anfitrión es un ordenador portátil con
procesador Intel i5 de octava generación y 8GB de RAM por lo que es solvente para
virtualizar la máquina KALI Linux con 4GB de memoria RAM dedicada y así trabajar con
un rendimiento adecuado.

3.2 Sistema hipervisor: VMWare Workstation Pro v16

El software utilizado para ejecutar la máquina virtual KALI Linux es VMWare Workstation
Pro versión 16, se puede descargar y adquirir desde su web oficial [6].

Se ha preferido utilizar una máquina virtual de KALI Linux sobre una máquina hardware
dedicada por las siguientes ventajas:

• Opción de restaurar estados anteriores mediante la función snapshot de
VMWare. Esto facilita la recuperación del sistema en caso de desastres como
instalación incorrecta de paquetes, cambios de configuración erróneos, etc.

• Mayor comodidad en la redacción del TFM al poder ejecutar el procesador de
textos utilizado para el TFM (Microsoft Word sobre Windows 11) de forma
simultánea a KALI Linux y sus contenedores, y utilizando únicamente una
máquina física.

• Posibilidad de realizar capturas de pantalla de KALI Linux y sus herramientas
de una forma sencilla al estar ejecutándose sobre un hipervisor en un escritorio
Windows 11.

El uso de VMWare en preferencia a otras utilidades de virtualización como
VirtualBox e Hyper-V, ambas soluciones gratuitas para uso personal frente a VMWare
Workstation Pro que es una solución de pago, se debe a:

• Con VMWare se puede definir de forma exacta y sencilla la configuración de los
distintos interfaces de red virtualizados y su relación con los interfaces de red
físicos de la máquina anfitriona.

[6] VMWare, 2022, Descargar VMware Workstation Pro | ES
URL: https://www.vmware.com/es/products/workstation-pro/workstation-pro-evaluation.html
https://www.vmware.com/es/products/workstation-pro/workstation-pro-evaluation.html
13

• El autor cuenta con mayor experiencia de uso en VMWare, por lo que la
mayoría de las operaciones de configuración a realizar en el hipervisor están
interiorizadas y no supondrán un excesivo tiempo extra.

• El mayor coste que implica esta solución frente a otras no aplica ya quese
adquirió la correspondiente licencia para la redacción de un documento TFG.

La configuración de red necesaria para que la máquina virtual KALI Linux tenga
conectividad a Internet se ha solucionado mediante un interfaz físico compartido en
modo bridge con la máquina virtual. La configuración de este interfaz de red a utilizar
desde KALI Linux se debe realizar en el Virtual Network Editor de VMWare:

Figura 6. Configuración adaptadores de red en VMWare

Y posteriormente se añadiría un interfaz de red virtual conectado a esta red llamada
VMnet0 en la máquina virtual KALI Linux.

3.3 Sistema contenedor: KALI Linux 2022.3

KALI Linux es una distribución Linux basada en la rama testing de Debian. Está
enfocada a la seguridad informática e incluye multitud de utilidades
preconfiguradas en el sistema para realizar pentesting, ataques a contraseñas,
auditorías de redes WIFI, análisis forense, etc.

KALI Linux está mantenida por Offensive Security [7] una empresa dedicada a seguridad
informática que además cuenta con certificados para expertos en pentesting, como su
renombrado y prestigioso certificado OSCP [8].

[7] Offensive Security, 2022, Official OSCP Curriculum
URL: https://www.offensive-security.com/
[8] Offensive Security, 2022, OSCP Penetration Testing Certification, PEN-200
URL: https://www.offensive-security.com/pwk-oscp
https://www.offensive-security.com/
https://www.offensive-security.com/pwk-oscp
14

La versión de KALI utilizada es 2022.3 (núcleo de Linux versión 5.19.11) en su
distribución específica para máquina virtual de 64bits sobre VMWare y que está
accesible mediante un enlace [9] en su página web.

Figura 7. Selección de edición KALI para descarga

Su instalación y despliegue es sencilla:

1. Se descarga el fichero “7z” del enlace para máquina virtual VMWare comentado
anteriormente.
2. Se descomprime el fichero “7z” en una carpeta.
3. Desde VMWare Workstation Pro, se elige en el menú la opción File → Open y
se selecciona el fichero “kali-linux-2022.3-vmware-amd64.vmx” en la carpeta
donde se descomprimió el fichero “7z”.

Una vez importada la máquina virtual en VMWare Workstation Pro se le asigna
más memoria RAM virtual o y se configura su adaptador de red para que haga
bridge sobre un adaptador físico de la máquina anfitriona.

Cuando se inicie la máquina KALI Linux, se mostrará una ventana de identificación de
usuario en la que se deberá ingresar “kali” como usuario y también como contraseña:

Figura 8. Ventana de acceso al sistema KALI Linux

[9] KALI, 2022, Descargar KALI
URL: https://kali.download/virtual-images/kali-2022.3/kali-linux-2022.3-vmware-amd64.7z
https://kali.download/virtual-images/kali-2022.3/kali-linux-2022.3-vmware-amd64.7z
15

El primer paso que se debe realizar es configurar el teclado para que admita los
caracteres del castellano en un teclado Windows. Para ello se ejecutará desde una
consola de shell el siguiente comando, que se debe realizar en cada reinicio:

Tras esto, se puede configurar el adaptador de red desde un entorno de texto
amigable en shell mediante el comando:

Una vez que se tenga conexión a Internet, se actualizará el sistema a sus últimas
versiones mediante el siguiente comando de shell, obsérvese el uso de “sudo” para
invocar estos comandos con permisos de administración de máquina:

Tras la actualización de paquetes del sistema será necesario reiniciar KALI Linux para
aplicar correctamente los cambios. Tras el reinicio el sistema estará actualizado.

A continuación, se enumeran las utilidades incluidas en KALI Linux que se han
utilizado en mayor medida en las fases del CTF de este TFM:
3.3.1 NMap

NMap [10] es una utilidad de código abierto que se utiliza en modo consola. NMap
realiza escáneres de puertos: identifica cuáles puertos se encuentran abiertos y qué
servicios se encuentran tras cada uno de estos puertos. También es posible realizar con
NMap escáneres más detallados donde aparezca la versión de los servicios detectados
e incluso vulnerabilidades que apliquen a estos.

Aunque es posible utilizar NMap como usuario estándar, algunos de sus parámetros
necesitan que el usuario que lo invoque lo haga con permisos de administración
o root. Es por esto por lo que se puede decir que su sintaxis es:

Como parámetros existen multitud de modificadores que permiten alterar el modo de
escanear los servicios, el tipo de servicio a escanear, el rango de puertos, el detalle de
la búsqueda. Además, es posible realizar búsquedas “no profundas” para evitar levantar
sospechas en sistemas IDS o búsquedas en profundidad, más lentas y con mayor
detalle, y por ello mayor riesgo de detección en sistemas IDS, antimalware, etc.

[10] NMap, 2022, Nmap: the Network Mapper - Free Security Scanner
URL: https://nmap.org/
$ setxkbmap es winkeys

$ nmtui

$ sudo apt update && sudo apt-get upgrade

$ sudo nmap <parámetros> host_a_escanear

https://nmap.org/
16

Los parámetros más utilizados en este TFM han sido:

-p<puerto_inicial>-<puerto_final>: para concretar o extender el escáner a un
rango de puertos. Por defecto sólo se escanean los 1.000 primeros puertos TCP.

-sV: para intentar detallar la versión o información del servicio que se está ejecutando
en cada puerto abierto.

-Pn: para tratar todos los puertos como accesibles y no realizar antes la comprobación
de host ICMP que puede hacer perder resultados positivos.

-sS: para efectuar un escaneo silencioso que evita, en la mayoría de los casos, que se
registre la petición en el sistema destino. Esto se debe a que no completa el handshake
en tres pasos estándar del protocolo TCP utilizando funciones especiales del kernel de
Linux. Este parámetro necesita permisos de root y puede generar algún falso positivo.

-sU: para escanear puertos UDP en lugar de TCP que son los que se escanean por
defecto con NMap.

-vv: para aumentar el nivel de registro en pantalla. Se utiliza para mostrar en pantalla
los resultados, sin esperar al final del escaneo como se hace por defecto con NMap.

Por ejemplo, para escanear todos los puertos TCP del host con IP 10.10.10.115
mediante un escaneo silencioso, sin realizar la comprobación de conectividad inicial al
host¸ y mostrando los resultados directamente, sin esperar a finalizar el escaneo, se
ejecutaría el comando:

Figura 9. Salida a pantalla del comando NMap
$ sudo nmap -p1-65535 -sS -Pn -vv 10.10.10.115

3.3.2 WhatWeb & Nikto & Wappalyzer

WhatWeb [11] y Nikto [12] son dos herramientas de consola que recogen información
sobre un servidor web. Entre otros datos muestran: el sistema y la versión de servidor
web que están ejecutando, el sistema operativo del servidor web, los métodos HTML
permitidos, codificaciones soportadas, etc.

Su uso es sencillo, para escanear el host 10.10.10.110 en el puerto TCP8080 (HTTP)
con escaneo agresivo (-a nivel 3 de 4) y mostrar en pantalla (-v), se utiliza el comando:

Figura 10. Ejemplo de salida a pantalla de WhatWeb

En nikto únicamente es necesario definir el host y el puerto:

Figura 11. Ejemplo de salida a pantalla de Nikto

[11] KALI, 2022, WhatWeb Usage Example
URL: https://www.kali.org/tools/whatweb/
[12] Chris Sullo, 2022, Nikto2 - CIRT.net
URL: https://cirt.net/Nikto2
$ whatweb -v -a 3 http://10.10.10.110:8080

$ nikto -h http://10.10.10.110:8080

https://www.kali.org/tools/whatweb/
https://cirt.net/Nikto2
18

Wappalyzer [13] es una herramienta similar a las dos anteriores pero integrada en el
navegador Firefox. Permite conocer parte de la infraestructura/tecnología que utiliza una
web navegando hasta la URL a escanear:

Figura 12. Ejemplo de información Wappalyzer

3.3.3 DirBuster

DirBuster [14] es una utilidad para el escaneode directorios/aplicaciones web
mediante fuerza bruta basada en las respuestas que devuelve el servidor a cada
petición. Permite encontrar carpetas o ficheros en servidores web que no tengan
habilitada la exploración de directorios. Presenta una GUI que facilita su manejo.

Es posible utilizar diccionarios con los términos más comunes para agilizar las
búsquedas, así como definir las extensiones de fichero a probar y la profundidad de
directorios a explorar. Por ejemplo, para escanear el servidor HTTP 10.10.10.115:8080,
buscando ficheros sin extensión, php, txt, jpg, html, bak y basándose en un diccionario
incluido en KALI Linux, se utilizaría la siguiente configuración:

Figura 13. DirBuster, configuración recomendada

[13] Wappalyzer, 2022, Wappalyzer: Find out what websites are built with
URL: https://www.wappalyzer.com/
[14] KALI, 2022, dirbuster | Kali Linux Tools
URL: https://www.kali.org/tools/dirbuster/
https://www.wappalyzer.com/
https://www.kali.org/tools/dirbuster/
19

3.3.4 Metasploit Framework

Metasploit Framework [15] es una utilidad de consola de comandos que centraliza,
clasifica, documenta y organiza el desarrollo y la utilización de exploits. Su función
es agilizar el uso de exploits con un interfaz rápido y funciones preestablecida para la
carga de payloads. Para iniciar esta utilidad se utiliza el siguiente comando:

Figura 14. Inicio de utilidad Metasploit Framework

3.3.5 Hydra

Hydra [16] es una utilidad de consola de comandos diseñada para automatizar y
optimizar los ataques por fuerza bruta a diferentes sistemas de autenticación
como SSH, HTTP, MySQL, Telnet, SNMP, STMP, NFS, etc. Permite el uso de
diccionarios públicos o personalizados para cada una de las entradas (host / login /
password), procesamiento en paralelo y posibilidad de retomar trabajos interrumpidos.

Por ejemplo, para realizar un ataque por fuerza bruta SSH con usuario root y con
diccionario de contraseñas rockyou se utilizará el siguiente comando:

Figura 15. Ejemplo de uso de Hydra

[15] Metasploit, 2022, Metasploit | Penetration Testing Software, Pen Testing
URL: https://www.metasploit.com/
[16] GitHub, 2022, vanhauser-thc/thc-hydra
URL: https://github.com/vanhauser-thc/thc-hydra
$ msfconsole

$ hydra -l root -P rockyou.txt ssh://10.10.10.1:22

https://www.metasploit.com/
https://github.com/vanhauser-thc/thc-hydra
20

3.3.6 SQLMap

SQLMap [17] es una utilidad de consola de comandos diseñada para detectar las
vulnerabilidades web que permiten inyecciones SQL y acelerar y automatizar la
extracción de datos desde estas. Para su uso se necesita una URL completa que
incluya los parámetros GET a utilizar en las pruebas de inyección SQL. Incluye
diferentes opciones para evitar su detección por parte de sistemas de protección como
WAF o NGF y para limitar el número de consultas a realizar y evitar protecciones anti-
DoS.

Por ejemplo, para comprobar si un formulario es sensible a un ataque de inyección SQL
se utilizará el comando siguiente:

Figura 16. Ejemplo de uso de SQLMap

3.4 Contenedores Docker CTF

Para el uso de los contenedores en este CTF ha sido necesaria la instalación de
Docker [18]. Al estar los paquetes Docker incluidos dentro de la distribución, este proceso
es sencillo. La instalación consta de dos comandos, el primero realiza la instalación:

Y el segundo activa en el sistema el demonio de Docker:

[17] sqlmap, 2022, sqlmap: automatic SQL injection and database takeover tool
URL: https://sqlmap.org/
[18] Docker, 2022, Docker: Accelerated, Containerized Application Development
URL: https://www.docker.com/
$ sqlmap -u http://10.10.10.10/myform.php?new=1 -a

$ sudo apt install -y docker.io docker-compose
$ sudo systemctl enable docker --now
https://sqlmap.org/
https://www.docker.com/
21

4. CTF

4.1 Escenario 1 – OoOps machine

Se procede a descargar el escenario 1, llamado “OoOps machine” como se indica en la
documentación:

Una vez descargado se procede a iniciar el contenedor con el comando de shell:

Y se comprueba que este se mantiene en ejecución antes de comenzar con la fase de
enumeración:

Figura 17. [ESC1] Inicio de Escenario 1 (output de Docker)

4.1.1 Enumeración Escenario 1

En este escenario, por el propio comando lanzado para la ejecución del contenedor, se
puede deducir que el contenedor expone sus puertos TCP 21, 22, 8080 y 10000,
por lo que se centra el escaneo en estos para agilizar el proceso. En caso contrario sería
recomendable escanear todos los puertos del host y posteriormente investigarlos.

En primer lugar, se lanza NMap sobre estos puertos con el parámetro (-sV) para
conseguir la máxima información posible sobre versiones:

Figura 18. [ESC1] Resultado de enumeración NMap
$ sudo docker build . -t tfm:machine1

$ sudo docker run --rm -it -e 10.10.10.110 -p 21:21 -p 22:22 -p
8080:80 -p 10000:10000 tfm:machine1

Tras analizar la información devuelta por NMap se confirma que los puertos TCP
21, 22 y 8080 están abiertos y en ellos corren servicios cuyas versiones ya se conocen.

Con esta información se redacta el siguiente resumen:
• TCP 21 → Servicio FTP → Aplicación vsFTPd en versión 3.0.3
• TCP 22 → Servicio SSH → Aplicación OpenSSH en versión 7.6p1
• TCP 8080 → Servicio HTTP → Aplicación Apache en versión 2.4.29
• TCP 10000 → Servicio snet-sensor-mgmt pero puerto cerrado

FTP (TCP21)

En primer lugar, se procede a investigar el servicio FTP tras el puerto TCP21 y se
comprueba si permite acceso anónimo con credenciales: anonymous / anonymous:

Figura 19. [ESC1] Análisis acceso FTP

Es posible conectarse con dichas credenciales y estas dan acceso, al parecer por
el fichero <index.php>, a la raíz de un sitio web. Se analizará en profundidad en la
siguiente fase.

SSH (TCP22)

En segundo lugar, se procede a investigar el servicio SSH tras el puerto TCP22 y se
comprueba que no permite login sin contraseña o con contraseñas triviales con
el usuario root. Se realizará un análisis ampliado en las siguientes fases.

Figura 20. [ESC1] Acceso SSH
23

HTTP (TCP8080)

Se utiliza WhatWeb y Nikto sobre el puerto TCP 8080 para obtener información
adicional:

Figura 21. [ESC1] Análisis web WhatWeb

Figura 22. [ESC1] Análisis web Nikto

Gracias a estas 2 utilizades se confirma la información de NMap: el servidor web que se
ejecuta es Apache en versión 2.4.29 sobre un sistema operativo Ubuntu, y se consigue
información adicional acerca de las cabeceras HTTP no presentes en la web y que no
protegen sobre ataques XSS, etc.

Se lanza un escaneo de DirBuster sobre http://10.10.10.110:8080/ según la
configuración expuesta en la sección 2 de esta memoria y aparecen estos ficheros que
aparentemente coinciden con los que aparecían en el FTP de acceso anónimo:

Figura 23. [ESC1] Ejecución de DirBuster
http://10.10.10.110:8080/
24

Se procede a acceder a la web índice para ver qué información presenta y no aparece
más que un texto sin posibilidad de interactuar con la web:

Figura 24. [ESC1] Acceso HTTP en TCP8080

De forma adición se realizar la prueba de descargar el otro fichero que aparecía en el
FTP: <index.html.bak>, este es el index.html por defecto de Apache2 renombrado.

Snet-Sensor-Mgmt (TCP10000)

El puerto TCP1000 aparece cerrado por lo que no es posible realizar un mayor
reconocimiento del servicio que se está ejecutando.

Si se realiza una búsqueda se pueden encontrar exploits como el publicado aquí:
https://github.com/Popsiclestick/write-ups/blob/master/NCL-2014/Exploit%202.md
Pero estos exploits no se pueden utilizar al estar el puerto TCP10000 aparentemente
cerrado.

Resumen con la información útil identificada en esta fase:Puerto TCP Servicio Versión Información Extra
21 FTP 3.0.3 Accede a www con anonymous
22 SSH 7.6p1 Requiere usuario y contraseña
8080 HTTP Apache 2.4.6 Directorio raíz accesible desde FTP
10000 SNET-SENSOR-MGMT ¿? Puerto cerrado

4.1.2 Análisis de vulnerabilidades Escenario 1

Se revisa la información y se decide que el primer punto a probar es si desde el
navegador web es posible cargar/ejecutar los ficheros php, cargados desde el FTP con
usuario anonymous. Para ello se genera un fichero llamado <test.php> que contiene
una invocación a PHPInfo y se carga mediante el acceso FTP anónimo en el directorio
/html por ser el visible desde acceso web a la máquina:

Figura 25. [ESC1] Contenido de test.php generado para prueba PHPInfo
https://github.com/Popsiclestick/write-ups/blob/master/NCL-2014/Exploit%202.md
25

Figura 26. [ESC1] Carga de test.php por FTP

Se puede ver que los ficheros cargan con permisos de solo lectura por lo que una
vez subidos no se pueden sobrescribir o borrar. Tras cargar el fichero por FTP al
directorio /html del servidor, este pasa a ser accesible mediante una petición web:

Figura 27. [ESC1] Carga de fichero PHPInfo

Se procede a dar un paso más y se incluye en el fichero PHP comandos shell que
se ejecutarán en el servidor destino por el usuario de Apache2/PHP:

$ chat test02.php
<?php
$output = shell_exec('ls /home/ -lart');
echo "<pre>$output</pre>";
?>

En este caso se quiere ver la estructura de la carpeta /home/ para conocer nombres de
usuario y otros datos:

Figura 28. [ESC1] Carga de PHP para mostrar /home

Se comprueba que aparentemente hay un usuario llamado hacker en el sistema, se
procede a repetir el último paso, pero variando la ruta por la del nuevo usuario:

Figura 29. [ESC1] Carga de PHP para mostrar /home/hacker

Se descubre que la flag está disponible en esta carpeta. Se procede a su lectura
mediante el comando “cat” (script test4.php en Anexos) y se consigue la primera
flag del CTF:

Se lanza un “whoami” mediante PHP (script test5.php en Anexos) para confirmar el
usuario que está interpretando los procesos PHP en el servidor y éste es el servicio
estándar para procesos HTML Apache2: www-data.

Se lanza un comando “ps -aux” para conocer los procesos de la máquina que se están
ejecutando con el usuario “www-data” y con el resto de los usuarios:

Figura 30. [ESC1] Comando PS -AUX
Escenario 1 - OoOps_machine:
• Flag de usuario: 244cdf401e667cca77b8228066096985

Se descubre un proceso lanzado como usuario root que ejecuta un script llamado
myhacker.sh con un parámetro sospechoso que es “tefeme_86_pass”.

Como se ha visto (a partir de su ruta en /home/hacker) que existe un usuario llamado
hacker, se procede a intentar un login ssh con estos parámetros:

• Usuario: hacker
• Contraseña: tefeme_86_pass

Y este resulta exitoso, por lo que se cuenta con acceso SSH al contenedor:

Figura 31. [ESC1] Acceso SSH con usuario hacker

4.1.3 Explotación de vulnerabilidades Escenario 1

Para conseguir la escalada de privilegios se investigan más comandos shell que
ejecutar en el servidor en búsqueda de algún punto adicional de entrada:
• Se revisa la configuración y el contenido de los ficheros passwd y shadow:
los únicos usuarios con shell Bash asignada son “hacker” y “root”. El fichero
/etc/shadow se encuentra correctamente protegido.
• El usuario hacker está definido en sudoer sin permisos de ejecución en todos los
comandos, no puede invocar ningún comando como root.
• Se buscan ficheros con permisos especiales SUID y SGID, no se encuentran
ficheros con permisos especiales fuera del estándar para el correcto
funcionamiento de Linux.
• Se revisan las tareas programadas para localizar alguna que se ejecute con
algos privilegios y que lea o escriba un diccionario mal configuradas.
• Se revisan las versiones de las aplicaciones de sistema críticas como su, sudo,
crontab, openssh, sshd, etc. En este punto se localiza una vulnerabilidad en la
versión instalada de sudo que es la que se va a explotar.

La versión de sudo que está instalada en el contenedor es la 1.8.26:

Figura 32. [ESC1] Versión SUDO instalada

Se buscan vulnerabilidades de esta versión de SUDO y existen 7 listadas:
https://www.cybersecurity-help.cz/vdb/sudo/sudo/1.8.26/

Entre las cuales existe una vulnerabilidad de escalada de privilegios (Security
Bypass) que no depende de la presencia de otros componentes:
https://www.cybersecurity-help.cz/vdb/SB2019101501
https://www.exploit-db.com/exploits/47502
https://vuldb.com/es/?id.143468

Su explotación es sencilla y necesita ejecutar el siguiente comando desde shell:

Tras esto se piden credenciales de hacker y se ejecuta el comando como root aunque
hacker no estuviera en el grupo de sudoers. Así se puede conseguir una shell como
root y buscar la segunda flag de este escenario:

Figura 33. [ESC1] Explotación de vulnerabilidad en SUDO

$ sudo -u#-1 <comando a ejecutar como root>

Escenario 1 - OoOps_machine:
• Flag de root: 648d390c021ce7cfde2f95ea3fcd71ec

https://www.cybersecurity-help.cz/vdb/sudo/sudo/1.8.26/
https://www.cybersecurity-help.cz/vdb/SB2019101501
https://www.exploit-db.com/exploits/47502
https://vuldb.com/es/?id.143468
29

4.1.4 Post-Explotación Escenario 1

Como tareas de post-explotación para conseguir persistencia en el acceso al host
sin la instalación de software adicional se podrían plantear distintas opciones:

• Crear una contraseña para root y habilitar el acceso remoto por sshd como root
comentando la línea “PermitRootLogin no” en el fichero “/etc/ssh/sshd_config”
• Crear un nuevo usuario con acceso remoto y que tenga mayores permisos en
sudoer
• Habilitar la autenticación mediante clave privada en ambas opciones para
continuar accediendo tras cambios de contraseña.

4.1.5 Reporte y mitigaciones Escenario 1

VULNERABILIDAD 1:

CVE: CVE-1999-0497
SERVICIO: FTP, TCP21
INFORMACIÓN: El acceso anónimo está habilitado en el servidor FTP que se ejecuta
en el contenedor. Esto permite la carga de ficheros sin autenticación.
MITIGACIÓN: No habilitar el acceso anónimo en el servidor FTP. Si es necesario este
tipo de acceso, que la carga de ficheros no se realice sobre un directorio accesible desde
web (HTTP) y de forma adicional aplicar una máscara para evitar que PHP los interprete
como ejecutables. Estos cambios se deben realizar en el fichero "/etc/vsftpd.conf" y
corresponden a las líneas "anonymous_enable=YES" y "anon_root=/var/www"
INFORMACIÓN ADICIONAL:
https://www.cve.org/CVERecord?id=CVE-1999-0497
https://www.cvedetails.com/cve/CVE-1999-0497/
https://vuldb.com/es/?id.14330

VULNERABILIDAD 2:

CVE: CVE-2019-14287
SERVICIO: SSH, TCP22
USUARIO AFECTADO: hacker
INFORMACIÓN: La versión de “sudo” es 1.8.26 y permite, en algunas configuraciones
determinadas de sudoers, ejecutar comandos como "root" sin que el usuario tenga
permisos. Se realiza desde la consola SSH del usuario afectado mediante el comando:

MITIGACIÓN: Actualizar el sistema para que la versión de sudo en el sistema sea mayor
a la 1.8.26 y tenga esta vulnerabilidad corregida.

$ sudo -u#-1 <comando a ejecutar como root>

https://www.cve.org/CVERecord?id=CVE-1999-0497
https://www.cvedetails.com/cve/CVE-1999-0497/
https://vuldb.com/es/?id.14330
30

INFORMACIÓN ADICIONAL:
https://www.cvedetails.com/cve/CVE-2019-14287/
https://www.exploit-db.com/exploits/47502

4.1.6 Resumen de Flags Escenario 1

Escenario 1 - OoOps_machine:
• Flag de usuario: 244cdf401e667cca77b8228066096985
• Flag de root: 648d390c021ce7cfde2f95ea3fcd71ec

https://www.cvedetails.com/cve/CVE-2019-14287/
https://www.exploit-db.com/exploits/47502
31

4.2 Escenario 2 - Odyssey_v2Se procede a descargar el escenario 2, llamado “Odyssey_v2” como se indica en la
documentación:

Una vez descargado se procede a iniciar el contenedor con el comando de shell:

Y se comprueba que este se mantiene en ejecución antes de comenzar con la fase de
enumeración:

Figura 34. [ESC2] Inicio de Escenario 2 (output de Docker)

4.2.1 Enumeración Escenario 2

En este escenario, como también sucede con el escenario número 1, el propio comando
lanzado para su ejecución desvela los puertos expuestos: TCP 2222 y TCP 8080. Es
por esto por lo que se focaliza el esfuerzo escaneando únicamente estos puertos.

Por tanto, se ejecuta NMap sobre dichos puertos con el parámetro (-sV) para indicar
que se necesita la máxima información sobre las versiones de los servicios que se
ejecutan tras cada puerto:

Figura 35. [ESC2] Resultado de enumeración NMap
$ sudo docker build . -t tfm:machine2

$ sudo docker run --rm -it -p 2222:22 -p 8080:80 tfm:machine2

Con esta información se redacta el siguiente resumen:
• TCP 2222 → Servicio SSH → Aplicación OpenSSH en versión 7.6p1
• TCP 8080 → Servicio HTTP → Aplicación NGINX en versión 1.14.0

SSH (TCP 2222)

En primer lugar, se procede a investigar el servicio SSH tras el puerto TCP2222 y se
comprueba que no permite login sin contraseña o con contraseñas triviales con el
usuario root. Por la respuesta del servidor se deduce que permite autenticación
mediante contraseña o clave pública/privada:

Figura 36. [ESC2] Acceso SSH

Se utilizará este servicio en las siguientes fases de este escenario.

HTTP (TCP 8080)

Debido a la escasa información obtenida en el escenario 1 con las utilidades de análisis
Web, se realiza directamente un escaneo con DirBuster, con la configuración
presentada en la sección 2 de esta memoria, para localizar ficheros y directorios
accesibles mediante WWW en el servidor http://10.10.10.110:8080

Figura 37. [ESC2] Resultados de DirBuster
http://10.10.10.110:8080/
33

Se recopila y ordena toda la información conseguida con DirBuster. A continuación, se
presenta un resumen de lo encontrado, lo cual se desarrollará más adelante en esta
sección:

- En la raíz del website no existe ningún fichero <index.php> o <index.html>.
- En la raíz del website existe un fichero <phpinfo.php> que se puede utilizar
para conocer la versión de PHP y de las extensiones que tiene activadas.
- Existe un directorio <admin> dentro del cual existe un fichero llamado
<admin.php>.
- Existe un directorio llamado <images> que contienen imágenes en formato
jpg numeradas correlativamente desde 0 a 15.
- Existe un directorio llamado <notes> que contiene un fichero en texto plano
llamado <note.txt>.
- Existen 16 carpetas numeradas correlativamente desde 0 a 15 y en cada una
de ellas existe un fichero de texto llamado <junk.txt>.

Figura 38. [ESC2] Representación gráfica de recursos encontrados

Se procede a analizar (ficheros php interpretados en servidor) o descargar (resto de
ficheros) los ficheros encontrados. Las descargas se realizan mediante un <wget>
desde la shell de comandos, por ejemplo:

Tras analizar los contenidos se detalla cada uno de los ficheros encontrados:

/phpinfo.php
Resumen sobre la instalación de PHP donde se indica, entre otros, que la versión que
se está ejecutando de PHP es la 7.1.33dev, que tiene el modo FPM activado y que se
está ejecutando sobre un servidor nginx.
$ wget http://10.10.10.110/0/junk.txt > ./myjunk0.txt
34

Esto puede ser útil más adelante para la búsqueda de vulnerabilidades junto con el resto
de los datos que se muestran en <phpinfo.php>:

Figura 39. [ESC2] PHPInfo del servidor web (TCP8080)

/admin/admin.php
Esta página parece no devolver ningún resultado. Se estudiará posteriormente en la
fase de análisis de vulnerabilidades.

/images/0...15.jpg
Se procede a descargar las imágenes. Se analizarán posteriormente por si contienen
alguna información adicional como metadatos o datos ocultos por esteganografía.

Figura 40. [ESC2] Ejemplo de una de las imágenes (0.jpg)

/notes/note.txt
Este fichero contiene únicamente el siguiente texto: “1 3 11”

/0..15/junk.txt
Se descarga el conjunto de ficheros de texto plano <junk.txt>, uno dentro de cada
directorio numerado del 0 al 15. Su contenido es el siguiente:
0. bm8gc295IGNsYXZl
1. MTIzNF9zZWM=
2. bm8gc295IGNsYXZl
3. aG9vcmEh
4. bm8gc295IGNsYXZl
35

5. bm8gc295IGNsYXZl
6. bm8gc295IGNsYXZl
7. bm8gc295IGNsYXZl
8. bm8gc295IGNsYXZl
9. bm8gc295IGNsYXZl
10. bm8gc295IGNsYXZl
11. 00000000: 6361 6c69 666f 726e 6961
12. bm8gc295IGNsYXZl
13. bm8gc295IGNsYXZl
14. bm8gc295IGNsYXZl
15. bm8gc295IGNsYXZl

Analizando el formato de los valores se puede confirmar que el contenido del texto del
directorio 11 está en hexadecimal y el resto podrían estar codificados en base64.

Se procede a descifrarlos mediante las herramientas incluidas en KALI Linux para
probar si es cierto y conocer su contenido:

Figura 41. [ESC2] Descifrar fichero base64 en KALI

Figura 42. [ESC2] Descifrar fichero base64 en KALI

0. bm8gc295IGNsYXZl → base64 decode → no soy clave
1. MTIzNF9zZWM= → base64 decode → 1234_sec
2. bm8gc295IGNsYXZl → base64 decode → no soy clave
3. aG9vcmEh → base64 decode → hoora!
4. bm8gc295IGNsYXZl → base64 decode → no soy clave
5. bm8gc295IGNsYXZl → base64 decode → no soy clave
6. bm8gc295IGNsYXZl → base64 decode → no soy clave
7. bm8gc295IGNsYXZl → base64 decode → no soy clave
8. bm8gc295IGNsYXZl → base64 decode → no soy clave
9. bm8gc295IGNsYXZl → base64 decode → > no soy clave
10. bm8gc295IGNsYXZl → base64 decode → no soy clave
11. 00000000: 6361 6c69 666f 726e 6961 → hex decode → california
12. bm8gc295IGNsYXZl → base64 decode → no soy clave
13. bm8gc295IGNsYXZl → base64 decode → no soy clave
14. bm8gc295IGNsYXZl → base64 decode → no soy clave
15. bm8gc295IGNsYXZl → base64 decode → no soy clave

Se observa que precisamente los valores correspondientes a los directorios indicados
en la nota (/notes/note.txt): 1, 3 y 11, son los únicos distintos a “no soy clave”.

4.2.2 Análisis de vulnerabilidades Escenario 2

Se buscan en Google vulnerabilidades para entornos PHP versión 7.1.33dev sobre
nginx y se localiza una vulnerabilidad (CVE-2019-11043) explotable cuando el
modo FPM está activado en PHP, requisito que se cumple en el escenario 2.

Dicha vulnerabilidad está comentada, entre otros, en el siguiente artículo:
https://www.hackplayers.com/2019/10/descubren-en-un-ctf-un-rce-en-nginx-php-
fpm.html

Y está implementada en lenguaje GO en el siguiente repositorio de Github:
https://github.com/neex/phuip-fpizdam

Para comprobar que el escenario 2 es vulnerable se realiza una prueba clonando y
compilando, desde el repositorio comentado con anterioridad, a la máquina KALI. Se
utiliza la siguiente instrucción, ya que la descrita en el repositorio Github no es operativa
con la versión actual de GO:

Tras esto se accede a la carpeta de binarios y se lanza el ejecutable tomando como
objetivo el fichero PHP encontrado en el reconocimiento inicial:

Figura 43. [ESC2] Confirmación de la vulnerabilidad analizada (1)

Como se indica, si se lanza ahora un comando a través de la ruta de navegación
mediante la sintaxis mostrada se ejecutará en el sistema destino con el usuario
encargado de ejecutar PHP:

Figura 44. [ESC2] Confirmación de la vulnerabilidad analizada (2)
$ go install github.com/neex/phuip-fpizdam@latest
$ cd ./go/bin
$ ./phuip-fpizdam http://10.10.10.110:8080/admin/admin.php

https://www.hackplayers.com/2019/10/descubren-en-un-ctf-un-rce-en-nginx-php-fpm.html
https://www.hackplayers.com/2019/10/descubren-en-un-ctf-un-rce-en-nginx-php-fpm.html