Creación de una botnet

Universidad de Valladolid ESCUELA DE INGENIER´ IA INFORM´ ATICA GRADO EN INGENIER´ IA INFORM ´ ATICA MENCI´ ON EN TECNOLOG´ IAS DE LA INFORMACI ´ ON Creaci´on de una botnet Alumno: Javier Barrientos Gonz´alez Tutor: Blas Torregrosa Garc´ıa A mi familia. I II AGRADECIMIENTOS Agradecimientos Agradecimientos a mi familia por todo el apoyo que me ha dado a lo largo de este camino. III AGRADECIMIENTOS IV RESUMEN Resumen El objetivo de este proyecto es dise˜nar y desarrollar una botnet con fines educativos utilizando el protocolo IP. Para su desarrollo se han estudiado varios ejemplos para analizar sus m´etodos de comunicaci´on, protecci´on y ocultaci´on. Este proyecto requiere la implementaci´on de un servidor central o C&C contra el que se comunicar´a cada bot, al igual que un sito web para que el administrador de la botnet pueda controlarlos. Cada bot estar´a desplegado remotamente y se le podr´a asignar diferentes tareas por lo que tambi´en se desarrollar´a su l´ogica. Los bots tienen como objetivo aquellos ordenadores cuyo sistema operativo sea base Windows. El trabajo se ha desarrollado empleando Python como lenguaje de programaci´on, gRPC para la comunicaci´on entre los bots y el servidor y Flask como framework para el desarrollo de la aplicaci´on web que se utilizar´a para administrar la botnet. Todo el proyecto ha sido elaborado siguiendo la metodolog´ıa ´agil Scrum. V RESUMEN VI ABSTRACT Abstract The objective of this project is to design and develop a botnet for educational purposes using the IP protocol. For its development, several examples have been studied to analyze its communication, protection and concealment methods. This project requires the implementation of a central or C&C server against which each bot will communicate, as well as a website so that the botnet administrator can control them. Each bot will be remotely deployed and can be assigned different tasks so its logic will also be developed. The bots target those computers whose operating system is Windows based. The work has been developed using Python as the programming language, gRPC for communication between the bots and the server, and Flask as a framework for the development of the web client that will be used to manage the botnet. The entire project has been developed following the agile Scrum methodology. VII ´ INDICE GENERAL XIV ´ INDICE DE FIGURAS ´ Indice de figuras 2.1. Botnet centralizada[10] .............................. 8 2.2. Botnet descentralizada[10] ............................ 8 2.3. Cyber Kill Chain .................................. 11 2.4. Pasos que realiza una botnet ............................ 12 3.1. DesarrolloScrum[16] ............................... 17 5.1. Entorno de riesgos de un proyecto. . . . . . . . . . . . . . . . . . . . . . . . . 35 6.1. Arquitectura cliente/servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 6.2. Diagrama de conceptos [4] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.3. Modelodedominio................................. 47 6.4. Modelodedespliegue................................ 48 7.1. Entornodelaboratorio............................... 50 7.2. Comportamiento de la botnet ........................... 51 A.1. Apariencia final de la p´agina principal. . . . . . . . . . . . . . . . . . . . . . . 75 A.2. Apariencia final de la p´agina de los bots...................... 76 A.3. Apariencia final de la p´agina de informaci´on de un bot con la informaci´on y la geolocalizaci´on.................................... 77 A.4. Apariencia final de la p´agina de informaci´on de un bot con las tareas. . . . . 78 XV ´ INDICE DE FIGURAS A.5. Apariencia final de la p´agina de las tareas. . . . . . . . . . . . . . . . . . . . . 79 A.6. Apariencia final de la p´agina del formulario para a˜nadir una nueva tarea. . . 79 A.7. Apariencia final de la p´agina de informaci´on de una tarea. . . . . . . . . . . . 80 A.8. Apariencia final de la p´agina de logs........................ 80 A.9. Apariencia final de la p´agina de archivos. . . . . . . . . . . . . . . . . . . . . 80 A.10.Apariencia final de la p´agina del mapa. . . . . . . . . . . . . . . . . . . . . . . 81 A.11.Apariencia final de la p´agina del mapa con el di´alogo del bot seleccionado. . . 81 XVI ´ INDICE DE TABLAS ´ Indice de tablas 3.1. Planificaci´on de los sprints ............................ 18 3.2. Historiasdeusuario ................................ 19 3.3. Continuaci´on de historias de usuario . . . . . . . . . . . . . . . . . . . . . . . 20 3.4. TareasSprint0................................... 21 3.5. Tareas sprint 1 ................................... 22 3.6. Tareas sprint 2 ................................... 22 3.7. Tareas sprint 3 ................................... 23 3.8. Tareas sprint 4 ................................... 24 3.9. Tareas sprint 5 ................................... 25 3.10. Tareas sprint 6 ................................... 26 3.11. Tareas sprint 7 ................................... 27 3.12. Tareas sprint 8 ................................... 28 5.1. Riesgo de falta de formaci´on . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36 5.2. Riesgodeenfermedad ............................... 37 5.3. Riesgo de cambios en los requisitos . . . . . . . . . . . . . . . . . . . . . . . . 37 5.4. Riesgo de planificaci´on optimista . . . . . . . . . . . . . . . . . . . . . . . . . 37 5.5. Riesgo de fallo del entorno de laboratorio . . . . . . . . . . . . . . . . . . . . 37 5.6. Riesgo de falta de seguimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 5.7. Riesgo de cambios en las tecnolog´ıas utilizadas . . . . . . . . . . . . . . . . . 38 XVII ´ INDICE DE TABLAS 5.8. Presupuestofinal.................................. 39 8.1. Prueba ejecuci´on del bot en el entorno de laboratorio . . . . . . . . . . . . . . 59 8.2. Prueba de comunicaci´on del bot con el servidor encendido . . . . . . . . . . . 59 8.3. Prueba de comunicaci´on del bot con el servidor apagado . . . . . . . . . . . . 60 8.4. Prueba del bot solicitando tareas al servidor . . . . . . . . . . . . . . . . . . . 60 8.5. Prueba del bot realizando la tarea de ejecuci´on de un comando . . . . . . . . 60 8.6. Prueba del bot realizando la tarea de subir un fichero a la m´aquina remota . 60 8.7. Prueba del bot al realizar la tarea de enviar un fichero inexistente . . . . . . . 61 8.8. Prueba del bot al realizar la tarea de enviar un fichero . . . . . . . . . . . . . 61 8.9. Prueba del bot al realizar la tarea de tomar una captura de pantalla . . . . . 61 8.10. Prueba del bot al realizar la tarea de apagarse . . . . . . . . . . . . . . . . . . 61 8.11. Prueba del bot al realizar la tarea de eliminarse . . . . . . . . . . . . . . . . . 62 8.12. Prueba del bot enviando las tareas completadas . . . . . . . . . . . . . . . . . 62 8.13. Prueba acceso a la p´agina de los bots con el servidor apagado . . . . . . . . . 62 8.14. Prueba de la aplicaci´on accediendo a la p´agina de los bots ........... 62 8.15. Prueba de la aplicaci´on accediendo a un bot existente . . . . . . . . . . . . . 63 8.16. Prueba de la aplicaci´on accediendo a un bot que no existe . . . . . . . . . . . 63 8.17. Prueba de la aplicaci´on accediendo a la p´agina de las tareas con el servidor apagado....................................... 63 8.18. Prueba de la aplicaci´on accediendo a la p´agina de las tareas . . . . . . . . . . 63 8.19. Prueba de la aplicaci´on accediendo a la p´agina de a˜nadir prueba sin tener bots disponibles ..................................... 64 8.20. Prueba de la aplicaci´on agregando una nueva tarea . . . . . . . . . . . . . . . 64 8.21. Prueba de la aplicaci´on agregando una nueva tarea sin completar los campos 64 8.22. Prueba de la aplicaci´on descargando ficheros . . . . . . . . . . . . . . . . . . . 64 8.23. Prueba de la aplicaci´on descargando ficheros que no existen . . . . . . . . . . 65 XVIII CAP´ ITULO 1. INTRODUCCI ´ ON, OBJETIVOS Y MOTIVACI ´ ON Cap´ıtulo 1 Introducci´on, objetivos y motivaci´on 1.1. Introducci´on En los ´ultimos a˜nos se ha podido ver un considerable aumento de dispositivos inteligentes IoT (Internet of Things) a lo largo de todo el globo. Si junto a esta expansi´on unimos la falta de seguridad en la mayor´ıa de estos dispositivos podemos conseguir que estos sean un recept´aculo perfecto para software malicioso, cuyo principal fin es obligar al dispositivo a pertenecer a una red mucho mayor con otros dispositivos infectados que, entre muchas de las posibles opciones, destacan la realizaci´on de ataques de denegaci´on de servicio (DDoS) y el minado de criptomonedas de manera remota. En este proyecto se abordar´a el proceso de creaci´on de un servidor central y una aplicaci´on web para el control y la monitorizaci´on de manera remota de los diferentes dispositivos Windows infectados que componen los bots o zombis de nuestra botnet, siendo estos infectados por un troyano que tambi´en se ha desarrollado. 1.2. Motivaci´on En lo referente a las botnets, documentar, estudiar y desarrollar nuevas t´ecnicas de comunicaci´on por red. El comprender como funcionan, las t´ecnicas que usan actualmente y sus objetivos pueden ser mi principal motivaci´on a la hora de realizar este proyecto. 1 1.3. OBJETIVOS DEL PROYECTO 1.3. Objetivos del proyecto 1.3.1. Objetivos de desarrollo El principal objetivo del desarrollo de este proyecto es la creaci´on de una botnet con fines educativos. Para ello se utilizar´a un entorno de ataque seguro utilizando una red de ordenadores previamente preparados. En dicho entorno la m´aquina objetivo es una m´aquina Windows con la ´ultima versi´on del sistema operativo instalado mientras que la m´aquina que contiene el servidor de la botnet tendr´a un sistema operativo Kali Linux. Para conseguir este objetivo se crear´a un servidor central desde donde se controlar´an los bots y desde donde obtendr´an las diferentes tareas a realizar. Para poder controlar el servidor central se crear´a una aplicaci´on web que tambi´en se desplegar´a en la m´aquina del servidor. Entre las opciones planteadas se encuentra la posibilidad de ejecutar comandos de manera remota, subir ficheros desde el servidor al ordenador infectado y la capacidad de bajar ficheros de este al servidor. Todo ello se har´a mediante una conexi´on remota por canales gRPC seguros bajo encriptaci´on y basados en HTTP/2 como protocolo de comunicaci´on. 1.3.2. Objetivos personales Como el proyecto a desarrollar es completamente educativo y est´a desarrollado como Trabajo de Fin de Grado, tambi´en presenta unos puntos de objetivos personales: Conocer en profundidad el protocolo IP. Aumentar mi habilidad con Python como lenguaje de programaci´on principal. Desarrollar mi conocimiento en tecnolog´ıas actuales de llamadas a procedimientos remotos, empleando gRPC y Protocol Buffers, pues ambos me parecen tecnolog´ıas muy potentes con una gran flexibilidad para el paso de mensajes y que, en un futuro, me gustar´ıa seguir aprendiendo y desarrollando en base a estas tecnolog´ıas. Interesarme, a´un m´as (si cabe), por el mundo de la ciberseguridad, la proliferaci´on de nuevos retos y la creaci´on de nuevas herramientas tanto de ataque, descubrimiento o de control. Comprender y explorar las posibilidades del sistema operativo Windows como base actual del proyecto a desarrollar. Entender y aprender el marco de trabajo de Scrum, cuyo uso hoy en d´ıa es muy habitual en m´ultiples procesos y entornos laborales de desarrollo software. 1.4. Estructura de la memoria El resto del documento est´a estructurado de la siguiente forma: 2 CAP´ ITULO 1. INTRODUCCI ´ ON, OBJETIVOS Y MOTIVACI ´ ON Cap´ıtulo 2: trata sobre el estado del arte, una visi´on general de las botnets por la historia y herramientas importantes utilizadas para el desarrollo de la tarea. Cap´ıtulo 3: trata sobre la metodolog´ıa de trabajo, as´ı como de las tareas desarrolladas a lo largo del proyecto. Cap´ıtulo 4: trata sobre las tecnolog´ıas utilizadas durante todo el proyecto. Cap´ıtulo 5: trata sobre los riesgos y el presupuesto del propio proyecto. Cap´ıtulos 6, 7 y 8: tratan, respectivamente, del dise˜no, implementaci´on y las pruebas. Cap´ıtulo 9: trata sobre el despliegue de la aplicaci´on y los pasos a seguir. Cap´ıtulo 10: trata sobre las conclusiones finales y las futuras mejoras que puede tener el proyecto. Ap´endices: presentamos dos ap´endices, el primero hace referencia al manual de usuario de la aplicaci´on web desarrollada y el segundo es el fichero .proto utilizado durante este proyecto para la serializaci´on de los mensajes entre el servidor y, la aplicaci´on web o el bot. 3 1.4. ESTRUCTURA DE LA MEMORIA 4 CAP´ ITULO 2. ESTADO DEL ARTE Cap´ıtulo 2 Estado del arte 2.1. Botnet 2.1.1. ¿Qu´e es una botnet? Una botnet [10] es un conjunto de dispositivos conectados a Internet que han sido infectados por un programa malicioso y que reciben ´ordenes de manera remota. Los dispositivos infectados son llamados bots o zombis. La principal caracter´ıstica es que cualquier equipo con conexi´on a Internet puede ser infectado y pasar a formar parte de una botnet. Al administrador de la red de dispositivos infectados se le llama botmaster. El servidor o entorno desde donde se gestiona la red se llama C&C (Command and Control). 2.1.2. Historia Los bots fueron desarrollados en un inicio como herramientas de gesti´on para canales IRC [38], proporcionando servicios de manera autom´atica al usuario y evitaban el cierre del canal debido a la inactividad, entre muchas de sus tareas. En marzo de 1999 fue descubierto el bot malicioso PrettyPark [17]. Era un gusano cuyas funciones son comunes a los bots de hoy en d´ıa. Alguna de sus caracter´ısticas son: la posibilidad de obtener el nombre, sistema operativo e informaci´on b´asica del dispositivo, la habilidad de obtener usuarios y contrase˜nas de los ajustes de red, redirecci´on de tr´afico o incluso ataques de denegaci´on de servicio. Los comandos maliciosos eran transmitidos a trav´es de un canal, siendo as´ı una de las primeras botnets. 5 2.3. MITRE ATT&CK 2.2.1. Cyber Kill Chain y las botnets A continuaci´on se expone el modelo de funcionamiento de una botnet (Figura 2.4) utilizando el ciclo de vida de un ciberataque descrito anteriormente. Figura 2.4: Pasos que realiza una botnet La primera etapa se reconoce los dispositivos que van a ser infectados para pertenecer a la botnet. Durante esta etapa se identifican sus caracter´ısticas, as´ı como sus puntos d´ebiles y la mejor manera de atacarles. Tras la anterior etapa, se prepara el ataque. Hay varias maneras de infectar un dispositivo, la m´as com´un es a trav´es de un troyano. Se puede ayudar de un correo electr´onico malicioso o ficheros adjuntos maliciosos. La etapa de distribuci´on est´a ligada de manera directa con esta etapa. Una vez el malware est´a en el dispositivo objetivo, se detona el ataque, comprometi´endolo. Si se compromete el dispositivo de manera correcta, el malware o troyano se instala en el dispositivo de la v´ıctima, inicia comunicaci´on con el servidor central y crea persistencia en el equipo. La ´ultima etapa real es la referente al comando y control. En esta etapa el dispositivo pertenece a la botnet, se comunica con el servidor central y, desde este, se le env´ıan tareas que realizar. Los objetivos, una vez cumplidos, son reenviados al servidor central y desde este se le vuelven a asignar nuevas tareas. Es por eso que en la figura se describe un bucle sobre esta etapa, el zombi est´a preguntando y realizando las tareas que se le vayan asignando. 2.3. MITRE ATT&CK MITRE [13] es una corporaci´on no gubernamental. Provee ingenier´ıa de sistemas, investigaci´on y desarrollo, y soporte sobre tecnolog´ıas de la informaci´on al gobierno de Estados Unidos. Posee un framework llamado MITRE ATT&CK (T´acticas, T´ecnicas y Conocimiento Com´un de Adversarios) [14], una plataforma que organiza y categoriza los distintos tipos de ataques, amenazas y procedimientos realizados por los distintos atacantes en el mundo digital y que permite identificar vulnerabilidades en los sistemas inform´aticos. El entorno presenta dos matrices principales: 12 CAP´ ITULO 2. ESTADO DEL ARTE Matriz empresarial (Enterprise): la matriz empresarial contiene informaci´on para las siguientes plataformas: Windows, macOS, Linux, PRE, Azure AD, Office 365, Google Workspace, SaaS, IaaS, red y contenedores. Matriz m´ovil (Mobile): la matriz m´ovil contiene informaci´on para las siguientes plataformas: iOS y Android. Esta base de conocimiento puede ser ´util para crear un mapa del sistema de defensa de una compa˜n´ıa o dispositivo ya que se describen principalmente los compartimientos de los atacantes. Tambi´en puede ser usado a la inversa, y aprender y comprender el funcionamiento de diversas t´ecnicas de reconocimiento, ataque y explotaci´on. Existe una herramienta online [15] para dise˜nar y categorizar las pruebas realizadas sobre diferentes sistemas y llevar un control de los resultados que se fueron obteniendo. 13 2.3. MITRE ATT&CK 14 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO Cap´ıtulo 3 Planificaci´on y desarrollo del proyecto 3.1. Scrum 3.1.1. Introducci´on Scrum [45] es un marco de trabajo para el desarrollo ´agil de software. En este proceso se aplican de manera regular un conjunto de buenas pr´acticas para poder sacar adelante el proyecto trabajando en equipo lo mejor posible. Scrum es utilizado en entornos complejos, donde se necesitan resultados r´apidos y los requisitos son cambiantes. La principal idea es reducir la complejidad del producto ayudado de la fuerza del trabajo en equipo. Scrum se basa en tres pilares: Transparencia. Los aspectos importantes del proceso deben ser visibles y entendibles por todos aquellos relacionados con el proyecto. La transparencia obliga a definir estos elementos siguiendo un est´andar com´un. Inspecci´on. El progreso debe ser inspeccionado de manera constante para detectar variaciones indeseadas de cara al resultado final. Este trabajo no debe ser muy repetitivo para evitar interferencias con el trabajo. Adaptaci´on. Si se detectan variaciones indeseadas que desv´ıan de l´ımites aceptables a un determinado proceso, este debe ser reajustado en el menor tiempo posible para evitar desviaciones mayores. 15 3.1. SCRUM 3.1.2. Equipo Scrum El Scrum Team o Equipo Scrum se compone de tres roles: el Product Owner, el Scrum Master y el Development Team. Product Owner.Representa al cliente y determina la visi´on del producto. Es el m´aximo responsable del valor del producto final y del trabajo del equipo de desarrollo ya que su labor principal es gestionar las prioridades a la hora de realizar las diferentes tareas. Scrum Master.Es el facilitador, su deber es potenciar la productividad del equipo y asegurarse que todos utilicen Scrum de manera correcta. Development Team.Son los profesionales encargados de realizar el trabajo a entregar. Es un equipo autoorganizado. La principal caracter´ıstica de estos equipos es su autoorganizaci´on, evitando que las competencias para poder desarrollar el trabajo dependan de personas ajenas al equipo. 3.1.3. Eventos Scrum presenta eventos predefinidos para minimizar la necesidad de realizar reuniones fuera del plan y crear as´ı una cierta regularidad. Los eventos son bloques de tiempo fijo que se dan a lo largo de las diferentes etapas del proyecto. Sprint.Es el bloque principal que compone el desarrollo del proyecto. A lo largo del desarrollo se realizar´an varios sprints cuyo contenido asignado es invariable. Presenta una duraci´on m´axima entre dos y cuatro semanas. Durante todo el sprint el Scrum Master se encarga de supervisar el equipo para ayudar a que se cumpla el objetivo marcado. Reuni´on de planificaci´on (Sprint Planning). Antes de comenzar un sprint se debe realizar una reuni´on de planificaci´on. En esta reuni´on el cliente presenta la lista de requisitos (Product Backlog) la cual el Product Owner ordena por nivel de prioridad. El Development Team, a partir de los requisitos con mayor prioridad, genera una lista de tareas o Sprint Backlog. Estos requisitos seleccionados son los que el equipo debe desarrollar en el sprint. Objetivo del sprint (Sprint Goal). Meta establecida en el Sprint Planning para ayudar al Development Team a entender el porqu´e del sprint a realizar. Es un punto de uni´on del grupo con el proyecto. Reuni´on diaria (Daily Scrum). Reuni´on corta que realiza el equipo de desarrollo para sincronizar sus actividades. Se produce a la misma hora, en el mismo lugar todos los d´ıas para reducir la complejidad. Se tiene en cuenta lo trabajado desde el anterior 16 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO Daily Scrum para la proyecci´on del siguiente y as´ı evaluar el progreso hacia el objetivo del sprint. Este tipo de reuniones mejoran la comunicaci´on, eliminan la necesidad de realizar otras reuniones, identifican impedimentos durante el desarrollo y promueven la toma de decisiones r´apida. Revisi´on del sprint (Sprint Review). Al final del sprint se hace una reuni´on de revisi´on donde se entregan los requisitos completados al cliente. Es posible que se adapte el proyecto y la lista de requisitos para enfocarse en nuevos objetivos. Retrospectiva del sprint (Sprint Retrospective). Es una reuni´on que se realiza previa al siguiente sprint con el Scrum Master para tratar diferentes aspectos como el esfuerzo y su manera de trabajar, pudiendo abordar posibles mejoras o soluciones a la hora de optimizar el trabajo en equipo en el futuro. Figura 3.1: Desarrollo Scrum [16] 3.2. Planificaci´on Para este proyecto he adaptado el marco de trabajo de Scrum a un trabajo individual sin perder la esencia de los tres roles diferenciados mencionados con anterioridad. La mayor parte del tiempo he representado el rol de Development Team y solo en las ocasiones necesarias (al principio y al final del Sprint) he asumido el rol del Product Owner. El rol del Scrum Master ha estado siempre presente al llevar una rutina de trabajo diario durante los diferentes sprints. La duraci´on de los sprints son de dos semanas. El d´ıa asignado para las reuniones de revisi´on y retrospectiva del sprint ser´a el lunes, coincidiendo as´ı tras el paso de las 2 semanas asignadas. 17 3.3. TAREAS REALIZADAS Para la lista de requisitos (Product Backlog), al igual que para la lista de tareas (Sprint Backlog), he utilizado Trello, aplicaci´on que me permite controlar en todo momento el desarrollo y estado de cada tarea a lo largo de los Sprint. Al inicio del proyecto se realizar´a un sprint 0 para preparar la documentaci´on y la planificaci´on inicial. Esto favorecer´a el trabajo futuro dejando los dem´as sprints para el desarrollo, implementaci´on y despliegue del proyecto, complementando esta memoria cada poco tiempo. Este primer Sprint comenzar´a el 1 de marzo de 2021. El Trabajo Fin de Grado del grado de Ingenier´ıa Inform´atica de la Universidad de Valladolid [32] corresponde a un total de 12 cr´editos, lo equivalente unas 300 horas. En total, dada la disponibilidad, se utilizar´an unas 35 horas por iteraci´on, estimando que el proyecto ser´a desarrollando en 8 sprint (contando con el sprint 0). Durante el desarrollo se realiz´o un cambio de tecnolog´ıa que sucedi´o al final del sprint 1, haciendo que el planteamiento inicial, al igual que el dise˜no implementado, tuviera que ser modificado. Este cambio hizo que el proyecto se alargase un sprint m´as en el mes de Julio, provocando m´as carga de trabajo en el resto de sprint para compensar las horas perdidas. A continuaci´on se muestra en detalle la planificaci´on final del proyecto: Sprint Fecha inicio Fecha fin Notas Sprint 0 01/03/2021 15/03/2021 Planificaci´on inicial Sprint 1 15/03/2021 29/03/2021 Sprint 2 29/03/2021 12/04/2021 Cambio de tecnolog´ıa Sprint 3 12/04/2021 26/04/2021 Sprint 4 26/04/2021 10/05/2021 Sprint 5 10/05/2021 24/05/2021 Sprint 6 24/05/2021 07/06/2021 Sprint 7 07/06/2021 21/06/2021 Sprint 8 21/06/2021 05/07/2021 Periodo extraordinario Tabla 3.1: Planificaci´on de los sprints 3.3. Tareas realizadas En este apartado se mostrar´a una visi´on de las historias de usuario de este proyecto que est´an representadas en las tablas 3.2 y 3.3. A mayores se explicar´a el desarrollo de los sprints de manera concisa, mostrando las tareas de una manera m´as detallada. 18 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO N´umero H.U. Descripci´on 1 Mostrar los bots registrados El usuario consulta los bots que hay registrados en la base de datos junto a la informaci´on de la m´aquina infectada. 2 Mostrar la informaci´on de un bot El usuario consulta la informaci´on del bot almacenada en la base de datos (informaci´on de la m´aquina infectada, geolocalizaci´on, tareas pendientes, tareas completadas). 3 Mostrar tareas pendientes El usuario consulta las tareas pendientes totales que faltan por hacer, incluyendo su estado, el tipo de tarea, la hora a la que fue creada y a que bot va dirigida dicha tarea. 4 Mostrar tareas completadas El usuario consulta las tareas completadas totales, incluyendo el estado final, el tipo de tarea, la hora a la que fue creada, la hora a la que fue completada y que bot ha realizado dicha tarea. 5Mostrar la informaci´on de una tarea El usuario consulta la informaci´on de la tarea y comprueba si la tarea se ha completado. Si es as´ı, puede ver la respueta del bot. 6 A˜nadir una tarea El usuario a˜nade una tarea determinada a uno o varios bots a su lista de tareas pendientes. 7 Mostrar los logs de los bots El usuario consulta la lista de logs de los bots que se han conectado con el servidor, as´ı como su posibilidad para descargar el fichero. 8 Mostrar el log del servidor El usuario consulta el log del servidor con su posibilidad de descargar el fichero. 9Mostrar los elementos descargados de las m´aquinas infectados El usuario consulta los archivos descargados por las diferentes tareas que han realizado los bots con la posibilidad de descargar el fichero. 10 Mostrar los bots registrados en un mapa El usuario puede consultar la ubicaci´on geogr´afica de los bots registrados en un mapa global. 11 Registrar un bot en el servidor El bot se conecta autom´aticamente con el servidor y se registra su informaci´on principal. Tabla 3.2: Historias de usuario 19 3.3. TAREAS REALIZADAS N´umero Tarea Descripci´on 12 Obtener las tareas pendientes El bot pregunta al servidor cada cierto periodo de tiempo si tiene tareas pendientes y, si es as´ı, las recibe desde el servidor. 13 Realizar una tarea El bot realiza autom´aticamente una tarea pendiente. 14 Enviar una tarea realizada El bot env´ıa al servidor una tarea completada. 15 Eliminar un bot El usuario puede eliminar uno o varios bots de manera remota. Tabla 3.3: Continuaci´on de historias de usuario Las tareas en detalle estar´an representadas por un identificador con el n´umero de la tarea, el tipo de tarea realizada, su descripci´on para ayudar a entender en qu´e consiste el trabajo, cuantas horas me ha llevado su realizaci´on y si se ha podido completar en el tiempo asignado. Los tres tipos de tareas presentes a lo largo del proyecto son: DOC. Tarea centrada en la realizaci´on de la documentaci´on, estudio y desarrollo de la parte te´orica del proyecto. DEV. Tarea centrada en el desarrollo del producto. TEST. Tarea centrada en la realizaci´on de pruebas sobre la robustez y la funcionalidad. 3.3.1. Sprint 0 Durante este sprint se aborda y se trabaja la mayor´ıa de los aspectos generales sobre el proyecto (formaci´on y herramientas necesarias para el proyecto) as´ı como la mayor parte del contenido te´orico de la memoria. Sin embargo la tarea 2 no fue completada por una mala estimaci´on del peso de la tarea, dejando incompleta esta tarea para el siguiente sprint. En la tabla 3.4 se muestran las tareas planificadas. En total se emplearon 32 horas para la realizaci´on del sprint 0. 20 CAP´ ITULO 3. PLANIFICACI ´ ON Y DESARROLLO DEL PROYECTO Tarea Tipo Descripci´on Horas Estado T001 DOC Redacci´on de los apartados de introducci´on y objetivos 4 Finalizada T002 DOC Redacci´on del apartado del estado del arte 5 No finalizada T003 DOC Redacci´on del apartado de an´alisis del proyecto 4 Finalizada T004 DEV Creaci´on y configuraci´on del entrono de trabajo virtual Python 1 Finalizada T005 DOC Formaci´on sobre sockets en Python 6 Finalizada T006 DOC Formaci´on sobre backdoors en Python 12 Finalizada 32 Tabla 3.4: Tareas Sprint 0 3.3.2. Sprint 1 Esta iteraci´on comienza el mismo d´ıa que acaba el anterior sprint. Lo primero que se hace es finalizar la tarea sobre la redacci´on del estado del arte en la memoria. Una vez finalizada se contin´ua con el dise˜no del proyecto y la descripci´on de las tareas que realizar´an los bots. Una vez documentado toda la base te´orica del proyecto se procede a iniciar la creaci´on del proyecto en GitLab, seguido de la creaci´on del servidor y el cliente (o bot). El servidor consta de una interfaz por terminal que permite gestionar diferentes aspectos recogidos en la tabla de tareas planteadas como la consulta de bots registrados o la posibilidad de a˜nadir una tarea. El cliente es un archivo que se mantiene en bucle que cumple la principal funci´on de preguntar si existen tareas para ´el y, en el caso de ser as´ı, obtenerlas. Se llegan a realizar todas las tareas a excepci´on de la creaci´on del primer m´odulo para la ejecuci´on de comandos de manera remota por parte del bot. En este caso la tarea quedar´a a medias y deber´a ser completada en el siguiente sprint. Por ´ultimo, y tras una reuni´on con el tutor, se revis´o el dise˜no principal del proyecto as´ı como la tecnolog´ıa utilizada para el paso de mensajes entre el cliente y el servidor. Al tutor no le gust´o la idea de utilizar una tecnolog´ıa tan rudimentaria para un trabajo donde la conectividad es un pilar fundamental. En este caso el tutor me recomend´o utilizar la tecnolog´ıa gRPC y Protocol Buffers frente a la tecnolog´ıa de sockets. Por este motivo, el trabajo realizado hasta el momento qued´o inservible (a excepci´on de la tarea a medio realizar) teniendo que replantear para el siguiente sprint todo el dise˜no y buscando nueva documentaci´on y formaci´on acerca de esta nueva tecnolog´ıa. En la tabla 3.5 se muestran las tareas planificadas. En total se emplearon 39.5 horas para la realizaci´on del Sprint 1. 21 3.3. TAREAS REALIZADAS En la tabla 3.12 se muestran las tareas planificadas. En total se emplearon 44 horas para la realizaci´on del sprint 8. Tarea Tipo Descripci´on Horas Estado T073 DEV Desarrollo del m´odulo del servidor de la base de datos 8 Finalizada T074 TEST Pruebas entre el bot, el servidor y la aplicaci´on web 12 Finalizada T075 DEV Desarrollo del m´odulo de persistencia del bot 8 Finalizada T076 DEV Despliegue del proyecto en el entorno de laboratorio de la escuela 2 Finalizada T077 TEST Pruebas entre el bot, el servidor y la aplicaci´on web en en el entorno de laboratorio 6 Finalizada T078 DOC Finalizaci´on de la memoria 8 Finalizada 44 Tabla 3.12: Tareas sprint 8 28 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS Cap´ıtulo 4 Tecnolog´ıas utilizadas 4.1. Python Python [43] es un lenguaje de programaci´on interpretado, multiparadigma, orientado a objetos y de alto nivel. Apareci´o en 1991 y a d´ıa de hoy es uno de los lenguajes m´as utilizados en todo el mundo. Su ´ultima versi´on estable es la 3.9.5. La elecci´on de Python para realizar el proyecto ha sido su facilidad para realizar scripts al igual que la creaci´on de m´odulos instalables y de f´acil modificaci´on. Todo el desarrollo de este proyecto se ha realizado bajo la versi´on estable 3.8.6. 4.1.1. Requests El paquete Requests [40] permite realizar en Python, de manera simple, peticiones HTTP. Es uno de los paquetes m´as descargados en la actualidad y su utilidad es muy extendida entre la comunidad. Se utilizar´a para la interacci´on entre el frontend y el backend de la aplicaci´on web de gesti´on de la botnet. 4.1.2. pytz El paquete pytz [6] contiene la base de datos Olson tz, tambi´en llamada tz o zoneinfo [28], que permite los c´alculos de zonas horarias de manera precisa. Permite obtener la zona horaria a trav´es de la localizaci´on pasada. El principal uso es complementar la asignaci´on de tiempos a˜nadiendo a estos la zona horaria correspondiente. 29 4.2. GRPC 4.1.3. PyScreeze El paquete PyScreeze [48] permite tomar capturas de pantalla y posee varios m´etodos para su almacenamiento. Es necesario el m´odulo Pillow [11]. Se utilizar´a para la confecci´on de una de las tareas de los bots. 4.1.4. PyInstaller El paquete PyInstaller [22] permite agrupar una aplicaci´on escrita en Python y sus dependencias en un ´unico ejecutable. Dicho programa resultante puede ser utilizado sin necesidad de tener un int´erprete de Python instalado. La aplicaci´on final, referente al bot del proyecto, es generado utilizando este paquete. 4.2. gRPC gRPC [4] es un framework de llamada de procedimiento remoto (RPC) de c´odigo abierto que puede ejecutarse en cualquier entorno. Fue desarrollado en un inicio por Google. Se utiliza para conectar servicios de manera eficiente con m´ultiples aplicaciones como el balanceo de carga o la verificaci´on y autenticaci´on. Para este proyecto se utilizar´an llamadas gRPC en Python [5] para transmitir la informaci´on entre las diferentes partes del proyecto (cliente web, bots y servidor gRPC) a trav´es del protocolo HTTP/2. 4.2.1. Protocol Buffers Las llamadas gRPC son definidas utilizando los llamados Protocol Buffers [23], un mecanismo de serializaci´on de estructuras de datos. La idea de los Protocol Buffers es definir como se van a estructurar los datos y, una vez compilados, se genera el c´odigo fuente que permite escribir y leer f´acilmente dichos datos. Su implementaci´on permite a las llamadas gRPC la creaci´on y composici´on de diferentes tipos de mensajes. 4.3. Flask Flask [41] es un framework minimalista escrito en Python. Se utiliza para la creaci´on de aplicaciones web utilizando Python y Jinja2 [42] para el tratamiento de plantillas. En este proyecto se utilizar´a para crear la aplicaci´on web que controlar´a el servidor gRPC, constituyendo as´ı el servidor C&C de la botnet. 30 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS 4.4. SQLite SQLite [26] es un sistema de gesti´on de bases de datos relacional escrito en C cuyo motor SQL destaca en ser peque˜no, r´apido, aut´onomo y de gran confiabilidad. Est´a integrado en la mayor´ıa de dispositivos m´oviles, ordenadores y aplicaciones. Su formato es multiplataforma y compatible con versiones anteriores. El c´odigo fuente es de dominio p´ublico. Para este proyecto se utilizar´a una base de datos relacional para el almacenamiento y gesti´on de los diferentes bots y sus correspondientes tareas. 4.4.1. DB Browser DB Browser [39] es una herramienta de c´odigo abierto que permite crear, dise˜nar y editar archivos de bases de datos que son compatibles con SQLite. Se ha utilizado la aplicaci´on para comprobar y verificar, de manera visual bajo un entorno amigable, la base de datos del proyecto (datos, tablas, etc.). 4.5. Leaflet Leaflet [2] es una biblioteca JavaScript de c´odigo abierto basada en OpenStreetMaps [12] que permite la realizaci´on de mapas interactivos cuyo enfoque es la simplicidad, el rendimiento y la facilidad de uso. Al ser de c´odigo abierto su implementaci´on es totalmente gratuita. Se utiliza esta biblioteca para el mapeo unitario o global de los bots conectados y registrados por la botnet a partir de su direcci´on. 4.6. Bootstrap Bootstrap [50] es uno de los frameworks de HTML, CSS y JavaScript m´as populares en la actualidad para la composici´on de p´aginas web. Una de sus principales prestaciones es el dise˜no m´ovil. En este proyecto se utilizar´a para crear la parte frontend de la aplicaci´on web de gesti´on de la botnet. 4.6.1. Bootstrap Table Bootstrap Table [51] es una extensi´on de las funcionalidades originales del framework Bootstrap. 31 4.7. GIT Se ha utilizado para complementar los elementos originales de Bootstrap (principalmente las tablas creadas) para a˜nadir, en este caso, filtros din´amicos del contenido de la tabla. 4.7. Git Git [24] es una herramienta gratuita de control de versiones de c´odigo abierto. Se utiliza para el desarrollo y el mantenimiento del c´odigo, as´ı como de las diferentes versiones de las aplicaciones. Se estructura en repositorios, cada uno de los cuales almacena los archivos que constituyen el proyecto. En este proyecto he utilizado las diferentes herramientas que me ha ofrecido Git para mantener, organizar y actualizar el c´odigo fuente del proyecto. 4.7.1. GitLab Una de las herramientas que ofrece la Escuela de Ingenier´ıa Inform´atica de la Universidad de Valladolid de manera gratuita es un entorno de GitLab [31] para poder gestionar los proyectos creados a lo largo de la carrera. GitLab [29] es un servicio web de control de versiones y desarrollo de software colaborativo basado en Git. 4.8. LaTeX LaTeX [34] es un sistema de composici´on de textos, orientado a la creaci´on de documentos escritos que presenten una alta calidad tipogr´afica. LaTeX es el est´andar para la comunicaci´on y publicaci´on de documentos cient´ıficos y est´a disponible como software libre y gratuito. 4.8.1. Overleaf Overleaf [25] es un editor colaborativo de LaTeX basado en la nube que se utiliza para escribir, editar y publicar documentos cient´ıficos. He utilizado Overleaf para poder escribir y editar la memoria del proyecto. Al ser un servicio basado en la nube se puede realizar dicho trabajo desde cualquier lugar con la ventaja de que presenta un compilador integrado. 4.9. Astah Astah [3] es una herramienta de modelado UML. Se ha utilizado para desarrollar los diagramas de dise˜no y despliegue. 32 CAP´ ITULO 4. TECNOLOG´ IAS UTILIZADAS 4.10. Trello Trello [49] es una herramienta que permite la creaci´on, gesti´on y compartici´on de tableros en l´ınea. En ellos se pueden crear listas y dentro de estas listas agregar tarjetas con cierto contenido. Se ha utilizado para llevar a cabo el control del proyecto, as´ı como las tareas realizadas y las que faltan por realizar. 33 4.10. TRELLO 34 CAP´ ITULO 5. PLAN DE RIESGOS Y ESTIMACI ´ ON DE COSTES Cap´ıtulo 5 Plan de riesgos y estimaci´on de costes 5.1. Plan de riesgos Un riesgo [27] es un evento o condici´on que, en el caso de ocurrir, puede tener un efecto positivo o negativo sobre los objetivos del proyecto. Los riesgos pueden estar categorizados de diferentes maneras pero me basar´e en el modelo definido por Kalle Lyytinen y sus compa˜neros. Afirma que los cuatro pilares fundamentales de un proyecto son las personas involucradas o actores, la tecnolog´ıa utilizada, la estructura y las tareas a realizar. Los cuatro pilares est´an interconectados entre ellos, haciendo que, en diversas circunstancias, un problema dependa de otro o afecte de manera directa al resto. Figura 5.1: Entorno de riesgos de un proyecto. 35 5.1. PLAN DE RIESGOS Existen una serie de pautas o pasos para llevar a cabo un correcto plan de riesgos: 1. Identificaci´on de riesgos. 2. An´alisis de los riesgos. 3. Planificaci´on de riesgos. 4. Monitorizaci´on de riesgos. Lo m´as com´un es que los pasos del 1 al 3 se repitan de manera continua. 5.1.1. Riesgos encontrados en el proyecto En este apartado se van a detallar los riesgos detectados a la hora de desarrollar el proyecto. Estos riesgos afectan a los cuatro pilares explicados con anterioridad y, dependiendo del tipo de riesgo y de su probabilidad, se explicar´a tambi´en el plan de mitigaci´on y el plan de contingencia ante dicho riesgo. El impacto, al igual que la probabilidad, puede ser bajo (poca probabilidad o poco impacto al proyecto), medio (una probabilidad moderada o un impacto sustancial) o alto (es muy probable que suceda o que el impacto al proyecto sea demasiado directo). Los riesgos est´an descritos desde la tabla 5.1 hasta la tabla 5.7. Riesgo RG-01 Descripci´on Una persona del equipo de desarrollo no presenta suficiente formaci´on sobre las tecnolog´ıas empleadas Impacto Alto Probabilidad Medio Plan de mitigaci´on Se utilizan tecnolog´ıas conocidas que se han utilizado en la carrera y en el entorno de trabajo Plan de contingencia Solicitar ayuda a gente con mayor experiencia Tabla 5.1: Riesgo de falta de formaci´on 36 CAP´ ITULO 5. PLAN DE RIESGOS Y ESTIMACI ´ ON DE COSTES Riesgo RG-02 Descripci´on Una persona del equipo cae enfermo y deja de poder realizar las tareas asignadas Impacto Alto Probabilidad Baja Plan de mitigaci´on Disponer de tiempo extra al final del proyecto para, si hiciera falta, realizar un sprint de refuerzo Plan de contingencia Dejar varias tareas para futuras iteraciones Tabla 5.2: Riesgo de enfermedad Riesgo RG-03 Descripci´on Los requisitos cambian a˜nadiendo funcionalidad al proyecto no prevista en un inicio Impacto Alto Probabilidad Baja Plan de mitigaci´on Planear bien las tareas al inicio del proyecto Plan de contingencia Dejar varias tareas para futuras iteraciones Tabla 5.3: Riesgo de cambios en los requisitos Riesgo RG-04 Descripci´on No se cumplen los tiempos de entrega y el desarrollo del proyecto aumenta m´as de lo esperado Impacto Medio Probabilidad Media Plan de mitigaci´on Centrarse en las tareas principales que conforman el n´ucleo del proyecto Plan de contingencia Eliminar tareas extra o complementarias para centrarse en las principales Tabla 5.4: Riesgo de planificaci´on optimista Riesgo RG-05 Descripci´on Durante el desarrollo del proyecto se pueden producir varios fallos en las m´aquinas virtuales Impacto Medio Probabilidad Baja Plan de mitigaci´on Mantener el entorno en condiciones ´optimas Plan de contingencia Avisar a los t´ecnicos Tabla 5.5: Riesgo de fallo del entorno de laboratorio 37 6.2. GRPC 6.2.2. Protocol Buffers Los Protocol Buffers son un mecanismo de c´odigo abierto que se utiliza para serializar los datos de una manera estructurada y neutral, tanto al lenguaje como a la plataforma utilizada. Se utiliza en gRPC para describir tanto la interfaz de servicio como la estructura de los mensajes de dicha interfaz. Sus principales caracter´ısticas son las siguientes: Son eficientes, es decir, son detallados y descriptivos. Al ser de un tama˜no mucho menor que sus competidores proporcionan un mayor rendimiento. Se utilizan para intercambiar mensajes entre servicios, no entre navegadores. Son compilables, pudiendo generar bibliotecas y otros recursos en m´ultiples lenguajes de programaci´on. Se pueden especificar tipos concretos de datos, as´ı como campos de validaci´on. En un fichero de extensi´on .proto se definen los servicios y sus llamadas RPC y los mensajes que se van utilizar. Como se puede observar, en estos mensajes se define el tipo de dato as´ı como su orden. El fichero debe ser compilado por un compilador espec´ıfico para obtener las bibliotecas y el c´odigo necesario para su utilizaci´on. A continuaci´on podemos ver un ejemplo de la estructura de un fichero .proto. // Definici´on del servicio service HelloService { // Env´ıa un saludo rpc SayHello (HelloRequest) returns (HelloResponse); } // Mensaje de petici´on message HelloRequest { string greeting = 1; } // Mensaje de respuesta message HelloResponse { string reply = 1; } 6.2.3. Funcionamiento gRPC se basa en la idea de definir un servicio, especificando los m´etodos con sus par´ametros y sus respuestas. Todos estos servicios y m´etodos, junto a los mensajes, son definidos 44 CAP´ ITULO 6. DISE ˜ NO en un fichero .proto. En el lado del servidor se implementa una interfaz y se ejecuta un servidor gRPC para manejar las peticiones de los clientes. Por otro lado, el cliente posee c´odigo auxiliar que proporciona los mismos m´etodos que el servidor. El diagrama 6.2 muestra un esquema simple de como interact´uan las diferentes interfaces entre ellas. Figura 6.2: Diagrama de conceptos [4] Como se ha mencionado anteriormente, los clientes y los servidores gRPC se pueden ejecutar en diferentes arquitecturas y lenguajes, permitiendo la escalabilidad y el multilenguaje sin esfuerzo adicional, todo gracias a los ficheros .proto y los compiladores disponibles. En gRPC existen 4 variantes: Unary RPCs. El cliente env´ıa una ´unica solicitud y este recibe una ´unica respuesta. rpc SayHello(HelloRequest) returns (HelloResponse); Server streaming RPCs. El cliente env´ıa una ´unica solicitud y obtiene una secuencia de mensajes como respuesta. El cliente recibe mensajes hasta que no haya m´as. gRPC garantiza el orden de los mensajes. rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse); Client streaming RPCs. El cliente env´ıa una secuencia de mensajes al servidor. Una vez el cliente haya terminado de enviar los mensajes, el servidor los trata y devuelve una ´unica respuesta. gRPC garantiza el orden de los mensajes. 45 6.2. GRPC rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse); Bidirectional streaming RPCs. Transmisi´on bidireccional de mensajes en los que ambos env´ıan una secuencia de mensajes. Los dos flujos operan de manera independiente, haciendo que tanto clientes como servidores puedan leer y escribir en el orden que deseen. Se conserva el orden de los mensajes en cada flujo. rpc BidiHello(stream HelloRequest) returns (stream HelloResponse); 6.2.4. Ventajas F´acil de aplicar gracias a los archivos .proto. Mensajes sobre HTTP/2. La estructura por capas reduce el esfuerzo de programaci´on. Presenta autenticaci´on integrada. 6.2.5. Desventajas gRPC est´a a´un en un desarrollo temprano. La soluci´on de errores es compleja, requiere de instancias adicionales. Depende de una red estable y potente. No es compatible con el multicasting. 6.2.6. gRPC en este proyecto Se ha utilizado gRPC frente a otros servicios como REST para la comunicaci´on entre el servidor y los clientes o bots. Los bots pertenecientes a la botnet se comunican de manera directa y segura sobre HTTP/2 con el servidor. Dependiendo de la tarea asignada, el bot enviar´an un tipo de mensaje u otro (de los descritos anteriormente y definidos en el fichero .proto (Ap´endice B)) al servicio a trav´es de la interfaz. A mayores, la aplicaci´on web de administraci´on que utiliza el botmaster, se comunica con el servidor tambi´en a trav´es de canales creados por gRPC. Esta aplicaci´on web reside en el propio servidor, tal y como se puede observar en el modelo de despliegue. 46 CAP´ ITULO 6. DISE ˜ NO 6.3. Modelo de dominio Una vez analizadas las historias de usuario presentes en las tablas 3.2 y 3.3 se elabora el modelo de dominio presente en la figura 6.3. El modelo est´a centrado en los mensajes generados para la comunicaci´on gRPC. La estructura de este fichero est´a disponible en el Ap´endice B. Figura 6.3: Modelo de dominio 6.4. Modelo de despliegue El despliegue del proyecto est´a representado en la figura 6.4. 47 6.4. MODELO DE DESPLIEGUE Los bots se conectar´an con el servidor mediante conexiones HTTP/2, utilizando las interfaces creadas por gRPC para la comunicaci´on. El servidor est´a compuesto por el servidor gRPC que atiende las llamadas RPC tanto del botmaster como la de los bots. A mayores el servidor contiene una aplicaci´on Flask que utilizar´a el botmaster para gestional la botnet y acceder al servidor gRPC. Para acceder a la aplicaci´on Flask, el botmaster utilizar´a un navegador web cualquiera. Figura 6.4: Modelo de despliegue 48 CAP´ ITULO 7. IMPLEMENTACI ´ ON Cap´ıtulo 7 Implementaci´on Este cap´ıtulo trata sobre el entorno de laboratorio donde se ha desarrollado el proyecto, as´ı como la estructura final del c´odigo y la implementaci´on de la botnet. 7.1. Entorno de laboratorio Para el desarrollo de la botnet, as´ı como las pruebas y su despliegue, desde la Escuela de Ingenier´ıa Inform´atica de la Universidad de Valladolid se ha utilizado un entorno de laboratorio controlado. La figura 7.1 representa el esquema del entorno de laboratorio. En ´el podemos observar la organizaci´on de la red entre diferentes secciones. Aunque presente muchas redes y sistemas, nuestro servidor se encuentra en una m´aquina de la red “ATACANTES”, mientras que nuestra m´aquina objetivo est´a en la red “INTRANET”, protegida por un firewall de red. La m´aquina Kali Linux que cumplir´a el rol de servidor C&C posee las siguientes caracter´ısticas: Versi´on S.O.: Kali Linux 2021.1 (x64) Procesador: 2 procesadores Common KVM processor 2.53 GHz Memoria: 2 GB RAM Almacenamiento: 20 GB de espacio de almacenamiento La m´aquina Windows presente en la red “INTRANET”tendr´a asignado el rol de sistema infectado, siendo un sistema vulnerable donde realizar la ejecuci´on del bot de manera segura y controlada. Posee las siguientes caracter´ısticas: 49 7.2. IMPLEMENTACI ´ ON DE LA BOTNET Figura 7.1: Entorno de laboratorio Versi´on S.O.: Windows 10 Pro compilaci´on 19042.1083 (x64) Procesador: 2 procesadores Common KVM processor 2.53 GHz Memoria: 4 GB RAM Almacenamiento: 40 GB de espacio de almacenamiento La idea de utilizar un entorno de laboratorio reside en controlar la ejecuci´on de una herramienta como la desarrollada en este proyecto, evitando que terceros o personas ajenas a su desarrollo se vean afectadas de alguna manera. A mayores, al ser un entorno controlado, se puede monitorizar todas las conexiones y eventos que se realicen en las diferentes m´aquinas. 7.2. Implementaci´on de la botnet En este apartado trataremos el funcionamiento de la botnet, as´ı como las tareas que realiza y el funcionamiento de la aplicaci´on web de gesti´on de la red. Se ha realizado, con ayuda del framework MITRE ATT&CK mencionado anteriormente, un esquema para definir el comportamiento de la botnet (Figura 7.2). Se ha utilizado la matriz de empresa ya que da soporte a la plataforma objetivo, Windows. 50 CAP´ ITULO 7. IMPLEMENTACI ´ ON En la figura se˜nalada est´a marcado en verde los procedimientos utilizados, as´ı como las t´ecnicas utilizadas. Figura 7.2: Comportamiento de la botnet En el cap´ıtulo 2 se ha hablado del ciclo de vida que sigue una botnet. En este proyecto partimos desde el momento que el malware se ha ejecutado, es decir, desde el momento de explotaci´on. A partir de aqu´ı, los siguientes apartados hablar´an de la comunicaci´on entre el bot y el servidor, como se instala este en el sistema y como realiza las diferentes acciones para las cuales ha sido desarrollado. 7.2.1. Comunicaci´on con C&C El servidor C&C presenta una arquitectura cliente/servidor centralizada. Este servidor est´a situado en la m´aquina Kali Linux descrita anteriormente. Es dise˜nado bajo la tecnolog´ıa gRPC con el lenguaje de programaci´on Python. La comunicaci´on siempre se realiza desde el cliente al servidor, es decir, desde el zombi al servidor C&C. 51 7.2. IMPLEMENTACI ´ ON DE LA BOTNET La comunicaci´on con el servidor central se realiza a trav´es de las llamadas RPC descritas en el fichero .proto presente en el Ap´endice B utilizando canales seguros y encriptados. La botnet est´a desarrollada para que, aunque el servidor no est´e disponible, los bots en los distintos dispositivos se mantengan a la espera hasta que vuelvan a poder ponerse en contacto con el servidor C&C. Cuando el zombi consigue establecer conexi´on con el servidor, ya sea por primera vez o despu´es de no haber podido ponerse en contacto, se le env´ıa la informaci´on b´asica del dispositivo infectado, as´ı como su geoposici´on. Cuando el servidor recibe dicha informaci´on puede hacer dos cosas: registrar un nuevo bot o actualizar su estado. Al registrar un nuevo bot, se registra la informaci´on del dispositivo obtenida en la base de datos, as´ı como su posici´on. Se le da un valor de “conectado”haciendo que aparezca disponible para la asignaci´on de tareas. En cambio, si ya est´a registrado en la base de datos y solo si es necesario, se actualizan los valores guardados. A mayores, sea el estado que sea anterior, volver´a a aparecer como “conectado”. La primera vez que un bot se conecta se crear´a, tanto un log en la carpeta destinada a ellos, como una carpeta para las tareas de descargar ficheros o capturas de pantalla. 7.2.2. Persistencia Los bots est´an dise˜nados para mantenerse en el dispositivo objetivo. En este caso lo primero que se hace es crear un n´umero de serie ´unico, que ser´a el n´umero identificativo del bot de cara al servidor. Este n´umero es escondido en la carpeta del sistema %appdata %, seguido de una copia del propio malware para una ejecuci´on paralela. En este caso se ha dise˜nado que, si no existe persistencia en el dispositivo, se cree permitiendo que cada vez que se inicie sesi´on en la cuenta de usuario el bot copiado a la carpeta del sistema se ejecute y establezca conexi´on con el servidor (siguiendo el formato descrito en el apartado anterior) utilizando el n´umero de serie generado anteriormente. Si dicho n´umero no existe o se ha eliminado, se volver´a a crear. 7.2.3. Tareas implementadas A parte de establecer comunicaci´on entre el dispositivo infectado y el servidor los bots pueden realizar diferentes tareas de manera independiente. Esta es la parte central del desarrollo. Para saber que tareas debe realizar se ha establecido un sistema de sondeo al servidor cada cierto tiempo para preguntarlo. Estas tareas han sido dise˜nadas de manera modular tanto en el servidor como en el bot, permitiendo a˜nadir nuevos tipos de tareas o quitarlas sin afectar al comportamiento final de la botnet. La estructura del mensaje tarea est´a presente en el fichero .proto en el Ap´endice B. 52 CAP´ ITULO 7. IMPLEMENTACI ´ ON Las tareas que soporta esta botnet son las siguientes: Ejecuci´on de c´odigo remoto Esta tarea consiste en ejecutar comandos en el dispositivo de manera remota y, una vez completados, obtener la respuesta y guardar esta en el servidor y en la base de datos. Para la realizaci´on de esta tarea el bot presenta un m´odulo con las funciones necesarias para la creaci´on de instancias de PowerShell en Windows para la ejecuci´on de las l´ıneas de comando que se le pida. El comando va insertado dentro de la tarea que ha obtenido de la lista de tareas pendientes que el servidor le ha devuelto. Subir un fichero a la m´aquina remota Esta tarea consiste en subir un fichero a la m´aquina o dispositivo remoto a la misma carpeta donde se encuentra ejecut´andose el malware (carpeta %appdata %). En este caso la tarea contiene el nombre del fichero que el botmaster desea subir al dispositivo. Con esta informaci´on el bot env´ıa una petici´on al servidor pidiendo el fichero y la respuesta del servidor ser´a una serie de paquetes de datos o chunks, con la informaci´on acerca del fichero. Para asegurarnos que el fichero est´a disponible a la hora de enviarlo se crea una copia en una carpeta del servidor por si, por un error, el original es borrado o modificado. Descargar un fichero de la m´aquina remota Esta tarea consiste en bajar un fichero de la m´aquina o dispositivo remoto al servidor. En este caso la tarea contiene la direcci´on absoluta del fichero que deseamos descargar. El bot lo ´unico que debe hacer cuando lo encuentre es convertir la informaci´on en chunks y enviarlo al servidor, listo para guardarlo en la carpeta que posee para este tipo de ficheros. El fichero es posible que no exista, por lo que la tarea en ese caso se dar´a como completada pero con un estado de ”no localizado”. Tomar una captura de pantalla de la m´aquina remota Esta tarea consiste en la toma de una captura de pantalla de la pantalla principal del dispositivo infectado. Una vez se ha realizado la tarea la imagen se env´ıa de la misma manera que la descrita anteriormente para descargar un fichero de la m´aquina remota, solo que, en este caso, el nombre de la imagen empezar´a por “SCREENSHOT”seguido del identificador de la tarea. 53 P-003 Comunicaci´on del bot con el servidor apagado Descripci´on El bot est´a en ejecuci´on y quiere ponerse en contacto con el servidor cuando este est´a apagado. Resultado esperado El bot se mantiene a la espera ejecut´andose hasta que el servidor est´e disponible de nuevo. Resultado obtenido El bot se mantiene a la espera ejecut´andose hasta que el servidor est´e disponible de nuevo. Tabla 8.3: Prueba de comunicaci´on del bot con el servidor apagado P-004 El bot solicita tareas al servidor Descripci´on El bot pregunta si tiene tareas que realizar. Resultado esperado El bot recibe una posible secuencia de tareas pendientes por parte del servidor. Resultado obtenido El bot recibe una posible secuencia de tareas pendientes por parte del servidor. Tabla 8.4: Prueba del bot solicitando tareas al servidor P-005 El bot realiza la tarea de ejecuci´on de un comando Descripci´on El bot realiza la ejecuci´on de la tarea encargada de ejecutar comandos de manera remota y devolver el resultado al servidor. Resultado esperado El bot ejecuta el comando y devuelve el resultado. Resultado obtenido El bot ejecuta el comando y devuelve el resultado. Tabla 8.5: Prueba del bot realizando la tarea de ejecuci´on de un comando P-006 El bot realiza la tarea de subir fichero desde el servidor Descripci´on El bot pide al servidor el fichero concreto que tiene indicado en la tarea. Resultado esperado El bot env´ıa el nombre del fichero y este recibe los datos referentes al fichero solicitado. Resultado obtenido El bot env´ıa el nombre del fichero y este recibe los datos referentes al fichero solicitado. Tabla 8.6: Prueba del bot realizando la tarea de subir un fichero a la m´aquina remota 60 CAP´ ITULO 8. PRUEBAS P-007 El bot realiza la tarea de enviar un archivo que no se encuentra al servidor Descripci´on El bot tiene la tarea de enviar un archivo que no existe al servidor. Resultado esperado El bot informa al servidor que el fichero solicitado no est´a disponible. Resultado obtenido El bot informa al servidor que el fichero solicitado no est´a disponible. Tabla 8.7: Prueba del bot al realizar la tarea de enviar un fichero inexistente P-008 El bot realiza la tarea de enviar un archivo al servidor Descripci´on El bot tiene la tarea de enviar un archivo que existe al servidor. Resultado esperado El bot env´ıa al servidor los datos en bruto del fichero solicitado. Resultado obtenido El bot env´ıa al servidor los datos en bruto del fichero solicitado. Tabla 8.8: Prueba del bot al realizar la tarea de enviar un fichero P-009 El bot realiza la tarea de tomar una captura de pantalla Descripci´on El bot realiza una captura de la pantalla del dispositivo y la env´ıa al servidor. Resultado esperado El servidor recibe la captura de pantalla correctamente. Resultado obtenido El servidor recibe la captura de pantalla correctamente. Tabla 8.9: Prueba del bot al realizar la tarea de tomar una captura de pantalla P-010 El bot realiza la tarea de apagarse Descripci´on El bot se apaga. Resultado esperado El bot detiene su ejecuci´on. Resultado obtenido El bot detiene su ejecuci´on. Tabla 8.10: Prueba del bot al realizar la tarea de apagarse 61 P-011 El bot realiza la tarea de eliminarse Descripci´on El bot elimina la persistencia y el numero de identificaci´on del dispositivo infectado. Resultado esperado El bot queda inoperativo en la m´aquina infectada. Resultado obtenido El bot queda inoperativo en la m´aquina infectada. Tabla 8.11: Prueba del bot al realizar la tarea de eliminarse P-012 El bot env´ıa las tareas completadas al servidor Descripci´on Una vez finalizadas las tareas, estas son enviadas al servidor. Resultado esperado El servidor recibe una sucesi´on de tareas completadas. Resultado obtenido El servidor recibe una sucesi´on de tareas completadas. Tabla 8.12: Prueba del bot enviando las tareas completadas P-013 Acceder a la p´agina de los bots de la aplicaci´on con el servidor apagado Descripci´on Accedemos a la p´agina donde se encuentra el listado de todos los bots registrados por la red con el servidor apagado. Resultado esperado P´agina de error 500, no se ha encontrado el servidor. Resultado obtenido P´agina de error 500, no se ha encontrado el servidor. Tabla 8.13: Prueba acceso a la p´agina de los bots con el servidor apagado P-014 Acceder a la p´agina de los bots de la aplicaci´on Descripci´on Accedemos a la p´agina donde se encuentra el listado de todos los bots registrados por la red. Resultado esperado La p´agina nos mostrar´a el listado completo de los bots. Resultado obtenido La p´agina nos mostrar´a el listado completo de los bots. Tabla 8.14: Prueba de la aplicaci´on accediendo a la p´agina de los bots 62 CAP´ ITULO 8. PRUEBAS P-015 Acceder a la informaci´on de un bot existente Descripci´on Se pulsa sobre el identificador de un bot disponible en la lista. Resultado esperado Se muestra la p´agina con la informaci´on del bot. Resultado obtenido Se muestra la p´agina con la informaci´on del bot. Tabla 8.15: Prueba de la aplicaci´on accediendo a un bot existente P-016 Prueba de la aplicaci´on accediendo a un bot que no existe Descripci´on Insertamos una URL con un identificador de un bot que no existe. Resultado esperado Se muestra la p´agina de la informaci´on del bot pero nos comunica que no se ha podido encontrar. Resultado obtenido Se muestra la p´agina de la informaci´on del bot pero nos comunica que no se ha podido encontrar. Tabla 8.16: Prueba de la aplicaci´on accediendo a un bot que no existe P-017 Acceder a la p´agina de las tareas con el servidor apagado Descripci´on Se accede a la p´agina donde se muestran todas las tareas pendientes y completadas cuando el servidor est´a apagado. Resultado esperado P´agina de error 500, no se ha encontrado el servidor. Resultado obtenido P´agina de error 500, no se ha encontrado el servidor. Tabla 8.17: Prueba de la aplicaci´on accediendo a la p´agina de las tareas con el servidor apagado P-018 Acceder a la pagina de las tareas Descripci´on Se accede a la p´agina donde se muestran todas las tareas pendientes y completadas. Resultado esperado Se muestra la p´agina de tareas. Resultado obtenido Se muestra la p´agina de tareas. Tabla 8.18: Prueba de la aplicaci´on accediendo a la p´agina de las tareas 63 P-019 Acceso a la p´agina de a˜nadir tarea sin ning´un bot disponible Descripci´on Accedemos a la p´agina por URL sin tener ning´un bot conectado o disponible para poder agregar una tarea. Resultado esperado Error, p´agina de aviso de que no puede acceder a esa secci´on. Resultado obtenido Error, p´agina de aviso de que no puede acceder a esa secci´on. Tabla 8.19: Prueba de la aplicaci´on accediendo a la p´agina de a˜nadir prueba sin tener bots disponibles P-020 Agregar una nueva tarea Descripci´on El administrador rellena los campos necesarios de las tareas para poder enviar la tarea al servidor. Resultado esperado Tarea a˜nadida y redirecci´on a la p´agina de tareas. Resultado obtenido Tarea a˜nadida y redirecci´on a la p´agina de tareas. Tabla 8.20: Prueba de la aplicaci´on agregando una nueva tarea P-021 Agregar una tarea con alg´un campo sin completar Descripci´on El administrador no rellena alguno de los campos obligatorios para alguna tarea. Resultado esperado La p´agina no le deja continuar, saltan avisos de que faltan campos por completar. Resultado obtenido La p´agina no le deja continuar, saltan avisos de que faltan campos por completar. Tabla 8.21: Prueba de la aplicaci´on agregando una nueva tarea sin completar los campos P-022 Descargar un fichero desde la aplicaci´on Descripci´on Se descarga un fichero (log o cualquier fichero) desde la aplicaci´on. Resultado esperado El fichero se descarga correctamente. Resultado obtenido El fichero se descarga correctamente. Tabla 8.22: Prueba de la aplicaci´on descargando ficheros 64 CAP´ ITULO 8. PRUEBAS P-023 Descargar un fichero que no existe desde la aplicaci´on Descripci´on Se descarga un fichero (log o cualquier fichero) que no existe desde la aplicaci´on. Resultado esperado P´agina de error 404, no se ha encontrado el recurso solicitado. Resultado obtenido P´agina de error 404, no se ha encontrado el recurso solicitado. Tabla 8.23: Prueba de la aplicaci´on descargando ficheros que no existen 65 66 CAP´ ITULO 9. DESPLIEGUE Cap´ıtulo 9 Despliegue Este cap´ıtulo trata sobre el despliegue y los pasos que hay que realizar para poder desplegar las diferentes partes de la botnet desarrollada. A mayores, se explicar´a como se compila y se despliega en la m´aquina Windows el bot. 9.1. Preparaci´on del entorno Para preparar el entorno para el despliegue de la botnet necesitamos tener una versi´on de Python igual o superior a la versi´on 3.8.6. Una vez que se tiene Python instalado en nuestro sistema debemos descargar el c´odigo fuente del proyecto, localizado en https://gitlab.inf.uva.es/javbarr/PyBotnet. El servidor puede ser ejecutado tanto en Linux como en Windows. Es posible que para las m´aquinas Windows sea necesario instalar alg´un programa adicional. En este caso el despliegue se realizar´a sobre una m´aquina Kali Linux. Una vez que tenemos el proyecto descargado en una carpeta, en el directorio ra´ız creamos un entorno virtual de Python que llamaremos venv. Para ello, estando en la ra´ız del proyecto, ejecutamos el siguiente comando python3 -m venv venv Tras crear el entorno virtual debemos activarlo. Para ello debemos escribir source ./venv/bin/activate 67 9.1. PREPARACI ´ ON DEL ENTORNO Si queremos desactivar el entorno virtual solo debemos escribir deactivate Una vez tenemos el entorno virtual activado, debemos instalar los paquetes de Python existentes en el fichero requirements.txt. Tambi´en debemos instalar los m´odulos desarrollados a lo largo del proyecto. Para ello, primero, debemos ejecutar el siguiente comando desde el directorio ra´ız python3 -m pip install -r requirements.txt Una vez instalados los m´odulos Python del fichero de requisitos debemos compilar el fichero .proto. Para ello utilizamos el siguiente comando, especificando la ubicaci´on del fichero existente en la carpeta protos. El comando a ejecutar es python3 -m grpc.tools.protoc --python_out=. --grpc_python_out=. --proto_path=. ./protos/botnet.proto --experimental_allow_proto3_optional Ahora instalaremos nuestro propio paquete creado con los m´odulos del proyecto. Se instalar´an bajo el nombre pybotnet 1.0 y debemos escribir, tambi´en desde el directorio ra´ız del proyecto python3 -m pip install . Una vez finalizada la instalaci´on de los m´odulos debemos crear la clave privada y los certificados para nuestro servidor, nuestra aplicaci´on web y nuestros bots. Para ello se utilizar´a OpenSSL como herramienta de creaci´on de certificados y claves. Si en nuestro directorio ra´ız no existe una carpeta certs para los certificados lo primero que tenemos que hacer es crear una carpeta con ese nombre. Esto es importante ya que, tanto los nombres aqu´ı presentes, tanto la estructura descrita es la utilizada de manera interna por el servidor. Una vez la carpeta exista podemos crear la clave privada del servidor con el siguiente comando. Entramos en la carpeta y ejecutamos los siguientes comandos openssl genrsa -out server.key 2048 A partir de la clave privada creamos el certificado para las llamadas locales. 68 CAP´ ITULO 9. DESPLIEGUE openssl req -new -x509 -nodes -sha256 -days 365 -key server.key -out localhost.crt -subj "/C=ES/ST=Castilla y Leon/L=Valladolid /O=Universidad de Valladolid/OU=Escuela de Ing Informatica CN = localhost" Tambi´en, a partir de la clave privada, creamos el certificado para los bots con la direcci´on IP p´ublica del servidor de la botnet. openssl req -new -x509 -nodes -sha256 -days 365 -key server.key -out env.crt -subj "/C=ES/ST=Castilla y Leon/L=Valladolid/O=Universidad de Valladolid /OU=Escuela de Ing Informatica" -addext "subjectAltName = IP:xxx.xxx.xxx.xxx" 9.2. Despliegue del servidor Una vez tenemos todo el entorno preparado podemos iniciar nuestro servidor. El servidor est´a compuesto del servidor gRPC y de la aplicaci´on web soportada en Flask. Ambos elementos se pueden ejecutar de manera independiente, por terminal, sin ning´un problema. Para facilitar al botmaster la ejecuci´on de ambas cosas se han creado dos scripts de gesti´on. Para poder ejecutar ambos scripts en la m´aquina Kali Linux primero debemos darle permisos a ambos ficheros. chmod +x start.sh chmod +x stop.sh Ambos scripts se deben ejecutar desde el directorio ra´ız del proyecto. El script start.sh inicializa el servidor gRPC por un lado y la aplicaci´on web en la direcci´on localhost:8080 por otro. En cambio, el script stop.sh detiene ambas ejecuciones. 9.2.1. Servidor gRPC Es posible ejecutar s´olo el servidor gRPC sin necesidad de ejecutar la aplicaci´on web. Para ello podemos ejecutar el fichero Python directamente desde el directorio ra´ız utilizando los siguientes comandos. # Ejecuci´on normal python3 ./server/grpcserver.py 69 el estado actual del bot (si est´a o no activo) y las principales propiedades de la m´aquina que ha infectado: sistema operativo (solo est´a disponible en Windows), nodo o nombre de la m´aquina, versi´on del sistema operativo, n´umero de compilaci´on, juego de instrucciones y los datos del procesador que presenta. Posee un contador para saber el n´umero total de bots, as´ı como un bot´on para actualizar la p´agina directamente. Figura A.2: Apariencia final de la p´agina de los bots. En caso de no presentar ning´un bot la botnet nos saldr´a un mensaje en vez de la tabla avis´andonos que no hay ning´un bot en este momento. Pulsando en el ID del bot nos llevar´a a la p´agina de informaci´on del bot seleccionado. Dicha p´agina la podemos ver desglosada en dos partes. La primera parte (Figura A.3) presenta la informaci´on b´asica del bot, tales como su estado, las tareas que tiene pendientes y las tareas completadas. A su vez tiene, de nuevo, la informaci´on de la m´aquina infectada as´ı como su geoposici´on aproximada en un mapa. En la parte final de la p´agina podemos ver un listado de las tareas pendientes que tiene el bot por hacer, como tambi´en un listado de las tareas completadas (Figura A.4). Las tablas de las tareas contiene el ID de la tarea, el tipo de tarea realizada o por realizar, la fecha de cuando se ha agregado dicha tarea y, si se ha completado, la fecha de finalizaci´on de la tarea. Si se pulsa sobre el ID de la tarea te llevar´a a la p´agina de informaci´on de las tarea (Figura A.7). Si a la hora de acceder a la informaci´on del bot este no est´a disponible, saldr´a un mensaje de informaci´on avisando que el bot que est´a buscando no se ha encontrado en la base de datos. El bot´on “Tareas”nos llevar´a a la p´agina principal de gesti´on de las tareas de la botnet (Figura A.5). En esta p´agina tenemos arriba del todo (si hay alg´un bot disponible) un bot´on con el t´ıtulo “A˜nadir Tarea”, para ir a la p´agina con el formulario para a˜nadir una nueva tarea (Figura A.6). Tambi´en dispone de un bot´on para actualizar la p´agina. Est´a completada por dos tablas que contienen, si existen tareas de su condici´on, tareas. Estas tareas est´an representadas por su ID, el tipo de tarea, su estado, la fecha de cuando 76 AP´ ENDICE A. MANUAL DE USUARIO Figura A.3: Apariencia final de la p´agina de informaci´on de un bot con la informaci´on y la geolocalizaci´on. fueron a˜nadidas, la fecha, si la tarea se ha completado, de cuando fueron completadas y el ID del bot que ha realizado dicha tarea o la va a realizar. Las tablas poseen unos filtros para poder filtrar las tareas seg´un el tipo de tarea, el estado de la tarea y por el ID del bot. Esto es muy ´util cuando se poseen demasiadas tareas registradas esperando o completadas. Si la botnet presenta uno o varios bots, podemos a˜nadir tareas para realizar. Pulsando el bot´on para a˜nadir una nueva tarea nos llevar´a a la p´agina del formulario (Figura A.6) donde tendremos una lista con todos los bots y varias opciones. De la lista de bots debemos seleccionar m´ınimo un bot y, en el caso que se quiera, se pueden seleccionar todos a la vez. Una vez seleccionado cuales son los bots que queremos que hagan la tarea debemos seleccionar el tipo de tarea. Actualmente hay 6 tareas: Ejecuci´on de c´odigo remoto Subir fichero al host remoto Descargar fichero del host remoto Tomar captura de pantalla del host remoto Apagar bot 77 Figura A.4: Apariencia final de la p´agina de informaci´on de un bot con las tareas. Eliminar bot Dependiendo de la tarea seleccionada se podr´a desbloquear un cuadro de di´alogo de los disponibles para a˜nadir informaci´on complementaria a la tarea tal como, el comando que se desea ejecutar, el fichero que se quiere subir o la direcci´on del fichero que se quiere descargar. Una vez completado el formulario solo debemos darle al bot´on de A˜nadir Tarea y se nos redirigir´a a la p´agina principal de las tareas. Si pulsamos sobre el ID de la tarea nos llevar´a a la p´agina de la informaci´on sobre la tarea seleccionada (Figura A.7). En esta p´agina tenemos la informaci´on base de la tarea, el tipo de tarea, su estado, la fecha de cuando se ha creado, la fecha, si existe, de cuando se ha completado y el bot que ha llevado a cabo o va a llevar a cabo la tarea. Si se pulsa sobre el bot vas directamente a su p´agina de informaci´on. Dependiendo de la tarea realizada se mostrar´a, a continuaci´on de la tabla de informaci´on b´asica, la descripci´on de la tarea. Se informar´a tambi´en si la tarea no se ha completado. El bot´on “Logs”nos llevar´a a la p´agina donde se ubican todos los logs recogidos a lo largo del tiempo por el servidor (Figura A.8). Est´an presentes los logs de los diferentes bots y el log del servidor global. Cuando se pulsa sobre el nombre de un log puedes abrirlo en una nueva ventana o incluso descargarlo. El bot´on “Archivos”nos llevar´a a la p´agina donde se ubican todos los archivos descargados por los diferentes bots en el servidor (Figura A.9). Se ordenan por carpetas cuyo nombre es el identificador del bot. Dependiendo del archivo presente y su extensi´on tendr´a un icono u otro con el fin de mejorar la compresi´on del archivo presente. Si se pulsa sobr el archivo se puede abrir en una nueva pesta˜na o descargarlo. El bot´on “Mapa”nos llevar´a a la p´agina con un mapa global con todos los bots presentes (Figura A.10). Este mapa contiene un icono de localizaci´on por cada bot y, si pulsamos sobre uno de ellos, podemos obtener m´as informaci´on acerca de la geolocalizaci´on como son la direcci´on IP, el nombre del dispositivo y la ciudad donde se ubica (Figura A.11). 78 AP´ ENDICE A. MANUAL DE USUARIO Figura A.5: Apariencia final de la p´agina de las tareas. Figura A.6: Apariencia final de la p´agina del formulario para a˜nadir una nueva tarea. 79 Figura A.7: Apariencia final de la p´agina de informaci´on de una tarea. Figura A.8: Apariencia final de la p´agina de logs. Figura A.9: Apariencia final de la p´agina de archivos. 80 AP´ ENDICE A. MANUAL DE USUARIO Figura A.10: Apariencia final de la p´agina del mapa. Figura A.11: Apariencia final de la p´agina del mapa con el di´alogo del bot seleccionado. 81 82 AP´ ENDICE B. C ´ ODIGO DEL FICHERO .PROTO Ap´endice B C´odigo del fichero .proto syntax = "proto3"; enum Type { UNKNOWN = 0; CONNECTION = 1; ADMIN = 2; CMD = 3; UPLOAD = 4; DOWNLOAD = 5; SCREENSHOT = 6; SHUTDOWN = 7; DELETE = 8; } enum Status { MISSING = 0; OK = 1; ERROR = 2; WAITING = 3; } enum StatusBot { CONNECTED = 0; DISCONNECTED = 1; } message Empty{} message Geo { string bot_id = 1; string ip = 2; string hostname = 3; 83 string city = 4; string region = 5; string country = 6; string loc = 7; } message Bot { string bot_id = 1; StatusBot status = 2; string system = 3; string node = 4; string release = 5; string version = 6; string machine = 7; string processor = 8; optional Geo geo = 9; } message TaskId { string task_id = 1; } message Task { string task_id = 1; string bot_id = 2; Type type = 3; Status status = 4; string date_start = 5; string date_finish = 6; optional string command = 7; optional string file = 8; optional string response = 9; } message Response { Status status = 1; Type type = 2; } message BotId { string bot_id = 1; } message Chunk { string bot_id = 1; Status status = 2; string filename = 3; bytes data = 4; } message File { 84 AP´ ENDICE B. C ´ ODIGO DEL FICHERO .PROTO string bot_id =1; string file = 2; } service Botnet { rpc SendFile(stream Chunk) returns (Response); rpc GetFile(File) returns (stream Chunk); rpc GetBots(Empty) returns (stream Bot); rpc GetActiveBots(Empty) returns (stream Bot); rpc GetBot(BotId) returns (Bot); rpc SetConnection(Bot) returns (Response); rpc SendStreamComplete(stream Task) returns (Response); rpc GetTasksBot(BotId) returns (stream Task); rpc GetCompleteBot(BotId) returns (stream Task); rpc GetTasks(Empty) returns (stream Task); rpc GetComplete(Empty) returns (stream Task); rpc GetTask(TaskId) returns (Task); rpc AddTask(stream Task) returns (Response); rpc GetGlobalBots(Empty) returns (stream Geo); } 85