How to run accurate dynamic mobile application security testing?

If you read this blog post, this certainly means there is no need to convince you about the importance of securing your mobile application against hacking. And to make a proper job, you certainly embrace a multi-layer approach.

First, by designing and coding with the aim to handle well the sensitive data and operations. This is what OWASP specified in the MASVS by two levels: L1 (Standard Security) and L2 (Defense-in-depth).

Second, by hardening the code against attacking tools, mixing code obfuscation and anti-tampering measures to make reverse-engineering harder to achieve. OWASP’s MASVS have captured this in the R, Resiliency, layer.

We wrote a blog post about this: How can OWASP help you define your mobile app security policy?

How can you make sure your app protections are effective?

Now comes this critical question: how do you validate these software protections? They are implemented to withstand attacks. This means that you need to create the conditions of attacks to observe if they are effective.

Easy to say, but how difficult in practice?

You don’t have necessarily the knowledge and skills internally to do this. And the human external resource is tedious and incompatible with regular and systematic verifications.

There is one option though: specialised automated testing tools. There are quite a few. They are not necessarily appropriate to address the critical point of security protection validation. We believe that a testing process should mandatorily have the application actually executed.

In other words: make sure the application is running when testing different attack scenarios and observe if the behaviour is as expected.

In “Gartner” language, this could be seen as a Dynamic test. And the tool feature would be named a DAST (Dynamic Application Security Testing). Okay ... but this wording mainly comes from AST (Application Security Testing), and the application to mobile apps does not necessarily work.

Many DAST tools do not make the proper testing of the application binary running and being tested. Maybe because it is difficult to implement.

Some will name it IAST, standing for Interactive Application Security Testing. This combines together the notion of dynamic and interactivity, here the manual interactions allowing to gain security testing code coverage.

Regardless of the toolmaker and the terminology, you will need to do one thing: make sure you know precisely which problem you want to solve: which assurance do you want on your mobile application. Once done, selecting the right tool should easily flow...

What kind of dynamic testing for the application resiliency?

To protect your application, you have to understand how it behaves when:

• Running in suspicious environments, such as a rooted or jailbroken phone,
• A potential threatening software is used along with the phone (a debugger, an instrumentation framework like Frida, a debugger, etc.),
• A piece of code is being injected into it,
• And many more scenarios.

As a result, a dynamic test is a test happening at runtime. We need:

1. A mobile application
2. A dynamic test running on the mobile application in real conditions
3. A mobile device

Two reasons why you shouldn't test your apps on emulators

Reason #1: Your anti-emulation protection would falsify your actual results

If your application is correctly protected, it should NOT allow the use of emulators. As a result, all your dynamic tests run on an emulator will be biased.

Using an emulator would generate a lot of false-positive tests as the app would crash immediately, even though you're testing your root detection or your code injection protection.

Let’s imagine one needs to test the protections against hooking techniques to inject some code.

On an emulator, if you’re protected against the emulation, all your tests would trigger the protection, making you confident about your protection level.

On a real device, you would test your protections layer by layer, passing through the emulation detection, the root detection, and the hook detection.

Long story short, running Dynamic Testing for the same application on an emulator or on a real device would end up in completely different results.

Don’t. Do. That.

Reason #2: Hackers love device emulators

Allowing your app to run on an emulated device is highly risky as it allows attackers to better handle the runtime environment, which makes reverse-engineering easier.

In your strategy to slow the work of attackers down, blocking emulators to run your app is essential.

Tip #1: Get your own devices

🚨 Disclaimer: to run your own dynamic tests on real devices, you need to be able to develop a custom ROM and manage the dynamic attacks yourselves. This part requires strong expertise. Believe me 🙂

It’s neither that complex nor that expansive to get your own devices to run dynamic attacks. If you can’t afford to buy some devices and pay them upfront, you can think of renting your fleet

Tip #2: Automate your Dynamic Tests

An even more efficient way to run dynamic tests is to automate them with MAST tools (Mobile Application Security Testing). At eShard, we released esChecker to automate hundreds of tests on behalf of our clients.

It’s an easy way for them to test their Android and iOS mobile apps every time a new app build is ready against top-market and cutting-edge static and dynamic tests.

Integrating the security verifications within your SDLC (Software Development Lifecycle) is the best way to make sure that every app update doesn’t push any protection regression in production. We highly recommend automating these tests within your CI/CD pipeline (using built-in plugins or APIs).

Takeaways

In a nutshell, here’s what you need to remember:

• Protect your application against the use on emulated devices,
• Run dynamic tests on real devices to evaluate your security policy (rent them or buy them on the second-hand market),
• Automate your dynamic testing to make sure you don't miss any protection regression.

From our experience, it’s really hard to internalise this skill set. This is why we’ve built esChecker.

Do you want to see how it can help you automate your security testing? Give it a try for your iOS or Android applications.