Cargando…README: He dedicido reescribir y juntar las dos entradas anteriores ya que el contenido se encontraba disgregado y no muy bien redactado. De hecho, es posible que éste mismo post sea reescrito en un futuro, ya que cuanto más escarbo en ésta app, más líneas de investiagación se abren.
La aplicación de mensajería WhatsApp vuelve a la carga con una funcionalidad que ya ha sido reportada como peligrosa en el pasado, ésta vez con ciertos matices diferentes. Puede que no tan peligrosos, pero que todavía suponen un riesgo para la privacidad de los usuarios de WA así como para la integridad de un servidor en la nube.
La precarga de contenido
Consiste en un mecanismo para embellecer la escritura y el envío de URLs a través del chat. Por medio de una petición HTTP hacia la URL escrita, se obtiene una página HTML de donde se extraen datos como el título de la página, la meta descripción y, si está disponible, el icono asociado al recurso.
Fig 1. Ejemplo de precarga con el buscardor
Duckduckgo.
El problema subyace en el procedimiento que WA emplea para llevar a cabo dicha petición. Lo ideal sería que al escribir la URL, la app del usuario realizara una solicitud a un servidor de la empresa, y que fuera éste último el que parseara los datos del recurso procedentes del servidor destino y finalmente los devolviera a la app del cliente. O que al menos la petición pasara por un proxy de WA. En resumen, cumplir éste esquema:
Fig 2. Esquema ideal del curso de la precarga
Por desgracia, la realidad es que el imaginario servidor intermedio de WA no existe, o al menos no está implicado en la recolección de datos. Esto supone un problema, y es que al ser nuestro terminal quien realiza las peticiones, es también la dirección IP pública del mismo quien queda reflejada en los ficheros log del servidor destino.
Fig 3. Captura de pantalla del log
Observando el log de la Fig 3, se pueden extrapolar ciertos aspectos bastante curiosos del comportamiento de WA:
- Se realiza una petición por cada letra pulsada. Es decir, no existe un
tiempo fijo de espera entre 2 peticiones HTTP. - El campo User-Agent se ha modificado por «WhatsApp».
- Efectivamente, se observa la dirección IP pública del dispositivo.
Además, una petición HTTP implica más casos de uso. ¿Cómo se comportaría la app en caso de redirecciones, interpretación de código JS y descarga de contenido?
Código JS
Subí un pequeño documento al servidor donde hice las pruebas, donde mediante javascript redireccionaba la petición a otra parte de la web. Observando los log pude comprobar que no se produjo ningun petición más. No se interpreta el javascript.
Fig 4. Documento HTML con JS que no se interpretará.
Redirecciones
También subí un pequeño snippet PHP al servidor que forzaba un bucle infinito de redirección. Escribiendo la URL a dicho script se generaron las entradas en el log. Para contarlas, empleé el comando cat access.log | egrep "redireccion.php" | egrep " 302 " | egrep "WhatsApp" | wc -l y el resultado fue, en total, 22 peticiones. Aunque es posible que
este valor varíe en función de la configuración de cada servidor, no representa demasiada carga para él, a priori.
Descarga de contenido multimedia
El hecho de que en la precarga se vea una imagen, implica que el cliente de WA se la ha descargado. Lo hace a través de las etiquetas <meta> o <link> entre otras. Subí éste fichero al servidor y habilité la escritura de accesos a los recursos multimedia en el log del servidor. Después escribí la URL en WA, y la sorpresa fue que WA, ya no enviaba en el User-Agent la palabra «WhatsApp», sino el
agente de usuario real . Fig 5.
Fig 5. Campo User-Agent de un terminal real.
47.60.42.203 – – [24/Nov/2015:23:15:12 +0100] “GET /wp-content/kguinio.png HTTP/1.1” 200 3576 “-” “Dalvik/1.6.0 (Linux; U; Android 4.4.4; Vodafone 890N Build/KTU84P)”
Además, con el comando nc -l -p 8888 < index-media.html | tee nc.log creé una pequeña «aplicación cliente servidor» para ver qué pasaba si accedía a dicha dirección donde el index-media.html apuntaba a un fichero de varios GB. Por suerte, parece que WA controla el tamaño y el tipo de contenido al que se accede, de modo que no se dispararía el consumo de datos.
Implicaciones
Juntando todos estos hechos, podemos concluir que:
- El dueño de un dominio, puede saber, sin necesidad de acceder a tus conversaciones de WA, qué recursos se han enlazado sobre él. En otras palabras, deducir el contenido de una conversación de WhatsApp, que intrínsecamente debería ser privada … ¿no?.
- Hoy en día existen multitud de BBDD que asocian direcciones IP públicas con coordenadas geográficas. Y aunque es complicado determinar con exactitud la ubicación de un dispositivo sólo por eso, se puede geolocalizar una IP. Y sólo por haber escrito una URL – no necesariamente haberla enviado.
- En el caso de que la precarga incluya una imagen, también has dejado tu agente de usuario en los log. Si antes podrían localizarte, ahora también identificarte, ya que una IP más un User-Agent puede resultar en un identificador único. Éste punto y el anterior los puede llevar a cabo fácilmente google analytics, sin embargo el código JS no se interpreta. Hipotéticamente, podrías ser incluido en una campaña personalizada de advertising sólo por haber escrito un link en una app que ni siquiera es web. Y eso considerando que el dueño del dominio no es malicioso. El campo User-Agent proporciona mucha información para planear un ataque más sofisticado a un host.
- Hemos visto que por cada letra, se realiza una petición HTTP. Normalmente los lenguajes de programación incluyen funciones como
sleep(int milisegundos);con las que se puede espaciar temporalmente 2 peticiones consecutivas. Se hace para no sobrecargar un una app en servidor. No obstante, escribir una URL en WA o pulsar F5 repetidas veces en un navegador, dista mucho de considerarse un ataque de denegación de servicio distribuido (DDoS). Pero, ¿qué pasaría en el hipotético caso de que cientos o miles de personas empezaran a escribir la misma URL a la vez? ¿Lograrían tumbar un servidor? ¿Quién cargaría con las responsabalidades legales? Al fin y al cabo, es un bug o error de diseño de WA. - Por suerte, estas implicaciones no están sujetas al devenir de una tercera persona o atacante. Eres tú mismo quien puede elegir si escribir un enlace o no. Aun así, siempre es conveniente que lo sepas todo.
Versiones afectadas
Sólo lo he podido probar en Android. Las versiones que he comprobado que implementan ésta funcionalidad
son:
- v2.12.361
- v2.12.365
- v2.12.367
Puedes dejar un comentario o mandadme un mensaje si tienes alguna versión que implemente dicha característica y no está en ésta lista.
Soluciones
Al menos, yo no he sido capaz de encontrar ninguna opción de WA que permita desahibilitar ésta característica. Si tú la conoces, también puedes dejarla en un comentario.
