Mejora en la UI/UX en la realización de ataques con Huntdown
Abstract
Hoy en día, los ataques cibernéticos están a la orden del día. Las empresas están cada vez más concienciadas de la importancia de proteger sus datos y los de sus clientes, invirtiendo recursos significativos en seguridad. Para lograrlo, es fundamental contar con un conocimiento sólido sobre las herramientas utilizadas y analizar sus posibles vulnerabilidades para prevenir ataques. En este contexto, la figura del penetration tester desempeña un papel crucial al evaluar la seguridad de una empresa y verificar si cumple con los estándares de seguridad establecidos. Este Trabajo de Fin de Grado, titulado Mejora en la UI/UX en la realización de PenTests con HuntDown, se centra en mejorar la herramienta HuntDown, con el objetivo de proporcionar a los usuarios una experiencia más intuitiva, ergonómica y eficaz. Este proyecto busca optimizar ciertas características de la aplicación, facilitando su uso y mejorando la eficiencia en la realización de pruebas de penetración.
Full text
id191600 MEJORA EN LA UI/UX EN LA REALIZACIÓN DE ATAQUES CON HUNTDOWN BRUNO RUANO PRIETO Director/a RENÉSERRALGRACIÀ(DepartamentodeArquitecturadeComputadores) Titulación GradoenIngenieríaInformática(Tecnologíasdelainformación) Memoria del trabajo de fin de grado Facultat d'Informàtica de Barcelona (FIB) Universitat Politècnica de Catalunya (UPC) - BarcelonaTech 20/01/2025
Resum Avui dia, els atacs cibernètics estan a l’ordre del dia. Les empreses estan cada cop més conscienciades de la importància de protegir les seves dades i les dels seus clients, invertint recursos significatius en seguretat. Per aconseguir-ho, és fonamental tenir un coneixement sòlid sobre les eines utilitzades i analitzar-ne les possibles vulnerabilitats per prevenir atacs. En aquest context, la figura del penetration tester juga un paper crucial a l’hora d’avaluar la seguretat d’una empresa i verificar si compleix els estàndards de seguretat establerts. Aquest Treball de Fi de Grau, titulat Mejora en la UI/UX en la realización de PenTests con HuntDown, se centra a millorar l’eina HuntDown, amb l’objectiu de proporcionar als usuaris una experiència més intuïtiva, ergonòmica i eficaç. Aquest projecte busca optimitzar certes característiques de l’aplicació, facilitant-ne l’ús i millorant l’eficiència en la realització de proves de penetració. 2
Resumen Hoy en día, los ataques cibernéticos están a la orden del día. Las empresas están cada vez más concienciadas de la importancia de proteger sus datos y los de sus clientes, invirtiendo recursos significativos en seguridad. Para lograrlo, es fundamental contar con un conocimiento sólido sobre las herramientas utilizadas y analizar sus posibles vulnerabilidades para prevenir ataques. En este contexto, la figura del penetration tester desempeña un papel crucial al evaluar la seguridad de una empresa y verificar si cumple con los estándares de seguridad establecidos. Este Trabajo de Fin de Grado, titulado Mejora en la UI/UX en la realización de PenTests con HuntDown, se centra en mejorar la herramienta HuntDown, con el objetivo de proporcionar a los usuarios una experiencia más intuitiva, ergonómica y eficaz. Este proyecto busca optimizar ciertas características de la aplicación, facilitando su uso y mejorando la eficiencia en la realización de pruebas de penetración. 3
Abstract Nowadays, cyberattacks are commonplace. Companies are increasingly aware of the importance of protecting their data and their clients' data, investing significant resources in security. To achieve this, it is essential to have solid knowledge of the tools being used and to analyze their potential vulnerabilities to prevent attacks. In this context, the role of the penetration tester is crucial in evaluating a company's security and verifying whether it meets established security standards. This Final Degree Project, titled Mejora en la UI/UX en la realización de PenTests con HuntDown, focuses on enhancing the HuntDown tool with the goal of providing users with a more intuitive, ergonomic, and efficient experience. This project aims to optimize specific features of the application, facilitating its use and improving efficiency in conducting penetration tests. 4
Tabla de Contenidos 1. Introducción y contextualización..................................................................................... 9 1.1 Terminología...............................................................................................................10 1.2. Definición del problema.............................................................................................11 1.3. Stakeholders............................................................................................................. 12 2. Justificación..................................................................................................................... 12 3. Alcance del proyecto.......................................................................................................13 3.1. Objetivos................................................................................................................... 13 3.2. Obstáculos y riesgos.................................................................................................13 4. Metodología......................................................................................................................14 5. Descripción de tareas......................................................................................................15 5.1. Tareas de gestión del proyecto................................................................................. 15 5.2. Tareas de desarrollo del proyecto............................................................................. 15 5.3. Tareas de documentación de la memoria................................................................. 16 5.4. Tareas de seguimiento.............................................................................................. 17 5.5. Recursos................................................................................................................... 17 5.6. Recursos Humanos...................................................................................................17 5.7. Resumen de la planificación..................................................................................... 18 6. Diagrama de Gantt y estimación del tiempo................................................................. 19 7. Gestión de riesgos...........................................................................................................20 7.1. Calendario cerrado....................................................................................................20 7.2. Inexperiencia.............................................................................................................20 7.3. Errores.......................................................................................................................20 7.4. Posibles Modificaciones............................................................................................21 8. Presupuesto..................................................................................................................... 22 8.1. Identificación de los costes....................................................................................... 22 8.2. Costes del personal por actividad (CPA)...................................................................22 8.3. Coste de las tareas................................................................................................... 22 8.4. Costes genéricos.......................................................................................................24 8.4.1. Recursos hardware.......................................................................................... 24 8.4.2. Recursos software............................................................................................24 8.4.3. Otros costes..................................................................................................... 24 8.5. Estimación de los costes...........................................................................................25 8.6. Presupuesto final.......................................................................................................26 8.7. Control de gestión..................................................................................................... 26 9. Introducción a Huntdown................................................................................................27 9.1. Diagrama de la arquitectura......................................................................................27 9.2. Servicio de mensajería..............................................................................................28 9.3. Gestor de la base de datos....................................................................................... 28 9.4. Gestor de ataques.....................................................................................................28 9.5. Gestor de instancias virtuales................................................................................... 29 5
9.6. Interfaz de Usuario....................................................................................................29 10. Mejora de la Interfaz en las opciones de ataque.........................................................29 10.1. Mejora gráfica..........................................................................................................29 10.2. Componentes..........................................................................................................31 10.2.1. Text.................................................................................................................33 10.2.2. Select............................................................................................................. 34 10.2.3. Switch.............................................................................................................36 10.2.4. Switch text......................................................................................................37 10.2.5. Secret.............................................................................................................38 10.3. Selección de modo..................................................................................................39 10.4. Gestión de conflictos...............................................................................................42 11. Gestión de “Secret Keys”..............................................................................................48 11.1. Configuración de Parámetros..................................................................................49 11.2. Uso de Secret Keys.................................................................................................50 11.2.1. Listar...............................................................................................................50 11.2.2. Añadir............................................................................................................. 55 11.2.3. Eliminar...........................................................................................................59 12. Integración de ficheros externos en los ataques........................................................62 12.1. Directorio Original....................................................................................................64 12.2. Ruta local del sistema............................................................................................. 65 12.3. Descarga del archivo...............................................................................................68 13. Nuevo ataque wfuzz.......................................................................................................70 13.1. Archivos de configuración....................................................................................... 71 13.1.1. wfuzz-attack.json............................................................................................71 13.1.2. wfuzz-dashboard.json.................................................................................... 72 13.1.3. wfuzz-options.json..........................................................................................73 13.2. Caso de uso............................................................................................................ 75 15. Aspectos Legales...........................................................................................................76 16. Sostenibilidad.................................................................................................................78 16.1. Autoevaluación........................................................................................................78 16.2. Aspecto ambiental...................................................................................................79 16.3. Aspecto económico.................................................................................................79 16.4. Aspecto social......................................................................................................... 80 17. Conclusiones..................................................................................................................81 17.1. Posibles mejoras.....................................................................................................81 17.1.1. Incorporación de Nuevos Componentes con React.......................................81 17.1.2. Ampliación de las Configuraciones de Usuario..............................................82 17.1.3. Integración de Subida de Archivos en Vagrant.............................................. 82 18. Referencias.....................................................................................................................83 6
Índice de figuras [Figura 1] Riesgo de sufrir un ataque cibernético................................................................ .4 [Figura 2] Ataques informáticos en España y Portugal.........................................................5 [Figura 3] Metodología Agile.................................................................................................9 [Figura 4] Diagrama de Gantt - Planificación de las tareas................................................. 14 [Figura 5] Diagrama de la arquitectura de Huntdown.......................................................... 27 [Figura 6] Fichero OptionsFile, plantilla de las opciones de los ataque…………………….30 [Figura 7] Vista anterior de la configuración de ataques......................................................31 [Figura 8] Vista actual de la configuración de ataques ....................................................... 31 [Figura 9] Fichero OptionsGroupView.js...............................................................................32 [Figura 10] Función FormOption..........................................................................................33 [Figura 11] Código del formato text......................................................................................33 [Figura 12] Visualización del input text en las opciones de ataque..................................... 34 [Figura 13] Código del formato select..................................................................................35 [Figura 14] Visualización del input select en las opciones de ataque..................................35 [Figura 15] Código del formato switch..................................................................................36 [Figura 16] Visualización del input switch en las opciones de ataque..................................36 [Figura 17] Código del formato switch-text...........................................................................37 [Figura 18] Visualización del input switch-text en las opciones de ataque.......................... 38 [Figura 19] Código del formato secret..................................................................................38 [Figura 20] Visualización del input secret en las opciones de ataque..................................39 [Figura 21] Variable Modes..................................................................................................40 [Figura 22] Fragmento de código de verificación de los modos.......................................... 40 [Figura 23] Variable handleSelectedMode...........................................................................41 [Figura 24] Fragmento de código del componente Accordion............................................. 41 [Figura 25] Visualización de grupos con el modo dir seleccionado..................................... 42 [Figura 26] Visualización de grupos con el modo dns seleccionado................................... 42 [Figura 27] Función handleConflict...................................................................................... 43 [Figura 28] Función handleSubmit y gestión de las alertas................................................. 45 [Figura 29] JSON de las opciones de abusedIP.................................................................. 46 [Figura 30] Visualización de alertas de requerimientos....................................................... 47 [Figura 31] JSON de las opciones de gobuster................................................................... 47 [Figura 32] Visualización de alertas de conflictos............................................................... 48 [Figura 33] Diagrama del mecanismo de las API keys........................................................ 49 [Figura 34] Visualización del apartado Settings.................................................................. 50 [Figura 35] Función listKeys................................................................................................ 51 [Figura 36] Función listSecrets en Router.js.........................................................................52 [Figura 37] Endpoint listScrets en secrets.go.......................................................................53 [Figura 38] Código de la estrutura de la lista de keys......................................................... 54 [Figura 39] Visualización de la lista de keys.........................................................................54 [Figura 40] Formulario para añadir una key..........................................................................55 [Figura 41] Código del formulario..........................................................................................56 [Figura 42] Función handleSubmit para añadir una key........................................................57 [Figura 43] Endpoint addSecret en secrets.go......................................................................59 [Figura 44] Visualización de la adición de la nueva key........................................................59 [Figura 45] Función handleDeleteSecret...............................................................................60 7
[Figura 46] Endpoint deleteSecret........................................................................................61 [Figura 47] Pop-up antes de eliminar la key.........................................................................62 [Figura 48] Visualización de la key eliminada......................................................................62 [Figura 49] Fragmento del código que gestiona el archivo................................................. 63 [Figura 50] Visualización de los archivos en /etc/huntdown/wordlists................................. 64 [Figura 51] Parámetros rellenados con el archivo dir.txt..................................................... 64 [Figura 52] Resultados de la ejecución 1............................................................................ 65 [Figura 53] Función processFilePath................................................................................... 66 [Figura 54] Parámetros rellenados con la ruta del archivo.................................................. 67 [Figura 55] Directorio /etc/huntdown/wordlists/ con el nuevo archivo..................................67 [Figura 56] Resultado de la ejecución 2...............................................................................67 [Figura 57] Parámetros rellenados con una URL............................................................... 68 [Figura 58] Función downloadFile........................................................................................69 [Figura 59] Directorio /etc/huntdown/wordlists/ con el nuevo archivo..................................70 [Figura 60] Resultado de la ejecución 3...............................................................................70 [Figura 61] Archivo wfuzz-attack.json.................................................................................. 72 [Figura 62] Archivo wfuzz-dashboard.json...........................................................................73 [Figura 63] Archivo wfuzz-options.json................................................................................ 74 [Figura 64] Parámetros de las opciones de ataque wfuzz...................................................75 [Figura 65] Resultado de la ejecucción de wfuzz.................................................................75 Índice de tablas [Tabla 1] Resumen de las tareas........................................................................................ 13 [Tabla 2] Riesgo del proyecto...............................................................................................15 [Tabla 3] Tabla de los roles con sus sueldos........................................................................17 [Tabla 4] Costes de las tareas..............................................................................................18 [Tabla 5] Coste en los recursos hardware............................................................................19 [Tabla 6] Coste en los recursos software.............................................................................19 [Tabla 7] Tabla de coste de otros recursos...........................................................................20 [Tabla 8] Tabla de estimación de costes...............................................................................20 [Tabla 9] Tabla de costes de imprevistos..............................................................................20 [Tabla 10] Tabla de presupuesto final...................................................................................21 [Tabla 11] Tabla de desviaciones que pueden surgir en el proyecto....................................21 8
1. Introducción y contextualización En los últimos años, es indudable que la tecnología ha llegado a todos los rincones del mundo. Hoy en día, casi todo el mundo tiene cerca un dispositivo conectado a la red, lo que significa que está conectado al resto del planeta. Gracias a la globalización y a la constante actualización de las diversas tecnologías, tanto personas particulares como empresas están expuestas a posibles vulnerabilidades tecnológicas. A su vez, enfrentan la amenaza constante de cibercriminales dispuestos a utilizar herramientas para acceder a información privilegiada, lo que puede ocasionar todo tipo de daños, ya sean sociales, económicos o incluso personales. Figura 1: Riesgo de sufrir un ataque cibernético. Fuente: IMF Actualizar las tecnologías es fundamental para evitar vulnerabilidades, ya que el software y el hardware se vuelven obsoletos con el tiempo, dejando puertas abiertas a posibles ataques cibernéticos. Los desarrolladores lanzan actualizaciones periódicas para corregir fallos de seguridad, reparar errores y mejorar la protección contra nuevas amenazas. Cuando no se implementan estas actualizaciones, los sistemas permanecen expuestos a vulnerabilidades conocidas que los ciberdelincuentes pueden explotar fácilmente. Estos desarrolladores actualizan estas tecnologías gracias a personas que, de manera legal y con autorización, pueden vulnerar y acceder dentro de las estructuras informáticas por cullpa de las fallas de seguridad a la hora de desarrollar dichas tecnologías. Es un trabajo de equipo, donde se retroalimentan entre ellos para mejorar el servicio. 9
● DP3 - Familiarización del proyecto y su código (20h) Estudio del proyecto existente y su código fuente, entendiendo la estructura, funcionalidad y cómo los diferentes módulos interactúan entre sí. ● DP4 - Diseñar la interfaz de las opciones de ataque (10h) Diseño visual y funcional de las opciones de ataque para la interfaz del proyecto. Al haber distintos tipos de ataques, se requiere un análisis detallado de cada uno para desarrollar un diseño intuitivo que facilite su uso. El objetivo es ofrecer una experiencia clara y eficiente, adaptada a las características de cada ataque. ● DP5 - Implementar el diseño de las opciones de ataque (40h) Desarrollo e integración del diseño de las opciones de ataque en el proyecto, asegurando que el diseño sea funcional y responda a las necesidades planteadas. ● DP6 - Diseñar la visualización de las estadísticas (10h) Diseño de cómo se mostrarán las estadísticas de los ataques en el proyecto, asegurando una presentación clara y útil para el usuario. ● DP7 - Implementar el diseño de visualización de las estadísticas (40h) Codificación y desarrollo de la visualización de las estadísticas dentro del proyecto, integrándose de manera efectiva con el resto de las funcionalidades. Ver las estadísticas de los diferentes ataques, por ejemplo los ataques realizados, completados, ataques erróneos y características específicas de cada uno. ● DP8 - Diseñar la visualización de los resultados de los ataques. (10h) Creación del diseño que mostrará los resultados de los ataques, enfocándose en la claridad y usabilidad de la información presentada al usuario. Igual que en las opciones de los ataques, cada ataque proporciona información diferente, con lo cual la información resultante es específica para cada ataque. ● DP9 - Implementar visualización de los resultados (40h) Desarrollo del diseño visual de los resultados de los ataques, integrándose en el código del proyecto y asegurando su correcta funcionalidad. ● DP10 - Pruebas, ejecución y resolver errores (30h) Realización de pruebas para verificar el correcto funcionamiento de las opciones de ataque, identificación y corrección de posibles errores o inconsistencias. 5.3. Tareas de documentación de la memoria ● DM1 - Documentación de la Memoria Final (90h) Una parte importante del proyecto se enfoca en documentar todo lo que se ha hecho durante su desarrollo. Esta tarea se lleva a cabo de forma continua a lo largo de todo el proyecto. 16
● DM2 - Preparación de la defensa del TFG (15h) Se lleva a cabo una presentación en la que se expone y se defiende el trabajo realizado durante el desarrollo del proyecto. Esta tarea incluye tanto la elaboración de la presentación como la realización de pruebas para demostrar el funcionamiento de lo desarrollado. 5.4. Tareas de seguimiento ● S1 - Reuniones de seguimiento (15h) Esta tarea abarca todas las reuniones mantenidas con el director del proyecto para supervisar y evaluar el avance del desarrollo del mismo. 5.5. Recursos ● [TU] Tutor del proyecto. ● [WSL] WSL es una característica del sistema operativo Windows que permite ejecutar un sistema de archivos Linux, junto con herramientas de línea de comandos y aplicaciones de GUI de Linux, directamente en Windows, junto con el escritorio y las aplicaciones tradicionales de Windows. ● [VS] Visual Studio Code: IDE para desarrollar el proyecto. ● [GS] Google Suite: Herramientas de Google (Gmail, Docs, Sheets, Drive, etc.) ● [DI] Draw.io: Aplicación para hacer esbozos y dibujos. 5.6. Recursos Humanos Los roles que intervendrán en el proyecto serían lo siguientes: ●Jefe de proyecto: El jefe de proyecto es responsable de coordinar todos los aspectos del desarrollo de HuntDown. Su función incluye la planificación, definición de los objetivos y alcances del proyecto, y la supervisión de todo el equipo. ●Desarrollador Frontend: Será el responsable de mejorar la usabilidad y diseño visual de la aplicación, utilizando tecnologías como React (o cualquier otro framework elegido) para crear una experiencia más intuitiva y atractiva. En particular, deberá trabajar en la visualización de los resultados de los ataques, asegurándose de que los datos se presenten de forma clara y personalizable. ●Desarrollador Backend: Usará tecnologías como Go (o cualquier otra adecuada) para manejar la lógica detrás de los ataques y cómo se almacenan y procesan los datos. Será responsable de garantizar que la aplicación ejecute los ataques de manera eficiente, y de implementar las nuevas funcionalidades que permitan realizar ataques en cadena. ●Ingeniero de Sistemas: Será responsable de la configuración, administración y seguridad de los servidores y la infraestructura donde correrá HuntDown. ●Software Tester: El software tester es quien se encargará de asegurar la calidad de HuntDown. Será responsable de probar tanto el frontend como el backend para identificar errores, problemas de rendimiento, o posibles vulnerabilidades. 17
5.7. Resumen de la planificación A continuación, las tareas que se van a realizar con su duración, dependencias y recursos necesarios: Tabla 1: Resumen de las tareas 18 Código Tarea Duración Dependencia Recurso Tareas de Gestión del Proyecto GP1 Alcance y objetivos del proyecto 30 - [TU,GS] GP2 Planificación del proyecto 20 GP1 [GS] GP3 Gestión económica y sostenibilidad 20 GP2 [GS] GP4 Documento final 15 GP1,GP2,GP3 [GS] Tareas de desarrollo del proyecto DP1 Formación sobre Go 10 - - DP2 Formación sobre React 10 - - DP3 Familiarización del proyecto y su código 20 - [TU,WSL,VS] DP4 Diseñar la interfaz de las opciones de ataque 10 DP3 [TU,DI] DP5 Implementar el diseño de las opciones de ataque 40 DP4 [WSL,VS] DP6 Diseñar la visualización de las estadísticas 10 DP3 [TU,DI] DP7 Implementar el diseño de visualización de las estadísticas 40 DP6 [WSL,VS] DP8 Diseñar la visualización de los resultados de los ataques 10 DP3 [TU,DI] DP9 Implementar visualización de los resultados 40 DP8 [WSL,VS] DP10 Pruebas, ejecución y resolver errores 30 DP5,DP7,DP9 [WSL,VS] Tareas de documentación de la memoria DM1 Documentación de la Memoria Final 90 - [GS] DM2 Preparación de la defensa del TFG 15 DM1 [GS] Tareas de Seguimiento S1 Reuniones de seguimiento 15 - [TU] TOTAL DE HORAS 425
6. Diagrama de Gantt y estimación del tiempo A continuación de mostrar la planificación del proyecto en un Diagrama de Gantt[4]: 19 Figura 4: Diagrama de Gantt - Planificación de las tareas
7. Gestión de riesgos En este proyecto puede haber ciertas dificultades y riesgos a la hora de ir alcanzando los objetivos marcados.Según el horario, el proyecto consta de 425 horas, pero esto se puede desviar a causa de los riesgos que pueden ocurrir durante estos meses. Algunos de ellos son los siguientes: Riesgo Probabilidad Impacto en horas Calendario cerrado Baja 15 Inexperiencia Media 20-25 Errores Media/Alta 25-35 Posibles Modificaciones Baja 10 Tabla 2: Riesgo del proyecto 7.1. Calendario cerrado Este riesgo se refiere a la rigidez en el cronograma del proyecto, lo que puede limitar la flexibilidad para realizar ajustes o cambios necesarios. El calendario está organizado para llevar a cabo las tareas en el momento adecuado, pero pueden surgir alteraciones o situaciones que impidan la realización de dichas tareas, como fallos de conexión, problemas técnicos o situaciones inesperadas. Por ello, siempre hay que tener en cuenta un margen de horas que se le debe dedicar a esta sección para garantizar la integridad del calendario. 7.2. Inexperiencia La falta de experiencia en ciertas tecnologías puede influir en el desarrollo del proyecto. Se dedican específicamente 20 horas a la formación sobre tecnologías como React y Go (mencionadas en GP1 y GP2), pero esto no nos convierte en expertos. Por lo tanto, debemos pensar a futuro y destinar tiempo a la familiarización y dominio de las tecnologías que vamos a desarrollar. 7.3. Errores La probabilidad de que haya errores es alta en este sector. Este proyecto se encuentra en fase de desarrollo y, antes de comenzar, ya se han identificado ciertos errores a tener en cuenta (algunos de los cuales es posible que logre solucionar). Al ser conscientes de la existencia de algunos errores, también debemos considerar la posibilidad de otros que no conocemos y que nos tocará enfrentar. 20
Ya existe una sección de tareas de errores (GP10), pero esa sección es específica para el desarrollo de mi parte del proyecto. Este riesgo se refiere a errores ajenos que no están relacionados con mi implementación. 7.4. Posibles Modificaciones Ya hemos comentado con el tutor que, a la hora de realizar las tareas, puede ser necesario modificar otras partes del proyecto. Esto puede ser tanto para optimizar las funcionalidades como para editarlas y cambiar su comportamiento. En todo caso, se evitará hacer modificaciones innecesarias, pero es posible que en algún momento del proyecto, por algún motivo u otro, sea necesario llevar a cabo dichas modificaciones. 21
8. Presupuesto 8.1. Identificación de los costes Para la realización de un proyecto, se debe tener en cuenta el presupuesto que supone contratar a los trabajadores implicados, así como los servicios y materiales necesarios para una buena gestión del trabajo. Se identificarán diferentes costes: costes de personal, costes de las tareas y costes genéricos. 8.2. Costes del personal por actividad (CPA) Para poder desarrollar el proyecto, hará falta contratar personal calificado para cada tarea. Por ello, habrá un coste por la contratación de cada persona en los diferentes roles. Rol Coste por hora Coste por hora + SS Jefe de proyecto [J] 14.19€ 18.44€ Desarrollador Frontend [DF] 11.81€ 15.35€ Desarrollador Backend [DB] 11.45€ 14.89€ Ingeniero de sistemas [IS] 12.50€ 16.25€ Software Tester [ST] 8.68€ 11.28€ Tabla 3. Tabla de los roles con sus sueldos. Hemos buscado los roles que se necesitarían para este proyecto y sus supuestos salarios. También hemos realizado una estimación de sus salarios (incluyendo la Seguridad Social). Los datos los hemos extraído de la página Glassdoor[5]. La cifra nos salía anualmente, así que hemos tenido que hacer una conversión para pasarlo a horas. €/ℎ𝑜𝑟𝑎 =𝑠𝑢𝑒𝑙𝑑𝑜/𝑎ñ𝑜 12 𝑚𝑒𝑠𝑒𝑠 ·1 𝑚𝑒𝑠 30 𝑑𝑖𝑎𝑠 ·1 𝑑𝑖𝑎 8 ℎ𝑜𝑟𝑎𝑠 8.3. Coste de las tareas Ahora, en la tabla 4, veremos el coste que implica cada tarea del proyecto y qué partes han intervenido en cada una. 22
23 Código Tarea Duración Horas Coste J DF DB IS ST Tareas de Gestión del Proyecto GP1 Alcance y objetivos del proyecto 30 30 553,2€ GP2 Planificación del proyecto 20 20 368,8€ GP3 Gestión económica y sostenibilidad 20 20 368,8€ GP4 Documento final 15 15 276,6€ Tareas de desarrollo del proyecto DP1 Formación sobre Go 10 10 153,5€ DP2 Formación sobre React 10 10 153,5€ DP3 Familiarización del proyecto y su código 20 5 5 5 5 288,25€ DP4 Diseñar la interfaz de las opciones de ataque 10 10 153,5€ DP5 Implementar el diseño de las opciones de ataque 40 20 10 10 618,4€ DP6 Diseñar la visualización de las estadísticas 10 10 153,5€ DP7 Implementar el diseño de visualización de las estadísticas 40 20 10 10 618,4€ DP8 Diseñar la visualización de los resultados de los ataques 10 10 153,5€ DP9 Implementar visualización de los resultados 40 20 10 10 618,4€ DP10 Pruebas, ejecución y resolver errores 30 30 338,4€ Tareas de documentación de la memoria DM1 Documentación de la Memoria Final 90 60 10 10 10 1.571,3€ DM2 Preparación de la defensa del TFG 15 15 276,6€ Tareas de Seguimiento S1 Reuniones de seguimiento 15 15 276,6€ TOTAL 6.941€ Tabla 4. Costes de las tareas
8.4. Costes genéricos Estos costes se basan en las herramientas u objetos que se necesitan para el desarrollo. Esto incluye objetos tecnológicos, programas y su coste de mantenimiento. 8.4.1. Recursos hardware En la siguiente tabla se enumeran los recursos de hardware necesarios para la realización del proyecto. En este caso, solo necesitaremos mi portátil personal. Recursos Hardware Coste Amortización Lenovo Legion 1.050€ 50.71€ TOTAL 1.050€ 50€ Tabla 5. Coste en los recursos hardware El coste de la amortización lo calculamos de esta manera: 𝐴𝑚𝑜𝑟𝑡𝑖𝑧𝑎𝑐𝑖ó𝑛 = 𝑅𝑒𝑐𝑢𝑟𝑠𝑜𝑠 ℎ𝑎𝑟𝑑𝑤𝑎𝑟𝑒 (€) * 𝐻𝑜𝑟𝑎𝑠 𝑑𝑢𝑟𝑎𝑛𝑡𝑒 𝑒𝑙 𝑝𝑟𝑜𝑦𝑒𝑐𝑡𝑜 (𝑇𝐹𝐺) 𝑉𝑖𝑑𝑎 ú𝑡𝑖𝑙 (5 𝑎ñ𝑜𝑠) · 𝐷í𝑎𝑠 𝑙𝑎𝑏𝑜𝑟𝑎𝑏𝑙𝑒𝑠 (220 𝑑í𝑎𝑠) · 𝐻𝑜𝑟𝑎𝑠 𝑑𝑒 𝑢𝑠𝑜(8 ℎ) Es mi ordenador personal que compré cuando empecé mis estudios en la UPC (septiembre de 2019) [6]. 8.4.2. Recursos software Los recursos de software que utilizamos para el proyecto, en este caso, son todos gratuitos. y son los siguientes: Recursos Software Coste Visual Studio Code 0,00€ Google Suite 0,00€ Excalidraw/Draw.io 0,00€ TOTAL 0,00€ Tabla 6. Coste en los recursos software 8.4.3. Otros costes En otros costes, deberían considerarse el consumo de energía que gasto en mi domicilio y el pago por tener conexión a Internet con la operadora. Es la tarifa que pago a la compañía. El consumo energético es variable, así que establecemos una estimación media. 24
Recurso Coste/mes Total Consumo energético 50€ 200€ Conexión a Internet 60€ 240€ TOTAL 110€ 440€ Tabla 7. Tabla de coste de otros recursos 8.5. Estimación de los costes Ahora sumaremos todos los costes y también se considerarán los imprevistos y la contingencia que se tienen en cuenta en este sector, que está alrededor del 10% al 20%. Añadiremos un 10%. Recursos Coste Coste de contingencia Costes de Personal por actividad 6.941,25€ 691,42€ Recursos Hardware 1.050€ 105€ Recursos Software 0,00€ 0,00€ Otros costes 440€ 44€ TOTAL 8.431€ 843€ Tabla 8. Tabla de estimación de costes En la tabla 9 se muestran los costes de los imprevistos que podemos encontrar en el desarrollo, indicando el encargado de cada rol y su coste: Imprevistos Tiempo (h) Rol Coste (€) Inexperiencia 25 DF,DB 226,8€ Calendario cerrado 15 J 278,6€ Errores 35 DF,DB,ST 488,16€ Posibles modificaciones 10 DF,DB,IS 154,96€ TOTAL 1.148€ Tabla 9. Tabla de costes de imprevistos El coste lo hemos contabilizado multiplicando las horas de cada trabajador por su coste. Si hay más de un trabajador, se hace una media. 25
Para cada JSON de las opciones de ataque, se ha añadido un parámetro llamado formattype. Este parámetro contiene como valor uno de los componentes definidos previamente. En la Figura 9 podemos ver el archivo OptionGroupView.js. Es el encargado de mostrar en la aplicación las opciones de los ataques. Este utiliza la función FormOption que podemos ver en la Figura 10, que se encarga de leer el parámetro formattype para determinar qué componente debe renderizar. Recibe una lista con todas las opciones de cada ataque y, al llegar a FormOption, pasa por un componente switch que, dependiendo del valor de formattype, muestra un tipo específico de input. Figura 9: Fichero OptionsGroupView.js 32
Figura 10: Función FormOption 10.2.1. Text En la Figura 11, podemos observar el input text que está definido para valores que requieren un input más común, como caracteres utilizados frecuentemente para rellenar un parámetro. Por ejemplo, puede ser utilizado para ingresar una palabra, una dirección IP o un número. Dentro de este contenedor, se renderiza un título titleOption que describe la opción, acompañado de un botón de información. Este botón utiliza el componente OverlayTrigger para mostrar un pop-up explicativo al usuario al pasar el cursor sobre él. Se utiliza el componente Form.Control dentro de este contenedor para renderizar un campo de entrada de texto. Este campo está equipado con dos eventos: onChange yonBlur. El evento onChange se activa cada vez que el usuario modifica el contenido del campo de texto, llamando a dos funciones proporcionadas como props: handleTextChange, para actualizar el estado del valor de la opción, y handleConflict, para gestionar posibles conflictos con otras opciones. Figura 11: Código del formato text 33
Figura 12: Visualización del input text en las opciones de ataque 10.2.2. Select El select está diseñado para aquellos inputs en los que las opciones ya están definidas y el usuario solo debe seleccionar una de ellas. Al usuario se le muestra un menú desplegable que facilita la selección de las opciones disponibles, evitando la necesidad de escribir manualmente. Esto proporciona una manera más rápida y eficiente de elegir un input. Es útil, por ejemplo, para seleccionar ficheros ya definidos o configuraciones preestablecidas como modos de ejecución. El formato select, que podemos ver en la Figura 13, se utiliza para gestionar opciones que requieren la selección de un valor de una lista predefinida. Su diseño asegura que las opciones sean fácilmente accesibles y que las selecciones realizadas se procesen correctamente. Dentro del contenedor, se utiliza el componente Form.Select para renderizar el menú desplegable. Este componente presenta las opciones disponibles y, cuando el usuario selecciona un valor, activa el evento onChange. Este evento llama a varias funciones proporcionadas como props. El handleSelectedMode gestiona la selección del modo y asegura que el sistema registre correctamente el valor elegido. El handleTextChange actualiza el estado asociado a la opción seleccionada. El handleConflict maneja posibles conflictos con otras opciones dependientes o relacionadas. El select despliega las opciones que se encuentran definidas en el archivo de opciones, bajo la etiqueta selectOptions. Además, incluye una condición específica para los casos en los que el título de la opción es "Mode", facilitando el parseo del JSON para funcionalidades específicas que se explicarán en detalle más adelante en el apartado 10.3. en la Seleccion de modo. Este enfoque asegura que el componente sea versátil y adaptable a diversas necesidades de configuración. 34
Figura 13: Código del formato select Figura 14: Visualización del input select en las opciones de ataque 35
10.2.3. Switch El switch es un checkbox diseñado para aquellas opciones que solo requieren marcar si queremos utilizarlas o no. Se utiliza en casos como, por ejemplo, en nmap, para indicar si queremos realizar la resolución de hosts (parámetro -n) o activar un modo verbose. Este tipo de componente permite al usuario habilitar o deshabilitar fácilmente una funcionalidad específica. El switch se implementa utilizando el componente Form.Check con el atributo formattype configurado como switch, lo que permite representarlo como un interruptor interactivo. Este componente incluye un evento onChange que se activa cada vez que el usuario interactúa con el interruptor. Este evento llama a dos funciones: handleCheckboxChange, que actualiza el estado de la opción en el sistema, y handleConflict, que gestiona posibles conflictos con otras opciones configuradas. De esta forma, el switch ofrece una experiencia intuitiva y eficiente para controlar opciones binarias en la interfaz de usuario. Podemos observar su implementación en la Figura 15 y su visualización en la Figura 16. Figura 15: Código del formato switch Figura 16: Visualización del input switch en las opciones de ataque 36
10.2.4. Switch text El switch text es un conjunto de componentes que funciona para opciones que se tienen que seleccionar y, además de ello, añadir un valor al parámetro. El switch utiliza un componente Form.Check, que permite al usuario activar o desactivar la opción. Su estado se controla mediante el atributo checked, que verifica si la opción está activada. Cuando el usuario interactúa con el interruptor, se llaman dos funciones: una para gestionar posibles conflictos con otras opciones y otra para actualizar el estado de activación de la opción. El campo de texto está implementado con un componente Form.Control. Este campo permite al usuario proporcionar información adicional si el interruptor está activado. Incluye eventos como onChange para actualizar el valor ingresado y manejar conflictos, y onBlur para realizar verificaciones adicionales al perder el foco. El campo se desactiva automáticamente si el interruptor está desactivado y la opción lo requiere. Podemos ver el código en la Figura 17 y su visualización en la Figura 18. Figura 17: Código del formato switch-text 37
Figura 18: Visualización del input switch-text en las opciones de ataque 10.2.5. Secret El secret es similar al select, pero en este caso es específico porque se realiza una llamada a la base de datos para obtener las secret keys del usuario y mostrarlas. El formato secret es un formato especial utilizado para las API Keys del usuario. Se utiliza un componente Form.Select para renderizar un menú desplegable que permite seleccionar un secreto. Este componente incluye un evento onChange, que se activa cada vez que el usuario selecciona una opción del menú. Al activarse, este evento llama a dos funciones proporcionadas como props: handleTextChange yhandleConflict. El menú desplegable presenta una opción predeterminada titulada "Select a secret", seguida de una lista generada dinámicamente a partir de un arreglo llamado keys. Cada elemento del arreglo representa un secreto y se renderiza como una opción dentro del menú. Las opciones muestran detalles de la API Key, incluyendo el identificador de la key secret_key y se le envía el valor real del secret. La Figura 19 muestra la implementación y la Figura 20 su visualización. Esta implementación se explicará más a fondo en el apartado 11, en la Gestión de Secret Keys. Figura 19: Código del formato secret 38
Figura 20: Visualización del input secret en las opciones de ataque Esto es útil para un futuro poder añadir nuevos compononente de manera más ordenada y fácil, solo es añadir otro case en el switch e implementar la funcionalidad deseada. 10.3. Selección de modo Para algunos ataques, existe una opción integrada definida exclusivamente en sus configuraciones, que generalmente corresponde al modo de ejecución. Por ejemplo, tomemos el caso de Gobuster.Gobuster es una herramienta de código abierto escrita en Go, diseñada para realizar tareas de fuerza bruta en directorios, archivos, subdominios y otros recursos de servidores web. Es utilizada por profesionales de la seguridad informática y penetration testers para descubrir rutas, archivos ocultos o subdominios en servidores y aplicaciones web. El modo de ejecución varía dependiendo de si se desea descubrir rutas ocultas o subdominios en servidores. Por esta razón, antes de realizar el ataque, es necesario establecer el modo de ejecución, que puede incluir opciones como: ● dir: Identificar rutas ocultas o no documentadas que podrían contener información sensible o vulnerabilidades. ● dns: Ayudar en la enumeración de subdominios, que es una etapa crucial en la fase de reconocimiento de un pentest. ● vhost: Detectar configuraciones de host virtual que no sean accesibles directamente desde el dominio principal. ● s3: Identificar buckets configurados de manera pública que podrían contener datos sensibles. ● fuzz: Probar entradas personalizadas como parámetros de consulta, encabezados o cookies. ● gcs: Identificar buckets de almacenamiento de Google configurados de forma pública. ● tftp: Detectar archivos accesibles en servidores TFTP, que suelen tener configuraciones más simples y menos seguras. Solo se puede seleccionar un modo a la vez. Por ello, para mejorar la interfaz de usuario, hemos considerado que sería más útil permitir al usuario interactuar únicamente con el modo que desea emplear, bloqueando los modos que no se quieran utilizar. Esto facilita un uso más intuitivo y eficiente de la herramienta. 39
Primero miramos si el ataque que queremos realizar tiene diferentes modos. En el OptionsFile de los ataques hay un apartado llamado Mode, dónde puede contener un lista de diferentes modos posibles que puede tener. Si este ataque contiene modos, este lo guardaremos en una variable llamada Modes. Podemos ver como lo realiza en la Figura 21. Figura 21: Variable Modes En el archivo OptionGroupView.js, en la Figura 22, verificamos si los grupos de las opciones están dentro de un modo. Figura 22: Fragmento de código de verificación de los modos La línea variable isMode verifica si la categoría actual es un modo válido. Para ello, se utiliza el array props.validModes, que contiene los modos permitidos, y se verifica si la categoría está incluida en dicho array. Si validModes no está definido, la expresión evalúa como false, indicando que no es un modo válido. A continuación, isActive determina si el modo está activo. Si la categoría es un modo válido (es decir, si isMode es true), se comprueba si coincide con el modo seleccionado actualmente (props.selectedMode). Si no es un modo válido, se asume que la categoría está activa, lo que permite la interacción con otras opciones no relacionadas con modos. La variable selectedMode es gestionada por la función handleSelectedMode, que se encarga de establecer el modo actual seleccionado. Este componente se activa al realizar una selección mediante el componente select, que hemos explicado anteriormente. Podemos visualizar su implemnetación en la Figura 23 que hay a continuación. 40
Figura 23: Variable handleSelectedMode Cada grupo de opciones está compuesto por un componente de React llamado Accordion, en la Figura 24. Para determinar si ese modo debe estar bloqueado o seleccionado, se utiliza el estado isActive para establecer su estado. Figura 24: Fragmento de código del componente Accordion Para la experiencia del usuario, los resultados los podemos ver en la Figura 25 y la Figura 26, viendo cómo al cambiar de modo, seleciona y habilita el seleccionado. Esto se puede implementar para futuros ataques que tengan diferentes modos de ejecución únicos, y facilita su utilidad y comprensión para el usuario. 41
El reultado de la alerta lo podemos ver a continuación en la Figura 32. Figura 32: Visualización de alertas de conflictos 11. Gestión de “Secret Keys” Algunos de los ataques hacen llamadas a APIs para acceder a sus servicios. Una API (Application Programming Interface) es un conjunto de reglas, protocolos y herramientas que permite la comunicación entre diferentes aplicaciones, sistemas o servicios. En esencia, una API actúa como un intermediario que facilita la interacción entre dos sistemas, permitiendo que compartan datos o realicen acciones de manera estructurada y eficiente. En términos técnicos, una aplicación cliente envía una solicitud a la API, especificando la acción o la información requerida. La API procesa esa solicitud, accede a los datos o realiza la acción necesaria y devuelve una respuesta al cliente en un formato estándar, como JSON o XML. Un ejemplo común del uso de una API se encuentra en aplicaciones de clima. Cuando un usuario solicita el pronóstico de su ciudad, la aplicación envía una solicitud a una API de clima con la ubicación del usuario. La API procesa la solicitud, busca la información correspondiente en su base de datos y devuelve una respuesta con los datos del clima, como la temperatura, las condiciones atmosféricas o la probabilidad de lluvia. Estas APIs puede que conllevan en sí, una forma de autenticar y autorizar el usuario que está tramitando esa peticion. Para idenficar al usuario, existen lo que se conocen como API Keys. Una API Key es un identificador único que permite autenticar y autorizar solicitudes a una API, asegurando que solo usuarios o aplicaciones con permisos válidos puedan acceder a los recursos o servicios ofrecidos. Funciona como una contraseña que se incluye en cada solicitud realizada a la API, lo que permite al proveedor verificar la identidad del solicitante y determinar si tiene autorización para acceder a los datos o realizar determinadas acciones. Las API Keys garantizan la seguridad de los sistemas, monitorean el uso de los servicios y 48
aplican límites o cuotas de acceso. Las claves se generan cuando un usuario o desarrollador se registra para usar la API. Figura 33: Diagrama del mecanismo de las API keys Dado que algunos ataques pueden requerir el uso de API Keys, hemos considerado que sería apropiado implementar una funcionalidad que permita a los usuarios gestionar una lista de API Keys. De esta forma, los usuarios podrán guardar, organizar y utilizar sus claves de manera sencilla, sin necesidad de recordar manualmente qué key utilizar en cada caso. La idea principal es proporcionar una lista de API Keys donde el usuario pueda añadir, eliminar y visualizar sus claves. Cada API Key incluirá la siguiente información: ●ID: Un identificador único asociado a la key. ●Descripción: Información adicional sobre la API Key, que ayude al usuario a comprender su propósito o contexto. ●Secret Key:El valor de la API Key, necesario para autenticar o autorizar el acceso a servicios específicos. Esta funcionalidad permitirá a los usuarios gestionar sus API Keys de forma eficiente y personalizada, adaptándose a sus necesidades y facilitando el uso en diferentes ataques o configuraciones. Además, al centralizar la gestión de claves, se mejora la usabilidad y se reduce la posibilidad de errores al seleccionar o ingresar una API Key. 11.1. Configuración de Parámetros Para hacer la configuración, primeramente tenemos que pensar como el usuario puede llegar a utilizar esta API key en sus ataques. Como hemos explicado en el apartado 10.2.5., el caso especial de Secret, hemos añadido un componente más en el JSON, el formato secret, para hacer referencia a las opciones que necesiten una key. La gestión de la keys la hemos añadido en el apartado de Settings, que la hemos creado para añadir configuracines posibles del usuario. Al acceder a la página podremos ver la lista de las keys que tenemos establecidas en la Figura 34. 49
Figura 34: Visualización del apartado Settings 11.2. Uso de Secret Keys 11.2.1. Listar Para listar las API keys, como se utiliza, por ejemplo, en la sección de configuración o al seleccionar opciones durante un ataque, se realiza una solicitud al endpoint /listSecrets. Este endpoint permite recuperar y mostrar todas las API keys almacenadas, facilitando su gestión y selección. Existen dos puntos clave en la aplicación donde se realiza la llamada al endpoint /listSecrets. El primero es cuando se renderiza el componente Secret, que permite al usuario seleccionar una API Key en las opciones de los ataques. El segundo es al acceder a la sección Settings, un apartado creado para la configuración personal del usuario. Actualmente, en este apartado, se ha implementado la funcionalidad de gestión de las Secret Keys. Cuando entras al apartado de Settings, automáticamente de manera asincronada hace una llamada al endpoint /listSecrets obteniendo los datos en la variable listKeys. Podemos ver la implementación en la Figura 35. 50
Figura 35: Función listKeys Esta llamada llega al Router.js, que es el archivo que gestiona todos los endpoints para hacer consultas a la base de datos. La función listSecrets (Figura 36), define un endpoint en el servidor para manejar solicitudes HTTP POST, cuyo objetivo es obtener una lista de secret keys almacenados por el usuario que está integrado en el backend que utiliza Apache Pulsar para procesar la solicitud y devolver la información requerida. Cuando el usuario realiza una solicitud al endpoint /listSecrets, el servidor construye un mensaje de solicitud msgRequest, que incluye el session_id del usuario extraído de su sesión activa. Este identificador asegura que solo se recuperen los secretos asociados con el usuario que realiza la solicitud. El servidor gestiona la comunicación con el backend, inicializa un cliente con las configuraciones del host y puerto especificados, con el pulsar_host ypulsar_port, y envía el mensaje de solicitud a la base de datos ui-db.listSecrets. Este método permite obtener la respuesta directamente del backend, que contiene los secretos solicitados. Una vez que el servidor recibe la respuesta en el pulsar_response, intenta procesarla transformando los datos en un formato estándar. Los secretos se organizan en un array de objetos que incluye propiedades como id de la sesion, el nombre de la key,description, secret_key. 51
Si el procesamiento de la respuesta es exitoso, el servidor envía los datos transformados al cliente en formato JSON, permitiendo que se muestren o utilicen en la interfaz de usuario. Figura 36: Función listSecrets en Router.js De aqui envia la llamada al archivo secrets.go, que son los que se encargan de comunicarse con la base de datos. Aquí llama a la función listSecrets (Figura 37), cuyo objetivo es gestionar solicitudes para recuperar secretos almacenados. Comienza deserializando el mensaje recibido en una estructura MessageResponse. Este mensaje incluye información clave como el session_id, que identifica la sesión activa del usuario. A continuación, se utiliza la función GetSession_id para extraer el session_id del mensaje. 52
Una vez validado el session_id, la función intenta obtener un contexto de base de datos asociado a la sesión utilizando la función GetDBContext. Cuando la conexión con la base de datos es exitosa, la función construye un filtro que busca registros donde el campo secret_key exista. Esto asegura que la consulta recupere únicamente los documentos relevantes que contienen secretos. La consulta se ejecuta mediante la función localQuery. Si la consulta se completa con éxito, la lista de secretos recuperada se envía de vuelta al cliente. Figura 37: Endpoint listScrets en secrets.go Una vez obtenido todos los datos, el usuario puede visualizar la lista de los keys que tiene guardados en su sesion. En la figura 38 podemos ver el código que gestiona la estructura de la lista de keys y en la Figura 39 podemos ver su visualización. 53
Figura 38: Código de la estrutura de la lista de keys Figura 39: Visualización de la lista de keys 54
11.2.2. Añadir El mecanismo para añadir una API requiere: ●ID: El dentificador que se le quiere dar a la key. ●Descripcion: Informacion detallada sobre la key. ●Secret Key: El valor de la API key en cuestión. El usuario tiene que añadir los parametros establecidos para poder guardar su API key. En la Figura 40 podemos ver el formulario descrito. Figura 40: Formulario para añadir una key El formulario está creado a traves de un componente Form de React, que luego al pulsar el boton de “Add Key”, llama a la funcion handleSubmit, que gestiona la addición de la key. En la Figura 41 podemos ver el codigo de la estructura del Form. En la Figura 42 podemos ver la función handleSubmit, que se encarga de gestionar el envío de un formulario utilizado para agregar una nueva secret key. Empieza deteniendo el comportamiento predeterminado del formulario mediante event.preventDefault(), lo que evita que la página se recargue al enviarlo. También se utiliza event.stopPropagation() para evitar que el evento se propague más allá del formulario. A continuación, la función extrae los valores introducidos en los campos del formulario. Se obtienen los datos correspondientes al nombre de la clave, la descripción y el valor secreto, que se almacenan en las variables key,description, y secret. Se realiza una validación utilizando la función existKey para verificar si ya existe una clave con el mismo nombre. Si la clave ya existe, se muestra una alerta al usuario y el proceso se detiene, evitando duplicados. 55
Figura 41: Código del formulario 56
Figura 42: Función handleSubmit para añadir una key 57
12.1. Directorio Original Este método es el que estaba implementado de serie en el programa. El usuario introduce un archivo que se encuentra en la carpeta /etc/huntdown/wordlists. El programa comprueba si el archivo se encuentra alli. Si es cierto, lo utiliza para la ejecución de su comando. Ponemos de ejemplo la ejecucion de gobuster. Gobuster tiene como parámetro -w, que es la wordlist que se quiere emplear. Para este caso, añadiremos una url y le añadiremos un wordlist para hacer descubrimiento de directorios. En el comando seria algo asi: gobuster dir -u <url> -w <wordlist> Cuando está entrando en el if, si es un archivo que se encientra en el directorio /etc/huntdown/wordlists, solo hace falta escribir el nombre del archivo. Figura 50: Visualización de los archivos que hay en el diretorio /etc/huntdown/wordlists Actualmente tenemos estas wordlist en el directorio /etc/huntdown/wordlists/. Ahora probamos a ejecutar el gobuster con el archivo dir.txt. Figura 51: Parámetros rellenados con el archivo dir.txt Añadimos todos los parametros necesarios para hacer una ejecucion sencilla. Ponemos el modo dir, la wordlist dir.txt y la url http://127.0.0.1:80, como prueba. Ahora vamos a ejecutar el ataque. En la Figura 52, podemos observar los resultados de la ejecución, y podemos ver como se ha ultizado el fichero dir.txt que estaba en el directorio. 64
Figura 52: Resultados de la ejecución 1 12.2. Ruta local del sistema Para que el usuario quiera utilizar un archivo en alguna ruta del sistema, en la opción de wordlist el usuario tiene que agregar la ruta de donde se encuentra. Cuando se está gestionando el ataque, la opción del archivo comprueba las condiciones del if y entra en la función processFilePath. La funció processFilePath, se encuentra en la Figura 53, tiene como objetivo manejar y copiar archivos desde una ruta local especificada por el usuario a un directorio destino definido. Primero, verifica si el archivo proporcionado en la entrada existe, utilizando la función auxiliar fileExists. Si el archivo que se está buscando se encuentra en el sistema local, la función obtiene el nombre base del archivo utilizando filepath.Base, y genera la ruta completa del archivo en el directorio destino concatenando el directorio objetivo y el nombre del archivo. Antes de copiar el archivo, la función verifica si ya existe un archivo con el mismo nombre en el directorio destino. Si se encuentra un directorio con el mismo nombre, genera un nuevo nombre único agregando un sufijo numérico al nombre del archivo original. Este proceso se repite en un bucle hasta que se encuentra un nombre que no esté en uso, asegurando que no se sobrescriban archivos existentes. Una vez generado el nombre único, abre el archivo original y crea un nuevo archivo en el directorio destino. Copia el contenido del archivo de origen al nuevo archivo. Si la operación de copia se completa con éxito, devuelve el nombre final del archivo en el directorio destino. 65
Figura 53: Función processFilePath Ahora hacemos una ejecución añadiendo en la wordlist una ruta del sistema donde se aloja un archivo. El archivo que tenemos en el sistema local es el common.txt que contiene un diccionario de posibles directorios de webs y se encuentra en el ruta /mnt/c/Users/bruno/Downloads. 66
Figura 54: Parámetros rellenados con la ruta del archivo Ahora que hemos enviado la ejecucion del ataque, si observamos el directorio /etc/huntdown/wordlists/, veremos que se encuentra el fichero common.txt. Figura 55: Directorio /etc/huntdown/wordlists/ con el nuevo archivo Cuando vemos el resultado, vemos que el ataque ha sido realizado con el archivo common.txt. Podemos observarlo en la Figura 56. Figura 56: Resultado de la ejecución 2 67
12.3. Descarga del archivo En el caso de que el usuario quiera descargar un archivo que ha encontrado por internet, tiena la posibilidad de descargar ese archivo deseado introducion la url directamente. La función downloadFile, en la Figura 57, está diseñada para descargar un archivo desde una URL especificada y almacenarlo en un directorio local. Primero, obtiene el nombre base del archivo a partir de la URL, extrayendo sólo el nombre del archivo sin la ruta completa. Además, divide el nombre en su base y extensión para manejar posibles conflictos de nombres más adelante. Luego, construye una ruta completa hacia el archivo en el directorio local combinando el directorio objetivo y el nombre del archivo. Antes de descargar el archivo, verifica si ya existe un archivo con el mismo nombre en el directorio objetivo. Si es así, genera un nombre único al agregar un sufijo numérico al nombre base del archivo, repitiendo este proceso en un bucle hasta encontrar un nombre que no esté en uso. A continuación, la función realiza una solicitud HTTP GET a la URL proporcionada para obtener el contenido del archivo. También verifica que el código de estado de la respuesta sea 200 OK, asegurándose de que la descarga fue exitosa. Crea un archivo en el directorio local con el nombre determinado anteriormente. Copia el contenido descargado desde la respuesta HTTP al archivo local. Hacemos una prueba con una wordlist de Github creada por foospidy llamada directory-list-lowercase-2.3-small.txt [7] y le pasaramos esta url: https://raw.githubusercontent.com/foospidy/payloads/refs/heads/master/owasp/dirbuster/dire ctory-list-lowercase-2.3-small.txt Rellenamos los parametros con la url dicha anteriormente, como vemos en la Figura 57. Figura 57: Parámetros rellenados con una URL 68
Figura 58: Función downloadFile Podemos ver en la Figura 59, como en el directorio /etc/huntdown/wordlists se ha añadido el nuevo archivo. Figura 59: Directorio /etc/huntdown/wordlists/ con el nuevo archivo Al ver el output del ataque, vemos como se ha utilizado el archivo descargado. Lo podemos observar en la Figura 60. 69
Figura 60: Resultado de la ejecución 3 13. Nuevo ataque wfuzz En Huntdown, al ser una aplicación que obtiene información a partir de los ataques, hemos querido añadir una nueva herramienta muy utilizada en el ambito de la seguridad llamada wfuzz[8]. Wfuzz es una herramienta ampliamente utilizada en el ámbito de la ciberseguridad y pruebas de penetración para realizar fuzzing en aplicaciones web. El fuzzing es una técnica que consiste en enviar grandes cantidades de datos o entradas inesperadas a una aplicación para identificar posibles vulnerabilidades, como inyecciones de código, fallos de autenticación, rutas no seguras o errores no controlados. Wfuzz es particularmente útil para: ●Descubrimiento de recursos ocultos: Buscar archivos o directorios ocultos en un servidor web que no estén expuestos públicamente, pero que puedan ser accedidos mediante fuzzing de URLs. ●Ataques de fuerza bruta: Probar múltiples combinaciones de datos, como credenciales de inicio de sesión o parámetros de URL, para acceder a recursos protegidos. ●Detección de vulnerabilidades: Identificar parámetros inseguros en aplicaciones web que puedan ser vulnerables a ataques como SQL Injection,XSS (Cross-Site Scripting), etc. 70
13.1. Archivos de configuración Para que podamos utilizar esta herramienta en la aplicación, hemos tenido que configurar diferentes archivos JSON para que la herramienta sea funcional y la aplicación sea capaz de captar los datos. Estos archivos incluyen, por ejemplo, parámetros para inicializar el ataque, opciones personalizadas y configuraciones para parsear la información. 13.1.1. wfuzz-attack.json El archivo wfuzz-attack.json es un archivo de configuración en formato JSON que define los parámetros y opciones necesarios para configurar y ejecutar un ataque. Este archivo, que viene de la plantilla attackschema.go organiza los datos esenciales para que la aplicación pueda gestionar el ataque de manera estructurada y automatizada. A continuación, se explican los parametros del archivo y sus funcionalidades: ●attackname: Especifica el nombre del ataque, en este caso, wfuzz. Identifica de manera descriptiva la herramienta o el tipo de prueba a realizar. ●attackid: Asigna un identificador único al ataque, lo que permite rastrear o gestionar múltiples configuraciones en diferentes ejecuciones. ●state y step: Indican el estado actual del ataque. ○state: Refleja si el ataque ha sido ejecutado. ○step: Detalla el progreso de la ejecución. ●typeattack: Reitera el tipo de ataque que se realizará, lo que señala el uso de esta herramienta específica. ●resultsid: Este campo se utilizará para almacenar un identificador único relacionado con los resultados generados por el ataque. ●errormsg: Este campo está destinado a registrar mensajes de error si ocurren durante la ejecución. ●dockerimage: Especifica la imagen que se utilizará para ejecutar el comando. ●os_type: Indica el sistema operativo en el que se ejecutará el ataque. ●runnertype: Define cómo se ejecutará el ataque. ●dependencies: Lista las dependencias necesarias para ejecutar el ataque. ●clicommands: Es un arreglo que contiene los detalles de los comandos CLI que se ejecutarán durante el ataque. Cada objeto en este arreglo tiene varias claves: ○action: Define la acción específica del comando. ○optionsid: Identifica un conjunto de opciones para el comando. ○options: Lista las opciones del comando. ○redirectstdin, redirectstdout, redirectstderr: Controlan cómo se manejan las entradas y salidas estándar durante la ejecución. ○pipe: Indica si el comando necesita enviar su salida a otro proceso mediante un pipe. ○backgroundjob: Especifica si el comando debe ejecutarse en segundo plano. ○conncatenatecommands: Determina si el comando debe concatenarse con otros para formar una secuencia. ○timeout: Permite establecer un límite de tiempo para la ejecución del comando. ○fileoutput y outputtype: Definen si los resultados deben guardarse en un archivo y el formato de salida. 71
○needresults: Indica si se requiere que los resultados del comando sean procesados. Figura 61: Archivo wfuzz-attack.json En este archivo hemos configurado los parámetros necesarios para que la herramienta Wfuzz pueda utilizarse de manera correcta y para que, al gestionar la información, esta pueda ser identificada adecuadamente. Lo hemos identificado con el nombre de wfuzz y el identificador número 30. Como parámetro importante, tenemos el dockerimage, para el cual hemos utilizado una imagen de DockerHub [9] que contiene la herramienta. Específicamente, hemos empleado la imagen dominicbreuker/wfuzz del usuario dominicbreuker, lo que permite que la aplicación levante un contenedor Docker con un entorno preparado para su ejecución. 13.1.2. wfuzz-dashboard.json El archivo wfuzz-dashboard.json, es un archivo de configuración en formato JSON que se utiliza para definir los parámetros necesarios para mostrar información relevante sobre el estado y rendimiento de los ataques realizados en el menú principal de la aplicación. Está diseñado para proporcionar una vista resumida y accesible de los datos clave relacionados con el uso de la herramienta. Los parámetros del JSON son: 72
●attacknamedashboard: Define el nombre del ataque que aparecerá en el menú principal del dashboard. ●options: Es un objeto que contiene varias claves destinadas a almacenar información dinámica y relevante sobre los ataques realizados. Estas claves incluyen: ○executed: Indicará el número de ataques que han sido ejecutados con éxito. ○executing: Reflejará si hay algún ataque en proceso de ejecución. ○error: Mostrará un resumen de errores detectados durante la ejecución de los ataques. ○avgtime: Permitirá visualizar el tiempo promedio de ejecución de los ataques realizados, proporcionando una métrica útil para evaluar el rendimiento. ○attackmonth: Almacenará información sobre el número de ataques realizados en el mes actual, lo que facilita el seguimiento de la actividad reciente. Figura 62: Archivo wfuzz-dashboard.json 13.1.3. wfuzz-options.json El archivo wfuzz-options.json, basados en la plantilla optionsfile.go, es un JSON define la configuración de opciones disponibles para configurar y ejecutar un ataque con Wfuzz en la interfaz de usuario de una aplicación. Su objetivo principal es especificar las opciones que el usuario puede seleccionar o personalizar para ajustar los parámetros del ataque según sus necesidades. El archivo contiene estos parámetros: ●name: Especifica el nombre del ataque. ●optionsid: Es un identificador único para este conjunto de opciones. ●optionsname: Puede usarse para asignar un nombre descriptivo adicional a este conjunto de opciones. ●delimiter: Define el delimitador utilizado entre los diferentes parámetros de los comandos. ●options: Es un arreglo que contiene los detalles de cada opción configurable. ○title: Título descriptivo de la opción que se mostrará en la interfaz. ○maingroup: Clasifica la opción en un grupo principal. ○subgroup: Define un subgrupo adicional. ○flag: Es el indicador o parámetro que se utilizará en el comando. ○value: Se utiliza para almacenar el valor personalizado que el usuario introduzca. ○needcheckbox: Especifica si esta opción debe tener un checkbox asociado. ○checkbox: Indica el estado predeterminado del checkbox. 73
15.4. Aspecto social A nivel personal, la realización de este proyecto puede aportarme mucho, ya que quiero orientar mi carrera profesional hacia el ámbito de la seguridad informática. Trabajar en este proyecto me permitirá aprender nuevos lenguajes de programación, lo que incrementará mi versatilidad y capacidad para adaptarme a diferentes entornos de desarrollo. Además, me ofrece la oportunidad de profundizar en la estructura y funcionamiento de una aplicación, tanto en su frontend como en su backend, y entender cómo se gestiona de manera integral. Actualmente, el problema que quiero abordar se resuelve de forma manual por los profesionales del sector, quienes realizan los ataques a través de una terminal de ordenador o mediante el uso de softwares ya desarrollados. Sin embargo, estas soluciones a menudo son complejas y carecen de una interfaz accesible para usuarios menos técnicos. Mi solución, aunque no tenga un impacto social directo, podría generar una mejora indirecta en el ámbito de la seguridad informática. El desarrollo de aplicaciones como esta contribuye al avance continuo de la seguridad en redes, lo que repercute en una mayor protección de los datos y su privacidad, tanto a nivel empresarial como personal. En cuanto a la necesidad real del proyecto, depende del contexto en que se analice. En los últimos años ha habido un incremento en los ciberataques, especialmente a grandes empresas, y se prevé que esta tendencia siga en aumento. Dado que hoy en día casi toda la información crítica, como datos personales, financieros y de salud, está en la red, la seguridad informática se ha vuelto esencial. Por lo tanto, desde esa perspectiva, este proyecto responde a una necesidad creciente de mejorar la seguridad en el entorno digital. 80
17. Conclusiones Durante la realización del proyecto, se han alcanzado los objetivos establecidos de manera satisfactoria, aunque aún hay margen para ampliar y perfeccionar algunas de las funcionalidades implementadas. El objetivo principal del proyecto era mejorar la experiencia del usuario que utiliza este programa, y consideramos que este objetivo se ha logrado. Se han incorporado mejoras visuales que simplifican y facilitan la selección de opciones para los ataques. Además, se ha optimizado el sistema de componentes, permitiendo que los inputs se adapten automáticamente según su formato. También se ha implementado una funcionalidad para habilitar únicamente un modo de ejecución en aquellos ataques que lo requieran, mejorando la precisión y usabilidad del programa. Asimismo, se ha añadido un sistema de gestión de requisitos y conflictos entre opciones, que alerta al usuario en caso de configuraciones incompatibles o faltantes. Otra mejora significativa es la inclusión de un apartado de Settings para la configuración personalizada del usuario. En esta sección, se ha desarrollado una funcionalidad que permite almacenar y gestionar claves API en la base de datos, facilitando su reutilización en ataques que las requieran. Esto no solo mejora la organización, sino que también ahorra tiempo al usuario al evitar la necesidad de introducir las claves repetidamente. Se ha añadido la capacidad de trabajar con archivos ubicados en cualquier ruta del sistema y también de descargarlos directamente desde internet. Esto aporta una notable flexibilidad y versatilidad al programa, adaptándose mejor a las necesidades del usuario. Personalmente, me siento gratificado con el trabajo realizado y con la oportunidad de haber contribuido a este proyecto. Durante el desarrollo, he aprendido e implementado diversas tecnologías, y ha sido satisfactorio aplicar los conocimientos adquiridos en la facultad. Este programa tiene un gran potencial de expansión y mejora, lo que lo convierte en una herramienta prometedora dentro del campo en el que opera. Estoy convencido de que estas mejoras sentarán una base sólida para futuras iteraciones del proyecto. 17.1. Posibles mejoras A pesar de los avances logrados, aún existen oportunidades para mejorar y ampliar el proyecto. Algunas de las posibles mejoras que se podrían implementar en futuras iteraciones son las siguientes: 17.1.1. Incorporación de Nuevos Componentes con React Se podrían añadir más componentes personalizados para enriquecer la experiencia del usuario. Por ejemplo, un componente dedicado para la configuración de puertos en ataques, que permita a los usuarios especificar rangos de puertos, puertos individuales o configuraciones avanzadas de manera sencilla y visual. Esto ampliaría las capacidades del programa y ofrecería mayor precisión en tareas específicas. 81
17.1.2. Ampliación de las Configuraciones de Usuario Se podría implementar un sistema más robusto para gestionar configuraciones personalizadas del usuario. Esto incluiría la capacidad de guardar más elementos, como rutas de directorios predeterminados, configuraciones recurrentes o perfiles de usuario para diferentes escenarios. Estas mejoras proporcionarían al usuario mayor comodidad y permitirían una configuración más rápida y eficiente en ataques recurrentes. 17.1.3. Integración de Subida de Archivos en Vagrant Otra mejora significativa sería integrar la funcionalidad de subir archivos directamente en entornos virtualizados como Vagrant. Esto facilitaría la transferencia y el uso de archivos necesarios en entornos controlados, mejorando la flexibilidad y la interoperabilidad del sistema. Los usuarios podrían cargar archivos locales en sus entornos de ataque directamente desde la interfaz del programa, simplificando el flujo de trabajo. 82
18. Referencias [1] HuntDown / HuntDown · GitLab. (s.f.). GitLab. https://gitlab.com/HuntDownUPC/HuntDown [2] Metasploit | Penetration Testing Software, PEN Testing Security | Metasploit. (s. f.). Metasploit. https://www.metasploit.com/ [3] Laoyan, S. (2024, 2 febrero). What is Agile Methodology? (A Beginner’s Guide) [2024] • Asana. Asana. https://asana.com/resources/agile-methodology [4] Meardon, D. E. (s. f.). Diagramas de gantt | Atlassian. Atlassian. Disponible en: https://www.atlassian.com/es/agile/project-management/gantt-chart [5] Glassdoor. En el apartado de “Sueldos”. Disponible a: https://www.glassdoor.es/Sueldos/index.htm [6] Santander, B. (s. f.). ¿Qué es la amortización, qué tipos hay y cómo se calcula? Banco Santander. Disponible en: https://www.bancosantander.es/glosario/amortizacion [7] Foospidy. (s. f.). payloads/owasp/dirbuster/directory-list-2.3-small.txt at master · foospidy/payloads. GitHub. Disponible en: https://github.com/foospidy/payloads/blob/master/owasp/dirbuster/directory-list-2.3-small.txt [8] Wfuzz: The Web fuzzer — Wfuzz 2.1.4 documentation. (s. f.) Disponible en: https://wfuzz.readthedocs.io/en/latest/ [9] Docker Hub Container Image Library | App Containerization. (s. f.). Disponible en: https://hub.docker.com/ [10] Redacción. (2023, 21 septiembre). Ciberdelincuencia: un costo anual superior a los diez billones de dólares para la economía mundial - Usec Network Magazine. Usec Network Magazine. Disponible en: https://usecim.net/2023/09/21/ciberdelincuencia-un-costo-anual-superior-a-los-diez-billonesde-dolares-para-la-economia-mundial/ [11] Echavarria, N. (s. f.). 5 graves problemas generados por la ausencia de Ciberseguridad en las empresas. Disponible en: https://www.nedigital.com/es/blog/problemas-ciberseguridad [12] Open iT, Gestión de Licencias de Software, ServiceNow Partner. (2023, 12 junio). Tecnologías de la información sostenibles: beneficios y estrategias de aplicación. Disponible en: https://openit.com/es/sustainable-it-benefits-and-strategies-to-implement/ 83
84