Mostrando entradas con la etiqueta whatsapp. Mostrar todas las entradas
Mostrando entradas con la etiqueta whatsapp. Mostrar todas las entradas

14 marzo 2014

Descifrando msgstore.db.crypt5, la nueva base de datos de WhatsApp

WhatsApp es criticada muchas veces por su seguridad y le tocará arrastrar mala fama como ha ocurrido con otras aplicaciones o sistemas operativos. Lógico, teniendo en cuenta la cantidad de métodos que existen para espiarlo.

Hace 3 años Yago publicaba en este mismo blog uno de los primeros estudios con fallos muy críticos. Desde entonces hasta ahora han ido apareciendo numerosas noticias y otros problemas sin parar. WhatsApp está de moda y por ello, también en el ojo del huracán.

Sin ir más lejos, esta misma semana muchos medios de comunicación se han hecho eco de la entrada de un blog que decía que se podían robar conversaciones mediante una aplicación falsa (?) que leyese la tarjeta de memoria SD y mandase los archivos por Internet. ¿Perdón? Esto es algo sabido desde hace años y usado por malware. Nada que no apareciese incluso por aquí. Además afecta a todo Android y no solo a este cliente de mensajería. Hasta mi propio LG tiene una aplicación que hace backup de todo el terminal en la memoria SD y también es susceptible de ser robado. Y eso significa TODOS los datos de mi móvil. 

Pero muchos de los problemas de WhatsApp no son tan tremendos, no más que los que hay en otros protocolos como por ejemplo el del correo electrónico, que históricamente se ha transmitido en texto plano, que también permite falsificar al emisor y que no garantiza la integridad del mensaje. Claro, el correo-e no está de moda, ni sale ya en las noticias por ser parte de ventas y compras de miles de millones de euros. 

Yo uso whatsapp y también uso el correo electrónico ¿y? Lo increíble de whatsapp no es su seguridad, ni la falta de ella. Lo realmente impresionante es como han conseguido escalar su arquitectura con unas decenas de empleados, con millones de usuarios más que otras redes sociales y sin apenas incidentes de disponibilidad. Eso sí que es hacking.

Volviendo al tema. Desde la última actualización (2.11.152), WhatsApp ha cambiado el algoritmo y la clave para cifrar las copias de seguridad en las SD. No es que la hayan mejorado sustancialmente, pero ha cambiado y el viejo método ha dejado de funcionar para los nuevos archivos con extensión "crypt5".

Esta vez el mérito de obtener las claves para descifrar este formato se lo ha llevado el autor de una aplicación de estadísticas: Chat Statitics for WhatsApp. y aunque no ha publicado los datos, si ha facilitado la tarea para que otros la obtengan de su propia herramienta.

Una vez comprada la aplicación y diseccionada, si observamos su contenido, rápidamente se ven los métodos para cifrar y descifrar las bases de datos de la copia de seguridad.

dex2jar, jd-gui, etc.
Como se puede observar, carga una librería "libaes.so" dónde realmente está la chicha.

[root@digitalsec aramosf]# readelf -a libaes.so | grep FUNC
     1: 00000000     0 FUNC    GLOBAL DEFAULT  UND __cxa_finalize
     2: 00000000     0 FUNC    GLOBAL DEFAULT  UND __cxa_atexit
     3: 00000000     0 FUNC    GLOBAL DEFAULT  UND __stack_chk_fail
     4: 00000740  1225 FUNC    GLOBAL DEFAULT    7 AES_decrypt
     5: 00001470   574 FUNC    GLOBAL DEFAULT    7 CRYPTO_cbc128_decrypt
     7: 000016b0  1218 FUNC    GLOBAL DEFAULT    7 private_AES_set_encrypt_k
     8: 00001b80   605 FUNC    GLOBAL DEFAULT    7 private_AES_set_decrypt_k
     9: 00001de0  1249 FUNC    GLOBAL DEFAULT    7 AES_encrypt
    10: 000022d0    46 FUNC    GLOBAL DEFAULT    7 MD5_Init
    11: 00002300   258 FUNC    GLOBAL DEFAULT    7 MD5_Update
    12: 00000000     0 FUNC    GLOBAL DEFAULT  UND memcpy
    13: 00002410   429 FUNC    GLOBAL DEFAULT    7 MD5_Final
    14: 00000000     0 FUNC    GLOBAL DEFAULT  UND memset
    15: 000025c0  2570 FUNC    GLOBAL DEFAULT    7 Java_de_tiflo_whatsapp_st
    16: 00000000     0 FUNC    GLOBAL DEFAULT  UND strlen
    17: 00000000     0 FUNC    GLOBAL DEFAULT  UND fopen
    18: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc
    19: 00000000     0 FUNC    GLOBAL DEFAULT  UND fseek
    20: 00000000     0 FUNC    GLOBAL DEFAULT  UND ftell
    21: 00000000     0 FUNC    GLOBAL DEFAULT  UND fwrite
    22: 00000000     0 FUNC    GLOBAL DEFAULT  UND fread
    23: 00000000     0 FUNC    GLOBAL DEFAULT  UND free
    24: 00000000     0 FUNC    GLOBAL DEFAULT  UND fclose

