Thursday 4 September 2014

What if I were a cloud?

What if I were a cloud? I guess many security engeneers have been asking themselves this question in recent days. In this post I want to share my vision of the most critical steps in cloud storage for mobile devices.

I do not claim an absolute correctness and there are no strict requirements, I wish this article could be a starting point for some technical discussions, while the topic is hot.

Baseline:
  1. Сryptography is unbreakable,
  2. Devices are equipped with TPM (trusted platform module),
  3. Attacker has no inconspicuous physical access to victim's device.
I know, that not all devices are equipped with a TPM chip (by the way, iPhone is equipped), but I heard, that SIM card can be used, as a TPM in some cases. If you know how it technically works, please let me know. 


Enrollment

A new device enrollment is a critical step because Cloud should be sure that this device is authenticated and not a source of malicious activity. A device enrollment should be performed with two factor authentication. The second factor could be an OTP (one time password) sent as an SMS to the phone number associated with the account, or an OTP preset on any other device, which was already enrolled. For each new device the account owner should be notified by email.

How it works step by step:



  1. User generates an OTP on a device enrolled previously;
  2. Generated OTP goes to cloud;
  3. User enters the OTP on a new device;
  4. Device generates a TPM signe Certificate request (TPMCRT);
  5. If OTPs from steps 2 and 4 are equal, the enrollment is successful.
In the case of a new device:
  1. New device performs an enrollment request with a login and a password;
  2. Cloud sends SMS with an OTP to an associated phone number;
  3. New device sends TPMCRT + OTP;
  4. If OTPs from steps 2 and 3 are equal, the enrollment is successful.


What is TPMCRT :
  1. Client device generates a private key and a certificate request for each enrollment;
  2. TPM signs Certificate request (TPMCRT), so we get an unique device certificate.

Benefits:
  • In a case of credentials leak, an attacker can't enroll a new device, and get user's data;
  • If an attacker has an access to an enrolled device and can generate an OTP for a malicious device, the victim will get a notification.

Secure communication

First of all - certificate pinning, it should protect us from SSL MiTM. This kind of attacks could be a result not just of compromised Certificate Authority, using MDM mechanism, corrupt system administrators could distribute malicious Certificate Authority to devices, and then perform SSL MiTM.

Then Cloud should authenticate a device, in other words, Cloud should check that the device was enrolled:
  1. Device authenticates Cloud (with pinning);
  2. Device sends its certificate which was generated during enrollment.(?Https client-side authentication?);
  3. Cloud checks whether the certificate was enrolled;
  4. Cloud uses the TPM public key from the certificate and encrypts a CHALLENGE;
  5. Device receives the encrypted CHALLENGE and uses the TPM to decrypt it;
  6. Device generates a RESPONSE and encrypts it with the TPM;
  7. Device sends the encrypted RESPONSE to Cloud;
  8. Cloud decrypts it with the TPM public key, if it's ok, the authentication succeeded.

Benefits:
  • TPM doesn't allow an attacker to gain access to Cloud, even if he or she was able to steal the private enrollment key (with a malware or forensic boot).
  • We have the flexibility. For example, if we want to donate or sell the device, we can simply remove the enrollment key by device factory reset, or via Cloud web interface, if the device was stolen.


If you notice any mistakes or if you whould like to add anything, I will be happy to find your comment in Hackapp Facebook group or in any other place (plese leave link in comments).



Monday 1 September 2014

Official comment on iCloud leak

I'm really sorry that talk given by @hackappcom  and @abelenko on local @DefconRussia a group meeting (@chaos_construct event)  few days ago have had such nasty consequences. And blackhat community performed such weak, cheap and  ungrateful feedback.

In  justification I can only mention,  that we only described the way  HOW to hack AppleID. Stealing private "hot" data is outside of our scope of interests. We discuss such methods of hacks in our's narrow range, just to identify all the ways how privacy can by abused.

For everyone, who was involved in this incident, I want to remind, that today we are living in a Brave New Global World, when privacy protection wasn't ever so weak, and you have to consider, that all you data from "smart" devices could be accessable from Internet, the Place of Anarchy, and, as a result, could be a source of undesirable and unfriendly activity.

