Los bares { y las "Rutas de las Tapa" } también necesitan [ciber]seguridad (Parte 1 de 2)

Rutappa es una aplicación usada por multitud de consistorios de localidades de la geografía española para dar soporte al evento “Ruta de la Tapa”. A través de ella, los bares, restaurantes y demás participantes suben su tapa estrella para ser votada por los visitantes o comensales (más información en rutappa.es). El visitante entra en un sorteo por votar (cuanto más tapas diferentes voten, más posibilidades de ganar) y los bares y restaurantes aspiran a convertirse en el ganador de la “Ruta de la Tapa” de ese año y, por tanto, a exhibir la placa indicativa que les es entregada. En las siguientes líneas vamos a contar qué ocurrió durante el año paso.

Figura 1: Los bares { y las "Rutas de las Tapa" } también necesitan [ciber]seguridad
(Parte 1 de 2)

Recibimos en la oficina de blockchain3rs una llamada de un amigo personal. Su padre es propietario y regente de un bar/restaurante situado en un pueblo cualquiera de una provincia cualquiera de España. Es el negocio familiar y en él está toda la familia implicada y volcada en mejorarlo día a día. Algunos, como nuestro amigo, tienen otra profesión pero echa una mano cuando puede. Quizá en esta ocasión no solo va a ayudar a su padre sino al resto de bares y restaurantes que, con esmero y esfuerzo, participan en la "Ruta de la Tapa" de su región cada año.

Nuestro amigo nos comenta que no se fía del sistema de voto: este año se vota vía app, y cree que el ganador puede que no sea aquel más votado por los comensales reales, sino alguien que esté haciendo trampas manipulando las votaciones. Si esto fuera así, podríamos estando poniendo en riesgo la reputación de un bar, o favoreciendo a la reputación de un restaurante de forma engañosa, simplemente porque alguien tiene conocimientos de algún fallo de seguridad.

Análisis inicial de sistema  de votaciones de Runtappa

Nosotros decidimos implicarnos, y revisar a ver si el sistema de votación era robusto o cabía lugar a una manipulación por parte de alguien "tramposo" que quisiera aprovecharse. “Le vamos a echar un vistazo a la app, es casi todo lo que podemos hacer” - Le dijimos. La lógica que implementa la app para permitir a un usuario votar es la siguiente:

1) El comensal se descarga la app desde Google Play (Android) o App Store (Apple) y selecciona la ruta en la que se encuentra:

Figura 2: Aspecto de Runtappa

2) El usuario selecciona la tapa que “más le gusta”, después de supuestamente haber podido probar todas o al menos algunas. No se puede comprobar mucho de esta parte porque hay que fiarse de la buena voluntad de la persona que participa en este evento de forma altruista y como manera de agradecer el esfuerzo de los bares y restaurantes por esmerarse en esta costumbre tan nuestra de poner tapas.

Figura 3: Selección de la tapa que vamos a votar

3) El comensal le da 5 estrellas (o aceitunas) e introduce el código propio de la tapa que se encuentra en el bar o restaurante en cuestión.

Figura 4: Votando con aceitunas a la tapa

4) Si el usuario quisiera volver a votar por la misma tapa, el sistema no le permitiría hacerlo pues las protecciones de la app, a priori, no permiten votar a la misma persona más de una vez la misma tapa.

Figura 5: No se puede votar dos veces a la misma tapa

Pero la pregunta es, ¿será posible saltarse fácilmente esta protección? ¿Se puede hacer que voten muchas personas sin necesidad de utilizar la app? ¿Se podría manipular completamente el sistema de votaciones de un evento de "Ruta de la Tapa" en el que muchos restauradores se dejan tiempo y esfuerzo?

La vulnerabilidad en Runtappa

La primera acción natural que nos venía a la mente ejecutar fue la de “enterarnos” qué datos se intercambiaban la app y el servidor y cómo (protocolo o lógica) tenían implementado para evitar el double spending (en este caso realmente que un usuario no pueda votar dos veces la misma tapa).

Inicialmente asumimos que las conexiones entre app y servidor irían cifradas (haciendo uso de conexiones https probablemente) así que directamente nos decidimos a preparar un entorno de man-in-the-middle attack a nosotros mismos. A nuestro cliente. A nuestro móvil. Esta es una práctica muy común en la auditoría de aplicaciones web que se usa para poder hacer el uso de servidores proxy que nos permitan ver, detener, manipular y enviar las peticiones que van entre el cliente y el servidor.

Figura 6: Hacking Web Technologies

Con el fin de descifrar los datos y entender el flujo de la lógica del sistema de votos, con esta técnica, haríamos creer al servidor que el cliente real es nuestro servidor Proxy Forward y al cliente (la app de Runtappa) que el servidor real es también nuestro servidor Proxy Forward. Nuestro proxy controlaría y podría reportarnos entonces la conversación en claro entre las dos partes.

En el protocolo de iniciación de conexión Https, el cliente terminaría cualquier intento de establecimiento de conexión con el servidor si la firma de la entidad certificadora que va incluida en el certificado que le envía el servidor no se verifica correctamente con la clave pública de tal entidad certificadora o si el certificado que presenta el servidor no pertenece a la lista de certificados “root” de entidades certificadoras conocidas y fiables que tiene instalado el cliente por defecto.

