Desarrollo de un Plugin de FOCA para extraer cuentas de usuario en redes sociales

Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Desarrollo de un Plugin de FOCA para extraer cuentas de usuario en Redes Sociales. Autor: Iv´an Garc´ıa Hurtado 2 Escuela de Ingenier´ ıa Inform´ atica TRABAJO FIN DE GRADO Grado en Ingenier´ ıa Inform´ atica Desarrollo de un Plugin de FOCA para extraer cuentas de usuario en Redes Sociales. Autor: Iv´an Garc´ıa Hurtado Tutores: Amador Aparicio de la Fuente Mercedes Mart´ınez Gonz´alez 2 Resumen Este Trabajo de Fin de Grado consiste en el dise˜no y desarrollo de un plugin para FOCA. FOCA es una herramienta de extracci´on de metadatos presentes en documentos ofim´aticos accesibles desde Internet. El plugin aprovechar´a los servicios de inicio de sesi´on de distintas redes sociales para obtener informaci´on sobre las direcciones de correo electr´onico encontradas por FOCA. El plugin se ha construido en C# e integrado en FOCA mediante la API de plugins de la propia herramienta. La idea principal de este proyecto surge del concepto de Profiling (Perfilado de usuarios) en Ciberseguridad. La informaci´on sobre qu´e redes sociales est´a usando una persona es muy valiosa y est´a expuesta a Internet en la mayor´ıa de servicios. Actualmente existen herramientas que explotan esta fuga de informaci´on, pero ninguna utiliza el correo electr´onico, un dato que no puede ser considerado privado hoy en d´ıa, como punto de partida. 3 4 ´ Indice general 1. Introducci´on 13 1.1. Contexto ............................................. 13 1.2. Objetivos ............................................. 13 1.3. Alcance .............................................. 13 2. Plan de proyecto 15 2.1. Objetivosdelproyecto...................................... 15 2.2. Metodolog´ıadeproyecto..................................... 15 2.3. Fasesdelproyectoinicial..................................... 16 2.3.1. Diagrama de Gantt inicial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.4. Replanificaci´on del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 2.4.1. Diagrama de Gantt replanificado . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.5. Planderiesgos .......................................... 26 2.6. Costedelproyecto ........................................ 28 3. Preparaci´on del proyecto 29 3.1. FOCA............................................... 29 3.1.1. EsquemadeDatos .................................... 32 3.1.2. C´odigoFuente ...................................... 33 3.1.3. Instalaci´on ........................................ 36 3.1.4. APIdePlugins...................................... 37 3.2. SQLServer ............................................ 38 3.2.1. Instalaci´on ........................................ 39 3.2.2. SQL Server Management Studio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.3. Instalaci´on ........................................ 41 3.3. MicrosoftVisualStudio ..................................... 43 3.3.1. Instalaci´on ........................................ 44 3.4. Microsoft.NETFramework ................................... 45 3.5. Servicio de recuperaci´on de contrase˜na de Gmail . . . . . . . . . . . . . . . . . . . . . . . 45 3.5.1. Funcionamiento...................................... 45 3.5.2. Extracci´on de la informaci´on expuesta . . . . . . . . . . . . . . . . . . . . . . . . . 48 3.6. EstudiodeRedesSociales .................................... 54 3.7. TomadeRequisitos........................................ 55 3.7.1. RequisitosFuncionales.................................. 55 3.7.2. Requisitos no Funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55 3.7.3. Requisitos de Informaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 3.7.4. Requisitos de Seguridad y Privacidad . . . . . . . . . . . . . . . . . . . . . . . . . 56 5 4. An´alisis 57 4.1. Casosdeuso ........................................... 57 4.1.1. Diagrama de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57 4.1.2. CU1 - Comprobar redes sociales de un correo electr´onico . . . . . . . . . . . . . . . 58 4.1.3. CU2 - Mostrar historial de comprobaciones de redes sociales . . . . . . . . . . . . . 59 4.2. Modelodedominio........................................ 61 4.3. Diagrama de clases de an´alisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61 4.4. Realizaci´on de Casos de Uso de An´alisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 4.5. Flujodeinformaci´on....................................... 64 5. Dise˜no 65 5.1. Arquitectura ........................................... 65 5.2. Interfazdeusuario ........................................ 66 5.3. Diagrama de Clases de Dise˜no . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.4. Realizaci´on de los Casos de Uso de Dise˜no . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5. Persistencia de la informaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72 5.5.1. Basesdedatos ...................................... 72 5.5.2. Exportaci´onCSV..................................... 73 6. Implementaci´on 75 6.1. Extracci´on de informaci´on de redes sociales . . . . . . . . . . . . . . . . . . . . . . . . . . 75 6.1.1. Selenium ......................................... 75 6.2. Interfazgr´afica .......................................... 79 6.3. Accesoadatos .......................................... 81 7. Pruebas 83 7.1. Bater´ıadepruebas........................................ 83 8. Manual de instalaci´on y mantenimiento 91 8.1. Manualdeinstalaci´on ...................................... 91 8.2. Estructura de archivos del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 9. Conclusiones y trabajo futuro 97 9.1. Conclusiones ........................................... 97 9.2. Trabajofuturo .......................................... 97 Bibliograf´ıa 99 6 ´ Indice de figuras 2.1. Fases del modelo de desarrollo en cascada . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 2.2. Diagrama de Gantt - Preparaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.3. Diagrama de Gantt - An´alisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 2.4. DiagramadeGantt-Dise˜no................................... 19 2.5. Diagrama de Gantt - Implementaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 2.6. DiagramadeGantt-Pruebas.................................. 20 2.7. Diagrama de Gantt - Mantenimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.8. Diagrama de Gantt de la planificaci´on inicial . . . . . . . . . . . . . . . . . . . . . . . . . 21 2.9. Diagrama de Gantt - An´alisis (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.10. Diagrama de Gantt - Dise˜no (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 2.11. Diagrama de Gantt - Implementaci´on (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 2.12. Diagrama de Gantt - Pruebas (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.13. Diagrama de Gantt - Mantenimiento (II) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 2.14. Diagrama de Gantt de la replanificaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 3.1. Logotipo de la herramienta FOCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 3.2. Metadatos est´andar de una imagen JPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 3.3. Ejemplo de extracci´on de metadatos de documentos en un dominio . . . . . . . . . . . . . 30 3.4. Ejemplodean´alisisdered.................................... 31 3.5. Esquema de la base de datos de FOCA (I). Obtenido con SSMS (ver apartado 3.2.2). . . . 33 3.6. Esquema de la base de datos de FOCA (II). Obtenido con SSMS (ver apartado 3.2.2). . . 33 3.7. Entidades y controladores de Entity Framework . . . . . . . . . . . . . . . . . . . . . . . . 34 3.8. Contenido de ./SearcherCore ................................. 35 3.9. Contenido de ./MetadataExtractCore ............................. 36 3.10. Contenido de ./FOCA/Analysis ................................. 36 3.11. Ejemplo de plugin FOCA (Social Scan) en el men´u contextual . . . . . . . . . . . . . . . . 38 3.12. Aplicaciones y Caracter´ısticas - Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.13. Instalador de SQL Server 2016 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.14. Conexi´on a una instancia - SQL Server Management Studio . . . . . . . . . . . . . . . . . 41 3.15. Interfaz de SQL Server Management Studio. . . . . . . . . . . . . . . . . . . . . . . . . . . 41 3.16. Localizaci´on del ejecutable de SQL Server Management Studio . . . . . . . . . . . . . . . 42 3.17. Herramienta de edici´on del Registro de Windows (regedit).................. 43 3.18. Eliminar una clave - regedit ................................... 43 3.19. Instalaci´on de Visual Studio 2019 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 3.20.Iniciodesesi´ondeGmail .................................... 46 3.21. Challenges con informaci´on personal de los usuarios . . . . . . . . . . . . . . . . . . . . . 47 3.22. Peticiones HTTP realizadas al iniciar sesi´on. . . . . . . . . . . . . . . . . . . . . . . . . . 47 7 Desarrollo de un plugin que utilice las direcciones de correo electr´onico extra´ıdas por FOCA para comprobar si tienen una cuenta en ciertas redes sociales y servicios. Redacci´on de un manual del programador que describa el proceso de instalaci´on y mantenimiento del plugin desarrollado. Redacci´on de una memoria que recopile el trabajo realizado. 14 Cap´ıtulo 2 Plan de proyecto En este cap´ıtulo se explicar´a la planificaci´on que se ha realizado del proyecto: objetivos, metodolog´ıas utilizadas y una breve descripci´on de sus fases y tareas correspondientes. Primero se desglosar´a la planificaci´on del proyecto inicial para despu´es explicar la nueva planificaci´on causada por cambio de objetivos. 2.1. Objetivos del proyecto El objetivo del proyecto es el desarrollo de un plugin para la herramienta FOCA que determine en qu´e redes sociales aparece una cuenta de correo electr´onico extra´ıda de los documentos ofim´aticos encontrados por FOCA. Inicialmente el objetivo era utilizar el servicio de recuperaci´on de contrase˜na de Gmail para obtener informaci´on personal de un correo electr´onico, pero durante el desarrollo se encontr´o un problema que llev´o a un cambio de los objetivos (y posterior replanificaci´on) del proyecto. 2.2. Metodolog´ıa de proyecto En esta secci´on se explicar´a qu´e metodolog´ıa se ha seguido durante la planificaci´on y el desarrollo del proyecto. Se opt´o por seguir una ”metodolog´ıa de desarrollo en cascada” [1], caracterizada por ser un modelo de desarrollo secuencial en el que los resultados de una fase son utilizados en la siguiente. Generalmente, los proyectos dirigidos mediante una metodolog´ıa en cascada tienen la siguiente estructura: 15 Figura 2.1: Fases del modelo de desarrollo en cascada Entonces siguiendo la estructura general del modelo, este proyecto tendr´a las siguientes fases: (Preparaci´on): Fase precursora del proyecto. En ella se realiza la planificaci´on de cada fase y sus tareas, adem´as de preparar todo el material necesario para su realizaci´on. An´alisis: En esta fase se define la funcionalidad que ofrecer´a el plugin. Aqu´ı se incluyen el an´alisis de requisitos, casos de uso, modelo de dominio y modelo Entidad-Relaci´on. Dise˜no: En esta fase se utilizan los modelos de informaci´on generados en la fase de An´alisis para definir los elementos software necesarios en la implementaci´on, as´ı como su estructura. Implementaci´on: Programaci´on del software. En este caso trata sobre la construcci´on del plugin. Pruebas y verificaci´on: Dise˜no y puesta en marcha de casos de prueba que verifiquen el cumplimiento de los requisitos y casos de uso definidos en la fase de an´alisis. Mantenimiento: Correcci´on de errores encontrados tras el despliegue y/o implementaci´on de mejoras que puedan surgir en un futuro. En este caso se realizar´a un manual donde se explicar´a detalladamente el proceso de instalaci´on y utilizaci´on del plugin, as´ı como la estructura del c´odigo fuente para su mejor comprensi´on. Se ha escogido esta metodolog´ıa debido a que, al ser una metodolog´ıa secuencial y disponer de fases bien diferenciadas, permite una planificaci´on y organizaci´on del proyecto m´as clara. Esto permite realizar una estimaci´on de los costes del proyecto m´as exacta. Adem´as, debido a la comprobaci´on de lo desarrollado en cada fase, tambi´en permite evaluar el progreso del proyecto de forma m´as precisa. 2.3. Fases del proyecto inicial En este apartado se explica el desglose en fases y tareas, y la temporalizaci´on del proyecto inicial. De cada tarea se mencionan sus predecesoras, duraci´on estimada y una breve descripci´on. 16 Preparaci´on del proyecto En esta fase se realiza la planificaci´on del proyecto, temporalizaci´on de cada fase y sus tareas, y el estudio e instalaci´on del material y/o herramientas necesarias para su realizaci´on. ID: 01 Planificaci´on del proyecto Predecesoras: - Duraci´on: 5 d´ıas Planificaci´on y temporalizaci´on de las fases y sus tareas, elaboraci´on de los planes de riesgo y an´alisis de coste del proyecto ID: 02 Estudio de FOCA Predecesoras: 01 Duraci´on: 7 d´ıas Instalaci´on y puesta en marcha de FOCA (y sus dependencias). Estudio de su documentaci´on, esquema de datos y API de plugins. ID: 03 Pruebas de uso de FOCA Predecesoras: 02 Duraci´on: 3 d´ıas Realizaci´on de pruebas con la herramienta para familiarizarse con ella ID: 04 Estudio del servicio de Gmail Predecesoras: 03 Duraci´on: 3 d´ıas Estudio del funcionamiento del servicio de recuperaci´on de contrase˜na de Gmail, qu´e datos expone y c´omo extraerlos. ID: 05 Memoria - Cap´ıtulos 1, 2 y 3 Predecesoras: 04 Duraci´on: 2 d´ıas Preparaci´on de los cap´ıtulos 1, 2 y 3 de la memoria (correspondientes a la Introducci´on, Plan de Proyecto y Preparaci´on del Proyecto, respectivamente). Figura 2.2: Diagrama de Gantt - Preparaci´on An´alisis En esta fase del proyecto se especifica la funcionalidad que debe ofrecer el plugin. Tambi´en se incluye el estudio de las herramientas necesarias para cumplir con dicha funcionalidad. 17 ID: 06 An´alisis de requisitos Predecesoras: 05 Duraci´on: 2 d´ıas Obtenci´on de requisitos en base a los objetivos del proyecto. ID: 07 Estudio de herramientas Predecesoras: 06 Duraci´on: 8 d´ıas Estudio de las herramientas y librer´ıas disponibles para determinar cu´al cumple mejor con los requisitos extra´ıdos. ID: 08 An´alisis de Casos de Uso Predecesoras: 07 Duraci´on: 2 d´ıas Identificaci´on y desarrollo de los distintos Casos de Uso a partir de los requisitos. ID: 09 Modelo de Dominio Predecesoras: 08 Duraci´on: 2 d´ıas An´alisis de los requisitos y casos de uso para extraer las clases de an´alisis necesarias y formar los diagramas pertinentes. ID: 10 Memoria - Cap´ıtulo 4 Predecesoras: 09 Duraci´on: 1 d´ıa Preparaci´on del cap´ıtulo 4 de la memoria (An´alisis). Figura 2.3: Diagrama de Gantt - An´alisis Dise˜no Se especificar´a la arquitectura software a utilizar, dise˜no de la interfaz y desarrollo de los casos de uso en dise˜no. ID: 11 Arquitectura del plugin Predecesoras: 10 Duraci´on: 2 d´ıas Especificaci´on de la arquitectura software a utilizar 18 ID: 12 Dise˜no de la interfaz Predecesoras: 11 Duraci´on: 2 d´ıas Dise˜no de la interfaz de usuario del plugin bas´andose en los requisitos y en los casos de uso. ID: 13 Casos de Uso en Dise˜no Predecesoras: 12 Duraci´on: 3 d´ıas Desarrollar los Casos de Uso en an´alisis y realizar los correspondientes diagramas de secuencia en dise˜no. ID: 14 Diagrama de clases de Dise˜no Predecesoras: 13 Duraci´on: 1 d´ıa A partir de las clases de dise˜no, realizar el diagrama de clases correspondiente. ID: 15 Memoria - Cap´ıtulo 5 Predecesoras: 14 Duraci´on: 1 d´ıa Preparaci´on del cap´ıtulo 5 de la memoria (Dise˜no). Figura 2.4: Diagrama de Gantt - Dise˜no Implementaci´on En esta fase se aplicar´an los an´alisis realizados en las anteriores fases para implementar la funcionalidad del plugin. ID: 16 Esquema de Datos Predecesoras: 15 Duraci´on: 3 d´ıas A partir de la informaci´on obtenida en la fase de dise˜no, implementar los esquemas de datos necesarios en la base de datos. ID: 17 M´odulo de Acceso a Datos Predecesoras: 16 Duraci´on: 7 d´ıas Implementar los m´etodos de conexi´on e interacci´on con la base de datos. 19 ID: 18 Interfaz gr´afica Predecesoras: 17 Duraci´on: 5 d´ıas Implementaci´on del dise˜no de interfaz gr´afica realizado en la fase anterior. ID: 19 M´odulo de Extracci´on Predecesoras: 18 Duraci´on: 14 d´ıas Implementaci´on de la funcionalidad encargada de extraer la informaci´on del servicio de Gmail. ID: 20 Memoria - Cap´ıtulo 6 Predecesoras: 19 Duraci´on: 1 d´ıa Preparaci´on del cap´ıtulo 6 de la memoria (Implementaci´on). Figura 2.5: Diagrama de Gantt - Implementaci´on Pruebas En esta fase se comprueba que lo implementado en la fase anterior cumple con los requisitos y los casos de uso. ID: 21 Realizaci´on de pruebas Predecesoras: 20 Duraci´on: 7 d´ıas Realizaci´on de pruebas de funcionalidad del plugin y correcci´on de errores ID: 22 Memoria - Cap´ıtulo 7 Predecesoras: 21 Duraci´on: 1 d´ıa Preparaci´on del cap´ıtulo 7 de la memoria (Pruebas) Figura 2.6: Diagrama de Gantt - Pruebas 20 Mantenimiento Esta fase est´a dedicada a solucionar errores y/o implementar mejoras propuestas por el cliente. En este caso se realizar´a un manual del programador. ID: 23 Manual del programador Predecesoras: 22 Duraci´on: 5 d´ıas Redacci´on de un documento que explique la instalaci´on, funcionamiento y estructura del c´odigo fuente para facilitar la comprensi´on y mantenimiento del plugin a terceros. ID: 24 Memoria - Cap´ıtulos 8 y 9 Predecesoras: 23 Duraci´on: 3 d´ıas Preparaci´on de los cap´ıtulos 8 y 9 de la memoria (Mantenimiento y Conclusiones). Figura 2.7: Diagrama de Gantt - Mantenimiento 2.3.1. Diagrama de Gantt inicial El diagrama de Gantt resultante de la planificaci´on del proyecto inicial. Muestra el desglose en tareas de cada fase y su temporalizaci´on. Iniciando el 18 de Enero, la fecha de finalizaci´on estimada es el 10 de Junio. Figura 2.8: Diagrama de Gantt de la planificaci´on inicial 21 2.4. Replanificaci´on del proyecto Como se ha mencionado anteriormente, el proyecto sufri´o un cambio de objetivos que provoc´o la necesidad de volver a planificar el proyecto desde el principio. La causa del cambio de objetivos fue un problema que surgi´o durante la fase de Implementaci´on. Al programar el m´odulo de extracci´on (encargado de extraer la informaci´on del servicio de Gmail) la herramienta que se estaba utilizando no consegu´ıa acceder al servicio debido al sistema de detecci´on de software automatizado que Google tiene implementado. Tras probar con varias alternativas y no obtener resultados consistentes (el n´umero de veces que era bloqueado era demasiado alto como para ser ´util) se decidi´o cambiar los objetivos del proyecto a los mencionados en la introducci´on. En esta secci´on se mostrar´a la nueva planificaci´on del proyecto, partiendo de nuevo desde la fase de An´alisis (no es necesario repetir la fase de planificaci´on pues los recursos utilizados para el antiguo proyecto tambi´en son utilizados en el nuevo). An´alisis (II) Definidos los nuevos objetivos, hay que repetir todo el proceso de desarrollo. En esta fase se repite el proceso de an´alisis funcional, desde la toma de requisitos hasta el modelado de clases. ID: 01 Selecci´on de redes sociales Predecesoras: - Duraci´on: 1 d´ıa Se realiza una selecci´on de redes sociales de entre las disponibles, bas´andose en su popularidad y utilidad ID: 02 Redefinici´on de requisitos Predecesoras: 01 Duraci´on: 1 d´ıa Se vuelve a realizar la toma de requisitos en funci´on de los nuevos objetivos. ID: 03 Redefinici´on de Casos de Uso Predecesoras: 02 Duraci´on: 1 d´ıa Bas´andose en los nuevos requisitos, se identifican y desarrollan los nuevos casos de uso ID: 04 Modelo de Dominio Predecesoras: 03 Duraci´on: 1 d´ıa Se identifican las nuevas clases de an´alisis ID: 05 Memoria - Cap´ıtulo 4 Predecesoras: 04 Duraci´on: 1 d´ıa Preparaci´on del cap´ıtulo 4 de la memoria (An´alisis) 22 Figura 2.9: Diagrama de Gantt - An´alisis (II) Dise˜no (II) Utilizando los datos sacados en la fase de An´alisis, se dise˜nar´a una interfaz acorde y se desarrollar´an los casos de uso en dise˜no. ID: 06 Arquitectura del plugin Predecesoras: 05 Duraci´on: 2 d´ıas Especificaci´on de la arquitectura software a utilizar ID: 07 Dise˜no de la interfaz Predecesoras: 06 Duraci´on: 2 d´ıas Dise˜no de la interfaz de usuario del plugin bas´andose en los requisitos y en los casos de uso. ID: 08 Casos de Uso en Dise˜no Predecesoras: 07 Duraci´on: 3 d´ıas Desarrollar los Casos de Uso en dise˜no y realizar los correspondientes diagramas de secuencia en dise˜no. ID: 09 Diagrama de clases de Dise˜no Predecesoras: 08 Duraci´on: 1 d´ıa A partir de las clases de dise˜no, realizar el diagrama de clases correspondiente. ID: 10 Memoria - Cap´ıtulo 5 Predecesoras: 09 Duraci´on: 1 d´ıa Preparaci´on del cap´ıtulo 5 de la memoria (Dise˜no) Figura 2.10: Diagrama de Gantt - Dise˜no (II) 23 modificaci´on de un archivo, creador del archivo, permisos...) o fuera (g´eneros literarios de un libro, fechas de publicaci´on, marca de un coche...). Estos datos se utilizan principalmente para facilitar la clasificaci´on de los objetos a los que describen. Figura 3.2: Metadatos est´andar de una imagen JPEG La fuerza de FOCA como herramienta yace en la capacidad que tiene de extraer estos metadatos de los documentos y posteriormente analizarlos para relacionarlos entre s´ı y obtener una descripci´on general del dominio analizado en base a la informaci´on encontrada. Figura 3.3: Ejemplo de extracci´on de metadatos de documentos en un dominio Se pueden clasificar las funciones que ofrece esta herramienta en: B´usqueda de documentos. FOCA ofrece un conjunto de mecanismos de b´usqueda automatizada de servidores dentro de un dominio, permitiendo recorrer recursivamente la red objetivo. Actualmente, 30 utiliza de las siguientes t´ecnicas: • B´usqueda Web: Descubrimiento de servidores en los servicios de b´usqueda soportados (Google, Bing, DuckDuckGo) a partir de las URLs asociadas al dominio principal. • B´usqueda DNS: Descubrimiento de servidores a partir de consultas a los registros DNS principales: NS (Name server record, un registro que indica qu´e servidor DNS consultar para resolver un nombre de dominio), MX (Mail Exchange record, indica qu´e servidores DNS se utilizan en el encaminamiento de correos electr´onicos) y SPF (Sender Policy Framework record, un registro que indica qu´e servidores de correo electr´onico est´an autorizados a enviar correos en nombre del dominio correspondiente). • Resoluci´on de Hosts: Resolver los nombres de host encontrados en los DNS para obtener sus direcciones IP. • Esc´aner de registros PTR (tambi´en llamado consulta DNS inversa). Consultar los registros PTR para obtener los nombres de host de las IPs encontradas. • B´usquedas de diccionario. Usar nombres utilizados com´unmente contra los servidores de DNS para obtener m´as servidores del dominio. • Predicci´on DNS. En aquellos casos en los que se sospeche que los nombres de dominio siguen un patr´on. •Robtex. Un servicio online de an´alisis de dominios y direcciones IP. Extracci´on de metadatos. Permite extraer la informaci´on de los siguientes tipos de archivo: •PDF, INDDD (formato de estilo de documentos creado por Adobe InDesign). •Archivos de Office, OpenOffice y WordPerfect. •Im´agenes (metadatos EXIF). •Archivos misc´elaneos (XMP, OLE, RPD...) An´alisis de metadatos. Procesado de los metadatos para formar una red de dispositivos encontrados en el dominio y su jerarqu´ıa. Figura 3.4: Ejemplo de an´alisis de red 31 3.1.1. Esquema de Datos Respecto a su base de datos, FOCA toma una decisi´on de dise˜no muy caracter´ıstica. Normalmente las aplicaciones manejan su propia instancia de la base de datos de manera autom´atica. En el caso de FOCA, se debe proporcionar una instancia ya creada de antemano. Esto permite a FOCA poder interactuar con bases de datos ya creadas anteriormente (ya sean locales como en red) o compartir instancias entre varias aplicaciones de FOCA. Esta herramienta utiliza SQL Server como Sistema Gestor de Base de Datos, en espec´ıfico una instancia ya configurada. Dentro de esa instancia FOCA genera su propio esquema de datos de manera autom´atica (si no se ha generado anteriormente). La interacci´on con la base de datos se realiza mediante Entity Framework. La parte del modelo de datos que nos interesa es todo lo relacionado con el almacenamiento de metadatos, en espec´ıfico los correos electr´onicos, de cara al plugin desarrollado en este proyecto. Teniendo el connection string de la instancia que se est´a utilizando, es posible consultar la informaci´on almacenada. Respecto a este modelo de datos, los metadatos guardados se subdividen en 2 grupos, representados por sus respectivas tablas: ComputersItems yMetaDatas. Se explicar´a cada grupo por separado incluyendo el diagrama Entidad-Relaci´on de cada parte (por facilitar la visualizaci´on de los diagramas, ya que el general es demasiado amplio) generado por SQL Server Management Studio (ver apartado 3.2.2). En la tabla ComputersItems se referencian aquellos metadatos sobre los equipos encontrados (indicados con colores en la figura 3.5), estos son: Direcciones IPs (tabla IPsItems, en naranja). Usuarios (tabla UserItems, en verde). Contrase˜nas (tabla PasswordItems, en rosa). Dominios (tabla DomainsItems, en rojo). Impresoras (tabla PrintersItems, en amarillo). Rutas (tabla PathItems, en azul). Descripciones (tabla DescriptionItems, en morado). En la tabla MetaDatas se recoge la informaci´on general sobre cada documento ofim´atico encontrado. En la tabla MetaExtractors se recogen los metadatos encontrados para cada documento guardado en la tabla MetaDatas, divididos por categor´ıa de metadato. La informaci´on espec´ıfica de cada categor´ıa de metadato est´a guardada en su respectiva tabla (ver figura 3.6). Estas son: Usuarios (tabla UserItems, en rojo). Impresoras (tabla PrintersItems, en naranja). Correos electr´onicos (tabla EmailsItems, en amarillo). 32 Contrase˜nas (tabla PasswordItems, en morado). Historiales (tabla HistoryItems, en azul). Servidores (tabla ServerItems, en verde). Informaci´on de versiones (tabla OldVersionItems, en rosa). Figura 3.5: Esquema de la base de datos de FOCA (I). Obtenido con SSMS (ver apartado 3.2.2). Figura 3.6: Esquema de la base de datos de FOCA (II). Obtenido con SSMS (ver apartado 3.2.2). Se puede apreciar que hay categor´ıas referenciadas tanto por ComputersItems como por MetaExtractors, esto es debido a que existen metadatos extra´ıdos de documentos ofim´aticos que se pueden vincular a equipos inform´aticos encontrados (usuarios, impresoras y contrase˜nas) durante el proceso de an´alisis de metadatos. 3.1.2. C´odigo Fuente En este apartado se explicar´a la estructura del c´odigo fuente en base a la funci´on que desempe˜na. Este c´odigo est´a disponible en su repositorio GitHub [8]. 33 Funcionalmente se puede dividir la aplicaci´on en 5 bloques independientes: Acceso a datos. En este bloque se incluye toda la interacci´on con la base de datos. B´usqueda de subdominios. Este bloque se encarga del descubrimiento de nuevos subdominios bajo el dominio ra´ız y descargar sus documentos. Extracci´on y an´alisis de metadatos. Este bloque se encarga de la extracci´on de los metadatos en los documentos encontrados y su posterior an´alisis para formar la red de hosts del dominio ra´ız. Utilidades. Aqu´ı se incluye el resto de recursos de la aplicaci´on que no caen en las categor´ıas anteriores, como por ejemplo interfaces, soporte de sistemas operativos, plugins, recursos visuales, etc. Acceso a datos Para implementar la funcionalidad de acceso a datos, FOCA utiliza Entity Framework. Entity Framework es un Object-Relational Mapper (ORM) disponible para Microsoft ADO.NET (incluido en .NET Framework). Un ORM permite gestionar una base de datos relacional utilizando la orientaci´on a objetos de un lenguaje de programaci´on (en el caso de Entity Framework, C#). Proporciona una capa de abstracci´on sobre la base de datos utilizada, ahorrando a la aplicaci´on el tener que gestionar los detalles de la conexi´on, consultas, etc. En el caso de FOCA, el c´odigo fuente dedicado a la gesti´on de la informaci´on persistente se encuentra en ./FOCA/Database . Aqu´ı se definen las entidades relacionales implementadas ( ./FOCA/Database/ Entities ), y las consultas que la aplicaci´on puede realizar ( ./FOCA/Database/Controllers ). Juntas definen la capa de abstracci´on implementada por Entity Framework. Figura 3.7: Entidades y controladores de Entity Framework B´usqueda de documentos Respecto a la b´usqueda de subdominios y documentos, el c´odigo fuente se encuentra en un proyecto separado a FOCA, en ./SearcherCore . Este proyecto se encarga de realizar las b´usquedas de documentos 34 en los motores de b´usqueda soportados. Estos motores de b´usqueda disponen de sus propias APIs que permiten a distintas aplicaciones consumir sus servicios. Adem´as de consumir esas APIs, FOCA tambi´en realiza una b´usqueda convencional manipulando los par´ametros GET de las URL de los buscadores y utilizando web scraping. Figura 3.8: Contenido de ./SearcherCore Extracci´on y an´alisis de metadatos En el caso de la extracci´on de metadatos, se encuentra tambi´en en un proyecto separado, en ./MetadataExtractCore . Es el encargado de la extracci´on de los metadatos en cada documento soportado (mencionados anteriormente). Cada extensi´on soportada dispone de su propia clase en ./ MetadataExtractCore/Metadata que maneja la extracci´on de sus metadatos. Tambi´en est´an recogidos en clases los distintos tipos de metadatos que FOCA extrae de los documentos (en ./MetadataExtractCore/ Diagrams). 35 Figura 3.9: Contenido de ./MetadataExtractCore La parte de an´alisis de metadatos se encuentra en ./FOCA/Analysis e incluye toda la funcionalidad para correlacionar los metadatos extra´ıdos entre s´ı para obtener m´as informaci´on sobre el dominio (Fingerprinting, en Ciberseguridad). Tambi´en incluye el an´alisis de malware de DIARIO. Figura 3.10: Contenido de ./FOCA/Analysis 3.1.3. Instalaci´on Primero, hay que instalar las dependencias de la herramienta. FOCA esta construida sobre .NET Framework (versi´on 4.7.1), Microsoft Visual C++ (2010 o mayor) y utiliza SQL Server (2014 o mayor) como SGBD. El proceso de instalaci´on de estas dependencias es descargarse los instaladores de las p´aginas oficiales y ejecutarlos, pero pueden ocurrir problemas durante la instalaci´on debido a que la mayor´ıa de usuarios ya tienen alguna versi´on de estos instalada, instalaciones defectuosas, archivos corruptos, etc (Los posibles errores de instalaci´on est´an explicados en los apartados respectivos de cada dependencia). El proceso de instalaci´on de FOCA en s´ı es bastante sencillo. Es un proyecto open source disponible en el repositorio GitHub de ElevenPaths [8], por lo que simplemente hay que clonar el repositorio, compilar 36 el c´odigo fuente (ya viene con los binarios compilados, pero es recomendable recompilar el proyecto localmente) y ejecutarlo. El repositorio tambi´en dispone de la soluci´on de Visual Studio, por lo que para la compilaci´on y desarrollo es muy recomendable usar este IDE. Es recomendable tambi´en recompilar el proyecto localmente para asegurar la compatibilidad entre las distintas herramientas y m´odulos utilizados por FOCA.. Al iniciar la herramienta por primera vez, FOCA buscar´a una instancia local de SQL Server local en el sistema. En caso de no encontrarla, el usuario tendr´a que proveer el connection string de una instancia SQL Server para que FOCA cree su esquema de datos en ella. El connection string proporcionado ser´a utilizado en las siguientes ejecuciones de la herramienta por defecto (guardado en ./bin/Release/FOCA.exe.Config ). 3.1.4. API de Plugins La API de Plugins es un servicio ofrecido por FOCA que permite la ampliaci´on de funcionalidad de la herramienta mediante plugins. Estos plugins son librer´ıas de enlace din´amico (DLL) que pueden ser a˜nadidas a la herramienta en tiempo de ejecuci´on. En el repositorio de FOCA vienen incluidos el c´odigo fuente de la API (con su soluci´on de Visual Studio), varios ejemplos de plugins compilados e incluso ejemplos de c´odigo fuente para facilitar el desarrollo de los mismos. La integraci´on con FOCA es manejada por la API de varias maneras [9]: Interfaz de usuario. La API expone un componente personalizado de Windows Forms que el plugin podr´a rellenar con los elementos de su interfaz gr´afica. Este panel ser´a mostrado por FOCA en el apartado de plugins de la interfaz. Tambi´en permite mostrar la interfaz en una ventana separada de FOCA. Importar objetos. La API tambi´en permite enviar a FOCA datos encontrados por el plugin para analizarlos. Eventos. Dispone de un sistema de eventos a los que los plugins pueden suscribirse. Esto es ´util en el caso de querer ampliar la funcionalidad de FOCA en el manejo de estos eventos. La API define los siguientes elementos importables: PluginPanel: El panel con la interfaz del plugin mencionado anteriormente. PluginToolStripMenuItem: Elemento en el desplegable de Plugins de FOCA para cargar el panel. ContextMenus: Para a˜nadir elementos a distintos men´us contextuales de la aplicaci´on. Incluye endpoints para a˜nadir a cada men´u por separado y uno global para a˜nadir el elemento a todos los men´us soportados. ImportElements: Los distintos tipos de dato que est´an soportados por FOCA junto con los endpoints para importarlos. Son: •Domain •IP •URL •Association Domain IP 37 •Computer •Project •AddBackUp •AddProxy •AddUser •AddZoneTransfer Figura 3.11: Ejemplo de plugin FOCA (Social Scan) en el men´u contextual Los plugins tambi´en pueden suscribirse a determinados eventos mantenidos por FOCA para recibir informaci´on cuando ocurren. Para suscribirse, hay que crear una funci´on void con nombre igual al del evento deseado dentro de la clase Plugin. Los eventos soportados son: OnNewDomain OnNewURL OnNewIP OnNewProject OnNewRelation OnNewNetrange 3.2. SQL Server SQL Server es un Gestor de Bases de Datos Relacional (RDBMS) desarrollado por Microsoft. Microsoft da soporte a muchos servicios de SQL Server (v´ıa Microsoft Azure, On-Premise, para IoT, para desarrollo...), pero en este proyecto se utilizar´a la versi´on local. SQL Server 2016 Express es una versi´on de SQL Server empresarial gratuita dedicada a aplicaciones de peque˜na envergadura que se instala localmente. Como FOCA soporta versiones a partir de SQL Server 2014, se decidi´o utilizar la versi´on 2016. En el caso 38 de no estar seguro de que opci´on escoger, en la p´agina de SQL Server de Microsoft existe un ayudante que guiar´a a los usuarios por el proceso de selecci´on. Cuadro 3.1: Requisitos t´ecnicos del sistema - SQL Server 2016 Express [12] Caracter´ıstica M´ınimo Recomendado Sistema Operativo Windows 8 o superior Windows 10 o superior Disco Duro 6 GB libres 8 GB libres Memoria RAM 512 MB 1 GB Velocidad de procesador 1.4 GHz 2 GHz Tipo de procesador x64 x64 .NET Framework Versi´on 4.6 Versi´on 4.6 3.2.1. Instalaci´on Para la instalaci´on y ejecuci´on de FOCA, es necesario tener al menos la versi´on de SQL Server 2014. Para este proyecto se decidi´o utilizar la versi´on SQL Server 2016 Express. El primer paso en la instalaci´on es comprobar si existe una versi´on ya instalada, y si no es la que se requiere, desinstalarla [16]. Tambi´en puede ocurrir que la versi´on instalada de SQL Server est´e corrupta, en cuyo caso es recomendable desinstalar. Esto se puede realizar desde Aplicaciones y Caracter´ısticas, en el Panel de Control de Windows. Figura 3.12: Aplicaciones y Caracter´ısticas - Windows Despu´es de esto, se instala la nueva versi´on utilizando el instalador descargado de la p´agina oficial [13]. 39 Este servicio est´a basado en un mecanismo de challenges v´ıa HTTP. El proceso de recuperaci´on consta de un conjunto de preguntas de seguridad sobre tu cuenta sucedi´endose una detr´as de otra si no consigues responder. Figura 3.20: Inicio de sesi´on de Gmail Este conjunto de preguntas es variable para cada correo electr´onico pues depende de la cantidad de informaci´on personal contenida en la cuenta, y es esto lo que se pretende explotar con este proyecto. Este servicio depende en su totalidad de la cantidad de informaci´on personal que muestre al usuario para poder recuperar su cuenta. Mostrar muy poca informaci´on implicar´ıa no poder autenticar al usuario, y demasiada informaci´on ser´ıa una filtraci´on de datos personales demasiado grande. De la informaci´on expuesta, se recoger´an: Parte del correo de recuperaci´on de la cuenta (solo muestran unos pocos caracteres) Estado de la cuenta (Si existe, ha sido desactivada o ha sido eliminada) Parte de los n´umeros de tel´efono registrados en la cuenta (solo muestran unos pocos d´ıgitos) Dispositivos vinculados a la cuenta. 46 Figura 3.21: Challenges con informaci´on personal de los usuarios Sobre la implementaci´on t´ecnica del servicio, es un flujo de vistas HTML basado en cookies ytokens de sesi´on. El proceso comienza en el servicio de inicio de sesi´on, tras introducir un correo electr´onico y especificar que has olvidado la contrase˜na. En ese momento se genera un token de sesi´on que identificar´a el intento de recuperaci´on de contrase˜na, y ser´a utilizado durante todo el proceso (v´ıa par´ametros GET de las peticiones HTTP). Tras eso, iniciar´a el flujo de challenges, cada uno recibiendo todas las cookies del anterior y envi´andoselas al siguiente. Entre las cookies utilizadas por el servicio de recuperaci´on tambi´en se encuentran otras de servicios de Google como Google Analitics. Al final, si no se consigui´o superar ning´un challenge el flujo finaliza rechazando la solicitud de recuperaci´on (por supuesto, al superar alguno de ellos se procede a la recuperaci´on de la contrase˜na). Figura 3.22: Peticiones HTTP realizadas al iniciar sesi´on. 47 Figura 3.23: Peticiones HTTP realizadas al iniciar los challenges. Debido a este intercambio de informaci´on tan denso, se decidi´o utilizar herramientas de scraping de alto nivel que manejan el tr´afico de cookies y par´ametros autom´aticamente. 3.5.2. Extracci´on de la informaci´on expuesta La funci´on clave que debe ofrecer el plugin es la capacidad de extraer la informaci´on personal expuesta en servicio de recuperaci´on de contrase˜na de Gmail. Como se ha explicado anteriormente, es un servicio Web basado en challenges utilizados para verificar la identidad de los usuarios. Estas preguntas de seguridad exponen informaci´on sobre las cuentas de usuario para facilitar la autenticaci´on del mismo (por ejemplo, envi´andote un SMS al n´umero de tel´efono vinculado a la cuenta). Al ser un servicio Web dedicado completamente a la interacci´on con usuarios reales (no est´a orientado a ser consumido por aplicaciones como otros servicios de Google como la b´usqueda de Google, que dispone de una API), existen 2 maneras de interactuar con el y obtener la informaci´on que muestra de manera autom´atica: Web scraping. Este es el enfoque est´andar a la hora de recoger informaci´on de una p´agina web. Enviar una petici´on HTTP al servidor Web destino, y procesar el HTML recibido. Herramientas de manejo de Headless Browsers. Como su propio nombre indica, son herramientas que utilizan navegadores sin interfaz gr´afica, dedicados a ser utilizados por programas y no por usuarios finales. Respecto al Web scraping, es bastante utilizado en la mayor´ıa de casos de uso que necesitan obtener informaci´on de un sitio Web, en especial si ese servicio no dispone de una API con la que poder comunicarse. Adem´as, es una operaci´on bastante barata en t´erminos de recursos y rendimiento (es s´olo una petici´on HTTP). Pero esto conlleva una serie de desventajas. Al ser simplemente una petici´on, no realiza ning´un tipo de ejecuci´on del HTML recibido. Esto no es ning´un problema si la informaci´on requerida se encuentra en el HTML base de la p´agina, pero en bastantes ocasiones no es el caso. Con la propagaci´on de las SPAs (Single-page applications) y las librer´ıas de peticiones HTTP as´ıncronas (como AJAX [31] y el resto de herramientas construidas encima), la informaci´on no suele estar en el HTTP base (que es lo que env´ıa el servidor Web a los navegadores y por extensi´on, a nuestro programa) sino que la env´ıa el servidor en sucesivas peticiones realizadas tras cargar la p´agina. Esto se consigue incluyendo en el HTML base el c´odigo para lanzar el resto de peticiones utilizando una librer´ıa como AJAX. Entonces un navegador, que 48 adem´as de recibir el HTML lo ejecuta, lanza las peticiones sucesivas y obtiene la informaci´on. Utilizando Web scraping, se recibe el HTML pero no se ejecuta, impidiendo obtener la informaci´on deseada. Una manera de solucionar esto ser´ıa que el programa maneje estas peticiones sucesivas por su cuenta, lo cual lleva a la siguiente desventaja: la complejidad. Existen muchos servicios Web que intercambian una gran cantidad de informaci´on con sus respectivos servidores, ya sea mediante peticiones as´ıncronas, par´ametros en las peticiones, cookies, etc. Las librer´ıas de scraping convencionales no manejan ninguno de estos intercambios, relegando la responsabilidad en los programas que las utilicen. Este es el caso del servicio de Gmail, cuyo flujo de challenges est´a basado en el intercambio de cookies ytokens, haciendo esta alternativa inviable. Los Headless Browsers ofrecen las mismas posibilidades que el scraping sin sufrir de tales desventajas. Como su propio nombre indica, son herramientas que utilizan navegadores sin interfaz gr´afica de usuario, pues est´an destinados a ser manejados en las aplicaciones mediante controladores. Al ser navegadores completamente funcionales, son capaces de ejecutar el c´odigo HTML que reciben y manejar el intercambio de cookies y par´ametros de las peticiones, con la desventaja de ser m´as costosos a nivel de recursos y rendimiento. Existen disponibles varias librer´ıas de Headless browsers disponibles para .NET, entre ellas Selenium y Puppeteer, que son las utilizadas en este proyecto. Cambio de objetivos El problema que caus´o el cambio de objetivos, fue la seguridad contra software automatizado espec´ıfica del servicio de inicio de sesi´on de Google. Antes de iniciar el proceso de recuperaci´on de contrase˜na, tras introducir una direcci´on de correo electr´onico, el servicio comprueba si quien est´a interactuando con el servicio es un usuario final (una persona, lo que se espera) o se trata de software automatizado, en cuyo caso se rechaza inmediatamente. 49 Figura 3.24: Pantalla de rechazo de bots de Google En los siguientes apartados se describir´an los intentos de evadir este bloqueo de seguridad. Selenium Selenium es un entorno de software testing para aplicaciones Web [32]. Permite la automatizaci´on de casos de prueba utilizando varios navegadores a trav´es de sus respectivos controladores. Aunque est´e dedicado al testing, puede ser utilizado para extraer informaci´on de sitios web gracias a las funcionalidades que ofrece la librer´ıa. Existe una versi´on para .NET en forma de paquete NuGet [33], el gestor de paquetes principal de dicho framework. Teniendo los paquetes NuGet necesarios instalados, para navegar a una p´agina web determinada, hay que instanciar el controlador que se desea usar (inicialmente Firefox) y llamar a la funci´on WebDriver.GoToUrl pas´andole la URL destino como par´ametro. Figura 3.25: Visitar una p´agina - Selenium Firefox Inicialmente la preocupaci´on principal fue que Google ni siquiera permitiese al software automatizado 50 alcanzar la p´agina de inicio de sesi´on, pero al estar la comprobaci´on de seguridad tras la primera fase del proceso de inicio de sesi´on (comprobaci´on de correo electr´onico) no hubo ning´un problema. Fue al introducir el correo electr´onico cuando el inicio de sesi´on fue rechazado. Figura 3.26: Inicio de sesi´on de Google con el controlador Chrome - Selenium Para evitar este control de seguridad se han ido publicando varios m´etodos que lo consegu´ıan, pero fueron arreglados por Google en su d´ıa. Se describen a continuaci´on los m´etodos intentados: Cambiar el User-Agent utilizado. El controlador de Firefox permite la edici´on del perfil de usuario utilizado para editar propiedades como el User-Agent. Para ello hay que crear un perfil nuevo y editar las preferencias. Figura 3.27: Cambio de User-Agent - Selenium Firefox Utilizar el modo headless El controlador permite elegir al usuario si abrir el navegador controlado con Selenium en una ventana o sin interfaz gr´afica. Para ello, hay que a˜nadir el argumento –headless al controlador. Figura 3.28: Modo headless - Selenium Firefox Introducir tiempos de pensar en el proceso de automatizaci´on para simular la actividad normal de un usuario. 51 Selenium soporta 2 tipos de esperas: espera impl´ıcita (esperar un tiempo determinado), y espera expl´ıcita (esperar a que ocurra un evento). Algunos sitios utilizan el tiempo que tarda el usuario en responder para determinar si se trata de un usuario realmente (el software automatizado es pr´acticamente instant´aneo si no se controla esto). Figura 3.29: Esperas - Selenium Firefox Probar desde distintas IP y con distintas cuentas de correo electr´onico. Es posible que Google registre los intentos automatizados de inicio de sesi´on y utilice alg´un mecanismo de blacklist para bloquear los intentos de inicio de sesi´on de IPs reincidentes. Adem´as, como la comprobaci´on de seguridad se realiza tras introducir el correo electr´onico de la cuenta objetivo, es posible que aplique un protocolo de seguridad mas estricto en aquellas cuentas en las que se intenta automatizar el inicio de sesi´on m´as frecuentemente. Utilizar el WebDriver de Chrome. Selenium tambi´en ofrece manejar el navegador de Google Chrome mediante un controlador. Figura 3.30: Visitar una p´agina - Selenium Chrome Acceder al servicio mediante los inicios de sesi´on alternativos de Google [35]. En los inicios de sesi´on alternativos de Google (por ejemplo al iniciar sesi´on con Google desde Stack Overflow) se utilizaba un servicio m´as antiguo que el utilizado en los inicios de sesi´on directos desde cualquier aplicaci´on de Google. Esto se reflejaba tambi´en en la seguridad, siendo la m´as antigua mucho menos estricta. Puppeteer Puppeteer es una librer´ıa de NodeJS desarrollada por Google que ofrece una API para interactuar con los navegadores de Chrome y Chromium [36]. Existe una versi´on open source de la librer´ıa [37], disponible en .NET como paquete NuGet [39]. Para este proyecto se utiliz´o la versi´on m´as reciente (PuppeteerSharp 4.0.0 en NuGet). Con esta librer´ıa se intentaron las mismas configuraciones (soportadas) que con Selenium, sin ´exito: inicio de sesi´on alternativo, falsear el User-Agent y usar el modo Headless [38]. 52 Figura 3.31: Configuraci´on de Puppeteer Sharp Selenium Stealth Selenium Stealth es una versi´on de la librer´ıa de Selenium para Python con funcionalidad adicional dedicada a evadir controles de seguridad contra software automatizado [41]. Incluye la utilizaci´on de servidores proxy, utilizaci´on de User-Agent e informaci´on sobre el sistema (se env´ıan en las peticiones HTTP) falsos. De las alternativas estudiadas es la ´unica que ha mostrado resultados, consiguiendo evitar el bloqueo de Google, aunque de manera espor´adica. La utilizaci´on de esta librer´ıa contra el servicio de Gmail no produc´ıa resultados con la consistencia necesaria como para ser de utilidad. El escenario que mejor resultados ha producido fue utilizar el inicio de sesi´on alternativo de StackOverflow, falsificando el User-Agent y los datos sobre el sistema (idioma, sistema operativo, controladores gr´aficos, etc), e inserci´on de esperas en el proceso de automatizaci´on [40]. Figura 3.32: Configuraci´on de Selenium Stealth A pesar de conseguir evadir este control de seguridad algunas veces, no es suficiente como para ser considerado de utilidad (m´as de la mitad de los intentos son reconocidos como automatizados y bloqueados), adem´as respecto al tema de protecci´on contra software automatizado Google siempre est´a atento a las brechas que surgen en sus sistemas y al poco tiempo acaban arregladas (la brecha de seguridad utilizada fue publicada el 19 de Abril de 2021 [40]). En este caso, han a˜nadido captchas que aparecen aleatoriamente para aumentar la tasa de fallo de aquellos bots que se basen en realizar numerosas peticiones contra su servicio. 53 Figura 3.33: Captcha de inicio de sesi´on 3.6. Estudio de Redes Sociales Tras el cambio de objetivos mencionado en el apartado 3.5, se replante´o la funcionalidad que deber´a ofrecer el plugin (expuesta en la Introducci´on, ver apartado 1.2). Se deber´an consultar los inicios de sesi´on de redes sociales para comprobar si una direcci´on de correo electr´onico posee cuenta en esos servicios. En esta secci´on se detallar´an los criterios utilizados para escoger qu´e servicios de redes sociales utilizar. El conjunto de redes sociales y servicios utilizados tiene un gran impacto en la utilidad que tendr´a la herramienta. Es necesario seleccionar aquellos servicios que sean lo suficientemente populares para que la informaci´on de sus usuarios sea valiosa. Tambi´en es de inter´es cubrir la mayor cantidad de usuarios posibles, incluyendo aquellas redes sociales m´as extendidas entre la poblaci´on adulta. Seg´un un estudio sobre los usuarios de redes sociales en Espa˜na [42], las redes sociales m´as populares son: YouTube (gestionado por Google). Facebook. Instagram (propiedad de Facebook). Twitter. LinkedIn. Tumblr. Tambi´en se han a˜nadido el servicio de Google, el de Amazon y el de Microsoft, que est´an muy extendidos entre los usuarios (YouTube utiliza las cuentas de Google como cuentas de usuario, y Microsoft gestiona los inicios de sesi´on de Windows y de Office, entre otros), adem´as de servir como inicio de sesi´on alternativo en gran parte de las redes sociales. Teniendo estos servicios, hay que determinar cu´ales de ellos permiten a software automatizado realizar un intento de inicio de sesi´on. La caracter´ıstica que nos interesa aprovechar es que la gran mayor´ıa de 54 servicios no impiden al software automatizado realizar el inicio de sesi´on. Algunos de ellos, como Google, realizan esa comprobaci´on de seguridad despu´es del inicio de sesi´on (pero si por ejemplo la cuenta no existe, te notifican de ello). Este es un problema de dise˜no de la seguridad del servicio: es posible que al servicio le interese dejar a los usuarios iniciar sesi´on mediante software automatizado (por ejemplo, para un programa que haga publicaciones autom´aticas en una red social), pero lo que no se deber´ıa permitir es que un programa compruebe si el usuario tiene una cuenta en ese sitio. Del conjunto estudiado, LinkedIn es la ´unica red social que protege su inicio de sesi´on contra ataques maliciosos de este tipo. Entonces, los servicios que permiten a software automatizado determinar si una direcci´on de correo electr´onico tiene una cuenta en el sitio son: Google. Amazon. Facebook. Instagram. Twitter. Tumblr. Microsoft. 3.7. Toma de Requisitos En este apartado se detallar´a el proceso de an´alisis de requisitos que se llev´o a cabo sobre las premisas de funcionalidad del plugin. Estos requisitos ser´an utilizados como base del proceso de desarrollo. 3.7.1. Requisitos Funcionales Los requisitos funcionales especifican que funciones y/o comportamientos deben de ser implementados en el sistema. RF-01: El plugin podr´a comprobar si un correo electr´onico tiene cuenta en las redes sociales objetivo. RF-02: El plugin podr´a consultar los correos electr´onicos guardados en FOCA para usarlos contra los servicios de inicio de sesi´on de las redes sociales objetivo. RF-03: El plugin dispondr´a de un hist´orico exportable de las comprobaciones de redes sociales realizadas. 3.7.2. Requisitos no Funcionales Los requisitos no funcionales recogen que caracter´ısticas y/o restricciones deben de estar presentes en el sistema. RNF-01: El plugin estar´a desarrollado en C# (Microsoft .NET Framework). RNF-02: El plugin utilizar´a la API de FOCA. 55 Figura 4.5: Diagrama de Clases de An´alisis (BCE) 4.4. Realizaci´on de Casos de Uso de An´alisis En este apartado se detalla la realizaci´on de los casos de uso en an´alisis, aplicando un enfoque BCE. De cada caso de uso se expondr´a una breve descripci´on y las clases de an´alisis participantes junto con su correspondiente diagrama de secuencia. Caso de Uso 1 - Comprobar redes sociales de un correo electr´onico En este caso de uso se consultan los servicios de inicio de sesi´on de varias redes sociales para comprobar si una direcci´on de correo electr´onico proporcionada posee cuenta en estos servicios (comprobaci´on de redes sociales). Las clases de an´alisis participantes son (ver apartado 4.3): pluginMainForm,ControladorComprobacion,ControladorWeb,ComprobacionRRSS yResultadoServicio para la comprobaci´on de redes sociales. ControladorHistorial eHistorial para actualizar el historial. ControladorBD para consultar los correos electr´onicos encontrados por FOCA. Servicios de inicio de sesi´on yBase de datos FOCA como servicios externos (en verde). 62 Figura 4.6: CUA1 - Comprobar redes sociales de un correo electr´onico Caso de Uso 2 - Mostrar historial de comprobaciones de redes sociales En este caso de uso se muestra al usuario la informaci´on de las comprobaciones de redes sociales realizadas anteriormente, con la opci´on de exportarla a un archivo CSV. Las clases de an´alisis participantes son (ver apartado 4.3): pluginMainForm,ControladorHistorial eHistorial para obtener y mostrar el historial. Figura 4.7: CUA2 - Mostrar historial de comprobaciones de redes sociales 63 4.5. Flujo de informaci´on En esta secci´on se explicar´an los or´ıgenes y destinos de la informaci´on que el sistema debe manejar (definida en los Requisitos de Informaci´on, ver apartado 3.7.3). El plugin recoge informaci´on de 2 fuentes principales: FOCA . De este sistema se recoger´an los correos electr´onicos encontrados en los metadatos de documentos ofim´aticos de Internet. Estos correos se utilizar´an contra los servicios de inicio de sesi´on de redes sociales. Servicios de inicio de sesi´on de redes sociales . Utilizando los correos electr´onicos de FOCA contra los servicios de inicio de sesi´on, se obtiene en qu´e redes sociales existe una cuenta de usuario con ese nombre (un conjunto de valores boolean por cada una de las redes sociales consultadas). El plugin guardar´a el conjunto de valores boolean obtenido de los servicios de inicio de sesi´on junto con el correo electr´onico utilizado (englobados bajo Resultados en la figura 4.8) en un archivo CSV (a petici´on del usuario). Figura 4.8: Flujo de informaci´on del sistema. 64 Cap´ıtulo 5 Dise˜no En esta fase se realiza la especificaci´on de la funcionalidad del software a desarrollar a un nivel m´as bajo que en la fase de an´alisis, profundizando m´as en los elementos software necesarios para su implementaci´on. 5.1. Arquitectura A la vista de los requisitos, casos de uso, y clases de an´alisis identificadas en el proceso de an´alisis anteriormente realizado, se utilizar´a una arquitectura de 3 capas [45]: Capa de Presentaci´on: Esta capa gestiona las interacciones entre el usuario y la l´ogica del sistema. En este caso, la capa est´a compuesta por las interfaces de usuario embebidas en FOCA. Capa de l´ogica de aplicaci´on: Maneja toda la l´ogica de la aplicaci´on. Engloba tanto los elementos del dominio de la aplicaci´on como los servicios que se ofrecen, actuando como intermediarios entre la interfaz y el acceso a datos. Capa de acceso a Datos: Gestionan las fuentes de informaci´on que utilizar´a el sistema. Aqu´ı se incluyen el acceso a la base de datos y la interacci´on con los servicios de inicio de sesi´on. 65 Figura 5.1: Arquitectura del sistema 5.2. Interfaz de usuario Para realizar el dise˜no de la interfaz de usuario primero es necesario definir las caracter´ısticas principales de los usuarios que van a utilizar la herramienta, as´ı como sus necesidades a la hora de interactuar con la interfaz. Este plugin est´a orientado a los usuarios de la herramienta FOCA, en la que est´a integrado. FOCA es utilizada en el campo de la Ciberseguridad como herramienta profesional en Pentesting o en Auditor´ıas de Seguridad, entonces la eficiencia de trabajo ser´a una necesidad esencial que se debe maximizar. 66 Figura 5.2: Interfaz de FOCA (I) Figura 5.3: Interfaz de FOCA (II) 67 Tambi´en facilitar´ıa el uso de la interfaz el seguir los mismos patrones de dise˜no y formato que los utilizados en FOCA o en el resto de sus plugins. Figura 5.4: Interfaz del plugin DNS Snooping [46] Figura 5.5: Interfaz del plugin HaveIBeenPwned Teniendo los casos de uso y las necesidades de los usuarios en mente, se utiliz´o un patr´on de dise˜no de pesta˜nas para separar las partes de la interfaz relacionadas con las extracciones y las consultas a FOCA, de la interfaz del hist´orico. La raz´on detr´as de esto es la posibilidad de consultar los correos electr´onicos encontrados por FOCA antes de realizar un escaneo, ya que necesitas de una direcci´on de correo electr´onico para iniciarlo. Para los bocetos de la interfaz he utilizado WireFrame [29]. 68 Figura 5.6: Interfaz de usuario (I) Figura 5.7: Interfaz de usuario (II) 69 5.3. Diagrama de Clases de Dise˜no En esta secci´on detallar´e las clases de dise˜no utilizadas. Estas clases han sido derivadas de las clases de an´alisis identificadas en el apartado 4.3. Las clases de dise˜no utilizadas son: pluginForm. Esta clase modela la interfaz de usuario. Se trata de un formulario que recoge toda interacci´on del usuario con el sistema e invoca la l´ogica de aplicaci´on correspondiente. RRSSController. Esta clase se trata de un controlador GRASP [27] que recoge toda la funcionalidad del plugin referente a las comprobaciones de redes sociales. HistoryController. Esta clase se trata de un controlador GRASP que recoge la funcionalidad del plugin referente al historial de comprobaciones de redes sociales realizadas. WebExtractor. Esta clase se encarga de la interacci´on y extracci´on de informaci´on de los servicios Web de inicio de sesi´on. DBAccess. Esta clase se encarga de la conexi´on y las consultas realizadas contra la base de datos de FOCA. ScanResult. Clase perteneciente al dominio de la aplicaci´on que modela los resultados de una comprobaci´on de redes sociales realizada usando un correo electr´onico determinado. ServiceResult. Clase perteneciente al dominio de la aplicaci´on que modela el resultado de la comprobaci´on de redes sociales para un correo electr´onico en un servicio en espec´ıfico. Figura 5.8: Diagrama de Clases de Dise˜no 5.4. Realizaci´on de los Casos de Uso de Dise˜no En esta secci´on se detalla la realizaci´on de los casos de uso de dise˜no. Para cada caso de uso se expondr´an una descripci´on y las clases de dise˜no participantes con su respectivo diagrama de secuencia. Caso de Uso 1 - Comprobar redes sociales de un correo electr´onico En este caso de uso se consultan los servicios de inicio de sesi´on de varias redes sociales para comprobar si una direcci´on de correo electr´onico proporcionada posee cuenta en estos servicios (comprobaci´on de redes sociales). Las clases de dise˜no participantes son (ver apartado 5.3): pluginForm,RRSSController,WebExtractor,ScanResult yServiceResult para la comprobaci´on de redes sociales. 70 HistoryController para actualizar el historial. DBAccess para consultar los correos electr´onicos guardados en la base de datos de FOCA. Servicios de inicio de sesi´on yBase de datos FOCA como servicios externos (en verde). Figura 5.9: CUD1 - Comprobar redes sociales de un correo electr´onico Caso de Uso 2 - Mostrar historial de comprobaciones de redes sociales En este caso de uso se muestra al usuario la informaci´on de las comprobaciones de redes sociales realizadas anteriormente, con la opci´on de exportarla a un archivo CSV. Las clases de dise˜no participantes son (ver apartado 5.3): pluginForm eHistoryController para obtener y mostrar el historial. ScanResult para obtener la informaci´on de cada comprobaci´on de redes sociales para realizar la exportaci´on. 71 sesi´on de cada red social est´an programadas de distinta manera: cada una tiene sus propios elementos con sus propios atributos, por eso el proceso de extracci´on de la informaci´on tiene que ser espec´ıfico para cada una de ellas. Figura 6.4: Visitar una p´agina y buscar un elemento - Selenium Antes se ha mencionado que algunos patrones de dise˜no utilizados por redes sociales obstaculizan indirectamente las actividades de este tipo de software automatizado. Un claro ejemplo de esto son los avisos de uso de Cookies, muy utilizados en la actualidad. Dependiendo de su implementaci´on, estos avisos son capaces de bloquear la interacci´on del usuario (y de Selenium) con la p´agina hasta aceptarlos. Entonces, en las redes sociales que utilicen este tipo de pop-up hay que realizar pasos adicionales: buscar el bot´on de Aceptar cookies o similar y pulsarlo. Esto revela otro problema, los avisos de Cookies normalmente s´olo aparecen una vez, por tanto cuando no aparezcan Selenium lanzar´a una excepci´on porque no encuentra dicho bot´on. Una manera efectiva de lidiar con esto es capturando las excepciones correspondientes. Figura 6.5: Aviso de uso de Cookies - Instagram Figura 6.6: Manejo de los avisos de Cookies 78 6.2. Interfaz gr´afica En este apartado se explicar´an los detalles de la implementaci´on de la interfaz dise˜nada en el cap´ıtulo anterior. FOCA permite a los plugins mostrar sus interfaces de usuario en un panel propio de la interfaz de FOCA dedicado a ellos. Es por esto que las interfaces de los plugins est´an sujetos a utilizar la misma API de interfaz gr´afica que FOCA: Windows Forms. Windows Forms es una interfaz de programaci´on gr´afica incluida dentro de Microsoft .NET Framework. Se trata de una API que permite el acceso a los elementos gr´aficos nativos del sistema operativo encapsulando las llamadas al mismo. Visual Studio provee de un dise˜nador de interfaces de Windows Forms interactivo que permite la compilaci´on y despliegue de aplicaciones utilizando esta API de manera sencilla. Tomando como referencia el dise˜no de interfaz realizado anteriormente, la interfaz consta de 3 partes: Pesta˜na de historial. Panel de consulta de correos electr´onicos de FOCA. Panel de comprobaciones de redes sociales. Historial En la pesta˜na del historial es donde se muestran las operaciones realizadas anteriormente. Se trata de un DataGridView, un componente de Windows Forms que permite mostrar a los usuarios informaci´on en forma de tabla. Este componente es configurable desde el dise˜nador de Visual Studio para a˜nadir las columnas convenientes (en este caso, el correo electr´onico y una para cada red social) y editar el estilo de cada celda. El componente tambi´en se puede configurar en tiempo de ejecuci´on utilizando los atributos y m´etodos de la clase DataGridView: DataGridView.Rows: Lista que contiene la informaci´on de cada fila guardada en la tabla. DataGridViewRow.Cells: Lista que contiene la informaci´on de cada celda de una fila de la tabla. DataGridViewCell: Clase que maneja la informaci´on referente a una celda de la tabla, incluyendo su valor, formato y estilo. Tambi´en incluye la funci´on de exportar a CSV, para facilitar el an´alisis de los datos en herramientas como Microsoft Excel o relacionados. 79 Figura 6.7: Interfaz gr´afica del historial Consulta de correos electr´onicos de FOCA En el panel de consultas de correos electr´onicos se muestra al usuario los correos electr´onicos guardados en la base de datos de FOCA. Incluye unas cajas de texto que informan al usuario de los par´ametros de conexi´on de la instancia de base de datos que est´a siendo utilizada por FOCA, que son introducidos por el usuario la primera vez que lanza la herramienta y guardados por FOCA en ./FOCA/bin/Release/FOCA.exe.Config . Comprobaci´on de cuentas de redes sociales En el panel de comprobaciones de redes sociales es donde los usuarios pueden iniciar el proceso de comprobaci´on de cuentas de usuario sobre una direcci´on de correo electr´onico dada, configurar el headless browser y comprobar el estado del proceso si est´a en marcha. Una parte importante a la hora de implementar interfaces que interact´uan con procesos de larga duraci´on es mantener la funcionalidad de la interfaz durante la ejecuci´on de dicho proceso. Si se utiliza el mismo hilo de ejecuci´on que la interfaz para ejecutarlo, la interfaz no podr´a responder a la interacci´on con el usuario hasta que la ejecuci´on acabe. La soluci´on para este problema es ejecutar el proceso de larga duraci´on en un hilo separado al hilo de la interfaz. Windows Forms tiene un componente que permite mantener la funcionalidad de la interfaz, el Background Worker, que permite ejecutar tareas en un subproceso distinto. Para utilizarlo, s´olo hay que buscarlo en la caja de herramientas del dise˜nador de interfaces y arrastrarlo a la interfaz en cuesti´on. Entonces el IDE preparar´a los event listeners (registros que indican que eventos ejecutan funcionalidad del componente) que necesita el componente para que el desarrollador pueda programar los handlers (fragmentos de c´odigo ejecutados al ocurrir un evento determinado). La clase de BackgroundWorker provee 3 listeners principales, para los cuales habr´a que implementar sus respectivos handlers con el c´odigo que queremos que se ejecute en cada caso: DoWork. El evento que se dispara cuando le indicamos al worker que inicie su tarea (mediante el m´etodo BackgroundWorker.RunWorkerAsync()). ProgressChanged. El evento que se dispara cuando desde el worker se notifica que ha habido progreso en la tarea (mediante el m´etodo BackgroundWorker.notifyProgress(progress)). 80 RunWorkerCompleted. El evento que se dispara cuando el worker finaliza su tarea (teniendo disponible el resultado en el campo Result del propio evento). Entonces, en el handler del evento DoWork ejecutamos el proceso de recogida de informaci´on, utilizando el m´etodo notifyProgress() para actualizar la barra de estado de la interfaz, y en el handler de RunWorkerCompleted preparar la interfaz para el final del proceso. Figura 6.8: Interfaz gr´afica principal Figura 6.9: Interfaz gr´afica principal durante un proceso de comprobaci´on de redes sociales 6.3. Acceso a datos Para implementar las interacciones del plugin y la base de datos de FOCA se utiliz´o la librer´ıa de SQLClient, disponible como paquete en el gestor NuGet [53]. El plugin se conectar´a a la instancia de SQL Server que utiliza FOCA y buscar´a correos electr´onicos en la tabla pertinente (dbo.EmailsItems). Para conectarse a la instancia de FOCA, es necesario disponer de su connection string. Este par´ametro le proporciona el usuario la primera vez que inicia FOCA, que lo guarda en ./FOCA/bin/Release/FOCA.exe.Config para evitar preguntar al usuario siempre que ejecute la herramienta. De esta manera, disponiendo de 81 esta informaci´on es posible conectarse a dicha instancia a trav´es de cualquier conector SQL, en este caso SQLClient. Figura 6.10: Implementaci´on de la consulta con SQLClient 82 Cap´ıtulo 7 Pruebas Este cap´ıtulo est´a dedicado a la documentaci´on de los casos de prueba dise˜nados para asegurar que el plugin cumple con los requerimientos definidos anteriormente. En estas pruebas se asume que se dispone de todo lo necesario para operar FOCA con el mejor rendimiento posible (todas las dependencias de la herramienta, conexi´on a Internet, una instancia de SQL Server configurada, suficiente espacio en disco, memoria RAM libre y el sistema en un estado estacionario). 7.1. Bater´ıa de pruebas De cada prueba dise˜nada se describir´an: una breve descripci´on de la funcionalidad que se est´a probando, los pasos realizados, y los resultados que se esperan obtener de su ejecuci´on. Las pruebas est´an numeradas por orden de ejecuci´on. CP-1 Descripci´on Comprobaci´on de la existencia de cuentas de usuario en redes sociales de un correo electr´onico. Resultado esperado Inicio del proceso de comprobaci´on y al finalizar: un pop-up informativo y la actualizaci´on del hist´orico. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. Resultados obtenidos Ejecuci´on Resultado 1 No aparece el pop-up informativo. 2 Resultado esperado. Cuadro 7.1: Caso de Prueba 1 83 CP-2 Descripci´on Comprobaci´on del estado de la interfaz durante el proceso de comprobaci´on de redes sociales. Resultado esperado Al iniciar el proceso, se desactivar´a el bot´on Scan y se ir´a actualizando el panel de progreso a medida que el proceso avanza. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. Resultados obtenidos Ejecuci´on Resultado 1 La interfaz no responde durante el proceso de extracci´on. 2 No se actualiza el panel de progreso. 3 Resultado esperado. Cuadro 7.2: Caso de Prueba 2 CP-3 Descripci´on Comprobaci´on del estado de la interfaz al finalizar el proceso de comprobaci´on de redes sociales. Resultado esperado Al terminar la comprobaci´on, el panel de progreso muestra que el proceso ha terminado y se activa el bot´on Scan. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. Resultados obtenidos Ejecuci´on Resultado 1 No se reactiva el bot´on de Scan. 2 Resultado esperado. Cuadro 7.3: Caso de Prueba 3 CP-4 Descripci´on Comprobaci´on de que la interfaz se mantiene funcional durante la ejecuci´on del proceso de comprobaci´on de redes sociales. Resultado esperado Durante el proceso se permite cambiar a la pesta˜na del historial sin problemas. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. 3 Se cambia a la pesta˜na del historial. Resultados obtenidos Ejecuci´on Resultado 1 Resultado esperado. Cuadro 7.4: Caso de Prueba 4 84 CP-5 Descripci´on Prueba de coherencia de los resultados del proceso de comprobaci´on de redes sociales. Resultado esperado Se demuestra que el correo electr´onico posee cuenta en los servicios comprobados. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. 3 Se comprueba manualmente la direcci´on de correo introducida en los servicios utilizados. Resultados obtenidos Ejecuci´on Resultado 1 El proceso no devuelve que exista ninguna cuenta (cuando se ha comprobado que s´ı). 2 No se identifica ninguna cuenta de Instagram (comprobado que s´ı hay). 3 Resultado esperado. Cuadro 7.5: Caso de Prueba 5 CP-6 Descripci´on Prueba de consistencia de los resultados del proceso de comprobaci´on de redes sociales. Resultado esperado Los resultados de sucesivas comprobaciones utilizando el mismo correo electr´onico no var´ıan. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. 3 Al finalizar el proceso, se pulsa de nuevo el bot´on Scan Resultados obtenidos Ejecuci´on Resultado 1 Resultado esperado. Cuadro 7.6: Caso de Prueba 6 CP-7 Descripci´on Prueba del tratamiento de correos electr´onicos inv´alidos. Resultado esperado Se notifica al usuario que el correo introducido no es v´alido. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico inv´alida en el campo de texto. 2 Se pulsa el bot´on Scan. Resultados obtenidos Ejecuci´on Resultado 1 El proceso inicia con una direcci´on de correo electr´onico inv´alida. 2 Resultado esperado. Cuadro 7.7: Caso de Prueba 7 85 CP-8 Descripci´on Prueba del proceso de comprobaci´on de redes sociales usando el modo gr´afico. Resultado esperado Al iniciar el proceso se abre la ventana del navegador y muestra los distintos pasos del proceso. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. Resultados obtenidos Ejecuci´on Resultado 1 La opci´on gr´afica en la interfaz no se activa. 2 Resultado esperado. Cuadro 7.8: Caso de Prueba 8 CP-9 Descripci´on Comprobaci´on de que el modo gr´afico no influye en los resultados del proceso. Resultado esperado No hay diferencias en los resultados entre 2 ejecuciones sucesivas alternando el modo gr´afico. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. 3 Al finalizar se marca la casilla Headless y se pulsa de nuevo en el bot´on Scan. Resultados obtenidos Ejecuci´on Resultado 1 Resultado esperado. Cuadro 7.9: Caso de Prueba 9 CP-10 Descripci´on Comprobaci´on de que el modo gr´afico no influye en la funcionalidad de la interfaz durante la ejecuci´on del proceso. Resultado esperado Se puede minimizar la ventana del navegador e interactuar con la interfaz de manera normal. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. 3 Al abrirse la ventana del navegador, se puede minimizar e interactuar con la interfaz del plugin. Resultados obtenidos Ejecuci´on Resultado 1 Resultado esperado. Cuadro 7.10: Caso de Prueba 10 86 CP-11 Descripci´on Comprobaci´on de la consulta de correos electr´onicos a FOCA. Resultado esperado Se muestra al usuario los correos electr´onicos encontrados por FOCA. Secuencia de acciones Paso Acci´on 1 Se pulsa el bot´on Connect. Resultados obtenidos Ejecuci´on Resultado 1 No se encuentra la instancia referenciada por el connection string especificado. 2 Resultado esperado. Cuadro 7.11: Caso de Prueba 11 CP-12 Descripci´on Comprobaci´on de coherencia en consulta de correos electr´onicos a FOCA. Resultado esperado Los correos electr´onicos mostrados al usuario son los guardados en la instancia de base de datos que utiliza FOCA. Secuencia de acciones Paso Acci´on 1 Se pulsa el bot´on Connect. 2 Se comprueban los correos electr´onicos en la instancia de FOCA. Resultados obtenidos Ejecuci´on Resultado 1 Resultado esperado. Cuadro 7.12: Caso de Prueba 12 CP-13 Descripci´on Comprobaci´on de consulta durante un proceso de comprobaci´on de redes sociales. Resultado esperado La consulta se realiza correctamente. Secuencia de acciones Paso Acci´on 1 Se introduce una direcci´on de correo electr´onico en el campo de texto. 2 Se pulsa el bot´on Scan. 3 Se pulsa el bot´on Connect. Resultados obtenidos Ejecuci´on Resultado 1 Resultado esperado. Cuadro 7.13: Caso de Prueba 13 87 nombre, descripci´on, icono del plugin as´ı como los elementos que importa o exporta a la herramienta (por ejemplo, el panel con la interfaz gr´afica del plugin). Controladores/RRSSController.cs Es la clase que recoge la l´ogica de la aplicaci´on referente al proceso de comprobaci´on de redes sociales. Controladores/HistoryController.cs Es la clase que recoge la l´ogica de la aplicaci´on referente al hist´orico de comprobaciones de redes sociales realizadas. Controladores/WebExtractor.cs Es la clase que maneja la interacci´on con los servicios de inicio de sesi´on de las redes sociales y extrae la informaci´on. Incluye la configuraci´on de los controladores de Selenium y el proceso de interacci´on con los servicios web paso a paso. Data/ScanResults.cs Se encarga del modelo de datos utilizado por la aplicaci´on. Incluye la clase ScanResults (modelo de la informaci´on de cuentas de usuario en redes sociales encontradas sobre una direcci´on de correo electr´onico) y ServiceResult (modelo de la informaci´on sobre la existencia de una cuenta de usuario de un correo electr´onico determinado en una red social determinada). Data/DBAccess.cs Esta clase es la encargada de manejar la interacci´on con la base de datos de FOCA. Sirve de capa de abstracci´on sobre los esquemas de datos implementados en SQL Server. Resources En esta carpeta est´an guardados los recursos gr´aficos utilizados por el plugin, en este caso, solamente iconos. Properties yReferencias Apartados generados por Visual Studio que contienen la configuraci´on de la soluci´on y sus librer´ıas. 94 Figura 8.6: Estructura de archivos del proyecto 95 96 Cap´ıtulo 9 Conclusiones y trabajo futuro En este cap´ıtulo se har´a una recapitulaci´on del trabajo realizado. Se expondr´an los objetivos cumplidos durante el desarrollo del TFG y se detallar´an las ampliaciones de funcionalidad que se podr´ıan llevar a cabo a futuro. 9.1. Conclusiones Durante la realizaci´on de este Trabajo de Fin de Grado se ha desarrollado un plugin para la herramienta FOCA capaz de utilizar los correos electr´onicos encontrados por dicha herramienta para recopilar informaci´on sobre sus cuentas de usuario en distintas redes sociales y servicios. Pese a haber sufrido un cambio de objetivos, la finalidad de este TFG se sigue manteniendo: explotar la capacidad de FOCA de encontrar metadatos dentro de documentos ofim´aticos de Internet para usarlos como punto de partida en la b´usqueda de m´as informaci´on (un recurso muy utilizado en t´ecnicas de Profiling). A continuaci´on se resume el trabajo realizado: Planificaci´on y ejecuci´on de un proyecto de desarrollo software. Estudio de las funcionalidades que ofrece FOCA y su programaci´on, incluyendo su API de plugins. Estudio del modelo de datos implementado por FOCA en las instancias anfitrionas. Desarrollo de un plugin para FOCA que a˜nade funcionalidad a la herramienta. Familiarizaci´on con las distintas herramientas de desarrollo para aplicaciones de Windows. Manejo de varias librer´ıas y herramientas de Web scraping yHeadless browsers. 9.2. Trabajo futuro En este aparado se exponen las posibles mejoras o ampliaciones de funcionalidad que se podr´ıan implementar en versiones futuras del plugin. Las principales son: Mejorar la integraci´on del plugin con FOCA, implementando otras maneras de utilizar las funciones ofrecidas desde la propia herramienta. A˜nadir soporte para m´as fuentes de correos electr´onicos, no s´olo bases de datos SQL Server (otros DBMS, ficheros CSV, JSON, XML, etc). 97 Ampliar el cat´alogo de redes sociales utilizadas. Pese a ser un proceso muy individualizado, la capacidad de permitir a los usuarios a˜nadir nuevas redes sociales al proceso de extracci´on de informaci´on aumentar´ıa mucho la utilidad del mismo. Utilizar un mecanismo de colas de operaciones como el que ofrece FOCA para mejorar la eficiencia de extracci´on de informaci´on (esto dar´ıa pie a ejecuciones batch para comprobar cuentas de redes sociales de varios correos electr´onicos sin tener que interactuar con la interfaz para cada una de ellas). 98 Bibliograf´ıa [1] Hughes, B., & Cotterell, M. (2009). Software Project Management (5th Revised ed.). McGraw-Hill Education. [2] Precio promedio de luz en Espa˜na. (s. f.). Tarifasgasluz. Recuperado 20 de enero de 2021, de https: //tarifasgasluz.com/comparador/precio-kwh [3] Uso promedio de luz en Espa˜na. (s. f.). Tarifasgasluz. Recuperado 20 de enero de 2021, de https: //tarifasgasluz.com/faq/cuanto-cuesta-luz-mes [4] Cu´anta electricidad consume un ordenador. (s. f.). CHC Energ´ıa. Recuperado 20 de enero de 2021, de https://chcenergia.es/blog/cuanto-consume-un-ordenador-o-pc/ [5] BOE.es - BOE-A-2020-11043 Real Decreto-ley 28/2020, de 22 de septiembre, de trabajo a distancia. (2020, 22 septiembre). Bolet´ın Oficial del Estado. https://www.boe.es/eli/es/rdl/2020/09/22/ 28/con [6] FOCA. (s. f.). ElevenPaths. Recuperado 24 de enero de 2021, de https://www.elevenpaths.com/ innovation-labs/technologies/foca [7] Riley, J. (s. f.). Understanding Metadata. NISO. Recuperado 24 de enero de 2021, de https://groups. niso.org/apps/group_public/download.php/17446/Understanding%20Metadata.pdf [8] ElevenPaths/FOCA. (s. f.). GitHub. Recuperado 24 de enero de 2021, de https://github.com/ ElevenPaths/FOCA [9] Alonso, C. (s. f.). Foca API v0.1. Slideshare. Recuperado 26 de enero de 2021, de https://es. slideshare.net/chemai64/foca-api-v01 [10] Documentaci´on de Entity Framework. (s. f.). Microsoft Docs. Recuperado 27 de enero de 2021, de https://docs.microsoft.com/es-es/ef/ [11] Microsoft. (s. f.). Plataforma de datos de Microsoft. Recuperado 27 de enero de 2021, de https: //www.microsoft.com/es-es/sql-server [12] SQL Server 2016 y 2017: Requisitos de hardware y de software - SQL Server. (s. f.). Microsoft Docs. Recuperado 27 de enero de 2021, de https://docs.microsoft.com/es-es/sql/sql-server/install/ hardware-and-software-requirements-for-installing-sql-server?view=sql-server-ver15 [13] Microsoft. (s. f.-a). Descargas de SQL Server. Recuperado 27 de enero de 2021, de https://www. microsoft.com/es-es/sql-server/sql-server-downloads [14] Instalaci´on mediante la interfaz gr´afica de usuario - SQL Server. (s. f.). Microsoft Docs. Recuperado 27 de enero de 2021, de https://docs.microsoft.com/es-es/sql/database-engine/ install-windows/install-sql-server-from-the-installation-wizard-setup?view= sql-server-ver15 99 [15] SqlLocalDB (utilidad) - SQL Server. (s. f.). Microsoft Docs. Recuperado 30 de enero de 2021, de https://docs.microsoft.com/es-es/sql/tools/sqllocaldb-utility?view=sql-server-ver15 [16] Desinstalaci´on de una instancia existente - SQL Server. (s. f.). Microsoft Docs. Recuperado 30 de enero de 2021, de https://docs.microsoft.com/es-es/sql/sql-server/install/ uninstall-an-existing-instance-of-sql-server-setup?view=sql-server-ver15&tabs= Windows10 [17] SQL Server Management Studio (SSMS) - SQL Server Management Studio (SSMS). (s. f.). Microsoft Docs. Recuperado 10 de febrero de 2021, de https://docs.microsoft.com/es-es/sql/ssms/ sql-server-management-studio-ssms?view=sql-server-ver15 [18] Descarga e instalaci´on de Azure Data Studio - Azure Data Studio. (s. f.). Microsoft Docs. Recuperado 10 de febrero de 2021, de https://docs.microsoft.com/es-es/sql/azure-data-studio/ download-azure-data-studio?view=sql-server-ver15 [19] SSMS Installation error (0x80070643). (s. f.). Microsoft Forums. Recuperado 11 de febrero de 2021, de https://social.msdn.microsoft.com/Forums/sqlserver/en-US/ 183f4353-b0d7-451f-aa7f-0764cfc6254e/ssms-installation-error-0x80070643?forum= sqltools [20] Robledano, A. (s. f.). Qu´e es NET Framework. OpenWebinars.net. Recuperado 12 de febrero de 2021, de https://openwebinars.net/blog/que-es-net-framework/ [21] Microsoft. (s. f.-b). Download .NET Framework 4.7.2 — Free official downloads. Recuperado 12 de febrero de 2021, de https://dotnet.microsoft.com/download/dotnet-framework/net472 [22] Microsoft. (s. f.-a). Descargar Visual Studio 2019 para Windows y Mac. Visual Studio. Recuperado 13 de febrero de 2021, de https://visualstudio.microsoft.com/es/downloads/ [23] Microsoft. (s. f.-e). Visual Studio Community 2019 - Free IDE and Developer Tools. Visual Studio. Recuperado 13 de febrero de 2021, de https://visualstudio.microsoft.com/es/vs/community/ [24] Requisitos del sistema de Visual Studio 2019. (s. f.). Microsoft Docs. Recuperado 13 de febrero de 2021, de https://docs.microsoft.com/es-es/visualstudio/releases/2019/system-requirements [25] Instalar Visual Studio. (s. f.). Microsoft Docs. Recuperado 14 de febrero de 2021, de https://docs. microsoft.com/es-es/visualstudio/install/install-visual-studio?view=vs-2019 [26] Marqu´es, J. M. (2020). Diapositivas de la asignatura Dise˜no, Integraci´on y Adaptaci´on de Software. [Diapositivas]. [27] Larman, C. (2001). Applying Uml and Patterns: An Introduction to Object-Oriented Analysis and Design, and the Unified Process (2.a ed.). Prentice Hall. [28] Astah. (2020). [Herramienta de modelado UML]. Astah. https://astah.net/ [29] Wireframe.cc — The go-to wireframing tool. (s. f.). Wireframe.Cc. Recuperado 10 de marzo de 2021, de https://wireframe.cc [30] Editor de diagramas en l´ınea gratis. (s. f.). Visual Paradigm. Recuperado 10 de marzo de 2021, de https://online.visual-paradigm.com/es/diagrams/solutions/ free-online-diagram-editor/ 100 [31] jQuery.ajax() — jQuery API Documentation. (s. f.). JQuery API. Recuperado 7 de abril de 2021, de https://api.jquery.com/jquery.ajax/ [32] SeleniumHQ Browser Automation. (s. f.). Selenium. Recuperado 8 de abril de 2021, de https: //www.selenium.dev/ [33] Selenium.WebDriver 3.141.0. (s. f.). NuGet. Recuperado 8 de abril de 2021, de https://www.nuget. org/packages/Selenium.WebDriver/3.141.0 [34] WebDriver - Table of Content. (s. f.). Selenium. Recuperado 8 de abril de 2021, de https://www. selenium.dev/selenium/docs/api/dotnet/ [35] GMail is blocking login via Automation (Selenium). (s. f.). Stack Overflow. Recuperado 15 de abril de 2021, de https://stackoverflow.com/questions/57602974/ gmail-is-blocking-login-via-automation-selenium [36] Puppeteer — Tools for Web Developers —. (s. f.). Google Developers. Recuperado 16 de abril de 2021, de https://developers.google.com/web/tools/puppeteer [37] hardkoded/puppeteer-sharp. (s. f.). GitHub. Recuperado 16 de abril de 2021, de https://github. com/hardkoded/puppeteer-sharp [38] Puppeteer Sharp. (s. f.). Puppeteer Sharp. Recuperado 16 de abril de 2021, de http://www. puppeteersharp.com/api/index.html [39] PuppeteerSharp 4.0.0. (s. f.). NuGet. Recuperado 16 de abril de 2021, de https://www.nuget.org/ packages/PuppeteerSharp/ [40] Selenium Google Login Blocked in Automation. (2021, 18 abril). Stack Overflow. https://stackoverflow.com/questions/67150869/ selenium-google-login-blocked-in-automation-self-answered-bypassed-the-google [41] selenium-stealth. (s. f.). PyPI. Recuperado 18 de abril de 2021, de https://pypi.org/project/ selenium-stealth/ [42] Usuarios de redes sociales en Espa˜na. (s. f.). EPData. Recuperado 23 de abril de 2021, de https: //www.epdata.es/datos/usuarios-redes-sociales-espana-estudio-iab/382 [43] Password Cracking Dictionary. (s. f.). CrackStation. Recuperado 26 de abril de 2021, de https: //crackstation.net/crackstation-wordlist-password-cracking-dictionary.htm [44] John the Ripper password cracker. (s. f.). OpenWall. Recuperado 26 de abril de 2021, de https: //www.openwall.com/john/ [45] Fowler, M. (s. f.). PresentationDomainDataLayering. martinfowler.com. Recuperado 30 de abril de 2021, de https://martinfowler.com/bliki/PresentationDomainDataLayering.html [46] What is DNS cache snooping? (s. f.). Internet Systems Consortium (ISC). Recuperado 4 de mayo de 2021, de https://kb.isc.org/docs/aa-00509 [47] rfc4180. (s. f.). IETF. Recuperado 6 de mayo de 2021, de https://datatracker.ietf.org/doc/ html/rfc4180 [48] By. (s. f.). Selenium. Recuperado 13 de mayo de 2021, de https://www.selenium.dev/selenium/ docs/api/java/org/openqa/selenium/By.html 101 [49] XML Path Language (XPath) 3.1. (s. f.). W3.Org. Recuperado 15 de mayo de 2021, de https: //www.w3.org/TR/2017/REC-xpath-31-20170321/ [50] Documentaci´on de Windows Forms para .NET. (s. f.). Microsoft Docs. Recuperado 20 de mayo de 2021, de https://docs.microsoft.com/es-es/dotnet/desktop/winforms/?view= netframeworkdesktop-4.8 [51] BackgroundWorker Clase (System.ComponentModel). (s. f.). Microsoft Docs. Recuperado 20 de mayo de 2021, de https://docs.microsoft.com/es-es/dotnet/api/system.componentmodel. backgroundworker?view=net-5.0 [52] SqlConnection Clase (System.Data.SqlClient). (s. f.). Microsoft Docs. Recuperado 21 de mayo de 2021, de https://docs.microsoft.com/es-es/dotnet/api/system.data.sqlclient. sqlconnection?view=dotnet-plat-ext-5.0 [53] System.Data.SqlClient 4.8.2. (s. f.). NuGet. Recuperado 21 de mayo de 2021, de https://www.nuget. org/packages/System.Data.SqlClient 102