So, a weak "dictonary" passowrd (like P@$$w0rd) is not the best way to protect yourself in the modern world. But it's not your fault. It's a common problem of modern-being, that people use a technology without understanding all risks and consequences. Not all users are nerds (look  -  Jim Parsons account was not hacked!).

And now, after all that you've experienced, we can only suggest to start information security self-education. You may  follow us on twitter:

and read popular news feeds

and  if you want to go deeper, you better join local Defcone group.


P.S.

Stay wild :)

Tuesday 20 May 2014

API for your SDLC. Сheck your Apps before release!

Good news everyone!
Now we have API, and there are a few words about why to use it and how.
It's not a surprise that cost of fix depends on development stage, and patches for a released software are used to be the most expensive.






And HackApp has not been able to help with it. Today we are happy to present API, which can be scripted into your SDLC.

API is simple and has 3 actions:

  1. Add application , 
  2. Check status,
  3. Get Report .
Also we have a nice web page to explore uploaded apps :)

Add Application

There is a request to upload an app:

curl    --form "file=@%path_to_app_bundle%" https://hackapp.com/api/addapp  --form "secret=%secret_key%" -k

  • %path_to_app_bundle% - path to app file on your filesystem
  • %secret_key% - your API authentication key, how to get it you can read futher.


if everything is ok, you'll get response:


{"action": "add_app", "details": "", "app_hackapp_id": "%app_hackapp_id%", "app_id": "%app_id%", "result": "success"}

  • %app_id% - name of your app.
  • %app_hackapp_id% - app id in HackApp, you will need it, to check status, or get report.


Check status

Request to get status of already added app:

curl    --form "secret=%secret_key%" https://hackapp.com/api/appstatus  --form "app_hackapp_id=%app_hackapp_id%" -k


if everything is fine, you will get:

{"app_status": "done", "app_hackapp_id": "%app_hackapp_id%", "app_id": "%app_id%", "result": "success", "details": ""}

  • "result": "success"  -  your app is analysed and you can get report.

Get report

To get report:

curl    --form "secret=%secret_key%" https://hackapp.com/api/appreport  --form "app_hackapp_id=%app_hackapp_id%" -k

you will get JSON object. There is an explaining example:

{"com.idar.visupay":    # App name
{
"bugs": {  # Hash Array  where key is bug ID
"ios_ssp": [{"bug_file": "Payload/VISUPAY.app/VISUPAY", 
"bug_details": "", 
"bug_fix": "This can be achieved by specifying the \"--fstack-protector-all\" compiler flag", 
"bug_name": "Stack Smash protection disabled", 
"bug_file_id": "c9dd3255eed4a5a3d6a6ca5e00408e07", 
"bug_false_positive": 0, 
"bug_id": "ios_ssp", 
"bug_desc": "Compilation without stack protection can lead to malicious code execution", 
"bug_level": "medium"}], 
...
"desc": { # Hash Array with app details
                         "ver": "2.0.001", 
"perms": ["Storage in KeyChain"], 
"min_ios": "4.3", 
"uri": ["fb321971781207651://"], 
"drm": null, 
"store": "appstore" 
}
}
}

Apps' List

To get list:

curl    --form "secret=%secret_key%" https://hackapp.com/api/appreport  --form "app_hackapp_id=%app_hackapp_id%" -k

you will get JSON object. There is an example:

[{"app_status": "done", "app_hackapp_id": "9a7630baf742cc0583ba87aacbf6a9e6", "app_id": "com.idar.visupay"}, {"app_status": "done", "app_hackapp_id": "4bb60e00e7f5c17d891a72f03ccd1bbd", "app_id": "air.ru.mail.games.pokerarena"]}

GUI

There is a cute page to represent API activity 



by clicking here you'll get a list of all added apps 




... and there is a special button to get your current API secret key. Sure thing, you can change it, if you think someone else uses it ;)




API is available in PRO version
To enjoy a free trial, please contact info@hackapp.com.












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: