Android app man-in-the-middle attack

Question

Let's suppose I have an Android app that after strong authentication pulls sensitive data from server A and sends it to server B without storing it. The data appears only in the network traffic (encrypted obviously) and in the memory segment of the app.

The question is: is it feasible or even possible to modify the apk and hook it somehow to replace the data which is forwarded from server A to B with a predefined string?

I know that relying on client side security is a huge no, but I'd like to understand the complexity of this hack (getting the apk, decompiling, finding the function to hook, compiling, installing) and the possible show stoppers.

In this scenario how much more security could code obfuscation give? How easy to decompile and reverse engineer an obfuscated code?

I'm neither an android nor a java developer, but I'm more or less familiar with security concepts

Answer 1

My answer assumes that your attacker is "skilled in the art" of doing this sort of work.

getting the apk

It would take less time than it took you to write the question.

decompiling

It depends a bit on the speed of the computer, but it should be on the order of a few minutes.

finding the function to hook

If you go way out of your way to try to make this non-obvious... perhaps a day? It is a bit difficult to say in the abstract, as it depends a lot on the size and complexity of the app, whether this is just a single "function" or if the work is substantially more involved, etc.

Suffice it to say that anyone who wants to take the time will be able to find what needs to be changed.

compiling

It depends a bit on the speed of the computer and the size of the code base, but again it should be measured in minutes.

installing

It would take less time than it took you to write the question.

In this scenario how much more security could code obfuscation give?

A few years back, I was told by one security researcher that using simple ProGuard obfuscation actually made it easier to do this sort of attack.

There are more powerful obfuscators out there, including ProGuard's "big brother" DexGuard. Similarly, there are people who create de-obfuscators, tools that knock DexGuard-level obfuscation down to something more akin to ProGuard. For example, DexGuard tries to encrypt as much of your app as it can; de-obfuscators would generate a decrypted edition of the code.

Hence, the benefit of high-level obfuscators varies, based upon the current state of the arms race between obfuscator developers and de-obfuscator developers. I can't say with any certainty where the arms race stands now, let alone when somebody else reads this answer years from now.

I liken obfuscators to the old tale of two hunters in the woods being chased by a bear. If you were one of the hunters, you don't have to run faster than the bear to escape. You just have to run faster than the other hunter. In the case of obfuscators, the objective is to make fussing with your app unappealing, causing attackers to move onto other potentially easier targets. The problem with this approach is that it assumes that the attacker does not care about your app specifically, that your app is merely one target among many. Attackers who care about attacking your app for specific reasons will not behave that way, and they will spend the time to crack it. In other words, running faster than the other hunter assumes that the bear is not pissed off at you specifically.

Answer 2

MITM possibility with an android application is in the given order.

1. No SSL/TLS

It is quite easy to perform MITM in this case. The use of SSL/TLS instead of just 'encryption' was intentional. SSL/TLS not only provides 'Confidentiality' but also provides 'Authentication'. Thus if your app's communication is not on HTTPS or another SSL channel, it is quite easy to perform a network level MITM and manipulate all the requests and response.

2. Using device's trusted credential store.

Like browsers, android devices also has a set of trusted CA's. If the application relies on the device's trusted credential store for authentication over SSL, [I am not talking about password authentication here], it is still vulnerable to MITM in the following situations - a) one of the trusted CA in the list of device credential store was compromised, b) an adversary was able to add a custom certificate authority to the device credential store - both of which has at least greater than 0 probability.

3. SSL Pinning

SSL pinning is a method in which the application uses the credentials in devices trust store itself, but limit the CA's to a subset of what is available. There are methods with which this can also bypassed, possibly by a malware. An example is the use of Cydia Substrate/Xposed modules like JustTrustMe for performing penetration test on android applications which use SSL pinning.

4. Using a custom certificate store

This is when an application uses it's own certificate store where all the information is bundled in the APK itself. In this case, the attacker, to perform an MITM attack, would need to decompile or disassemble the application, modify the smali code to add own certificate, recompile and sign the apk and t=make the victim install it. Yes it is quite difficult.

Answer 3

If your Android app is written in Java (or Kotlin), and you don't use an obfuscator, the attack is quite easy. Professional obfuscation tools may deter the hacker, but if the goal is to replace output with some predefined string, code obfuscation will not offer actual protection.

People can even make these changes on the platform level, because your app will be using system networking API, which is open source on Android.

You should look for an answer on the protocol level. If both servers sign their packets, and include a signature of the incoming packet in their reply, it will make the challenge of MitM much harder.