1

Our annual penetration test result came back and this time around, one finding was reported: Our line-of-business Android App is vulnerable to memory dump attack.

The specifics of the method that were used is a bit obscure because it was down by external contractor who weren't willing to disclose anything beyond their contractual obligation. But from the report I can derive the following information:

  1. The proof of concept attack were done using Fridump, a python script that's using Frida and Frida server running on the device.
  2. The specific vulnerability that was reported: They can extract sensitive data from memory dump that was generated using fridump.
  3. The app under test was our Android 'debug' build. It is not clear to me why they were testing our 'debug' build instead of 'release'.
  4. The app uses combination of cordova and the now obselete CrossWalk Project. But there were no reports regarding the use of an obselete 3rd party library, so I think they should have more concern but that's issue for another day.

The point is, the sensitive data reported are javascript variable values. I don't have deep understanding regarding the application architecture, this is a 5-year-old legacy app, but I believe when the app is running, javascript code must be loaded into the app memory segment. Anyone who can plant instrumentation tool (like Frida) on the device can read anything from the app's memory segment.

The questions:

So is this still considered the app's vulnerability? Is the Android platform allow mitigation of such attack say by following certain rules?

Is it possible that debug android build is not guarded against memory dump attack? Will the 'release' version be less vulnerable to this kind of attack?

7
  • They may have used a rooted android device to penetration test your app. It's better to put constraint on what environment they can use. Use hardware backed SafetyNet attestation to verify that the device is Google Mobile Services certified.
    – defalt
    Oct 6, 2022 at 7:34
  • Anyone starting their "vulnerability" report with "On a rooted device where I gained elevated privileges, I can do X to your app" is just looking to get paid for BS. Yes. If you are in total control of the platform, including any user-specific secrets that they have to input at some point of using the app, the app is vulnerable. Doh. Finding that out should not be something you pay money for.
    – nvoigt
    Oct 6, 2022 at 7:59
  • I completly agree with both defalt and nvoight. But too bad I'm in no position to argue about the method used (or the choice of people who did it). So, an 'unfair' method where used, is there any way, be it 'fair' or 'unfair' to thwart such attempt? Is there any way to detect instrumentation attempt an throw it off trail?
    – bluearth
    Oct 6, 2022 at 11:58
  • Hardware backed SafetyNet attestation is the way.
    – defalt
    Oct 6, 2022 at 15:38
  • @defalt would you mind converting your comment into answer and elaborate a bit more, will gladly upvote it. I sure have further questions on this.
    – bluearth
    Oct 7, 2022 at 2:05

1 Answer 1

2

Is it possible that debug android build is not guarded against memory dump attack? Will the 'release' version be less vulnerable to this kind of attack?

Usually the main difference between release and debug builds(except of pointing to different environments, using different keys for signing etc) on Android is that the former is using some kind of obfuscation(which was done with Proguard in past, nowadays the R8 compiler), more on that you can read here. It depends on the configuration of release build of course but this behaviour is the default. But it won't prevent memory dumps in any way, it just makes reading and reason about the decompiled app's code harder. So it makes (almost)no difference in the case of memory dump attacks.

So is this still considered the app's vulnerability? Is the Android platform allow mitigation of such attack say by following certain rules?

Short answer is no, Android does not mitigate such attacks, as if you have a root(you mentioned frida was used so the device most likely was rooted, there are some ways to try to run frida on non-rooted devices also but it requires much more effort and there is no 100% bulletproof way to ensure that it will always work so I would guess pentesters are just using rooted devices which is much much easier) you can do basically whatever you like with the system.

What you can do then?

First option is to use hardware-backed attestation as mentioned in comments. You need to remember that it will definitely check against device being rooted but you cannot be sure that it will detect frida hooking framework which hooks the Android process at runtime(this is a little bit vague area as the exact checks attestation API is doing are not fully transparent, we only receive the attestations result but the checks itself is Google's sweet secret). This should be still enough though as hooking is closely connected with having a rooted device as mentioned above.

The other option that is available is a family of tools called RASP(Runtime Application Self Protection). They are able to detect both root and hooking frameworks at runtime and take appropriate actions based on configuration(e.g to kill the app when hooking detected). There are several solutions available for Android(Promon, Digital.ai, Guardsquare just to name a few) but they are paid solutions so I don't think it is worth to use them for just legacy app.

Is it considered app's vulnerability?

It depends as to make this attack vector successful attacker need to be in possession of the device with the logged in user(I assume you have accounts in your app), root it and then start hooking and dumping memory.

I would say that this kind of scenario is unlikely but if the nature of information being possibly stolen is very sensitive and you have very carefree users then you can have give the Google Play attestation a go.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .