Cómo obtener el campo User-Agent de un cliente en WhatsApp

En la entrada anterior os mostré que escribir – que no enviar –  una URL en una conversación de WhatsApp puede derivar en una violación de privacidad, cualidad supuestamente intrínseca de una conversación de WA. El caso es que no me sentía completo. «Una petición HTTP a un servidor implica más riesgos que dejar mi IP impresa en un log», pensaba. Así que, rascando un poco más, realicé una serie de tests para analizar su comportamiento.

¿Interpretación de código JS? NO

Subí al servidor éste fichero para comprobar si WA interpretaba el JS o simplemente se dedicaba a parsear los datos. Accediento a los log comprobé que efectivamente era lo segundo. De haber sido lo primero, las implicaciones y riesgos de seguridad no cabrían aquí.

¿Cuantas redirecciones? ~20

Un aspecto importante es el comportamiento de WA frente a una URL que se redirige a otra. El proceso, podría no terminar nunca si el recurso se redirecciona a sí mismo, poniendo en jaque temporalmente el servicio. Aplicaciones como los navegadores, contemplan ese caso de uso y saltan con la excepción «La página no se redirige correctamente, o de un modo por el cual no podría terminar nunca». Y corta la conexión. En este caso, creé un simple script PHP llamado redireccion.php con la siguiente línea de código

<?php # Creamos un bucle de redirección infinito
    header("Location: redireccion.php");
?>

De nuevo, escribí la URL en WA. Después, con el comando tail -n200 access.log | egrep "redireccion.php" | egrep "WhatsApp" | egrep " 320 " |  wc -l inferí el número de veces que redirigía. El resultado fue 22. Normalmente, no deberían ser tantas, así que existe la posibilidad de que hubiera sido el servidor quien terminara la conexión y el cliente, tan pancho. // TODO: Ahondar en este punto.

Precarga de iconos BUG

Otro punto que llamó mi atención, fue que probando con otras URLs aparecía un logotipo asociado a la respectiva web. Por ejemplo, con el buscador duckduckgo.

Resulta que WA saca esas imágenes de los campos <meta> cuando su atributo itemprop vale «image» o de los tag <link> cuando el atributo rel vale «apple-touch-icon», entre otras etiquetas HTML5. Colgué otro archivo más, en http://two.wordpress.test/wp-content/index.html . He añadido dicha etiqueta, y funciona.

Un detalle significativo de la entrada anterior es que WA, machaca el campo User-Agent del terminal y lo sustituye por la palabra «WhatsApp». Una buena medida de seguridad… pero que no sirve de nada si en la siguiente petición HTTP para obtener contenido multimedia dejas el campo User-Agent por defecto del teléfono. Es un campo que de no haber sido manipulado por el cliente, proporciona mucha información para planear un ataque más sofisticado en relación con las posibles vulnerabilidades. De la figura 4, por ejemplo, se puede leer gran cantidad de información relativa a mi terminal 😳

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)»

En fin. Si de la entrada anterior se podría geolocalizar un tertualiano interesado por una de nuestras URLs, ahora hasta incluso, en caso de que tuviéramos un icono representativo en nuestra web, podríamos identificar al usuario con más precisión si cabe, y hasta planear un ataque remoto más especializado gracias a la información que proporciona el agente de usuario. Considero que éste aspecto se trata de un bug en la app. La cosa se pone interesante. Aún quedan tests por realizar.