Analizando más lentamente estas funciones se obtienen las claves necesarias. En esta parte he tenido la suerte de contar con la ayuda de Mario Ballano que le ha puesto luz a parte del código donde yo me perdía y en la que hace falta jugar con el md5.



Tras un rato hemos descubierto que la función "CRYPTO_cbc128_decrypt" parecía una trampa, ya que el algoritmo usado realmente es: aes-cbc-192. Al final de la mañana hemos terminado el proceso con un script para descifrarlas automáticamente.

No hemos puesto la bandera, ya que el autor de Chat Statitics ya conocía este método, pero por lo menos, si lo hemos liberado para que lo use todo el mundo con sus herramientas y como no, ya está implementado en la recuperación de mensajes eliminados de http://www.recovermessages.com.

El script en cuestión ya está en mi github y requiere que se conozca el nombre de la cuenta asociada al móvil, que se puede sacar de Ajustes->Cuentas y sincronización->Google

Para usarlo es tan sencillo como invocarlo así: 
- python pwncrypt5.py msgstore.db.crypt5 grbnz0@gmail.com > msgstore.sdb

Y finalizo con el codiciado código:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
#!/usr/bin/python              
"""
48bits presents:
8===============================================D~~~
WhatsApp msgstore crypt5 decryptor by grbnz0 and nullsub
8===============================================D~~~
 
"""
                                                                                                                                                                                   
import sys
import hashlib
import StringIO
from M2Crypto import EVP
 
key = bytearray([141, 75, 21, 92, 201, 255, 129, 229, 203, 246, 250, 
   120, 25, 54, 106, 62, 198, 33, 166, 86, 65, 108, 215, 147])
iv = bytearray([0x1E,0x39,0xF3,0x69,0xE9,0xD,0xB3,0x3A,0xA7,0x3B,0x44,
   0x2B,0xBB,0xB6,0xB0,0xB9])
 
def decrypt(db,acc):
  fh = file(db,'rb')
  edb = fh.read()
  fh.close()
  m = hashlib.md5()
  m.update(acc)
  md5 = bytearray(m.digest())
  for i in xrange(24): key[i] ^= md5[i&0xF]
  cipher = EVP.Cipher('aes_192_cbc', key=key, iv=iv, op=0)
  sys.stdout.write(cipher.update(edb))
  sys.stdout.write(cipher.final())
 
if __name__ == '__main__':
  if len(sys.argv) != 3:
    print 'usage %s <db> <accountname> > decrypted.db' % sys.argv[0]
  else:
    decrypt(sys.argv[1],sys.argv[2])

A todos los que tenéis problemas y lo quereis hacer de una forma más sencilla y rápida, os recomiendo que uséis directamente la página web: http://www.recovermessages.com que además de descifrar el fichero os mostrará los mensajes eliminados.


Leer más...

10 enero 2014

La guía definitiva para el crimen perfecto

Supongamos que usted, por las razones que sean, tiene la necesidad de robar un banco, necesita dinero y, pese a todas las noticias que se leen sobre la falta de liquidez bancaria, vd sabe que dinero, hay

Sin duda, robar un banco es una forma relativamente rápida de obtener dinero, salvo por el notable inconveniente de que vd puede acabar detenido, procesado y en la cárcel

Asumiendo que vd ya tiene un plan para robar el banco, vamos a trabajar en las coartadas, algo básico a la hora de evitar ser enchironado 

Para ello vamos a hacer uso de toda la riqueza de las nuevas tecnologías para crear una serie de coartadas que le permitan a vd, en caso de que alguien le pregunte, justificar e incluso argumentar con total vehemencia que usted no estaba en ese momento y en ese lugar donde se produjo el robo.

De entrada, lo más probable es que la autoridad competente pida a su operador telefónico la posición de su teléfono para saber si vd estaba o no en la zona del crimen.

Probablemente en este punto vd piense ¡ voy a dejar el teléfono en mi casa ! y es verdad que con eso puede tener una coartada, pero créame, es una coartada muy débil.

Vamos a mejorarla. Asumiendo que vd tiene un móvil Android (si está planteando robar un banco obviamente no puede tener un Iphone ...) vd debe tener instalado en su móvil la aplicación 'AirDroid', esta aplicación le permite, desde un PC, acceder a su móvil remotamente y, lo más interesante, le va a permitir enviar y recibir SMS como si estuviese delante de su móvil.

Entonces, es fácil, vd deje su teléfono sano y salvo en su casa y, un poco antes o después del atraco, vd deberá conectarse a su móvil desde un PC y enviar cuantos más SMS a sus amigos, conocidos o familiares, mejor. Si vd tiene un amigo policía, fiscal o juez, ese es target OBLIGADO para enviarle mensajes.

De esa forma, cuando pidan los datos a su operador y el operador indique que su móvil no se ha movido de su casa, acto seguido vd podrá jurar con la mano en el pecho que estuvo en casa y no solo eso, sino que estuvo comunicándose con amigos. Obviamente una vez cometido el crimen, elimine la aplicación instalada.

Yendo un poco más allá, vd puede hacer uso de la API alternativa de Whatsapp que permite enviar mensajes a usuarios de Whatsapp sin usar el móvil. Con esta API, desde el mismo PC que hemos usado en el paso anterior, vd puede igualmente enviar mensajes de whatsapp a sus amigos de forma que su coartada 'yo estaba tranquilamente en mi casa' va a resultar mucho más creíble.

Para rematar la faena, usted puede falsificar 'check-ins' en la red social Foursquare (si vd no sabe que es, a modo resumen podemos decir que es una red donde muchos snobs compiten por publicar los sitios 'cool' donde han estado', usa el GPS de su móvil para 'garantizar' que estuvo ahí, pero se puede hackear y enviar check-ins falsos)

Busque una cafetería cercana a su casa (por aquello de que coincida con la torre a la que su móvil se va a conectar) y haga un 'checkin' falso en ella. De esa forma vd podrá decir que bajó a tomar un café y efectivamente foursquare confirmará que estuvo ahí.

Para seguir con la farsa, haga una foto al salón de su casa, coja esa foto y, mediante un software como PhotoME, edite los metadatos que van asociados a una imagen en formato digital (fecha, ubicación, cámara ...), en concreto nos interesa la fecha y lo relativo al GPS. Edite dicha foto con el software antes descrito cambiando la fecha a media hora después del atraco y, una vez cometido el crimen, ponga un tweet bucólico con un texto parecido a 'En la soledad de mi casa' con la foto en cuestión. Tenga cuidado para que coincida la hora que ha fijado con la hora del tweet real. Enhorabuena, vd tiene otra evidencia que indica que estuvo en su casa aquella tarde

Con todos estos pasos, ignoramos si vd va a librarse de ir a la cárcel, pero es casi seguro que va al menos va a crear un montón de confusión en el juzgado donde le estén procesando debido a la enorme avalancha de evidencias digitales y por la cantidad de detalles técnicos a rebatir.

Además, podrá hacer desfilar frente al juez a decenas de testigos que jurarán con la mano en el pecho que estuvieron enviándose SMS o mensajes de Whatsapp toda la tarde con vd
Leer más...

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.
Leer más...

11 junio 2013

Espiar Mensajes de WhatsApp (en iPhone sin jailbreak)

No pensaba escribir esta entrada, somos muy pesados con WhatsApp y sabemos que muchos lectores se aburren, pero no me queda más remedio, ya que he leído una noticia en un fantástico blog y quería comentarla.

La entrada tiene de título: "Aplicaciones para espiar a tus contactos de WhatsApp ¿funcionan o son un mito?" y se ellos a su vez, se hacen eco de un tweet de la @policia que habla sobre las grandes estafas que hay en Internet por el gran interés de los usuarios por leer los mensajes de sus ¿amigos? Tal y como se puede ver en la primera imagen que acompaña esta entrada, con más de 140.000 resultados para la consulta: "espiar mensajes de whatsapp".


No mienten, la red está llena de fraudes, de vídeos falsos, de aplicaciones engañosas y de estafas. Pero no todas ellas lo son. 

Pese a que el propósito de WhatsApp Anti-Delete Protection Tool no es el de espiar, bien es cierto que esta herramienta (a día de hoy solo para iPhone), una vez usada, permite recuperar el 100% de los mensajes borrados de forma transparente para el usuario propietario del móvil, es decir, sin que sepa que todos sus mensajes borrados pueden ser fácilmente recuperados. Y no, no es una estafa.

Los requisitos son sencillos; se ejecuta en Windows y requiere tener instalado .NET e iTunes. También es necesario disponer del móvil físicamente para aplicarle la protección y si nunca se usó en ese ordenador, también el código de desbloqueo.

Lo mejor de todo es que esto se hace sin necesidad de Jailbreak ni altera el comportamiento del teléfono, lo que hace que pase completamente desapercibido el cambio para el propietario.

Para explicar a los usuarios que adquieran la licencia de esta "papelera de reciclaje" para WhatsApp, he creado este vídeo donde explico paso a paso como se instala y funciona.




Aprovecho esta noticia para comentar que CSIRT-CV ha publicado una guía sobre el buen uso de esta herramienta, con algunos trúcos y curiosidades "WhatsApp... todo lo que realmente hay que saber".

Por último, recordaros que tal y como comenta el tweet de la @policia, espiar mensajes de otro usuario, puede ser un delito, así que no lo hagáis.

Leer más...

12 marzo 2013

Whatsapp revela el login de su CEO Jan Koum en su blog


Ellos son así. No se cansan. Siempre en boca de los investigadores en seguridad IT.

Todos sabemos que la seguridad empieza con un determinado estado mental, con una determinada actitud proactiva y preventiva. Despues de todo el principal vector de ataque siempre es el humano. Pero Jan Koum, uno de los dos CEO de Whatsapp, tiene su peculiar manera de entender la seguridad... 

O no la entiende.

Ambos CEO, Brian Acton y Jan Koum, son personas del mundo de la publicidad digital (despues de todo son formers de Yahoo!). No se espera de ellos que sean genios de la seguridad, pero creo que deberian dejarse aconsejar un poco mas a la hora de comunicar cosas en su blog con semejante alegría y despreocupación, porque estan regalando las herramientas para que un black hat hacker les haga un "pwnage" en toda regla.

Motivado por el orgullo que le proporciona su poderosa infraestructura tecnológica en servidores BSD, Jan revela datos técnicos en los posts del blog de Whatsapp, y lo hace mediante copy-paste de sus sesiones de terminal, llegando a revelar su login válido, que es "jkb"...

WTF!

Adjunto ejemplos sacados de este post:

Si yo fuera consultor de seguridad de Whatsapp, le preguntaría a Jan:
¿era necesario pegar la línea que contiene el prompt?

Pero no contento con ello, tambien revela más datos acerca del servidor, que si bien no son tan delicados, tampoco es saludable que se compartan:

Si alguno esperaba encontrar el password además del login, creo que le ha fallado el sentido común. Esta gente de Whatsapp es incauta, pero no es tan estúpida, y en el peor de los casos iríamos directos a ellos para avisarles antes.

Si ahora además estás pensando que revelar solamente el login "no es para tanto" y que un atacante aún tendría que averiguar el password de ese login, déjame que te comparta dos reflexiones del libro "El arte de la intrusión":

El dicho es cierto, los sistemas de seguridad tienen que ganar siempre, al atacante le basta con ganar sólo una vez.
~ Dustin Dykes

Siempre que algún ingeniero de software dice: "nadie se complicara tanto como para hacerlo" hay algún chaval en Finlandia dispuesto a complicarse.
~ Alex Mayfield
Ya lo he dicho. La seguridad no es un conjunto de herramientas, hardware y software; la seguridad es una actitud.

Jan, cambia tu login y no lo reveles de nuevo.

Artículo cortesía de Alejandro Amo
Leer más...

25 febrero 2013

Obteniendo cuentas de Whatsapp y Line como churros

Hace unos dias Yago me comentaba que le interesaba el tema de la telefonía VoIP. Le compartí algunas cosas sobre el tema que le gustaron y a raíz de esa conversación sale este post.

Un poco de historia: el "phreaking"
Realmente el "phreaking" (término que viene de "phone freak", monstruo de la telefonía) tuvo su momento glorioso en el pasado, y quien sea mas bien "30 añero" recordará haber leído en los ezines de los años 90 aquellas historias del mítico Joe Engressia, que podía marcar números de teléfono sin tocar el teclado, silbando; o de John Draper, conocido como "Capitán Crunch" porque utilizaba la misma técnica que Engressia, pero ayudado por un silbato sacado de una caja de cereales. 

Hubo mucho más: se desarrollaron dispositivos muy variados, llamados todos ellos "boxes", y a los cuales se les asignaba un color en función de lo que hacian, hasta el punto en que fué posible manipular de mil y una formas las lineas telefónicas de la por aquel entonces hegemónica AT&T. 

Por ejemplo la bluebox, (la primera box que se conoció, basada en el silbato usado por Draper), permitía marcar los tonos internos de señalización de llamadas, de otro modo inaccesibles para los usuarios de un teclado telefónico normal. La black box impedía que se detectase el hecho de que se había descolgado el teléfono, burlando así los sistemas de facturación de la compañía, y la Yellow Box realizaba lo que hoy conoceríamos como un DoS contra otra línea telefónica, dejándola inoperativa.

Los tiempos de la telefonía analógica y sus "glitches" ya han pasado, pero con el nacimiento de la tecnología VoIP, que empieza a desdibujar la línea entre internet y telefonía, puede decirse que la cultura phreaker sigue hoy dia teniendo mucho que decir. De hecho ahora las posibilidades son mucho mas abstractas, pero mayores.

La autenticación, control y validación de usuarios con teléfonos es poco efectiva
Hoy dia muchos servicios validan sus cuentas y la identidad de sus usuarios a través de sms a sus móviles o de llamadas a fijos. De este modo buscan evitar la suplantación de identidad, el fraude o el abuso en general.

Voy a explicar cómo se puede utilizar la telefonía VoIP en combinación con otros servicios online para ultrapasar esos métodos, creando cuentas anónimas que podemos usar como "decoy" sin tener que poner nuestro teléfono real, y sin perder la posibilidad de recibir llamadas o sms a estos números, para así poderlos usar como "verificadores" de nuestra identidad (¡ja!)

Por si alguien no lo ha notado, esto reabre la posibilidad (que algunos creen perdida) de crear cuentas como churros en servicios como Whatsapp y Line. Pero si se abre la mente, las posibilidades son algo más amplias. 


Antes de pasar a la receta, debemos conocer los ingredientes.

Cuenta SIP
SIP es la tecnología de VoIP más utilizada en todo el mundo, y es el estandar de facto con el cual son compatibles la mayoría de softwares y dispositivos. Una cuenta sip es el conjunto de credenciales que tiene un usuario dentro de la red. Con ellas, puede utilizar cualquier software de conexión VoIP (o routers y teléfonos físicos compatibles VoIP) para conectarse a la red y "registrar" su número. Por registrar se entiende al hecho de iniciar sesión en la cuenta VoIP y decir "aquí estoy yo, y quiero recibir las llamadas entrantes de esta cuenta".
Es interesante notar que varios clientes y dispositivos pueden usar la misma cuenta VoIP a la vez para realizar llamadas simultáneamente, pero solo uno puede "registrar" la linea para recibir las llamadas de otras personas. El comportamiento es similar al mapeo de puertos de un router.
Si el proveedor de la cuenta VoIP no tiene constancia de ningun cliente sip "registrado" en la cuenta en ese momento, puede enviar al llamante a un buzón de voz, simplemente informarle y colgar, o darle tonos falsos de llamada hasta que se aburra, con el fin enmascarar esta situación. 

Cliente SIP
Se entiende por cliente sip cualquier dispositivo físico o sofware capaz de gestionar una cuenta sip: iniciar sesion, hacer y recibir llamadas, etc. El protocolo sip contempla todo lo que se espera de una llamada telefónica tradicional. De hecho, si usamos un teléfono android como cliente sip para recibir y enviar nuestras llamadas, la diferencia entre las llamadas tradicionales y las llamadas VoIP es totalmente imperceptible y, manejado de forma transparente por el terminal y el sistema operativo, podremos poner la llamada en espera, enviar tonos, colgar, hacer conferencias, y todo lo que siempre hemos hecho en telefonía tradicional.


Número DID
Algunos proveedores SIP ofrecen como servicio adicional números DID (Direct Inward Dialing, llamada entrante directa). En terminología VoIP, esto quiere decir que el número no es para usarlo dentro de la red VoIP, sino que en realidad es una pasarela, una número físico real capaz de recibir llamadas de la red telefónica conmutada (la red de telefonia de toda la vida), ya que está físicamente conectado a ella. El proveedor de una linea DID se compromete a desviar las llamadas entrantes desde ese número hacia una cuenta SIP, uniendo el mundo digital y el mundo físico de una forma totalmete automática, sin que el llamante pueda advertirlo.

Google Voice
Aunque no es estrictamente una cuenta del estándar abierto SIP, google tiene su propio servicio de VoIP y es muy interesante. Te ofrece la posibilidad de tener un número DID gratis que realiza incluso más funciones que un teléfono físico real. Es una mezcla interesante entre un teléfono, y un pequeño PBX (coloquialmente llamados "centralitas" en España). No solo se puede desviar la llamada al cliente por software que ofrece la compañia y que se integra en gmail, sino que puedes desviarlo a otros números físicos de la red telefónica conmutada. Incluso puede desviar la llamada a varios teléfonos a la vez, y el primero que descuelga, se la queda.
Si nadie contesta, puede tomar un mensaje de voz que te hace llegar por correo electrónico junto a un reproductor de audio incrustado, o mediante un aviso al movil si tienes la aplicación google voice instalada.
A pesar de que el número es de una linea terrestre, si te envian uns sms al número DID google es capaz de recepcionarlo correctamente y presentarlo en la bandeja de entrada de google voice (esto es muy interesante... ¿lo veis venir?)
Pero... las funciones de google voice realicionadas con DID sólo funcionan en estados unidos y para la gente y las redes de allí. No porque Google no quiera, sino porque depende de redes de telefonía con las que debe realizar acuerdos que de momento no ha formalizado. Debido a estas limitaciones infraestructurales, google voice no puede desviar las llamadas a otros números que estén fuera de la red estadounidense, motivo por el cual te exigen que certifiques que eres el titular de un número de teléfono de alli. De hecho, google voice esconde todas estas opciones cuando detecta que conectas desde fuera de Estados Unidos, para evitar ofrecerte servicios que luego no puede darte realmente.

Callcentrinc
Callcentric es un popular proveedor SIP de USA, que se caracteriza porque además de ofrecerte tu "free sip account" como hacen muchos otros, ofrecen un "free phone number", que no es otra cosa que un número DID gratis para vincularlo a tu cuenta sip.
Es decir, tú les das un email, y ellos te dan un número de teléfono válido en USA...

¿Empezáis a ver cómo se podrian combinar estos ingredientes de forma creativa para realizar un pequeño hack sobre los sistemas de cuentas de aplicaciones como Whatsapp o Line?

Ahora que ya conocemos un poco mejor estos ingredientes, pasamos a...

La receta
Supongamos que quiero tener una cuenta de whatsapp válida para mi emulador android instalado en el PC. De este modo podré estar más cómodo chateando por el PC cuando lo tenga disponible. Pero no puedo registrar mi número de movil en dos terminales, asi que necesito un número nuevo.
En este caso, yo recomendaria el uso de un numero alternativo virtual de FonYou, tan utilizado y socorrido entre pequeños profesionales para separar vida personal y profesional cómodamente, pero quizás quiera crear no solo una segunda cuenta, sino más. Quizás soy un developer que necesita probar su nueva aplicación hecha sobre whatsapi utilizando 20 cuentas válidas de whatsapp, o simplemente soy un triste spammer que quiere usar las API's de whatsapp disponibles para enviar mensajes masivos anunciando mi sitio web o el de terceros que me pagan por ello.

¿Puedo usar un numero inventado? 
No, porque cuando whatsapp envie un código de validación a ese número por SMS o llamada, yo tendré que introducir dicho código en el software para demostrar que soy el titular. Así pues, el número tiene que ser realmente mio, en el sentido de que yo tengo que tener el control sobre él para recibir ese SMS. Hasta aqui el sistema funciona según lo que se espera de él.

¿Qué servicio hemos dicho que tenia la capacidad de recibir SMS? 
Google voice. Con el simple hecho de registrar una cuenta de google, tenemos acceso a un número de teléfono capaz de recibir SMS. Por lo tanto, ya sabemos lo que queremos: queremos crear una cuenta en google voice.

Ahora que ya sé lo que necesito, ¿qué obstáculos debo sortear para obtenerlo?
Como he dicho antes, google voice exige que conectes desde USA y que ya tengas un numero de teléfono "real" de USA. Por "real" quiero decir que está en la red telefónica conmutada tradicional, y que está geográficamente ubicado en USA.
Sabemos que la limtación geográfica a la hora de conectar a la web y fingir estar en USA se resuelve conectando a través de cualquiera de los proxys estadounidenses que aparecen constantemente en listas como esta, así que fingir la ubicación no será un problema.
Enfoquémonos por tanto en el problema menos conocido: tenemos que hacernos con un numero "real" de Estados Unidos para hacerle creer a Google Voice que estamos físicamente allí y nos deje activar sus servicios.

¿Quién hemos dicho que ofrecía un número "real" de USA con simplemente registrarse?
Callcentric. Si nos registramos en su web, obtenemos inmediatamente una cuenta SIP con su usuario y su contraseña.
El usuario es un numero con el formato 1777xxxxxxx, pero que nadie se confunda; aunque a ojos de un despistado parece un numero válido de USA con el prefjo internacional +1 delante, no lo es. Es solo un número VoIP. De hecho el area code 777 es muy WTF! porque no existe semejante cosa en la numeración conmutada estadounidense. El estado de Nevada lo quiso reclamar para asignarlo a los teléfonos de Las Vegas, por aquello del 777 en las tragaperras (LOL), pero se lo denegaron.

Una vez nos hayamos registrado en callcentric no habremos acabado con ellos, porque aún tenemos que solicitar el "free phone number", que es para lo que hemos venido aqui. Por tanto, nos aseguramos de tener nuestra recien creada sesión iniciada en la web y nos dirigimos a la sección "All Services" para buscar el servicio "Free Phone Number" y pulsar el botón Get a Number.
En la columna de la izquierda, ponemos esto (de hecho no hay mucho que cambiar)


En state, de momento solo ofrecen NY, cosa que nos da igual. El area code y el rate center los podeis elegir al azar. Tras pulsar "Lookup", el sistema nos dará un puñado de sugerencias tal que así:


Pulsamos "Order Now" para cualquiera de las opciones sugeridas. Respondemos NO a la pregunta "are you using the service within the US?" (es importante responder que NO). Seguimos el proceso, que es tratado por callcentric casi como si fuera un proceso de compra, pero tranquilos que no pedirán tarjeta 8-)
Seguid el asistente hasta pulsar el botón "checkout". Y con esto ya tendremos un número real de la red telefónica conmutada de USA. Nos llegará un email a modo de factura donde se indicará nuestro nuevo número de teléfono (en esta imagen, 1929223xxxx):


y de todos modos tambien será claramente visible en las preferences y en el dashboard de callcentric consultando el "caller ID to send" (en esta imagen, 1646xxxxxxx):

Veréis los números escritos de varias formas, con paréntesis, con guiones... explicaros el NANP aquí queda fuera del objetivo de estas líneas, pero debéis saberlo para no dudar durante el proceso: para el caso que nos ocupa, "19296969101" es lo mismo que "+1 (929) 6969-101"

Vale, pero ahora ¿cómo lo uso?
Fácil. Ya hemos dicho que un número DID es una extensión en el mundo real de una cuenta SIP en el mundo digital. Si alguien llama al numero DID, estará llamando a la cuenta SIP. Entonces lo único que tenemos que hacer es preparar nuestro PC/tablet/smartphone para convertirse en un cliente SIP capaz de recibir las llamadas entrantes de la cuenta SIP. Del resto, se encarga nuestro proveedor SIP.

Para hacer esto desde el PC, yo os voy a recomendar Linphone porque su hogar y ambiente naturales son el opensource y GNU/Linux, aunque es multiplataforma y tambien está disponible en Windows. Tambien podéis informaros sobre ekiga, aunque este me ha respondido un poco peor frente a problemas de conexión a la hora de registrar las cuentas SIP desde algunos sitios donde el mapeo de puertos no es una posibilidad.
En los terminales Android tambien teneis SIPDroid o el mismo cliente integrado en el sistema operativo (versiones más recientes de Android), que gestiona las llamadas SIP de forma transparente una vez configurado.

La confguración de los clientes SIP se sale del alcance de este artículo, pero supongamos que vuestra cuenta SIP en callcentric es 17772231234 (siempre empiezan por 1777). En tal caso, la configuración de la cuenta en Linphone sería tal que así:


Al pulsar aceptar os pedirá el password de la cuenta y lo guardará para futuro uso. Con eso ya teneis un software capaz de recibir llamadas desde la línea de USA, directamente hasta vuestro PC, que además tiene una forma de utilizarse muy parecida a la del popular skype. Dejamos el cliente SIP registrado en el PC y esperando a recibir llamadas. Ahora que ya tenemos todo alineado, solo queda rematarlo...

Conectamos a voice.google.com utilizando un proxy estadounidense (debe aceptar SSL!) que habremos configurado antes en el navegador, asegurándonos de que cualquier posible sesión nuestra de google está cerrada. Podems usar otro navegador sin proxy en paralelo para conectar al resto de sitios web mencionados aquí, puesto que no filtran por región. Así navegaremos a mayor velocidad.

Registramos una nueva cuenta de google usando el botón "sign up" y rellenamos los datos como si estuviéramos en USA. Durante el registro, google nos pide un email alternativo válido y un número de teléfono. Aquí podemos dejar sin poner aún el teléfono (nos lo pedirá luego). Suponiendo que queremos mantener nuestra privacidad y anonimato al máximo, podemos usar un email temporal de servicios como nowmymail.com como dummy para verificar el registro en google. 

Seguid el proceso de registro hasta que os pida un número de teléfono:

Aquí podemos hacer una pausa (sin cerrar esta ventana) para irnos a visitar el enlace de confirmación que nos había enviado google al email que le indicamos.

Luego volvemos a la ventana "Verify your account" y escribimos nuestro numero DID, sin el 1 inicial, y asegurando que sale la bandera de USA en el selector de al lado. Tambien tendremos que cambiar el método de envio de códigos, de TEXT MESSAGE a VOICE CALL, ya que los números DID de callcentric pueden recibir llamadas pero no SMS.

Con esto, si todo va bien, estaremos a punto de recibir nuestra primera llamada VoIP desde nuestro número DID estadounidense. Al pulsar CONTINUE la pantalla del navegador cambiará a la imagen que vemos a abajo, y deberia comenzar a sonar nuestro softphone. Descolgamos y escuchamos con atención la grabación, porque nos va a decir dos veces y en un inglés pausado y claro el código de validación que tenemos que introducir en "Enter verification code":


La llamada finalizará sola cuando la locución acabe. Ponemos el verification code y pulsamos "Continue".
Llegados a este punto, ya hemos validado la cuenta de google con las dos credenciales que nos piden, un email y un teléfono, ambos pseudofalsos y creados para la ocasión para proteger nuestra identidad.

