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…


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