Análisis de Vulnerabilidades en Aplicaciones de Rastreo de Covid-19 basadas en el Protocolo DP3T

An´alisis de Vulnerabilidades en Aplicaciones de Rastreo de Covid-19 basadas en el Protocolo DP3T Vulnerabilities Analysis in COVID-19 Tracking Applications based on the DP3T Protocol TRABAJO FIN DE GRADO GRADO EN INGENIER´ IA DE COMPUTADORES CURSO 2020–2021 Alonso Mart´ın Zurdo Pablo Izquierdo Garbajosa Directores Francisco Javier Crespo Y´a˜nez Luis Javier Garc´ıa Villalba Departamento de Sistemas Inform´aticos y Computaci´on Facultad de Inform´atica Universidad Complutense de Madrid Madrid, Junio de 2021 ´ Indice General ´ Indice de Figuras VII ´ Indice de Tablas IX Lista de Acr´ onimos XI Abstract XIII Resumen XV 1. Introducci´ on 1 1.1. Motivaci´on .................................... 1 1.2. Objetivos ..................................... 1 1.3. Plan de Trabajo ................................. 2 1.4. Estructura del Trabajo .............................. 4 2. Aplicaciones de Rastreo de Contactos 5 2.1. Origen ....................................... 5 2.2. Tipos de Aplicaciones de Rastreo ........................ 6 2.3. Modelos Descentralizados ............................ 6 2.4. Modelos Centralizados .............................. 7 2.5. Tipos de Adversarios ............................... 8 3. Protocolo de Rastreo de Proximidad Descentralizado para Preservar la Privacidad 11 3.1. Funcionamiento de DP-3T ............................ 11 3.1.1. Rastreo de Proximidad Descentralizado de Bajo Consumo ...... 12 3.1.2. Ratreo de Proximidad Descentralizado no Vinculable ......... 12 3.1.3. Rastreo de Proximidad Descentralizado H´ıbrido ............ 13 3.2. Riesgos de Privacidad y Seguridad ....................... 13 3.2.1. An´alisis de Privacidad .......................... 13 3.2.1.1. Privacidad del Dise˜no de Bajo Consumo ........... 14 3.2.1.2. Privacidad del Dise˜no no Vinculable ............. 14 iii iv ´ INDICE GENERAL 3.2.1.3. Privacidad del Dise˜no H´ıbrido ................ 15 3.2.2. An´alisis de Seguridad .......................... 16 3.2.2.1. Seguridad del Dise˜no de Bajo Consumo ........... 16 3.2.2.2. Seguridad del Dise˜no no Vinculable ............. 16 3.2.2.3. Seguridad del Dise˜no H´ıbrido ................. 17 3.2.3. Privacidad en Modelos Centralizados vs Descentralizados ...... 17 3.2.4. Seguridad en Modelos Centralizados vs Modelo Descentralizados . . 18 4. T´ ecnicas de An´ alisis de Vulnerabilidades 19 4.1. Prueba de Penetraci´on .............................. 19 4.1.1. Fases .................................... 19 4.2. Tipos de Pruebas ................................. 20 4.3. Est´andares .................................... 21 4.3.1. Sistema de Puntuaci´on de Vulnerabilidades Comunes ......... 22 4.3.2. Est´andares de Verificaci´on de Seguridad en Aplicaciones M´oviles del Proyecto Abierto de Seguridad de Aplicaciones Web ......... 29 4.3.3. Enumeraci´on de Debilidades Comunes ................. 31 5. Trabajos relacionados 33 6. An´ alisis de Vulnerabilidades en Aplicaciones Europeas de Rastreo de Covid-19 basadas en el Protocolo DP3T 39 6.1. Preparaci´on del laboratorio de trabajo ..................... 39 6.2. Aplicaciones .................................... 41 6.3. An´alisis de Resultados .............................. 41 6.3.1. An´alisis General ............................. 42 6.3.2. An´alisis de Permisos ........................... 42 6.3.3. An´alisis de C´odigo ............................ 47 7. Contribuciones Individuales 51 7.1. Pablo Izquierdo Garbajosa ............................ 51 7.2. Alonso Mart´ın Zurdo ............................... 53 8. Conclusiones y Trabajo Futuro 57 8.1. Conclusiones ................................... 57 8.2. Trabajo Futuro .................................. 58 9. Introduction 61 9.1. Motivation .................................... 61 9.2. Objectives ..................................... 61 9.3. Workplan ..................................... 62 9.4. Structure Of This Paper ............................. 64 ´ INDICE GENERAL v 10.Conclusions and Future Works 65 10.1. Conclusions .................................... 65 10.2. Future Works ................................... 66 Bibliograf´ ıa 67 ´ Indice de Figuras 1.1. Diagrama de Gantt ................................ 3 2.1. Rastreo de proximidad para dise˜nos centralizados PEPP-PT-NTK y OpenTrace. .................................... 8 3.1. Proceso de rastreo de proximidad ........................ 12 4.1. Fases del An´alisis de Penetraci´on ........................ 20 4.2. Diagrama de funcionamiento de los test de caja negra y de caja blanca . . . 21 4.3. Uso de m´etricas para el c´alculo del valor CVSS ................ 22 4.4. ´ Arbol de decisi´on para calcular en valor CVSS Final ............. 27 4.5. Controles de seguridad MASVS ......................... 31 5.1. (a) Ataque de consumo de energ´ıa. (b) Ataque de consumo de almacenamiento. 33 5.2. (a) Ataque de retransmisi´on. (b) Ataque de repetici´on. ............ 34 5.3. Ataque de trolling. ................................ 34 6.1. Emulador Genymotion .............................. 40 6.2. Interfaz de la herramienta MobSF. ....................... 40 6.3. Tipos de permisos por aplicaci´on ........................ 46 6.4. N´umero de problemas de c´odigo por aplicaci´on ................ 49 9.1. Gantt Diagram .................................. 63 vii ´ Indice de Tablas 1.1. Tareas Realizadas a lo largo del Proyecto ................... 2 4.1. Descripci´on de los grupos de m´etricas de CVSS V2 .............. 23 4.2. M´etricas del grupo Base ............................. 24 4.3. M´etricas del grupo Temporal .......................... 25 4.4. M´etricas del grupo de Entorno ......................... 25 4.5. Valor de las m´etricas de Entorno ........................ 27 4.6. Valor de las m´etricas Base ............................ 28 4.7. Valor de las m´etricas de Entorno ........................ 28 4.8. Vulnerabilidades m´as importantes de CWE .................. 31 5.1. Principales caracter´ısticas de los frameworks de rastreo de contactos. . . . . 36 5.2. Tabla de las 28 aplicaciones analizadas. .................... 37 6.1. Aplicaciones analizadas ............................. 41 6.2. Puntuaciones de MobSF ............................. 44 6.3. Permisos de las aplicaciones de la Tabla 6.1 .................. 45 6.4. Problemas de c´odigo detectados en las aplicaciones por MobSF ....... 48 6.5. Aplicaciones con los problemas de c´odigo de la Tabla 6.4 ........... 50 9.1. Tasks Performed throughout the Project .................... 62 ix Cap´ıtulo 1 Introducci´on 1.1. Motivaci´on Debido a la pandemia mundial provocada por el COVID-19 a principios de 2020, vimos como el n´umero de personas contagiadas por este virus crec´ıa a una velocidad muy alta, causando la saturaci´on de los hospitales, muchos fallecimientos y llevando a muchos pa´ıses a imponer un confinamiento domiciliario durante meses. Para controlar los contagios y actuar de manera r´apida ante un caso de una persona contagiada por el virus y evitar su expansi´on, surge un trabajo clave que es el rastreador, que es una persona que se dedica a investigar los contactos cercanos que ha tenido una persona que ha dado positivo en COVID-19 para avisarles y que hagan una cuarentena domiciliaria y se realicen las pruebas correspondientes. Debido a la r´apida expansi´on del virus, el rastreo manual se vuelve un trabajo muy arduo e imposible de conseguir, por lo que deja de ser efectivo, ya que, por ejemplo, si una persona contagiada ha estado usando el transporte p´ublico es imposible contactar con todas esas personas con las que ha compartido vag´on. Por este motivo surge la idea de crear una aplicaci´on m´ovil para hacer un rastreo digital de contacto m´as efectivo. Pero con el rastreo mediante una aplicaci´on m´ovil, surge, en las personas, la preocupaci´on y el temor de que con este sistema se viole su privacidad e intimidad y sus datos queden expuestos a posibles hackers, provocando que los usuarios no hagan uso del sistema y con ello se pierda la efectividad del rastreo de contactos. 1.2. Objetivos El objetivo de este trabajo es analizar que tipo de vulnerabilidades pueden tener las aplicaciones m´oviles para el rastreo de contactos que se basan en el protocolo DP-3T. Para ello se hace uso de una herramienta de an´alisis autom´atico de vulnerabilidades para aplicaciones m´oviles, con la que se hace un an´alisis est´atico y din´amico de las aplicaciones que nos ayudar´a a comprobar los diferentes tipos de vulnerabilidades que pueden tener 1 2Cap ´ ıtulo 1. Introducci´ on dichas aplicaciones y si se pone en riesgo la seguridad y privacidad de los usuarios que las usan. 1.3. Plan de Trabajo En la Tabla 1.1 se resumen las tareas realizadas a lo largo del desarrollo del proyecto. Adicionalmente, se adjunta en la Figura 1.1 un diagrama de Gantt que ilustra las tareas y su temporalidad. Identificador Tarea 1 Investigaci´on 1.1 Lectura e Investigaci´on de art´ıculos acad´emicos 2 Documentaci´on 2.1 Busqueda de informaci´on sobre el protocolo DP-3T 2.2 Busqueda de informaci´on sobre el an´alisis de penetraci´on y distintas herramientas 3 Busqueda del entrono de trabajo 3.1 Prueba de distintas herramientas 3.2 Configuraci´on del entorno de trabajo final 4 Experimentaci´on 4.1 Obtenci´on de APK de las aplicaciones 4.2 An´alisis est´atico 4.3 An´alisis de los resultados 5 Memoria 5.1 Anotaciones, citas y recopilaci´on de art´ıculos 5.2 Redacci´on de la memoria Tabla 1.1: Tareas Realizadas a lo largo del Proyecto 1.3. Plan de Trabajo 3 Figura 1.1: Diagrama de Gantt 4Cap ´ ıtulo 1. Introducci´ on 1.4. Estructura del Trabajo El resto del trabajo est´a organizado en siete cap´ıtulos con la estructura que se comenta a continuaci´on: El Cap´ıtulo 2contextualiza e introduce brevemente los or´ıgenes, conceptos y bases te´oricas de las aplicaciones de rastreo de contactos de manera general. En el Cap´ıtulo 3se habla m´as en detalle del protocolo de rastreo de proximidad descentralizado. Se describen sus tipos y su funcionamiento adem´as de analizar y comparar su privacidad y seguridad entre los distintos modelos que existen. En el Cap´ıtulo 4contextualiza al funcionamiento de las herramientas de an´alisis de vulnerabilidades. Se repasan los distintos tipos y se explican en detalle los est´andares que usa la herramienta utilizada para hacer el an´alisis de las aplicaciones. El Cap´ıtulo 5presenta distintos trabajos relacionados con este, explicando los resultados que se obtuvieron. En el Cap´ıtulo 6se detallan los resultados de los an´alisis realizados a las distintas aplicaciones europeas y como est´a configurado el laboratorio de an´alisis. El Cap´ıtulo 7resume las aportaciones individuales de cada integrante del equipo de trabajo. El Cap´ıtulo 8concluye este trabajo: resumiendo brevemente la experiencia del proyecto y analizando los resultados de los an´alisis. Se presenta el trabajo futuro y las posibles l´ıneas de investigaci´on. Los Cap´ıtulos 9y10 son traducciones al ingl´es de los Cap´ıtulos 1y8, respectivamente. Cap´ıtulo 2 Aplicaciones de Rastreo de Contactos El rastreo de contactos es uno de los m´etodos utilizados para contener una epidemia m´edica. Al rastrear a los humanos expuestos a una persona infectada, se puede reducir la propagaci´on de infecciones si esas personas potencialmente infectadas pueden aislarse de la poblaci´on restante. Adem´as, el rastreo de contactos ayuda a rastrear las ´areas que est´an expuestas a una infecci´on [HWMF21]. A ra´ız del brote pand´emico de la COVID-19 surgieron diferentes enfoques que presentaban soluciones tecnol´ogicas para mejorar la detecci´on y rastreo temprano de posibles brotes de COVID-19. Sobre ´estas tecnolog´ıas surgieron muchas dudas sobre la seguridad y la privacidad de los usuarios. Esto abri´o un debate sobre el tipo de modelo a seguir, por una parte un modelo centralizado y por otra parte un modelo descentralizado. En la Secci´on 2.1 se habla del origen de las aplicaciones de rastreo de contacto, en la Secci´on 2.2 se describe el objetivo y los tipos de aplicaciones de rastreo de contactos, las caracter´ısticas de los modelos descentralizados de las aplicaciones de rastreo de contactos se describe en la Secci´on 2.3, las caracter´ısticas de los modelos centralizados se describen en la Secci´on 2.4. Finalmente, en la Secci´on 2.5, se presentan los principales tipos de adversarios que se pueden encontrar. 2.1. Origen La pandemia de la COVID-19 se ha extendido muy r´apidamente. Muy pocos pa´ıses han logrado mantenerlo bien controlado, pero una de las principales herramientas que utilizan varios de estos pa´ıses es el rastreo de contactos. Espec´ıficamente, siempre que una persona es diagnosticada de COVID-19, cada persona que estuvo en contacto con esa persona infectada es avisada y se le dice que se ponga en cuarentena. Al principio el rastreo de contactos pod´ıa hacerse manualmente, pero con miles de casos el rastreo de contactos manual se vuelve mucho m´as dif´ıcil [CIY20]. A ra´ız de esta dificultad, los gobiernos de los pa´ıses, para ayudar a las autoridades sanitarias nacionales, decidieron implementar 5 6Cap ´ ıtulo 2. Aplicaciones de Rastreo de Contactos aplicaciones m´oviles de rastreo de contactos para automatizar y facilitar la labor de rastrear a las personas que hayan estado en contacto con una persona contagiada. 2.2. Tipos de Aplicaciones de Rastreo El principal objetivo de este tipo de aplicaciones es detectar lo antes posible nuevas fuentes potenciales de infecci´on, de modo que la propagaci´on de COVID-19 pueda mitigarse r´apidamente. Hasta ahora se pueden encontrar dos tipos de aplicaciones m´oviles [MKHR+20]. Aplicaci´ on de seguimiento de contactos: Se basa en los marcos de rastreo de contactos digitales descentralizados y centralizados que se basan en tecnolog´ıa inal´ambrica de proximidad como Bluetooth Low Energy (BLE). Cuando dos usuarios est´an f´ısicamente cerca, los smartphones se env´ıan su identidad en t´erminos de Ephimeral Identifier (EphID) entre s´ı. Cada smartphone registra todos sus encuentros que ocurrieron dentro de un per´ıodo de tiempo. Aplicaci´ on para compartir ubicaci´ on: Se basa en la informaci´on de posicionamiento del smartphone, es decir, mediante rastreo GPS o mapeo de torres de telefon´ıa m´ovil. Para una aplicaci´on de este tipo, el usuario debe aceptar que su smartphone env´ıe de forma regular su posici´on a un servidor central, que puede asignar, durante un per´ıodo de tiempo ilimitado, a cada usuario. Si un usuario informa una infecci´on por COVID-19, entonces se advierte de la situaci´on a todos los usuarios que estuvieron cerca del usuario infectado. 2.3. Modelos Descentralizados Actualmente el debate sobre los sistemas de rastreo de contactos se centra en soluciones basadas en tecnolog´ıa Bluetooth. En todos los sistemas, la aplicaci´on emite frecuentemente un EphID, al mismo tiempo, la aplicaci´on recopila los EphID que recibe de la aplicaci´on de otros usuarios cercanos, gestionando dos listas de identificadores, los enviados y los recibidos. Los identificadores se almacenan indicando cu´ando se enviaron y recibieron, con bastante frecuencia, los identificadores antiguos son eliminados de las listas [Vau20]. En los modelos descentralizados todo se genera localmente en el smartphone del usuario. Cuando un usuario es diagnosticado, recibe de la autoridad sanitaria un token que le permite cargar informaci´on en un backend central. Esta operaci´on requiere su consentimiento y el usuario puede tener un control sobre qu´e cargar [Vau20]. Algunos de los m´etodos descentralizados son: Private Automated Contact Tracing (PACT)(MIT):PACT es una colaboraci´on liderada por el Laboratorio de Ciencias de la Computaci´on e Inteligencia 2.4. Modelos Centralizados 7 Artificial del MIT. Es un enfoque simple y descentralizado para el uso de dispositivos de comunicaci´on digital personal para la automatizaci´on de la detecci´on de exposici´on mediante la se˜nalizaci´on BLE [RWI+20]. Temporary Contact Numbers (TCN) Coalition: Es una comunidad global de tecn´ologos unidos por la misi´on de apoyar aplicaciones de notificaci´on de exposici´on durante la pandemia de COVID-19 [JD20]. DP-3T: Este sistema proporciona una base tecnol´ogica para ayudar a frenar la propagaci´on del COVID-19 simplificando y acelerando el proceso de notificaci´on de personas que podr´ıan haber estado expuestas al virus para que puedan tomar las medidas para romper su cadena de transmisi´on [TPH+20]. Este protocolo se detalla m´as ampliamente en el cap´ıtulo 3. OpenCovidTrace: Su objetivo es integrar los protocolos de rastreo de contactos m´as populares basados en BLE y proporcionar funciones adicionales adem´as de ellos. Tales protocolos incluyen DP-3T, Google/Apple, Exposure Notification y BlueTrace. Sigue las especificaciones DP-3T originales [MKHR+20]. Whisper Tracing: Las identificaciones temporales se generan peri´odicamente en el smartphone del usuario y se intercambia con smartphones cercanos a trav´es de BLE. Cuando un usuario est´a infectado, la aplicaci´on carga a un servidor central las semillas que se utilizaron para producir los Identificador (ID) temporales de las ´ultimas dos semanas. 2.4. Modelos Centralizados Al contrario que en el modelo descentralizado, es el servidor central el que estima la probabilidad de exposici´on, en lugar de ser el smartphone localmente. Es el servidor el que notifica a los usuarios del riesgo o ´estos consultan el servidor sobre su estado. El servidor central tiene un pseudo-identificador a largo plazo para cada usuario y lo usa para derivar los EphID que se env´ıan a los smartphones. En caso de un diagn´ostico positivo, los usuarios pueden dar permiso para que su m´ovil env´ıe la lista registrada de observaciones al servidor para permitir el rastreo de proximidad. A continuaci´on se describen los protocolos m´as conocidos [TPH+20]: Pan-European Privacy-Preserving Proximity Tracing Need To Know (PEPP-PT-NTK) y OpenTrace: Ejecutan el proceso de rastreo de proximidad despu´es de que un usuario diagnosticado haya subido su lista de observaciones [(EphID, tiempo, duraci´on)] para la ventana contagiosa. El backend recupera los pseudo-identificadores a largo plazo de los usuarios en riesgo de los EphID informados y activa un proceso para notificarles si su exposici´on es lo suficientemente alta, como se muestra en la Figura 2.1. 8Cap ´ ıtulo 2. Aplicaciones de Rastreo de Contactos Figura 2.1: Rastreo de proximidad para dise˜nos centralizados PEPP-PT-NTK y OpenTrace. ROBust and privacy-presERving proximity Tracing (ROBERT): El backend rastrea la exposici´on de cada usuario del sistema. El servidor asocia estos EphID observados a largo plazo con pseudo-identificadores de usuarios en riesgo. No notifica a los pacientes, los usuarios deben consultar el servidor regularmente para saber su estado de exposici´on. DESIRE[CBB+20]: Generan identificadores en el smartphone, sin dejar de estimar la exposici´on de forma centralizada. En lugar de transmitir identificadores ef´ımeros e independientes, los smartphones en DESIRE transmiten claves p´ublicas ef´ımeras que, cuando se combinan con las claves p´ublicas de otros smartphones, producen el EphID. En caso de un diagn´ostico positivo, los usuarios pueden dar permiso para que su smartphone env´ıe una versi´on de los EphID observados al backend para permitir el rastreo de proximidad. 2.5. Tipos de Adversarios Los adversarios son personas, grupos u organizaciones que intentan comprometer la seguridad/privacidad del servicio de rastreo de contactos o interrumpir su funcionamiento. Los adversarios podr´ıan intentar las siguientes acciones para atacar un sistema de rastreo de contratos digitales [MKHR+20]: Interceptar, bloquear, modificar, inyectar o reproducir cualquier mensaje en el canal de comunicaci´on p´ublica. Utilizar la aplicaci´on m´ovil para acceder al sistema y habilitar o deshabilitar el servicio de notificaci´on de la aplicaci´on a voluntad. 2.5. Tipos de Adversarios 9 Cuando corresponda, el mismo adversario puede intentar registrarse en el servicio varias veces, es decir, crear varios perfiles. El mismo adversario puede llevar varios dispositivos e instalar la(s) aplicaci´on(es) en cada uno de ellos. El mismo adversario puede intentar instalar la aplicaci´on leg´ıtima junto con las personalizadas en el mismo dispositivo. Instalar antenas de alta potencia para amplificar su se˜nal de recepci´on y transmisi´on para cubrir un ´area m´as amplia con el prop´osito de aumentar su capacidad de seguimiento o transmisi´on. Acceder a los datos almacenados en el dispositivo. Causar Denial of Service (DoS), conmoci´on en el sistema, acoso al usuario final o contaminar los datos proporcionados al sistema. Configurar y operar su propio servidor backend malicioso. Tener acceso al c´odigo fuente del servidor backend. Aliarse con otros usuarios finales, personas que trabajan para las autoridades sanitarias o policiales, o administradores del backend. Comprometer un servidor backend y la infraestructura de la Tecnolog´ıa de la Informaci´on (TI) subyacente. Enga˜nar/atraer a los usuarios finales para que instalen malware en sus dispositivos. Tanto en los modelos centralizados como en los modelos descentralizados se pueden encontrar diferentes tipos de adversarios maliciosos que se describen a continuaci´on [TPH+20]: Usuarios regulares: Miran exclusivamente la informaci´on disponible a trav´es de la interfaz de usuario de la aplicaci´on para inferir informaci´on privada sobre otros usuarios. Tech-savvy user: Tiene acceso al sistema a trav´es de la aplicaci´on m´ovil. Adem´as, puede configurar (BT, WiFi y smartphones) para escuchar a escondidas localmente. Finalmente, puede descompilar/modificar la aplicaci´on y tener acceso al c´odigo fuente del backend. Esp´ ıa: Puede observar la comunicaci´on de la red y/o mensajes de difusi´on e intentar rastrear a las personas. Autoridad sanitaria: Tienen informaci´on de personas en riesgo s´olo cuando la misma persona en riesgo lo notifica. 16 Cap ´ ıtulo 3. Protocolo de Rastreo de Proximidad Descentralizado para Preservar la Privacidad 3.2.2. An´alisis de Seguridad Las principales preocupaciones sobre la seguridad son [TPH+20]: Eventos de exposici´ on falsa: Podr´ıa hacer creer a un usuario que est´a en riesgo. Suprimir contactos de riesgo: Que un usuario positivo o el backend eviten que otras personas se enteren de que est´an en riesgo. Evitar el descubrimiento de contactos: Un atacante podr´ıa perturbar el sistema y evitar el descubrimiento de contactos. 3.2.2.1. Seguridad del Dise˜ no de Bajo Consumo A continuaci´on se analiza la seguridad del dise˜no de bajo consumo a partir de las preocupaciones vistas anteriormente. Eventos de exposici´ on falsa. Un atacante con una antena potente puede desencadenar falsas alertas de exposici´on. Como resultado, otros dispositivos cercanos pueden interactuar con el dispositivo del atacante. Para completar el ataque, el atacante debe asegurarse que ´estas interacciones se marquen como eventos de exposici´on. Para ello, el atacante puede: 1) ´ El mismo da positivo y lleva su dispositivo al hospital. 2) Sobornar a una persona positiva para que lleve el dispositivo del atacante al hospital. 3) Secuestrar/sobornar a la autoridad sanitaria que autoriza a los positivos activar el rastreo. 4) Comprometer el servidor backend. Como los EphID derivan de una semilla usando una funci´on hash y una funci´on pseudoaleatoria, es inviable que un atacante sepa la semilla del usuario al observar sus transmisiones. Suprimir contactos de riesgo. Los usuarios infectados pueden decidir no informar de su positivo o dejar de transmitir las Evitar el descubrimiento de contactos. Cualquier sistema con este dise˜no es susceptible a ataques de bloqueo, haciendo dejar de funcionar el sistema. 3.2.2.2. Seguridad del Dise˜ no no Vinculable A continuaci´on se analiza la seguridad del dise˜no no vinculable a partir de las preocupaciones vistas anteriormente. 3.2. Riesgos de Privacidad y Seguridad 17 Suprimir contactos de riesgo y evitar el descubrimiento de contactos. Tiene las mismas propiedades que el dise˜no de bajo consumo respecto a suprimir contactos de riesgo y evitar el descubrimiento de contactos. Eventos de exposici´ on falsa. Un atacante puede causar falsas alarmas mediante ataques de extensi´on de rango BLE. Para crear eventos falsos, el atacante debe recibir y transmitir los EphID dentro del mismo tiempo. Como en el dise˜no de bajo consumo, la generaci´on del EphID es desvinculable y evita que un atacante reclame como propio el EphID de otro usuario. 3.2.2.3. Seguridad del Dise˜ no H´ ıbrido A continuaci´on se analiza la seguridad del dise˜no h´ıbrido a partir de las preocupaciones vistas anteriormente. Suprimir contactos de riesgo y evitar el descubrimiento de contactos. Tiene las mismas propiedades que el dise˜no de bajo consumo respecto a suprimir contactos de riesgo y evitar el descubrimiento de contactos. Eventos de exposici´ on falsa. Un atacante puede causar falsas alarmas mediante ataques de extensi´on de rango BLE. Para crear eventos falsos, el atacante debe recibir y transmitir los EphID dentro de la misma ventana de tiempo. Como en el dise˜no de bajo consumo, la generaci´on del EphID es desvinculable y evita que un atacante reclame como propio el EphID de otro usuario. 3.2.3. Privacidad en Modelos Centralizados vs Descentralizados A continuaci´on se comparan los resultados del an´alisis de la privacidad entre el modelo centralizado y el modelo descentralizado. Gr´ afico social. El servidor backend puede reconstruir el gr´afico social de los usuarios a partir de la informaci´on compartida por los usuarios positivos. El servidor puede unir subgrafos de diferentes casos positivos para obtener una imagen completa del verdadero gr´afico social. ROBERT y DESIRE proponen evitar la filtraci´on del gr´afico social mediante el uso de una red de comunicaci´on an´onima para cargar identificadores observados de una manera no vinculable. Gr´ afico de interacci´ on. En un sistema en el que tanto los identificadores como la exposici´on al COVID-19 se calculan de forma centralizada y los identificadores observados cargados est´an vinculados, el servidor backend siempre puede asociar identificadores de transmisi´on ef´ımeros cargados a pseudo-identificadores permanentes para dispositivos individuales. En PEPP-PT-NTK, OpenTrace y ROBERT, los identificadores observados tienen una marca de tiempo. Por lo tanto, 18 Cap ´ ıtulo 3. Protocolo de Rastreo de Proximidad Descentralizado para Preservar la Privacidad el servidor backend no solo puede reconstruir un gr´afico social, sino que tambi´en puede reconstruir un gr´afico de interacci´on. Trazabilidad de la ubicaci´ on. El dise˜no descentralizado limita el potencial de seguimiento de la ubicaci´on a los usuarios que han recibido un diagn´ostico positivo y durante el transcurso del per´ıodo contagioso. En los sistemas centralizados en los que las claves se generan en el servidor, el acceso a las claves del lado del servidor permite vincular los EphID al identificador permanente de la aplicaci´on correspondiente. Esto permite rastrear/identificar personas en funci´on de los EphID observados en el pasado, as´ı como rastrear los movimientos futuros de las personas. Estado del positivo en COVID-19. Los sistemas de rastreo de proximidad centralizados y descentralizados comparten la limitaci´on de privacidad inherente de que pueden ser explotados por un usuario experto en tecnolog´ıa para revelar qu´e personas de su lista de contactos podr´ıan estar infectadas. Sin embargo, los dise˜nos centralizados ocultan cu´ando y con qu´e frecuencia el usuario estuvo en contacto con un paciente con COVID-19 positivo. Como resultado, los atacantes expertos en tecnolog´ıa no pueden beneficiarse de la vinculaci´on entre EphID y la informaci´on de tiempo para amplificar su ataque. En cambio, necesitan depender de varias cuentas. 3.2.4. Seguridad en Modelos Centralizados vs Modelo Descentralizados A continuaci´on se compara el an´alisis de la seguridad entre el modelo centralizado y el modelo descentralizado. Eventos de exposici´ on falsa. Desencadenar falsas alarmas es f´acil en todos los dise˜nos centralizados excepto DESIRE. DESIRE requiere un intercambio activo entre usuarios para desencadenar un evento de exposici´on falso Suprimir contactos en riesgo. Es posible en cualquier sistema. Evitar el descubrimiento de contactos. Todos los sistemas son susceptibles a ataques de bloqueo. Cap´ıtulo 4 T´ecnicas de An´alisis de Vulnerabilidades Para conseguir mitigar el impacto de los ciber ataques, varias empresas crearon una multitud de t´ecnicas y est´andares con las que conseguir distinta informaci´on sobre las vulnerabilidades en distintos sistemas. En este cap´ıtulo exploraremos que son y como se llevan acabo los ataques simulados en la Secci´on 4.1 y algunos de los est´andares mas usados para las vulnerabilidades en aplicaciones m´oviles en la Secci´on 4.3. 4.1. Prueba de Penetraci´on La prueba de penetraci´on, conocida como “pen test” es un ciber ataque simulado contra tu propio equipo para comprobar si existen vulnerabilidades que se pudieran explotar. Esto mitiga las debilidades potenciales del sistema antes de que ocurra un ataque real. 4.1.1. Fases Las fases de esta prueba, como aparecen en la Figura 4.1, son las siguientes [IMP]: 1. Planificaci´ on y reconocimiento: Se define el alcance de al prueba y sus objetivos, adem´as de ganar comprensi´on del sistema que se va a probar, para poder intuir posibles vulnerabilidades. 2. Escaneado: Entender como responder´a la aplicaci´on a distintos intentos de intrusi´on. Esto se hace mediante dos tipos de an´alisis: An´ alisis est´ atico: Consiste en analizar el c´odigo fuente para comprobar como se comporta la aplicaci´on cuando est´e en funcionamiento. An´ alisis din´ amico: Tambi´en se analiza el c´odigo fuente, pero esta vez mientras est´a en ejecuci´on, siendo esta una manera m´as pr´actica de escanear la aplicaci´on, pues provee al “pen tester” de una visi´on a tiempo real de su funcionamiento. 19 20 Cap ´ ıtulo 4. T´ ecnicas de An´ alisis de Vulnerabilidades 3. Acceso: Se utilizan ataques del tipo inyecciones Structured Query Languaje (SQL), puertas traseras o Cross-Site Scripting (XSS) para ganar privilegios, interceptar tr´afico, robar datos para entender el da˜no que se puede hacer a la aplicaci´on. 4. Persistencia del acceso: La meta de la fase es comprobar si se puede utilizar alguna vulnerabilidad para mantener el acceso en el sistema el tiempo suficiente como para poder acceder a las zonas con los datos mas sensibles. La idea es imitar una amenaza Advanced Persistent Threat (APT). 5. An´ alisis de resultados: Los resultados del test se detallan en un informe que contiene las vulnerabilidades espec´ıficas explotadas, los datos sensibles a los que se ha tenido acceso y el tiempo que el “pen tester” ha estado en el sistema sin ser detectado. Figura 4.1: Fases del An´alisis de Penetraci´on 4.2. Tipos de Pruebas Las pruebas se clasifican dependiendo del objetivo y del escenario inicial [LR]: Test externo: Los objetivos son las partes del sistema que son visibles en internet, como pueden ser la aplicaci´on web, el email o el Domain Name Service (DNS). Test interno: El objetivo es ganar acceso al sistema mas all´a del firewall del sistema, simulando un atacante con acceso privilegiado, no tiene que simular necesariamente a un trabajador, pero si un atacante que haya robado las credenciales de un empleado mediante un ataque de phishing. Test ciego: En este tipo de test externo solo se le proporciona al “pen tester” el nombre de la empresa que tiene que atacar, lo que proporciona datos reales del tiempo que tardar´ıa un atacante en perpetuar un asalto a la aplicaci´on. 4.3. Est´ andares 21 Doble test ciego: El test es similar al test ciego, pero con la diferencia de que el personal de seguridad no es informado de que el ataque simulado va a tener lugar. Este tipo de test tiene algunos riesgos, como que se pongan varios sistemas en cuarentena con intenci´on de parar el ‘ataque’. Test de caja negra: Es un escenario similar al test ciego, en le que el tester tiene algo m´as de informaci´on sobre el sistema que tiene que atacar, como la Uniform Resource Locator (URL) de la web de la compa˜n´ıa, o su direcci´on IP, como se muestra en la Figura 4.2(a). Test de caja blanca: Se trata de un escenario en le que el “tester” tiene informaci´on detallada, como el c´odigo fuente, configuraciones o documentaci´on del sistema para se encuentre la mayor cantidad de vulnerabilidades en el menor tiempo como se muestra en la Figura 4.2(b). La diferencia fundamental con el test interno es que no se dispone ning´un tipo de credencial para ninguna cuenta de la empresa. Test dirigido: En este escenario, tanto el tester, como el equipo de seguridad trabajan juntos, manteni´endose informados de sus movimientos. Este ejercicio de prueba, da una visi´on al equipo de seguridad del punto de vista de un atacante potencial a tiempo real. (a) Test de Caja Negra (b) Test de Caja Blanca Figura 4.2: Diagrama de funcionamiento de los test de caja negra y de caja blanca 4.3. Est´andares Para ayudar a cuantificar la severidad y el impacto de las vulnerabilidades, algunas organizaciones han elaborado unos est´andares de clasificaci´on. Algunos de ellos son: El 22 Cap ´ ıtulo 4. T´ ecnicas de An´ alisis de Vulnerabilidades Sistema de Puntuaci´on de Vulnerabilidades Comunes, los Est´andares de Verificaci´on de Seguridad en Aplicaciones M´oviles y la Enumeraci´on de Debilidades Comunes. 4.3.1. Sistema de Puntuaci´on de Vulnerabilidades Comunes La m´etrica de evaluaci´on por sistema de puntuaci´on de vulnerabilidades comunes (del ingl´es, Common Vulnerability Scoring System (CVSS)) es un framework abierto creada por la organizaci´on Forum of Incident Response and Security Teams (FIRST) que es una asociaci´on de entidades que proporcionan mecanismos de buenas pr´acticas, herramientas y elementos para la clasificaci´on y respuesta a incidentes de seguridad [PM07]. FIRST ha estado trabajando en la renovaci´on del sistema CVSS desde su lanzamiento en febrero de 2005 hasta la salida de su ´ultima versi´on en junio de 2019. El sistema de puntuaci´on CVSS se compone de tres grupos principales de m´etricas (Base, Temporal y de Entrono) Que, a su vez, contienen otros conjuntos de m´etricas [PM07]. Las m´etricas usadas en la versi´on 2.0 se re´unen en tres grupos [PM07]: 1. M´ etricas Base: Contiene las cualidades intr´ınsecas de una vulnerabilidad, descritas en la Tabla 4.2. 2. M´ etricas temporales: Contiene las caracter´ısticas de la vulnerabilidad que cambian con el tiempo, listadas en la Tabla 4.3. 3. M´ etricas Entorno: Contiene las caracter´ısticas que se relacionan con el usuario, mostradas en la Tabla 4.4. En las Tablas 4.1 se describen los grupos de m´etricas mencionadas anteriormente y en las Tablas 4.2,4.3 y4.4 los valores que pueden tomar dichas m´etricas. Estos se usan como se indica en la Figura 4.3 para calcular el valor final [PM07]. Como se observa en la figura, el CVSS se calcula dando un valor a cada m´etrica expuesta anteriormente. Adem´as, la ´unica m´etrica obligatoria es la Base y opcionalmente se pueden evaluar las m´etricas temporales y de entorno. Figura 4.3: Uso de m´etricas para el c´alculo del valor CVSS 4.3. Est´ andares 23 Tabla 4.1: Descripci´on de los grupos de m´etricas de CVSS V2 Grupo M´ etrica Descripci´ on Valores Vector de acceso (AV) Refleja como se explota la vulnerabilidad, cuanto mas remoto pueda estar el atacante, mayor ser´a la puntuaci´on - Local - Red Adyacente - Red Complejidad de acceso (AC) Mide la complejidad de ataque necesaria para explotar una vulnerabilidad cuando el atacante ya ha obtenido acceso al sistema. Cuanto menor sea la complejidad necesaria, mayor la puntuaci´on - Alto - Medio - Bajo Autentificaci´on (Au) Mide la cantidad de veces que un atacante necesita autentificarse para aprovechar la vulnerabilidad. Cuantas menos autentificaciones sean necesarias, mayor ser´a la puntuaci´on - M´ultiple -´ Unico - Ninguno Impacto de confidencialidad (C) Mide el impacto de confidencialidad de un ataque realizado con ´exito. La confidencialidad se refiere a la divulgaci´on de informaci´on solo a los usuarios autorizados - Ninguno - Parcial - Completo M´etricas Base Impacto de integridad (I) Mide el impacto en la integridad del sistema despu´es de una vulnerabilidad explotada con ´exito. La integridad se refiere a la veracidad de la informaci´on - Ninguno - Parcial - Completo Impacto de disponibilidad (A) Mide el impacto en la disponibilidad del sistema despu´es de una vulnerabilidad explotada con ´exito. La disponibilidad se refiere a la accesibilidad de los recursos. Los ataques consumen ancho de banda en la red, ciclos de reloj o espacio en el disco - Ninguno - Parcial - Completo Explotabilidad (E) Mide el estado actual de las t´ecnicas de explotaci´on o la disponibilidad del c´odigo. Cuanto m´as disponible est´a el c´odigo de explotaci´on, mas aumenta el numero de atacantes potenciales, incluso aquellos que no est´an calificados. - No probado - Prueba de concepto - Funcional - Alto - No definido Nivel de remedio (RL) Mide la urgencia con la que tratar la vulnerabilidad, cuanto menos oficial y permanente sea una soluci´on, mayor ser´a su puntuaci´on. - Arreglo oficial - Arreglo temporal - Soluci´on alternativa - No disponible - No definido M´etricas Temporales Informe de confianza (RC) Mide le grado de confianza en la existencia de la vulnerabilidad y de la credibilidad de los detalles t´ecnicos conocidos. Cuanto mas valida sea por el proveedor u otras fuentes acreditadas, mayor es su puntuaci´on. - Sin confirmar - Sin corroborar - Confirmado - No definido Da˜no colateral potencial (CDP) Mide el potencial de perdida de vidas o activos f´ısicos por da˜no o robo. Esta m´etrica puede medir la p´erdida econ´omica de productividad o ingresos. - Ninguno - Bajo - Bajo-Medio - Medio-Alto - Alto - No definido Distribuci´on de objetivo (TD) Mide la proporci´on de sistemas vulnerables, act´ua como indicador del entorno para aproximar el porcentaje de sistemas que podr´ıan verse afectados. - Ninguno - Bajo - Medio - Alto - No definido M´etricas de Entorno Requisitos de seguridad Esta m´etrica sirve a los analistas para marcar la importancia de los Requisitos de Confidencialidad (CR), Integridad (IR) y Disponibilidad (AR) aumentando o disminuyendo su peso en la puntuaci´on final. - Bajo - Medio - Alto - No definido 24 Cap ´ ıtulo 4. T´ ecnicas de An´ alisis de Vulnerabilidades Tabla 4.2: M´etricas del grupo Base M´ etrica Valor Descripci´ on Local (L) Solo se puede explotar con acceso f´ısico al sistema o una cuenta local Vector de acceso (AV) Red Adyacente (A) Se requiere que el atacante tenga acceso al dominio de colisi´on (difusi´on) del software vulnerable Red (N) El software vulnerable esta vinculado a la pila de red y el atacante no requiere acceso local o a la red local Alto (H) Existen condiciones de acceso espec´ıficas. Como puede ser que el atacante pueda tener privilegios elevados, la configuraci´on vulnerable se ve raramente en la practica o que el atacante dependa de m´etodos de ingenier´ıa social f´acilmente detectables por personas con conocimientos Complejidad de acceso (AC) Medio (M) Las condiciones de acceso son algo espec´ıficas. Como que la parte atacante esta limitada a un grupo de sistemas o usuarios con alg´un nivel de autorizaci´on, se deba recopilar cierta informaci´on previa al ataque o que el ataque requiera ingenier´ıa social que podr´ıa enga˜nar a algunos usuarios Bajo (L) No existen condiciones de acceso espec´ıficas. Como que el ataque se pueda realizar manualmente y sin necesidad de recopilar informaci´on adicional o que el producto afectado requiera acceso a una amplia gama de sistemas y usuarios, probablemente an´onimos y poco confiables Autenticaci´on (Au) M´ultiple (M) Se requiere que se el atacante se identifique dos o mas veces, incluso si son las mismas credenciales ´ Unico (S) La vulnerabilidad requiere que se inicie sesi´on en el sistema Ninguno (N) No se requiere ninguna autenticaci´on para aprovechar la vulnerabilidad Impacto de confidencialidad (C) Ninguno (N) No hay impacto en la confidencialidad del sistema Parcial (P) Es posible accede a algunos archivos del sistema, pero el atacante no tiene control del alcance de la informaci´on que se obtiene Completo (C) Existe una divulgaci´on total, el atacante puede acceder a todos los datos del sistema Impacto de integridad (I) Ninguno (N) No hay impacto en la integridad del sistema Parcial (P) Es posible modificar algunos archivos del sistema, pero el atacante no tiene control sobre que archivos se puede sobrescribir o modificar, por lo que el alcance es limitado Completo (C) Existe una p´erdida total de protecci´on del sistema, el atacante puede modificar cualquier archivo el sistema Impacto de disponibilidad (A) Ninguno (N) No hay impacto en la disponibilidad del sistema Parcial (P) El rendimiento esta reducido o existen interrupciones en la disponibilidad de los recursos Completo (C) Hay un cierre total de los recursos afectados, el atacante puede hacer que los recursos no est´en disponibles por completo 4.3. Est´ andares 25 Tabla 4.3: M´etricas del grupo Temporal M´ etrica Valor Descripci´ on Explotabilidad (E) No probado (U) No existe c´odigo de la explotaci´on, o es solamente te´orico Prueba de concepto (POC) Existe un c´odigo de explotaci´on de una demostraci´on del ataque, pero al no ser funcional en todos los entornos o situaciones, puede requerir una modificaci´on sustancial por parte de un atacante experto Funcional (F) El c´odigo de la explotaci´on esta disponible y es funcional en la mayor´ıa de las situaciones Alto (H) El c´odigo funciona en todas las situaciones o se entrega de forma activa a trav´es de un agente aut´onomo m´ovil (virus o gusano) No definido (ND) Este valor sirve para omitir esta m´etrica cuando se calcule la puntuaci´on Nivel de remedio (RL) Arreglo Oficial (OF) El proveedor ha emitido un parche oficial con una soluci´on completa Arreglo temporal (TF) Hay una soluci´on oficial de manera temporal Soluci´on alternativa (W) Hay una soluci´on no oficial. En la mayor´ıa de casos, la entidad afectada crear´a un parche propio para mitigar la vulnerabilidad No disponible (U) No hay una soluci´on disponible, o es imposible de aplicar No definido (ND) Este valor sirve para omitir esta m´etrica cuando se calcule la puntuaci´on Informe de confianza (RC) Sin confirmar (UC) Existe una ´unica fuente no confirmada, o varios informes contradictorios Sin corroborar (UR) Hay varias fuentes no oficiales. Puede haber detalles t´ecnicos contradictorios o hay alguna ambig¨uedad Confirmado (C) La vulnerabilidad ha sido reconocida por el proveedor o autor de la tecnolog´ıa afectada No definido (ND) Este valor sirve para omitir esta m´etrica cuando se calcule la puntuaci´on Tabla 4.4: M´etricas del grupo de Entorno M´ etrica Valor Descripci´ on Da˜no colateral potencial (CDP) Ninguno (N) No hay posibilidad de perdida de vidas, activos f´ısicos, productividad o ingreso Bajo (L) Una explotaci´on exitosa puede resultar en da˜nos f´ısicos o materiales leves Bajo-medio (LM) Una explotaci´on exitosa puede resultar en da˜nos f´ısicos o materiales moderados Medio-alto (MH) Una explotaci´on exitosa puede resultar en da˜nos f´ısicos o materiales significativos Alto (H) Una explotaci´on exitosa puede resultar en da˜nos f´ısicos o materiales catastr´oficos No definido (ND) Este valor sirve para omitir esta m´etrica cuando se calcule la puntuaci´on Distribuci´on de objetivo (TD) Ninguno (N) No existen sistemas objetivos, solo el 0 % est´a en riesgo Bajo (L) Existen sistemas objetivos, pero a peque˜na escala, solo entre el 1 % y el 25 % est´a en riesgo Medio (M) Existen sistemas objetivos, pero a peque˜na escala, solo entre el 26 % y el 75 % est´a en riesgo Alto (H) Existen sistemas objetivos, pero a peque˜na escala, solo entre el 76 % y el 100 % est´a en riesgo No definido (ND) Este valor sirve para omitir esta m´etrica cuando se calcule la puntuaci´on Requisitos de seguridad Bajo (L) La p´erdida de la m´etrica asociada tenga solo un efecto adverso limitado en la organizaci´on Medio (M) La p´erdida de la m´etrica asociada tenga solo un efecto adverso grave en la organizaci´on Alto (H) La p´erdida de la m´etrica asociada tenga solo un efecto adverso catastr´ofico en la organizaci´on No definido (ND) Este valor sirve para omitir esta m´etrica cuando se calcule la puntuaci´on Cap´ıtulo 5 Trabajos relacionados En [Gvi20], se analiza la seguridad de la tecnolog´ıa de rastreo de proximidad que desarrollaron Google Inc. y Apple Inc. inspirada en el protocolo DP-3T. Este trabajo se centra en el an´alisis de seguridad con las especificaciones de ´esta tecnolog´ıa, analizan los ataques m´as comunes, sus consecuencias y proponen nuevas estrategias para la mitigaci´on de los mismos. Los ataques que analizan son: Ataques de consumo de energ´ ıa y almacenamiento: El atacante ataca a un dispositivo cercano enviando un gran volumen de mensajes. Si el mensaje no es v´alido, el dispositivo lo descarta, pero gastando energ´ıa (ataque de consumo de energ´ıa). Si el mensaje es v´alido, la aplicaci´on de rastreo almacena el id (ataque de consumo de almacenamiento), como se muestra en la Figura 5.1. Figura 5.1: (a) Ataque de consumo de energ´ıa. (b) Ataque de consumo de almacenamiento. Ataques de retransmisi´ on y repetici´ on: En un ataque de retransmisi´on, el atacante utiliza dos dispositivos en dos ubicaciones distintas y transmite desde un dispositivo cualquier mensaje retransmitido desde el otro. En un ataque de repetici´on, el atacante usa uno o dos dispositivos en diferentes momentos y transmite en el momento posterior un mensaje grabado en el momento anterior, como se muestra en la Figura 5.2. 33 34 Cap ´ ıtulo 5. Trabajos relacionados Figura 5.2: (a) Ataque de retransmisi´on. (b) Ataque de repetici´on. Ataques de trolling: El atacante es una persona que ha sido diagnosticada o espera ser diagnosticada positiva en COVID-19 pronto, y est´a interesada en hacer que las personas desprevenidas teman haber estado expuestas al virus. El atacante conecta su dispositivo m´ovil a un transporte (como un perro, un autom´ovil o un dron), que corre y anuncia id de proximidad a dispositivos de personas desprevenidas, como se muestra en la Figura 5.3. Figura 5.3: Ataque de trolling. Ataques de enlace: El atacante expone dos mensajes como provenientes del mismo dispositivo objetivo. El atacante permanece en una ubicaci´on fija durante un tiempo suficiente para recibir mensajes de cualquier dispositivo cercano. En un ataque de enlace basado en el tiempo, el atacante infiere que es probable que dos mensajes est´en 35 vinculados cuando su diferencia de tiempo es consistente con la frecuencia regular de mensajes. Ataques de localizaci´ on de se˜ nales: : El atacante est´a interesado en exponer la identidad de una o varias personas en una reuni´on, cuyo dispositivo anuncia mensajes que incluyen ID de proximidad particulares. Con este fin, el atacante rastrea la intensidad de la se˜nal de Bluetooth, junto con el campo de nivel de potencia de transmisi´on y la ubicaci´on del dispositivo m´ovil del atacante cuando se recibi´o cada mensaje, y usa esta informaci´on para inferir ubicaciones sobre el tiempo de la persona objetivo con buena precisi´on. El atacante puede identificar a la persona objetivo observando f´ısicamente qui´en est´a presente en las ubicaciones inferidas a lo largo del tiempo. Ataques de singularizaci´ on: El atacante acerca un dispositivo a la persona objetivo, registra el ID de proximidad recibido junto con cu´ando y d´onde, y deja de grabar en ese dispositivo. Si la persona objetivo es diagnosticada positiva, las claves de diagn´ostico de la persona objetivo permitir´an al atacante hacer coincidir los ID registrados en el dispositivo y se˜nalar a la persona objetivo. Esta investigaci´on demuestra que las especificaciones en el momento de la investigaci´on pueden introducir riesgos importantes para la sociedad, como violaciones de privacidad y p´erdida de confianza en el sistema. Las estrategias de mitigaci´on que proponen para los ataques descritos no requieren cambios arquitect´onicos en las especificaciones y son f´aciles de adoptar. En el art´ıculo [MKHR+20], se detallan las principales arquitecturas usadas para el desarrollo de rastreo de contactos(centralizadas y descentralizadas), que tecnolog´ıas usan y c´omo funcionan, como se muestra en la Tabla 5.1. El art´ıculo tambi´en analiza diferentes tipos de posibles ataques y propone t´ecnicas de mitigaci´on. Por ´ultimo, el art´ıculo habla sobre varias aplicaciones m´oviles de rastreo del COVID-19 europeas, nos informa sobre como se llaman, que tipo de arquitectura usan, que tecnolog´ıa usan (BLE,Global Positioning System (GPS), etc.), como gestionan los datos y como funcionan ´estas aplicaciones m´oviles. En el art´ıculo [HWMF21] analizan la privacidad y seguridad de 28 aplicaciones Android de rastreo de contactos, que se muestran en la Tabla 5.2. Analizan los privilegios de su c´odigo, las pol´ıticas de privacidad y el desempe˜no est´atico y din´amico. Tambi´en recopilan solicitudes de permisos, textos de pol´ıticas de privacidad, accesos a recursos en tiempo de ejecuci´on y vulnerabilidades de seguridad existentes y con ´estos datos eval´uan el impacto sobre la privacidad de los usuarios. La investigaci´on concluye que muchas de las aplicaciones se dise˜naron de manera r´apida, no tienen en cuenta la regulaci´on de la privacidad y su documentaci´on y pol´ıticas parecen incompletas. 36 Cap ´ ıtulo 5. Trabajos relacionados Los principales hallazgos son: Las pol´ıticas de privacidad para muchas aplicaciones se encontraron incompletas o inexistentes. Muchas aplicaciones mostraron un comportamiento de acceso a los permisos que invad´ıa la privacidad, especialmente los relacionados con la ubicaci´on. Varias aplicaciones comenzaron a acceder a los permisos de ubicaci´on antes de personalizarlos y registrarlos. Las aplicaciones de la UE mostraron, en general, menos riesgos de privacidad que las aplicaciones fuera de la UE. A´un as´ı, la mayor´ıa de las aplicaciones no cumplen con uno o m´as principios de privacidad. El an´alisis de vulnerabilidades de c´odigo mostr´o varias vulnerabilidades en los c´odigos de las aplicaciones. Estos hallazgos indican un estado muy inmaduro de las aplicaciones de rastreo. Tabla 5.1: Principales caracter´ısticas de los frameworks de rastreo de contactos. Framework Enfoque C´ odigo Autoridad Ubicaci´ on Autoreporte fuente sanitaria recopilados DP-3T Descentralizado Abierto SI NO NO Google/Apple Descentralizado Propiedad SI NO NO PEPP-PT-NTK Centralizado Abierto SI NO NO ROBERT Centralizado Abierto SI NO NO BlueTrace Centralizado Abierto SI NO NO TraceSecure Centralizado No disponible SI NO NO DESIRE Hibrido No disponible SI NO NO PACT(UW) Descentralizado Abierto SI NO NO PACT(MIT) Descentralizado No disponible SI Opcional NO TCN Descentralizado Abierto Opcional NO SI Open Covid Trace Descentralizado Abierto SI SI NO Whisper Tracing Descentralizado No disponible NO Opcional SI 37 Tabla 5.2: Tabla de las 28 aplicaciones analizadas. Pa ´ ıs App Tecnolog ´ ıa Tecnolog ´ ıa Tecnolog ´ ıa GPS BLE Sensors Australia COVIDSafe X Austria Stopp Corona X Brasil Coronavirus-SUS X Colombia CoronApp X Rep. Checa eRouska X Alemania Ito X Hungr´ıa VirusRadar X Georgia Stop Covid X X X Islandia Ranking C-19 X India Mahakavach X India COVA Punjab X India Aarogya Setu X X Israel Hamagen X Italia SM-Covid19 X X Italia diAry X X X Jordania Aman X Malasia Gerak X Malasia MyTrace X Macedonia del Norte StopKorona! X Noruega Smittestopp X X Rusia Contact Tracer X X Singapur Trace Together X Sud´africa Covi-ID X UK COVID Symptom Study X US COVID Safe X US PrivateKit X US NOVID X X Global Coalition X Cap´ıtulo 6 An´alisis de Vulnerabilidades en Aplicaciones Europeas de Rastreo de Covid-19 basadas en el Protocolo DP3T En este cap´ıtulo describimos detalladamente los resultados obtenidos de nuestro an´alisis sobre algunas de las aplicaciones m´oviles europeas de rastreo de proximidad para el COVID-19. Para realizar el an´alisis est´atico y din´amico de las aplicaciones se ha utilizado una herramienta autom´atica como es Mobile Security Framework (MobSF) y un emulador de Android para simular un smartphone Android como es Genymotion. Se empezar´a explicando como se prepar´o el laboratorio de trabajo en la Secci´on 6.1, a continuaci´on se detallar´a la informaci´on sobre las aplicaciones analizadas en la Secci´on 6.2 y se terminar´a con el an´alisis de las vulnerabilidades de dichas aplicaciones en la Secci´on 6.3. 6.1. Preparaci´on del laboratorio de trabajo Para el desarrollo del an´alisis de las vulnerabilidades en las aplicaciones de rastreo de proximidad de la COVID-19 se ha utilizado un ordenador port´atil con conexi´on a internet en el que se ha instalado una herramienta autom´atica de an´alisis de aplicaciones m´oviles y un emulador Android para realizar el an´alisis din´amico de las aplicaciones. Dado que las aplicaciones tienen protecci´on contra las m´aquinas virtuales obligando al uso de bluetooth y pol´ıticas de rastreo de Google ha resultado m´as dif´ıcil emularlo. Por suerte con el entorno de pruebas de MobSF no se ha tenido mayor complicaci´on para realizar el an´alisis tanto est´atico como din´amico. Antes de decidir por utilizar el entorno de MobSF se barajaron m´as opciones, como una m´aquina virtual especializada para el an´alisis de vulnerabilidades en dispositivos m´oviles llamado Santoku. Se explor´o como primera opci´on esta distribuci´on de Linux por 39 40 Cap ´ ıtulo 6. An´ alisis de Vulnerabilidades en Aplicaciones Europeas de Rastreo de Covid-19 basadas en el Protocolo DP3T su integraci´on con el emulador de dispositivos m´oviles que se consider´o mejor (Genymotion presentado en la Figura 6.1) adem´as de por la gran cantidad de herramientas que ten´ıa preinstaladas, como Wireshark, Mercury, Nmap, OWASP ZAP, Drozer o TCPDUMP entre muchas otras. Al final se acab´o descartando este entorno por la imposibilidad de emular las aplicaciones y usar las herramientas eficientemente. (a) Interfaz del emulador de Android Genymotion (b) Emulaci´on de smartphone Xiaomi Redmi Note 7 Figura 6.1: Emulador Genymotion La siguiente distribuci´on de Linux que se prob´o fue Androl4b, que cuenta tambi´en con una gran cantidad de herramientas para el an´alisis de penetraci´on, lo m´as relevante es que tiene instalada la herramienta que tiene mejor fama, MobSF (Figura 6.2). Figura 6.2: Interfaz de la herramienta MobSF. 6.2. Aplicaciones 41 Con este entorno se consigui´o lanzar an´alisis est´aticos sobre las Android Application Package (APK) de las aplicaciones, pero en la m´aquina virtual no se pod´ıan lanzar an´alisis din´amicos, por lo que tambi´en se acab´o descartando este entorno. El entorno final se mont´o con MobSF instalado de forma nativa en Windows que, adem´as de permitir realizar an´alisis din´amicos, daba informaci´on extra en los an´alisis est´aticos como, por ejemplo, la localizaci´on de los servidores que se usan en las aplicaciones. 6.2. Aplicaciones Para realizar los an´alisis se ha escogido 18 aplicaciones Europeas que usan la Tecnolog´ıa desarrollada por Google y Apple, que se basa en el protocolo DP-3T. La Tabla 6.1 se muestran las aplicaciones analizadas. Tabla 6.1: Aplicaciones analizadas Pais Aplicaci´ on Versi´ on Alemania Corona-Warn 1.13.2 Chipre CovTracer 2.0.2 Dinamarca Smite — stop 2.3.3 Eslovaquia ZostanZdravy 1.0.1 Eslovenia OstaniZdrav 1.10.1 Espa˜na Radar Covid 1.3.0 Estonia Hoia 1.0.9 Finlandia Koronavilkku 2.2.0 Francia Stop Covid-19 2.2.0 Holanda CoronaMelder 1.2.3 Hungr´ıa VirusRadar 1.0.0 Italia Immuni 2.2.1 Letonia Apturi Covid 1.0.52 Macedonia StopKorona! 1.1.0 Polonia STOP COVID-ProteGO Safe 4.9.1 Portugal STAYAWAY 1.1.3 Rep. Checa eRouska 2.2.687 Suiza SwissCovid 1.4.0 Es importante notar la versi´on que se ha utilizado para realizar los an´alisis. Los errores descritos m´as adelante pueden haber sido corregidos en versiones posteriores. Para obtener las APK de estas aplicaciones se consiguieron en la web APKPure pues no hay una manera oficial de conseguirlas. 6.3. An´alisis de Resultados Una vez conocidos el entorno de trabajo y las aplicaciones analizadas, se va a explorar cada vez m´as en profundidad los datos que ha proporcionado el analizador MobSF con una visi´on general en la Secci´on 6.3.1, un an´alisis de los permisos en la Secci´on 6.3.2 y un 48 Cap ´ ıtulo 6. An´ alisis de Vulnerabilidades en Aplicaciones Europeas de Rastreo de Covid-19 basadas en el Protocolo DP3T Tabla 6.4: Problemas de c´odigo detectados en las aplicaciones por MobSF Problema Severidad CVSS CWE OWASP OWASP V2 Top 10 MASVS 1. Utiliza un generador de n´umeros aleatorios inseguro alto 7.5 CWE-330 M5: Criptogaf´ıa insuficiente MSTG-CRYPTO-6 2. Los ficheros pueden contener informaci´on codificada alto 7.4 CWE-312 M9: Ingenier´ıa inversa MSTG-STORAGE-14 3. Implementaci´on insegura de SSL alto 7.4 CWE-295 M3: Comunicaci´on insegura MSTG-NETWORK-3 4. SHA-1 es una hash con colisiones hash alto 5.9 CWE-327 M5: Criptogaf´ıa insuficiente MSTG-CRYPTO-4 5. Utiliza una BD SQLite y ejecuta consultas SQL sin formato alto 5.9 CWE-89 M7: Calidad del c´odigo del cliente NA 6. Crea archivos temporales alto 5.5 CWE-276 M2: Almacenamiento MSTG-STORAGE-2 7. Puede leer/escribir desde almacenamiento externo alto 5.5 CWE-276 M2: Almacenamiento de datos inseguro MSTG-STORAGE-2 8. MD5 es un hash con colisiones hash alto 4.4 CWE-327 M5: Criptogaf´ıa insuficiente MSTG-CRYPTO-4 9. Implementaci´on insegura de WebView aviso 8.8 CWE-749 M1: Uso inadecuado de la plataforma MSTG-PLATAFORM-7 10. Divulgaci´on de direcciones IP aviso 4.3 CWE-200 NA MSTG-CODE-2 11. Escucha cambios en el portapapeles aviso 0 NA NA MSTG-STORAGE-2 12. Se escribe informaci´on sensible en los registros de la aplicaci´on informaci´on 7.5 CWE-532 NA MSTG-STORAGE-3 13. Puede escribir en el directorio de la aplicaci´on informaci´on 3.9 CWE-276 NA MSTG-STORAGE-14 14. Copia datos al portapapeles informaci´on 0 NA NA MSTG-STORAGE-10 15. Utiliza cifrado SQL informaci´on 0 NA NA MSTG-CRYPTO-1 6.3. An´ alisis de Resultados 49 Figura 6.4: N´umero de problemas de c´odigo por aplicaci´on Los errores m´as graves que tienen algunas aplicaciones son referentes al tratamiento de informaci´on sensible. Como se indica en la Tabla 6.5 el 100 % de las aplicaciones escriben este tipo de informaci´on en los registros de la aplicaci´on (logs) Lo que vulnera gravemente la privacidad del usuario de la misma y, adem´as, un 72 % de las aplicaciones contienen ficheros con informaci´on codificada. Un 61 % de las aplicaciones tienen problemas con la divulgaci´on de direcciones IP, lo que conllevar´ıa una exposici´on de informaci´on que no deber´ıa llegar a personas no autorizadas [PLO21]. Aunque el problema m´as preocupante se encuentra en el generador de n´umeros aleatorios inseguro (1), es el m´as grave porque toda la infraestructura de generaci´on de EphID se basa en n´umeros aleatorios, si su generaci´on es insegura y se pueden predecir los EphID quiere decir que alguien con ese conocimiento podr´ıa suplantar la identidad de otro usuario con el fin de atacar el sistema. 50 Cap ´ ıtulo 6. An´ alisis de Vulnerabilidades en Aplicaciones Europeas de Rastreo de Covid-19 basadas en el Protocolo DP3T Tabla 6.5: Aplicaciones con los problemas de c´odigo de la Tabla 6.4 Aplicaci´ on 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 Corona-Warn CovTracer Smite — stop ZostanZdravy OstaniZdrav Radar Covid Hoia Koronavilkku Stop Covid-19 CoronaMelder VirusRadar Immuni Apturi Covid StopKorona! STOP COVID-ProteGO Safe STAYAWAY eRouska SwissCovid Cap´ıtulo 7 Contribuciones Individuales 7.1. Pablo Izquierdo Garbajosa El primer paso al comenzar este trabajo fue recopilar toda la informaci´on posible de trabajos y art´ıculos relacionados principalmente con el protocolo DP-3T, pero tambi´en informaci´on sobre los diferentes tipos de modelos y protocolos que existen acerca del rastreo de contactos. Para la recopilaci´on de la informaci´on se utiliz´o el buscador de Google Scholar. En este paso aprend´ı a hacer uso del buscador Google Scholar para buscar los art´ıculos relacionados con el desarrollo del trabajo. Al ser ´este protocolo bastante reciente, la recopilaci´on de la informaci´on relevante para el trabajo ha sido un poco complicada, con lo que tambi´en se ha aprendido a filtrar la informaci´on m´as relevante para nuestro trabajo. Con el paso de los meses se fueron publicando tambi´en art´ıculos relacionados con el an´alisis de vulnerabilidades de las aplicaciones de rastreo del COVID-19 que usan diferentes pa´ıses del mundo que nos ayudaron mucho en nuestro proceso de recopilaci´on de informaci´on. Tambi´en destacar que pr´acticamente todos los art´ıculos relacionados con nuestro trabajo est´an escritos en ingl´es, esto me ha ayudado a mejorar mi lectura y mi vocabulario de dicho idioma. El segundo paso fue buscar las aplicaciones m´oviles de rastreo de contactos y la preparaci´on del laboratorio de trabajo para realizar el an´alisis de dichas aplicaciones. De la informaci´on recopilada anteriormente se eligieron las aplicaciones Europeas que se basaban en el protocolo DP-3T y descargamos sus APK de la web APKPure. Para la creaci´on del laboratorio buscamos informaci´on sobre las herramientas m´as utilizadas a la hora de realizar test de penetraci´on en aplicaciones m´oviles Android, con lo que aprend´ı a montar mi propio laboratorio de pruebas para analizar vulnerabilidades en aplicaciones m´oviles Android. Instalamos y probamos varios entornos virtuales creados para el tipo de an´alisis que necesit´abamos hacer pero ninguno permit´ıa realizar tanto an´alisis est´atico como din´amico, hasta que encontramos la herramienta MobSF que se pod´ıa instalar de forma nativa en Windows y permit´ıa hacer el an´alisis est´atico y permit´ıa hacer el an´alisis din´amico a trav´es de Genymotion, que fue la herramienta elegida para 51 52 Cap ´ ıtulo 7. Contribuciones Individuales emular un dispositivo Android. En ´este paso, a parte de aprender el uso de la herramienta MobSF, durante la b´usqueda de las herramientas que nos sirvieran para el an´alisis de aplicaciones aprend´ı el uso de otras herramientas de an´alisis de vulnerabilidades, como Drozer, que es un framework para testear vulnerabilidades de aplicaciones haciendo uso tambi´en de la herramienta Genymotion, pero no nos proporcionaba la informaci´on que busc´abamos. Tambi´en aprend´ı acerca de entornos virtuales como Androl4b, que es una distribuci´on de Linux que re´une herramientas de an´alisis de vulnerabilidades y de hacking ´etico, una de esas herramientas es MobSF, que es la herramienta que elegimos finalmente para nuestros an´alisis, pero ´esta distribuci´on no permit´ıa hacer el an´alisis din´amico de la aplicaci´on, por que la descartamos. Otra distribuci´on que aprend´ı fue Santoku, que incluye herramientas como Wireshark y la ya mencionada Drozer, pero tambi´en la descartamos ya que no nos proporcionaba las herramientas de an´alisis que necesitabamos. El siguiente paso fue analizar las aplicaciones seleccionadas a trav´es del laboratorio creado. Pasamos todas las aplicaciones por el analizador y recabamos toda la informaci´on que nos daba la herramienta MobSF. La herramienta nos dio informaci´on de todo tipo como el pa´ıs y la versi´on de Android de la aplicaci´on, localizaci´on de los servidores que utilizan, las API de Google y los permisos que solicitan cada aplicaci´on para funcionar. Para el apartado de los permisos, la herramienta hace uso de est´andares como CWE y OWASP MASVS, con los que hace una puntuaci´on de severidad sobre cada permiso, para entender el significado de dichas puntuaciones tuvimos que consultar sus respectivas p´aginas web y estudiar su significado. En este proceso, descartamos una gran cantidad de datos que la herramienta no identificaba como peligrosos y nos centramos en aquellos datos en los que la herramienta daba una puntuaci´on de peligro potencial. Toda esta informaci´on la recopilamos en tablas que luego fueron plasmadas en la memoria. En este paso aprend´ı a realizar un an´alisis est´atico y din´amico de una aplicaci´on m´ovil y cosas como ver y entender que tipos de permisos solicitan las aplicaciones y si suponen un peligro para el usuario, y el funcionamiento de los diferentes est´andares usados en el an´alisis de vulnerabilidades. Por ´ultimo pasamos a realizar la memoria y plasmar en ella toda la informaci´on estudiada y los experimentos realizados sobre las aplicaciones de rastreo de contactos. Para la realizaci´on de la memoria nuestros tutores nos recomendaron el uso de la herramienta LaTeX, herramienta que us´abamos por primera vez. Durante la elaboraci´on de la memoria he aprendido a hacer uso de la herramienta LaTeX y he comprobado que es una herramienta muy ´util para la realizaci´on de este tipo de trabajos, ayudando a mantener un formato adecuado y facilitando la inserci´on de im´agenes y tablas. 7.2. Alonso Mart ´ ın Zurdo 53 7.2. Alonso Mart´ın Zurdo Durante los primeros meses el primero objetivo fue la de recopilar informaci´on en distintos trabajos sobre el protocolo DP-3T, las vulnerabilidades que se pueden realizar y como se podr´ıan mitigar adem´as de distintos modelos de rastreo de contactos, as´ı como las ventajas de cada uno de ellos. Como este protocolo es relativamente nuevo, ha sido m´as complicado encontrar informaci´on relevante para el trabajo, aun con todo aprendiendo a usar el motor de busqueda de Google Scholar para encontrar distintos papers tambi´en se ha aprendido a filtrar la informaci´on relevante y resumirla de forma que sea m´as entendible a la hora de que alguien externo al tema lo lea m´as adelante. No fue hasta mas adelante que se publicaron varios papers sobre el an´alisis de vulnerabilidades en el protocolo DP-3T en los que analizaban aplicaciones de todos los pa´ıses, pero centr´andose en el reglamento general de protecci´on de datos y comparando as´ı las aplicaciones que estaban dentro de la UE con las que se desarrollaron fuera de ella. Este trabajo fue clave para enfocar el proyecto y, en concreto como gu´ıa para poder interpretar los datos obtenidos por el analizador. El planteamiento inicial era ejecutar distintos ataques sobre las aplicaciones basados en BLE que, si no esta bien implementado puede dar lugar a serios huecos en la seguridad del sistema. Todo este planteamiento requiri´o un estudio del protocolo de Bluetooth en profundidad que mas adelante se acab´o descartando por un enfoque m´as general con un analizador autom´atico de vulnerabilidades. M´as adelante empez´o la b´usqueda de herramientas para realizar un entorno de trabajo v´alido, en total se barajaron 3 entornos, empezando por la herramienta MobSF instalado en Windows de manera nativa. Este primer acercamiento al analizador dio bastantes problemas al ejecutarlo por, como se sabr´ıa mas adelante una instalaci´on corrupta de Python en el dispositivo. A continuaci´on se opt´o por el sistema Linux Santoku, que esta especializado para hacer an´alisis sobre dispositivos m´oviles, en especial se aprendi´o a utilizar Wireshark que sirve para hacer un an´alisis de los paquetes enviados a una red, conect´andolo al emulador de Android se pretend´ıa analizar el tr´afico de las aplicaciones de forma manual. La otra aplicaci´on que aprendi´o en profundidad fue Drozer, que se trata de un framework que utiliza un APK instalado en el m´ovil para hacer una conexi´on entre el m´ovil (emulador) y la m´aquina anfitriona de Santoku para ejecutar ataques como inyecciones SQL. Todo este aprendizaje se hizo de forma te´orica pues cuando se fue a ejecutar la herramienta se acab´o descubriendo la protecci´on contra la emulaci´on de las aplicaciones y se tuvo que descartar este entorno. Lo siguiente que se prob´o fue la distribuci´on de Linux Androl4b que, aunque ten´ıa menos herramientas para la simulaci´on de ataques, conten´ıa la herramienta que estaba mejor valorada, que era MobSF. Con esta herramienta se pudieron realizar los an´alisis est´aticos de las aplicaciones sin necesidad de utilizar un dispositivo f´ısico conectado. Aun 54 Cap ´ ıtulo 7. Contribuciones Individuales as´ı este entorno ten´ıa la limitaci´on de solo poder realizar an´alisis est´atico. Al ver esto se opt´o por instalar la herramienta de forma nativa en Windows, lo que result´o, junto al emulador de Android Genymotion en el entorno de trabajo final. Hasta encontrar una combinaci´on de emulador Android y analizador que permitiera buscar errores en las aplicaciones el tiempo invertido en aprender a manejar los entornos anteriores sirvi´o m´as adelante para entender mejor la herramienta final MobSF. Las aplicaciones que se utilizaron para el an´alisis se obtuvieron a trav´es de la p´agina web APKPure debido a que muchos proyectos oficiales no daban facilidades para compilar el c´odigo. Para agilizar la b´usqueda de informaci´on se dividi´o el trabajo de documentaci´on y la especializaci´on fue la b´usqueda y entendimiento del funcionamiento de las herramientas de an´alisis, as´ı como el funcionamiento interno de las mismas. Esto incluye los est´andares utilizados por la herramienta MobSF as´ı como las distintas fases y tipos de an´alisis utilizados por las empresas de software. Este conocimiento est´a plasmado en el Cap´ıtulo 4. Este trabajo de documentaci´on sirvi´o para entender de manera m´as cr´ıtica las puntuaciones que daba la herramienta MobSF. Tras analizar las aplicaciones se configuraron distintas tablas recabando los resultados obtenidos al ejecutar el analizador MobSF. Dichas tablas agruparon los resultados seg´un el lugar donde se obtuvieron los errores, como en el c´odigo o en los permisos. Debido al gran volumen de datos que se estaban manejando, se acab´o por descartar los datos que el analizador detectaba con ninguna severidad o datos de la estructura. Esta criba redujo los datos en un 40 % del total, lo que hizo el estudio m´as manejable y, por tanto, m´as sencillo. Una vez clasificados los errores se busc´o la severidad real de los mismos para comprobar como de grave eran los resultados que estaban marcados como severos o desconocidos. Para este proceso de comprobaci´on se consultaron las p´aginas web de distintos est´andares como CWE oOWASP MASVS, as´ı como tambi´en la API de Google para ver el uso de los permisos as´ı como las precondiciones y usos de los mismos. Esto ´ultimo acab´o dando mucha perspectiva con lo que respecta a los datos obtenidos y, sobre todo una visi´on de como se estaban utilizando ciertos permisos en contra de lo que indicaba la API. Con toda la informaci´on contrastada se escribi´o la memoria haciendo uso por primera vez del lenguaje de edici´on LaTeX haciendo hincapi´e en la realizaci´on de tablas y figuras adem´as de plasmar los resultados de los an´alisis y las conclusiones de los mismos. El trabajo m´as duro fue el de la organizaci´on de la informaci´on en el documento, pues debido al gran volumen de informaci´on empezaba a ser ca´otica. Las tablas mencionadas anteriormente sirvieron mucho a la hora de compactar y organizar los datos. Para la realizaci´on de las figuras mencionadas anteriormente se utiliz´o la web draw.io que al ser la primera vez que se montaba una figura que compactaba informaci´on ayud´o la simplicidad de la herramienta para acostumbrarse al entorno. Se hizo una excepci´on con el diagrama de Gantt que se hizo uso de la web Lucidchart que hab´ıa sido utilizada 7.2. Alonso Mart ´ ın Zurdo 55 anteriormente para asignaturas donde se hab´ıan hecho proyectos que requer´ıan de este tipo de diagramas. Todo el uso de la herramienta LaTeX supuso un esfuerzo extra ya que, como se ha comentado anteriormente, ha sido la primera toma de contacto con el entorno y ha sido necesario un aprendizaje de la realizaci´on de tablas, el uso de glosarios y la adecuada utilizaci´on de referencias para dar una estructura adecuada al documento final. Cap´ıtulo 8 Conclusiones y Trabajo Futuro 8.1. Conclusiones El objetivo de este trabajo era la comprobaci´on de seguridad en distintas aplicaciones europeas de rastreo de contactos basadas en el protocolo DP-3T mediante herramientas autom´aticas de an´alisis de vulnerabilidades. Esto se ha visto ralentizado por varios factores. El primero de esos factores es la novedad del protocolo. Esto provoca que la informaci´on sobre la misma sea reducida. El siguiente factor es la inexperiencia en el ´ambito del an´alisis de vulnerabilidades. Esto aument´o la curva de dificultad de entrada a la hora de realizar los experimentos como de interpretar los resultados devueltos por la misma. El ´ultimo de los factores es la protecci´on contra emulaciones de las aplicaciones. Como se ha mencionado en cap´ıtulos anteriores, estas aplicaciones tienen c´odigo que impide emularlo en una plataforma como Genymotion. Al principio fue una gran barrera para ejecutar los an´alisis, pero gracias a la herramienta MobSF acab´o por no ser m´as problema que la situaci´on inicial. Aun as´ı, el resultado fue satisfactorio y se pudo encontrar la manera de ejecutar los an´alisis sobre las aplicaciones. Estos an´alisis se ejecutaron con la ayuda de un analizador autom´atico llamado MobSF que ejecutaba sobre un emulador de Android, Genymotion, las aplicaciones que usan el protocolo DP-3T con la intenci´on de encontrar brechas en la seguridad y con ellas hacer un informe, puntuando seg´un los est´andares de la herramienta, estableciendo as´ı un grado de severidad de los errores encontrados. Los est´andares de esta herramienta se detalla su funcionamiento ´ıntegramente en el Cap´ıtulo 4, estos son CVSS que ayuda a puntuar de forma num´erica la gravedad de los resultados, OWASP MASVS que detalla los requisitos m´ınimos de ciberseguridad requeridos en una aplicaci´on con caracter´ısticas similares, y CWE que detalla los ataques que se pueden realizar con determinados errores en la seguridad. El resultado final de los an´alisis han sido negativos en cuanto a los permisos otorgados, errores de c´odigo entre otros. Como se detalla en el Cap´ıtulo 6las puntuaciones por parte del analizador MobSF han sido bajas en general, con una media de 47.7 de puntuaci´on 57 64 Cap ´ ıtulo 9. Introduction 9.4. Structure Of This Paper The rest of the work is organized in seven chapters with the structure that is commented below: Chapter 2contextualizes and briefly introduces the origins, concepts and theoretical bases of contact tracing applications in a general way. In Chapter 3the decentralized proximity tracking protocol is discussed in more detail. Their types and their operation are described, as well as analyzing and comparing their privacy and security between the different models that exist. Chapter 4contextualizes the operation of vulnerability analysis tools. The different types are reviewed and the standards used by the tool used to analyze the applications are explained in detail. Chapter 5presents different works related to this, explaining the results obtained. Chapter 6details the results of the analyzes carried out on the different European applications and how the analysis laboratory is configured. Chapter 7summarizes the individual contributions of each member of the work team. Chapter 8concludes this work: briefly summarizing the project experience and analyzing the results of the analyzes. Future work and possible lines of research are presented. Chapters 9and 10 are English translations of Chapters 1and 8, respectively. Cap´ıtulo 10 Conclusions and Future Works 10.1. Conclusions The objective of this work was to verify security in different European contact tracing applications based on the DP-3T protocol using automatic vulnerability analysis tools. This has been slowed down by several factors. The first of these factors is the novelty of the protocol. This causes the information on it to be reduced. The next factor is inexperience in the field of vulnerability analysis. This increased the entry difficulty curve when performing the experiments and interpreting the results returned by it. The last factor is protection against application emulations. As mentioned in previous chapters, these applications have code that prevents emulation on a platform like Genymotion. At first it was a big barrier to run the analyzes, but thanks to the MobSF tool it ended up being no more of a problem than the initial situation. Even so, the result was satisfactory and a way could be found to run the scans on the applications. These analyzes were executed with the help of an automatic analyzer called MobSF that ran on an Android emulator, Genymotion, the applications that use the DP-3T protocol with the intention of finding security gaps and with them make a report, scoring according to the standards of the tool, thus establishing a degree of severity of the errors found. The standards of this tool are fully detailed in Chapter ref Chapter4, these are CVSS which helps to numerically score the severity of the results, OWASP MASVS which details the minimum cybersecurity requirements required in an application with similar characteristics, and CWE which details the attacks that can be carried out with certain security errors. The final result of the analysis has been negative in terms of the permissions granted, code errors among others. As detailed in Chapter 6, the scores from the MobSF analyzer have been low in general, with an average score of 47.7 and 6.56 points according to the CVSS standard, which indicates that they are in medium severity, only 0.44 points from starting to be considered high severity. This is due to the mishandling of sensitive information that has been detected and the use of encryption algorithms known to have 65 66 Cap ´ ıtulo 10. Conclusions and Future Works security problems, which causes their use to be discouraged. The most critical errors are the use of the SHA-1 and MD5 cryptographic algorithms that are known to have hash collisions, this means that several inputs to the hash function can achieve the same output, creating a security breach. Another critical error is the use of several types of localization (precise and approximate) When the Google API explicitly states that one or the other should be used if necessary, but not both. All this can be improved with new versions of the applications where all these aspects are dealt with. It is also understood that the time that the development teams of these applications may have had may have been very reduced taking into account the spontaneity of the COVID-19 pandemic, which may have led to suboptimal decisions during development or more focused on functionality rather than protecting the privacy and security of end users. All this does not mean that the lack of the aforementioned security elements is due to the fact that they did not find it relevant to reinforce security, but rather that they may have reinforced others that have not been detected as errors for that reason. 10.2. Future Works As possible future works, it could be interesting to carry out the following actions: Analyze the latest versions of mobile applications to see if they have improved application security. Analyze, apart from European applications, applications from the rest of the world. Analyze mobile contact tracing applications that use centralized models. Use other types of mobile application analyzers that use more updated and modern standards. Take a closer look at the random number generator to see to what extent it affects the operation of EphID creation. Simulate a real attack on a mobile device that has a contact tracing application installed, such as a DoS Bluetooth attack. Bibliograf´ıa [CBB+20] Claude Castelluccia, Nataliia Bielova, Antoine Boutet, Mathieu Cunche, C´edric Lauradoux, Daniel Le M´etayer, and Vincent Roca. Desire: A third way for a european exposure notification system. https://github.com/ 3rd-ways-for-EU-exposure-notification/project-DESIRE/blob/master/ DESIRE-specification-EN-v1_0.pdf, May 2020. [CIY20] Hyunghoon Cho, Daphne Ippolito, and Yun William Yu. Contact tracing mobile apps for covid-19: Privacy considerations and related trade-offs. arXiv preprint arXiv:2003.11511, 2020. [Dev15] Android Developers. C2d deprecated. https://developers.google.com/android/ c2dm, Jul 2015. [Dev19] Android Developers. Permisos ble. https://developer.android.com/guide/ topics/connectivity/bluetooth-le#permissions, Dec 2019. [Dev20a] Android Developers. Funciones de hardware para la iu del dispositivo. https: //developer.android.com/guide/topics/manifest/uses-feature-element? hl=es-419#location-hw-features, Apr 2020. [Dev20b] Android Developers. Permisos que implican requisitos de funciones. https: //developer.android.com/guide/topics/manifest/uses-feature-element? hl=es-419#permissions, Apr 2020. [Goo15] Google. Activity recognition api. https://developers.google.com/ location-context/activity-recognition, Jun 2015. [Goo21] Google. Permisos de ubicaci´on. https://developers.google.com/maps/ documentation/android-sdk/location?hl=es-419#location_permissions, Apr 2021. [Gvi20] Yaron Gvili. Security analysis of the covid-19 contact tracing specifications by apple inc. and google inc. IACR Cryptol. ePrint Arch., 2020:428, 2020. [HWMF21] Majid Hatamian, Samuel Wairimu, Nurul Momen, and Lothar Fritsch. A privacy and security analysis of early-deployed covid-19 contact tracing android apps. Empirical Software Engineering, 26(3):1–51, 2021. [IMP] IMPERVA. Penetration testing. https://www.imperva.com/learn/ application-security/penetration-testing/. 67 68 BIBLIOGRAF´ IA [JD20] Nele Quast Jenny Wanger Sameer Halai Andreas Gebhard Kate Gallagher Jason D’Orazio, Christoph Steinlehner. Tcn ux recommendations whitepaper. https://github.com/TCNCoalition/whitepapers/blob/master/ tcn-ux-recommendations-whitepaper-v1.pdf, June 2020. [LR] Puneet Mehta Linda Rosencrance. pen test (penetration testing). https:// searchsecurity.techtarget.com/definition/penetration-testing. [MKHR+20] Tania Martin, Georgios Karopoulos, Jos´e L Hern´andez-Ramos, Georgios Kambourakis, and Igor Nai Fovino. Demystifying covid-19 digital contact tracing: A survey on frameworks and mobile apps. Wireless Communications and Mobile Computing, 2020, 2020. [OWA17] OWASP. Owasp top ten. https://owasp.org/www-project-top-ten/, 2017. [PLO21] MITRE PLOVER, Eric Dalci. Cwe-200: Exposure of sensitive information to an unauthorized actor. https://cwe.mitre.org/data/definitions/200.html, Mar 2021. [PM07] Sasha Romanosky Peter Mell, Karen Scarfone. A complete guide to the common vulnerability scoring system. https://www.first.org/cvss/v2/guide, Jun 2007. [RWI+20] Ronald L Rivest, DJ Weitzner, LC Ivers, Israel Soibelman, and MA Zissman. Pact: Private automated contact tracing. Retrieved December, 2:2020, 2020. [SS20] Carlos Holguera Sven Schleire, Jeroen Willemsen. Mobile Application Security Verification Standard. In Mobile Application Security Verification Standard, pages 4 – 17, March 2020. [TPH+20] Carmela Troncoso, Mathias Payer, Jean-Pierre Hubaux, Marcel Salath´e, James Larus, Edouard Bugnion, Wouter Lueks, Theresa Stadler, Apostolos Pyrgelis, Daniele Antonioli, et al. Decentralized privacy-preserving proximity tracing. arXiv preprint arXiv:2005.12273, 2020. [Vau20] Serge Vaudenay. Centralized or decentralized? the contact tracing dilemma. Technical report, 2020.