A partir de ahora comienza el proceso de configuración de google voice propiamente dicho.

Estaremos en una pantalla tal que así:


Lo que nos está pidiendo es un primer número al que desviar las llamadas recibidas en el número de google voice. Como hemos dicho antes, este número debe ser forzosamente de USA. De nuevo, pondremos nuestro número DID sin el 1 inicial y pulsaremos "continue". Eso hará que google genere un código de validación. Esta vez el código de validación es de solo dos digitos y viajará en el sentido inverso al anterior (de la web al teléfono), así que nos preparamos para atender a una llamada en nuestro softphone, en la que además tendremos que utilizar el teclado virtual durante la llamada para enviar los tonos pertinentes. Cuando estemos listos, pulsaremos el botón "Call me now".



Oiremos una breve locución que nos pide el código. Cuando se calle, lo pulsamos en el teclado de nuestro cliente SIP. Si estais usando Linphone, el aspecto del teclado será este:


En cuanto hayamos realizado el marcado del código de validación, usando pulsaciones bien prolongadas y firmes, oiremos de nuevo la locución confirmando que el número ha sido validado, al tiempo que veremos que la pantalla de nuestro navegador cambia automáticamente de nuevo:


Pulsamos "I want a new number" y aparece un cuadro donde podemos elegir números disponibles por código postal (filtro de la izquierda) y/o por conjuntos de números o letras que nos gusten (filtro de la derecha):