¿Qué podemos hacer entonces? Convertirnos nosotros en una entidad certificadora en la que el cliente confíe también para, así, hacer a la app cifrar sus mensajes con el certificado que le demos desde nuestro servidor proxy (simulando por supuesto los datos esperados por el cliente en cuanto nombre, dominio…) y poder descifrarlos, y a continuación, volver a cifrar esa petición en plano con el certificado que nos envíe el servidor real. La claves simétricas negociadas en el proceso “handshake” entre cliente (app) y servidor proxy (controlado por nosotros) y entre el servidor proxy y el servidor real son por tanto conocidas por nuestro proxy.

La herramienta propietaria Charles es ampliamente usada y reconocida como buen monitor / proxy para hacer el ataque que pretendemos; sin embargo, vamos a hacer uso de la herramienta Open Source mitmproxy, la cual, además, es muy flexible y permite interceptar y modificar “on the fly” los mensajes usando su API en Python (luego veremos que haber hecho uso de esta herramienta fue un “overkill”, aunque esto es algo inherente a la ciberseguridad, donde haz de empezar con tus propias premisas y donde casi todo es parte de una búsqueda). Preparamos la infraestructura a través de los siguientes pasos (nuestro proxy correrá sobre una máquina con OSX Catalina y nuestra app cliente en iOS 13.2.3).

Figura 7: Configuramos la conexión WiFi para redirigir el tráfico al proxy

1. Instalamos desde el terminal la herramienta mitmproxy: $ brew install mitmproxy
2. Ejecutamos el programa en su versión interfaz web: $ mitmweb
3. Redirigiremos el tráfico de nuestro móvil a nuestro servidor proxy. 

Para hacer este proceso, tanto nuestra máquina proxy como el móvil tienen que estar conectados a la misma red. En nuestro caso, a la red wifi de la oficina. Configuramos nuestro móvil de la siguiente manera. En “Server” pondremos la dirección IP de nuestra máquina, y el puerto por defecto donde corre nuestro proxy (mitmweb) es 8080.

Figura 8: Redirigiendo el tráfico a nuestro proxy

Para obtener la dirección IP de nuestra máquina OSX Catalina donde tenemos instalado el Servidor Proxy, podemos ejecutar el siguiente comando en terminal (si estás conectado vía WiFi):

$ ipconfig getifaddr en0

O bien obtenerla a través de Preferencias -> Red -> Avanzado -> TCP/IP -> IPv4 Address.

4. A continuación solo quedaría instalar el certificado.

a. Accede a esta URL y selecciona el de Apple.

Figura 9: Acceder a mitm.it para instalar el certificado

b. Instálalo y verifícalo accediendo a Settings -> General -> About -> Certificate Trust Settings. Habilítalo:

Figura 10: Confianza en el certificado del servidor proxy

5. Voilà! Abre la app rutappa y accede al navegador que arrancó cuando ejecutaste el paso 2.

La primera sorpresa es que, a pesar de todo, esta app no está usando conexiones seguras bajo HTTPs. Toda la comunicación con su backend ocurre sobre tráfico HTTP sin cifrado por lo que no está protegida su privacidad, ni su integridad y podríamos haber montado entornos mucho más sencillos para interceptar el tráfico.

Figura 11: Peticiones HTTP al servidor

La conversación ocurre en texto plano.  El endpoint en el servidor que usa la app para votar es una URL tan sencilla como:

 http://retalis.es/newrutappa/rutappa_connect/votar.php

Donde se envían como parámetros por POST “deviceid”, “pid”, “voto”, “telefono”. Demasiada poca información como para controlar todos los votos que se envíen de forma maliciosa.

Figura 12: Peticiones por POST con los parámetros

Como vemos en las imágenes, cuando hacemos un Replay Attack de la llamada, obtenemos en "Response" el mensaje que leíamos desde la app cuando intentábamos votar la misma tapa por segunda vez.

Figura 13: Ataque de replay controlado 

Sin embargo, variando simplemente los parámetros “deviceid” y “telefono” y podíamos hacer un replay exitoso: el sistema de votos es demasiado sencillo de saltar. La app en el servidor no valida nada. Ni que el número telefónico esté bien formado, ni que el identificador de dispositivo tenga cierto formato, hash de 32 caracteres generado con datos del dispositivo del cliente, del que hablaremos un poco más en la segunda parte de este artículo.

Figura 14: Modificando telefóno y hash se da por válido.

Modificando estos dos parámetros, podías votar infinitas veces a la misma tapa. Rompías el concurso. Por otra parte, nos resultaba extraño que te pidiese el número de teléfono y que activaras la geolocalización sin presentarte alguna hoja de condiciones para que las aprobases relacionado con la Ley General de Protección de Datos (GDPR).

Pero aún quedan muchas cosas por evaluar, y es verdad que podrían ponerse medidas en el lado del servidor para poder detectar aquellas que pudieran haber sido fraudulentas. Todo dependería de qué procesos hubiera en el servidor para mirar cosas como los parámetros DevideID, número de teléfono, USER-Agent, Time-Stamp y dirección IP de la votación, que son todos los datos que el servidor tiene de cada voto, pero lo veremos en la segunda parte de este artículo.

Saludos.

Autor: Paco García Villarán