Sunday, 12 June 2016

Mobile app security checking in two parts with a lyrical afterword (Part II)

Part two: Attack Surface

So, we finally got a list with possible security issues.

What should we do next?

Definitely, we need someone who would examine this list:
  • To separate real issues from false positives;

Remark: What can be a false positive in our case? For example, Ignore SSL Certificate Error. It does not matter if the issue is found for, let’s say, a graphical redactor and does matter if it’s listed for a bank client app.
  • To perform necessary tests which cannot be done automatically (see the part one);
  • To localize vulnerabilities (it could be that there are some troubles with third party components);
  • To determine vectors of the most possible attacks (see Lyrical Afterword (it’s coming soon));
  • To compose a plan (recommendations) on how to improve security of the analyzed app.

Who can do it? What is the first thing that comes to your mind? Developers or QA guys which have been working on this app? Sure, that’s logical. It seems that they know the app best, doesn’t it? Unfortunately, they are not good at this type of tasks. Why?

There is a vulnerability in you app.
Agh.... that’s true. But it’s not in our app, it’s in a lib which we use in our app...

You may check this drammatic story about AFNetworking library.

Sometimes developers cannot even think that some things can be used maliously (there is an example of such a story).

Software devs are good at app creating, QA folks are good at app testing. Those who we want are specialists from information security field. They have an unusual vision of how an innocent (at first glance) app can be used in malicious ways. It is exactly what is needed. You may read this sad post with juicy details.

IT security guys are hackers but they are on our side of barricades. They have specific knowledge and specific mind set, which allows them to determine the most possible and profitable ways of invasion (attack surface) and they know how to improve app security. They work in IT security day by day and are very familiar with current security trends (you cannot expect that from devs, since they need to think of security twice in a year).

Large companies or companies offering IT security services may afford a full time security specialist or even a team of security specialists. In general, there is no need to have a security guy in your staff, since IT security expertise or advice is needed from time to time (for example, prior a new app release or a new release of an existing app). Analogy with physicians works well here. It’s good to be informed regarding your health and follow medical recommendations. Should you live in a hospital for it? When you need it, you consult with a specialist and follow his/her recommendations.

It is very common to drop security part during first stages of development. Neglect of security in general may cost a lot.

(Lyric afterword is coming soon)

Wednesday, 11 May 2016

Mobile app security checking in two parts with a lyrical afterword (Part I)

Checklist, Security, Scanner, Bigda.., oh sorry mistyping... The words are very familiar and popular. Let’s find out what they do mean.

Part one: Automatizzzzzzzzzze

Is there a way to do mobile app security checking automatically? Fully? Partly? What can be automatized?

HackApp Security Scanner performs static checks. And we are working to automate as much checks as possible.

Let’s review a checklist which should be passed to reveal a level of app potential danger for end users and vendors. OWASP published a Mobile Apps Checklist (the complete checklist can be found at OWASP website which contains 87 checks for Android and 74 checks for iOS. All the checks can be divided to those which are performed on the server side and those which are done on the client side (an app). Existing methods of checking app are static and dynamic.

During static checks a motionless mobile app is examined. The following things should be analyzed:

  • Constants,
  • Resources,
  • Methods,
  • Third-party libraries.

To perform dynamic checks we should run an app and do following things:
  • Altering server-client interactions,
  • Reverse protocol engineering,
  • Cryptographic mechanisms analyzing.

Statistic checks can be automatized pretty easily. We can code as well some of dynamic checks, for example: Proper SSL implementation, Account Lockout policy, different kinds of injections, etc. This is the good news. The bad news is that it is either difficult or very difficult to do the most of dynamic checks automatically, for example: Logic security (race condition and other), Input validation, Side channel data leaks, etc.

There are tools intended to help developers to test app security. Quite often the tools are open source and should be fine tuned prior to use. You should also tune your environment to run them. After many hours of blogs reading, tuning and installation they are finally ready to use. That are cons. There are some pros as well. Just in a couple of years you’ll get a nice conveyor to scan thousends of apps. It does not matter that you have just two or three apps to scan. It’s hard to stop once you started :)

While installing a new tool in your environment… are welcome to check what we have new.

HackApp Scanner is an online tool. One of its purposes is to perform static checks without pain, desperation and time wasting. It’s always ready to use. An app can be analyzed just in a couple of clicks.

So, there is a tool which does for us a part of our job. The tool is fast and always available. How does it work? You take an app and feed it to the scanner. The scanner produces a list of possible security issues in order of their severity: high security alerts, warnings, informative messages. Descriptions contain files/classes where issues were discovered and some other useful staff.

Finally! We have the list. What should we do next?

Thursday, 3 March 2016

Excessive access. Who cares?

Quite often an app, especially a free one, requires an excessive access. If I can tolerate the absurdity of the access list I install the app if not… well, I just look for another app. Recently I came across a very greedy app. I could not pass by.

Installs: 10,000,000 - 50,000,000. Number of people rated the app as 4.2: 335,888

It could be that a keyboard cannot work without all this info and access or the app works only for good people… So it should learn first who I am and who my friends are.

In any case I’d prefer another app:

P.S. There is another interesting detail. The info below is not available if you are installing the app directly on a device. You could see it on your PC: Flash Keyboard on Google Play

and one more time:
Installs: 10,000,000 - 50,000,000.
Number of people rated the app as 4.2: 335,888

Stay calm. Be cool.

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.

  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. 


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.

  • 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.

  • 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.


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%"  --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%"  --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%"  --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/", 
"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%"  --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": ""]}


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

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

And don't forget to vacuum your database ;)