Partiendo de la premisa de que no sabemos códigos postales de USA ni tenemos interés en ninguno en particular, podemos jugar un poco con el filtro de palabras y números para ver qué sale...



Y cuando os canséis, elegid uno de entre las opciones y pulsad "Continue". Por ejemplo, yo al final elegí el (802) SBD-0250, o lo que es lo mismo, (802) 723-0250:


Ahora ya puedo registrar este número en Whatsapp y recoger el SMS tranquilamente en la bandeja de entrada de google voice, todo ello protegiendo mi identidad real y anonimato en todo momento:


Y ahora que ya tengo mi número DID en USA, puedo usarlo para crear y validar más cuentas de google. No todas las veces que quiera, puesto que google no permite usar mas de 3 o 4 veces el mismo teléfono para validar diferentes cuentas, pero por lo menos un par de veces mas lo puedo hacer. Y cuando google deje de aceptar este numero DID siempre puedo volver a crear otra cuenta de callcentric y empezar desde cero.

Conclusión

Lo que hemos practicado en este post es un principio de interacción entre productos y servicios, que al combinarse permiten crear una "distorsión" de sus modelos de seguridad. Dado que el uno no contaba con la presencia del otro, y uno proporciona de forma menos controlada credenciales que son válidas para el otro, se ablandan unos vectores de entrada que parecian mas duros observando estos productos y servicios por separado. 

Este tipo de problemas son complejos y su incidencia es difícil de evitar dados los modelos de seguridad y control de acceso digitales que se utilizan hoy día en la mayoría de sitios.

Lo mas curioso es que nadie ha cometido un error, no hay flaw alguno, no hay un vector real, por lo menos no un vector "de asalto". Callcentric tiene su estrategia y sus políticas, y no son incorrectas para su negocio. Google tampoco. Simplemente se ha realizado una combinación creativa de elementos obteniendo como resultado un pequeño hack.

Por norma general todas las empresas que ofrecen servicios online piensan, aunque sea un poco, en la seguridad de sus usuarios y en la autenticidad de sus identidades, pero no todos lo hacen de la misma manera. Cada servicio confía en un tipo de credencial mas que en otro, e incluso el modelo de negocio que practican y su estrategia de marketing tienen influencia en este tipo de medidas de seguridad. Si tenemos en cuenta que algunas de estas empresas proporcionan credenciales que sirven a su vez de credenciales válidas para otras empresas, se crean situaciones como esta, en la que google confía plenamente en los números de teléfono para controlar la identidad de los usuarios, pero compañías como callcentric, con un planteamiento diferente dado que su nicho está tremendamente competido y todos los proveedores SIP regalan números con su ancho de banda sobrante, ellos no son menos y regalan números válidos de USA a cambio de un simple email con la intención de captar clientes en otros servicios VoIP de pago, creando esta paradoja en la que el nivel de seguridad de google cae literalmente al mismo nivel de callcentric, que es bajo por diseño y por necesidades de su guión. 

Aunque en este caso es mas deliberado, tambien sucede lo mismo con nowmymail y otros proyectos similares que están rompiendo el paradigma del control de identidad asociado al email. Dado que muchos servicios online consideran al email como el mejor (o el único) medio para validar y autenticar la identidad de los usuarios, el hecho de que aparezcan empresas que ofrecen emails temporales válidos que duran 5 minutos para facilitarte el registro en un servicio y luego autodestruirse, convierten el control de registro por email en algo inutil mucho menos útil para estos servicios, rompiendo la extensa infraestructura de suposiciones en las que se han basado muchos de ellos y reabriendo el debate sobre la privacidad y el control de acceso de los usuarios online.

Google ya habla de aportar soluciones por hardware a modo de llaves que garanticen totalmente la identidad y privacidad del usuario, aunque esto tambien plantearía otros problemas. Pero google acostumbra a traer buenas ideas y puede que resuelvan estos problemas con su habitual ingenio.

La cuestión es que ahora no tenemos mas límite que nuestra paciencia para crear tantas cuentas válidas  en Whatsapp/Line y derivados como queramos. Y como he dicho al principio, esto es solo la punta del iceberg. Siendo capaces de recoger llamadas, enviar tonos DMTF durante la llamada, y recoger SMS,  podríamos burlar mecanismos de comprobación de identidad y de posición geográfica de varios servicios online, todo mientras mantenemos un total anonimato. 

Y hablando de anonimato, esto siempre lleva una doble moral consigo: el anonimato como individuos nos proteje y nos hace sentir mas seguros, pero el anonimato de todos los demás como masa a la hora de usar productos servicios y herramientas de todo tipo nos parece un peligro y problema potencial...

Artículo cortesía de Alejandro Amo
Leer más...