22 noviembre 2013

Curiosa y peligrosa nueva funcionalidad de WhatsApp

Mucho se ha hablado ya en Security by Default sobre la (in)seguridad de WhatsApp (de ahora en adelante WA), ya sea sobre sus problemas con el SPAM, la nula utilidad del cifrado de sus archivos de backup, el fallo del proceso de verificación del número a configurar durante la instalación, etc. Vista esta situación, a nadie le sorprende ya que aparezcan nuevas formas de explotar maliciosamente fallos y/o funcionalidades de la aplicación.

Hace unas semanas se publicó una nueva versión de la aplicación de WA para dispositivos Android que provocó cierto revuelo dado que se extendió el rumor de que se había comenzado a introducir publicidad en las propias conversaciones cuando en éstas se citaban ciertas webs (en forma de "favicon" o imagen asociada al link). Finalmente se desmintió dado que realmente no era publicidad sino una nueva funcionalidad de la aplicación, al estilo Facebook, en la que se muestran las imágenes que los administradores web insertan en el código de sus páginas para ser usadas como iconos por otros servicios (noticia relacionada).

Analicemos su funcionamiento...

Como se ha dicho anteriormente, esta funcionalidad permite a los administradores de páginas web indicar a otros servicios que imagen está asociada a dicho contenido y, por tanto, que se muestre junto con el "resumen" del mismo (como ocurre en Facebook -ver Figura 1-)

Figura 1: Noticia con imagen asociada en la página de la CNN en Facebook
Este comportamiento se produce debido a que en la página web se encuentra el siguiente código:
<meta content="http://i2.cdn.turner.com/cnn/dam/assets/131114133404-travel-replicas-eiffel-tower-shenzhen-story-top.jpg" property="og:image"/>

Si extrapolamos esta situación a la aplicación de WA nos encontramos con dos posibles escenarios:
  1. Al igual que ocurre con el resto de intercambios de "multimedia", es el servidor de WA el que accede al contenido de la página, obtiene la imagen asociada y se la envía al usuario.
  2. El dispositivo móvil del usuario detecta que en la conversación se ha hecho referencia a un enlace, lo visita de forma automática (y transparente) y le muestra la imagen asociada en caso de que en dicha página exista el tag "meta -> og:image".
Figura 2: Comportamiento de WhastApp cuando se le envía un enlace a una página que hace uso de ese "meta"
Tras comprobar el funcionamiento de la aplicación detectamos que nos encontramos ante el segundo escenario. Por lo tanto, dado que se trata de una funcionalidad que, de forma transparente al usuario (es decir, sin requerir intervención del mismo), accede a un recurso arbitrario remoto, ¿puede suponer un riesgo para la seguridad/privacidad de los usuarios de WA? Veremos que sí. 
Figura 3: Ejemplo del código utilizado en el script "whatsapp.php"
Si analizamos la petición que WA realiza a la página obtenemos la siguiente información de interés:

Array
(
  (...)
  [SCRIPT_URI] => http://www.ldelgado.es/private/whatsapp.php
  [HTTP_REMOTE_IP] => 213.xxx.xxx.xxx
  [HTTP_USER_AGENT] => Dalvik/1.6.0(Linux;Android 4.1.2;GT-I9100 Build/JZO54K)
  (...)
)

Como podemos observar, somos capaces de obtener tanto la IP actual (geolocalización!) desde la que se está conectando el dispositivo (obvio al ser una conexión directa con nuestra página) como la información relativa al dispositivo android en el que se está ejecutando la aplicación de WA (modelo del dispositivo y la versión de Android instalada).

En el curso de privacidad y protección de comunicaciones digitales organizado por Criptored, concretamente en el módulo de comunicaciones seguras mediante mensajería instantánea veíamos que una de las características de los sistemas de mensajería instantánea que utilizan XMPP es que en ningún momento se obtiene la IP de los usuarios con los que conversamos dado que toda la comunicación se realiza mediante los servidores del proveedor del servicio (salvo que se instalen extensiones para la transferencia de archivos y éstas utilicen conexiones peer-to-peer, aunque en el caso de WA siguen siendo gestionadas a través de sus servidores), por lo tanto, con esta nueva funcionalidad se consigue evitar esa característica pro-privacidad ofrecida nativamente.

Podéis probar la funcionalidad con el siguiente enlace (mostrará el logo de SbD):

¿Qué limitaciones nos encontramos?

Redirecciones

Para comprobar si la aplicación seguía redirecciones (y hasta que nivel de profundidad) establecimos una página de prueba sencilla que redirigiese contra sí misma, utilizando el siguiente código:

<?php header('Location: /redireccion.php'); ?>

Tras enviar el link a través de una conversación de WA, pudimos observar el lado del servidor que el dispositivo hizo un total de seis(6) peticiones, de lo que se deduce que permite hasta un máximo de 6 redirecciones encadenadas.

Ejecución de JavaScript

Otra de las pruebas que nos interesaba era si la aplicación interpretaba código de la página a la que accedía o únicamente "parseaba" el código de la misma en busca de la etiqueta "meta" comentada anteriormente. Para esta prueba utilizamos una página que realizaba una redirección a nivel de JavaScript (de ahora en adelante JS), utilizando el siguiente código:

<html>
   <head>
      <script type="text/javascript">
         document.location="/javascript.html"
      </script>
   </head>
</html>

Tras enviar el link a través de una conversación de WA, del lado del servidor sólo observamos que se realizara una única conexión, por lo que de ahí se deduce que el JS de la página no es interpretado.

Tamaño máximo de la descarga

Para esta comprobación generamos en el servidor un fichero de 1.8GB y enviamos un enlace al mismo a través de una conversación de WA. Al monitorizar la conexión del lado del servidor obtuvimos lo siguiente:

root@footest:/var/www# ls -lh out2
-rw-r--r-- 1 root root 1.8G Nov 17 19:22 out2
root@footest:/var/www# nc -l -p 80 -vv < out2
listening on [any] 80 ...
connect to [xxx.xxx.xxx.xxx] from static-(...).isp.net
[yyy.yyy.yyy.yyy] 39889
GET / HTTP/1.1
User-Agent: Dalvik/1.6.0 (Linux; U; Android 4.3.1; GT-I9300 Build/JLS36I)
Host: xxx.xxx.xxx.xxx
Connection: Keep-Alive
Accept-Encoding: gzip

too many output retries : Broken pipe
sent 8027776, rcvd 163 : Broken pipe
#

Tal y como puede observarse, la conexión se corta. Si analizamos el comportamiento de la aplicación de WA en el dispositivo (utilizando el visor de logs disponible en el SDK de Android -logcat-) obtenemos lo siguiente:

Figura 4: Captura del gráfico de carga de la CPU del dispositivo durante la prueba de descarga
Figura 5: Captura del log durante el 'crash' de la aplicación WhatsApp
Si nos fijamos en las imágenes anteriores, podemos observar como "com_whatsapp" está consumiendo practicamente la totalidad de los recursos de la CPU y como en el log se muestra que se ha forzado el cierre de la misma debido a que la aplicación no responde (Tag: ActivityManager). Por lo tanto, es posible provocar un DoS remoto.

Además de las pruebas descritas anteriormente también realizamos otras como comprobar si interpretaba varias URLs por mensaje, sin que el resultado fuera afirmativo.

¿Qué posibilidades de explotación se nos pueden ocurrir?
  1. Seguimiento de dispositivos (si la IP es del domicilio, del trabajo, 3G, etc)
  2. Generar un consumo excesivo de datos que acabe con el plan contratado (forzar la descarga de un fichero/imagen de gran tamaño). Ya no ocurre como con el intercambio de ficheros a través de la aplicación que ésta restringe el tamaño de los recursos a compartir (aunque ya nos mostraron Juan Garrido y Pablo San Emeterio que las medidas de restricción son totalmente ineficaces y puedes subir cualquier tipo de fichero y de cualquier tamaño...).
  3. Forzar una  'crash' de la aplicación. Si se envía una gran cantidad de datos en bruto (sin cumplir con el estándar HTTPv1.1) como respuesta a la petición, excediendo el máximo permitido, es posible provocar una excepción que fuerce el cierre de la aplicación. Sin embargo, esto no ocurre si se devuelve una imagen cuyo contenido esté especialmente manipulado (p.e para las pruebas utilizamos 'payloads' generados con la aplicación MultiFileFuzzer).

Dado que no se trata de una vulnerabilidad en sí (aparte del 'crash') sino de una funcionalidad que permite un uso malicioso de la misma, ¿qué posibles soluciones podemos plantearnos?
  1.  Comunicar a WA que no indique información relacionada con el dispositivo en el User-Agent de la petición (basta con que se sobrescriba a nivel de código dicha cabecera).
  2. Desactivar la descarga automática de imágenes (ver Figura 6) dado que la configuración por defecto es vulnerable (tiene configurada la descarga de imágenes en 3G y la de cualquier archivo desde redes Wi-Fi).
Figura 6: Ejemplo de configuración correcta de la aplicación de WhatsApp

Timeline:

  01-Nov-2013  Se consulta a WA por un email concreto para temas de seguridad.
  01-Nov-2013  Se recibe el primer email automático de respuesta (apertura de "ticket").
  05-Nov-2013  Se recibe el segundo email automático (información general).
  05-Nov-2013  Se consulta a WA como podemos notificarle una vulnerabilidad.
  06-Nov-2013  "Soporte" nos solicita los detalles de la vulnerabilidad.
  06-Nov-2013  Se envían los detalles técnicos de la vulnerabilidad (y PoC asociada).
  12-Nov-2013  "Soporte" nos solicita información adicional (sobre el DoS).
  12-Nov-2013  Se envía a "soporte" y "seguridad" los detalles paso-a-paso de explotación.
  14-Nov-2013  Nos comunican que no son capaces de reproducir la vuln (con la última versión)
  14-Nov-2013  Comprobamos que la vulnerabilidad de DoS ha sido corregida (v. 2.11.134+)

En la última versión (2.11.136+) está ya corregida la vulnerabilidad que provocaba el DoS y, además, han eliminado la funcionalidad de descarga de las imágenes asociadas a enlaces contenidos en los mensajes. Podéis descargarosla (esté o no ya en el Google Play) desde el siguiente enlace: 
http://www.whatsapp.com/android/market/WhatsApp.apk

Os adjuntamos también un enlace de descarga de una versión anterior de WhatsApp (2.11.109) para que podáis "jugar" con el "crash" comentado anteriormente, ¡quién sabe si, con tiempo, podéis encontrar algún vector de explotación interesante! :)
http://www.ldelgado.es/seguridad/whatsapp/whatsapp_v2_11_109.apk

Podéis acceder al "advisory" completo en la página de Ferran Pichel, foosec.com:
http://foosec.com/docs/whatsapp.html

Colaboración por Ferran Pichel y Luis Delgado.