jalbreak/root detection

[Javi D R]

Hi

Maybe its not the best place to ask for it but... can anybody suggest any tool to detect jailbreak or root in a device?

Thanks

[Jim Manico]

This is a cat and mouse game so be careful depending on it. Tools detect jailbroken devices and the jailbreakers evade it. Tools update, jailbreakers evade. Rinse, lather, repeat.

Aloha,
Jim

--
You received this message because you are subscribed to the Google Groups "OWASP Mobile Top 10 Risks" group.
To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.
For more options, visit https://groups.google.com/a/owasp.org/d/optout.

[Milan Singh Thakur]

Well said Jim..

But still Javi if you can try apps like root checker.

[Javi D R]

I have heard that root checker doesnt work very well, specially when you also install a root hider, isnt it?

Thanjs

[Anant Shrivastava]

https://github.com/devadvance/rootinspector <- this is a project by the author of rootcloak plus "android" so kind of most accurate as per my knowledge.

However just a tip for android devices, if you can do checks at native level that would be better. all java calls xposed root cloak will capture.

For iOS i recently encountered an app which had hardcoded checks for various binary locations as well as stuff like xcon and had some kind of binary protection so binary patching (and subsequent signing) resulted in executable corruption. (did it blackbox so can't say for sure what they used.)

Hope this helps.

P.S. I fully agree with @Jim here, its a cat and mouse game.

-Anant

--

[Jason Axley]

For Android, it is good to recommend the SafetyNet API https://developer.android.com/training/safetynet/index.html.  Here's a wrapper around it that I've come across before (have not used it yet though):  http://intohand.com/blog/post/safetynet-helper-open-source-library 

This uses a network round-trip to make it much harder to fake out the JWT response.  Of course, if someone has a rooted device, they could possibly just bypass the invocation of the call entirely if you don't implement it in a way that has side effects that would be difficult to shunt with XPosed or Cydia substrate.

And this only works on phones with the Google Experience (with Google Play Services, etc.) so if you have lots of users on Baidu phones or other Chinese carriers, it may not work for you.  

-Jason

[Anant Shrivastava]

When it comes to Safetynet please keep following in mind. (I have personally not yet used safetynet so this is based on twitter chatter)

https://twitter.com/copperheadsec/status/660600297061023744

Good coverage of what safetynet is doing :

https://koz.io/inside-safetynet/

https://www.cigital.com/blog/using-safetynet-api/ and https://koz.io/using-safetynet-securely-in-your-android-app/

-Anant

[Javi D R]

Thanks anant. I know some commercialcompanies that do that checking. It is more extended than what it should be

What about malware detection? All what i have found is commercial tools. Do you know any opensource tool (sdk) that do this?

If no os tools, then, i will have no other option than using comm tools :(. Any good recommendation there?

Thanks

[Jason Axley]

I'm familiar with that thread and the article digging into what it's doing.

The danger of judging a technology based on its original purpose, which may have been some nefarious purpose to lock out OEMs - who knows, is that this is a genetic fallacy.  It's most appropriate to review the current and intended state now, not what it started out as.  Adrian Peterson at Google specifically called out SafetyNet last year as a key platform for integrating additional security checks and collecting analytics data that enables them to look at the overall security state of Android devices at a macro level. Because the API collects local data that can then be analyzed on Google's servers for platform integrity checks, they can modify the algorithms as needed for integrity protection.  The CTS checks are also adding many security checks to them so CTS compatibility can be one benchmark for platform integrity and a way Google can help OEMs make better ROMs, in theory.

I don't see a dependency on Google Play Services necessarily being a bad thing.  Any app actually running on a modern Android platform and using the network should actually already at least be implementing this play services API to ensure that the security provider is up-to-date before making secure connections:  https://developer.android.com/training/articles/security-gms-provider.html  If not, you're at risk of using a security provider of unknown security posture.

-Jason

[Javi D R]

So, am i right then with the following assumptions:

1 - jailbreak and root will always be 1 step ahead of detection techniques

2 - solutions provided by third parties are not 100% accurate

3 - Doing my own detection technique is the most likely solution,using the methods described here -- http://stackoverflow.com/questions/1101380/determine-if-running-on-a-rooted-device

Correct?

[Paco Hope]

Some thoughts inline.

On 3 Mar 2016, at 16:04, Javi D R <javi.x...@gmail.com> wrote:

1 - jailbreak and root will always be 1 step ahead of detection techniques

They will be until they aren’t. One day both Apple and Google will finally make these things fundamentally unbreakable. Apple’s nearly there already. What does that mean for us as security professionals? Assume for a moment that it becomes impossible to jailbreak/root a phone. What do we do then? Does malware exist any longer? Does your app still check for root/jailbreak? Does your app still look for malicious apps attacking it on the same device? Probably, but what those apps can do will be significantly limited if the device is truly impossible to jailbreak for the vast majority of users.

2 - solutions provided by third parties are not 100% accurate

Definitely. There’s a fundamental reason for this. If I am the operating system, I can lie. If you are an app, and I am the OS, you cannot possibly validate my authenticity. You look for some file, I can lie and tell you that it isn’t there. Or I can lie and tell you that it is. I am the OS. So no user-level code can ever verify the authenticity of code that runs at a higher privilege. Attestation of the OS’s integrity has to be baked into the OS itself.

Paco

[Jim Manico]

"One day both Apple and Google will finally make these things fundamentally unbreakable."

Eh, history does not back that up. Take research from yesterday https://www.cs.tau.ac.il/~tromer/mobilesc/ f Pretty fascinating side-channel attack against this "unbreakable" phones.

"One day" seems like a long ways away. I hope you are right about this, but I am skeptical. Anyone who claims their tool/server/app whatever is unbreakable usually regrets such statements.

- Jim

[Paco Hope]

I’m not so much implying no one can break anything ever. More about whether it’s worth building detections and reactions to jailbroken-ness. Let’s say you’re making a banking app. And you think to yourself “do I need to worry about jailbroken phones?”. So you think “out of the population of all my banking customers, what is the percentage that might have jailbroken phones?”

It all comes down to why someone wants to do jailbreak detection in the first place? Are you a bank who wants to store something secret in the app, assuming that no one ever will be able to extract that secret? Then the “academics in Israel” argument matters. Because it’s not that locked down, yet. Perhaps it never will be.

Are you a bank who wonders whether a specific individual accountholder might have their session token / personal data / password / etc. stolen from the banking app by a different, malicious app running on the same, jailbroken device? Google and Apple are rapidly diminishing the likelihood of that happening. It will soon be completely impractical for the average banking user to have a jailbroken iPhone. Android is lagging behind, but will get there in the end.

Maybe it’s global secrets versus per-user secrets. Devices are not yet secure enough (and may never be secure enough) to put a global secret in an app. But they are rapidly becoming secure enough to put per-user secrets in the apps without fear of malware attacking the app across the device. The vast majority of Android kit deployed today is not secure enough even for that. But it will be. That’s where SafetyNet is headed. And iOS devices are nearly there already.

If your only concern is adjacent apps attacking your app on the device, I think iOS has already hit the point where you don’t need to worry about jailbreak detection. If your concern is malicious apps attacking your mobile microservices, well, that’s probably better protected at the microservices themselves. And if your concern is some global key, secret, algorithm, etc. stored in your app that you don’t want exposed, it’s better to work on fixing the design so that it doesn’t rely on a stored global something (if that’s possible at all). Securely rotating or changing the stored global something is probably worth more effort on your iOS app than jailbreak detection is.

In the end, jailbreak detection is a security control. I don’t understand the risk that it’s controlling though. Nor do I understand why it’s the right (for some definition of “right”: cheapest, easiest, fastest, most effective, etc.)  control for that risk. I think video games have a better motivation to do root/jailbreak detection than banks do. They care a lot about local manipulation, on-device of per-user data.

Paco

[Milan Singh]

+1 Jim...nothing is unbreakable :)

+1 Paco for such an insight.

For sure gaming companies are more worried about implementing Jailbreak/root detection control, than banks. I have been working for BFSI clients for quite some time and they are really worried about such control in place. But they prefer to use MDM as an additional control (increased cost). Also app wrapping (injecting encryption code snippet in app) is widely used by em.

I would say, it is good to place Jailbreak/root detection in place and ensure roll-back (app un-installation) as soon as detected.

[Anant Shrivastava]

Hi Folks,

Good to see such detailed discussions (something i miss in a lot of other mailing lists), i side with jim on this that nothing is unbreakable. however i suppose with mobile applications the conventional wisdom of keeping secrets and server and be done with it is no longer valid and we do need some kind of trust to be established at the client side. This trust at this point can't be obtained from vendor side as all platforms are practically broken. Hence the whole cat and mouse game around root detection and bypasses. 

So with that in mind what do i personally believe.

Should we suggest people to do root detection : Yes if they assume data is of importance. (but we also need to tell them about how to use encryption and platform specific features to best possible way)

Should root detection bypass be open source and made available: till we have the need for root detection and people putting effort in this area,  i suppose we need to keep finding bypasses. The end result of this approach either the whole process gets discarded as end result not achievable or it improves and adds a significant level of complexity. but at the end of it its a cat and mouse game and will keep getting on it the same way.

Should every application do root detection: No, only do if your app has some thing to hide at local system level. (audio, video, or any kind of data) 

Also i personally believe lots of stuff is out there what we need is not to build more new stuff but rather focus on putting out details in how to use existing stuff in better (or rather in correct) manner.

-Anant

[Jim Manico]

+1 I'm with you now, Paco. Good insights!

Aloha,
Jim

[sla...@gmail.com]

Hi,

I will also add my "2 cents" to the root detection thread. My background
is mostly mobile banking, and I focus on the end users' security.

I think you should differentiate between detecting root/jailbreak and
actually doing something radical about it (like banning the app usage).
Long story short: IMHO detection is a good practice, but banning not
necessarily.

A few years ago there was an interesting case here in Poland. One of the
biggest banks decided to ban the usage of their mobile banking
application on rooted/jailbroken phones. The decision unexpectedly met
with a huge disaproval of the users, social media PR disaster, and
eventually they decided to pull back the changes and allow the rooted
users. So if you ban the power users who root/jailbreak their phones
themselves on purpose, they will most likely just get angry, go to
competition or use Xposed modules - and that won't make them more secure
or your business better.
A different story with users who don't know their phone is rooted. They
should definitely get to know it during first application startup, with
precise information on the risk and next steps to follow.
So I usually advise detecting root/jailbreak/tampering/malware etc. and
definitely reporting it to the backend (so that FDS could make better
decisions). But rather than denying - display clear information of risk
involved, and if need be liability disclaimer. If your clients want to
use the application anyway, IMHO its better when they take on the
responsibility for possible frauds on their own free will, than to
expose them for additional threats with root-hiding.


cheers
Slawek Jasek

On 04.03.2016 18:53, Jim Manico wrote:
> +1 I'm with you now, Paco. Good insights!
>
> Aloha,
> Jim
>
>
> On 3/4/16 12:51 AM, Paco Hope wrote:
>> I’m not so much implying no one can break anything ever. More about
>> whether it’s worth building detections and reactions to
>> jailbroken-ness. Let’s say you’re making a banking app. And you think
>> to yourself “do I need to worry about jailbroken phones?”. So you
>> think “out of the population of all my banking customers, what is the
>> percentage that might have jailbroken phones?”
>>

>> It all comes down to *why* someone wants to do jailbreak detection in

>> the first place? Are you a bank who wants to store something secret in
>> the app, assuming that no one ever will be able to extract that
>> secret? Then the “academics in Israel” argument matters. Because it’s
>> not that locked down, yet. Perhaps it never will be.
>>
>> Are you a bank who wonders whether a specific individual accountholder
>> might have their session token / personal data / password / etc.
>> stolen from the banking app by a different, malicious app running on
>> the same, jailbroken device? Google and Apple are rapidly diminishing
>> the likelihood of that happening. It will soon be completely
>> impractical for the average banking user to have a jailbroken iPhone.
>> Android is lagging behind, but will get there in the end.
>>
>> Maybe it’s global secrets versus per-user secrets. Devices are not yet
>> secure enough (and may never be secure enough) to put a global secret
>> in an app. But they are rapidly becoming secure enough to put per-user
>> secrets in the apps without fear of malware attacking the app across
>> the device. The vast majority of Android kit deployed today is not
>> secure enough even for that. But it will be. That’s where SafetyNet is
>> headed. And iOS devices are nearly there already.
>>

>> If your *only* concern is adjacent apps attacking your app on the

>> device, I think iOS has already hit the point where you don’t need to
>> worry about jailbreak detection. If your concern is malicious apps
>> attacking your mobile microservices, well, that’s probably better
>> protected at the microservices themselves. And if your concern is some
>> global key, secret, algorithm, etc. stored in your app that you don’t
>> want exposed, it’s better to work on fixing the design so that it
>> doesn’t rely on a stored global something (if that’s possible at all).
>> Securely rotating or changing the stored global something is probably
>> worth more effort on your iOS app than jailbreak detection is.
>>
>> In the end, jailbreak detection is a security control. I don’t
>> understand the risk that it’s controlling though. Nor do I understand
>> why it’s the right (for some definition of “right”: cheapest, easiest,
>> fastest, most effective, etc.) control for that risk. I think video
>> games have a better motivation to do root/jailbreak detection than
>> banks do. They care a lot about local manipulation, on-device of
>> per-user data.
>>
>> Paco
>>
>>> On 3 Mar 2016, at 22:15, Jim Manico

>>> <<mailto:jim.m...@owasp.org>jim.m...@owasp.org> wrote:
>>>
>>> "One day both Apple and Google will finally make these things
>>> fundamentally unbreakable."
>>>
>>> Eh, history does not back that up. Take research from
>>> yesterday https://www.cs.tau.ac.il/~tromer/mobilesc/ f Pretty
>>> fascinating side-channel attack against this "unbreakable" phones.
>>>
>>> "One day" seems like a long ways away. I hope you are right about
>>> this, but I am skeptical. Anyone who claims their tool/server/app
>>> whatever is unbreakable usually regrets such statements.
>>
>> --
>> You received this message because you are subscribed to the Google
>> Groups "OWASP Mobile Top 10 Risks" group.
>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to owasp-mobile-top-1...@owasp.org

>> <mailto:owasp-mobile-top-1...@owasp.org>.

>> For more options, visit https://groups.google.com/a/owasp.org/d/optout.
>

> --
> You received this message because you are subscribed to the Google
> Groups "OWASP Mobile Top 10 Risks" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to owasp-mobile-top-1...@owasp.org

> <mailto:owasp-mobile-top-1...@owasp.org>.

[Javi D R]

Mmm we are moving from the technical area to legal..

Taking a decission om what to do with a rooted device is one thing. The main story here is the ability to detect that the device has been manipulated and how to check it

To unsubscribe from this group and stop receiving emails from it, send an email to owasp-mobile-top-1...@owasp.org.

[Jason Axley]

Exactly. Just because a rooted device can be secured beyond when an OEM supports Android doesn't mean it is.  This is a perfect test-and-learn opportunity.  What does the real-life data actually say?  Do you see a correlation between rooted devices and higher fraud?  We had a minimal requirement to log the rooted status and any known potentially unwanted apps installed so we could mine the data for correlates.  We unfortunately make too many recommendations in infosec without all of the data - whether to use a control or not (or continue to use one) may take some measurement to understand the real risk and reduction.

We know for darned sure that devices without public jailbreaks are very difficult even for government contractors to compromise, so that appears to offer a very high degree of security assurance to applications if the platform has integrity and is patched.  The real question is how you can layer on enough checks that it will not be trivial for someone intent on bypassing them to hook and skip those checks to ascertain the platform integrity.  I think that this can be possible.  I've seen where it has exhausted some pen testers that had 2 weeks with some commercial products.  Nothing is impenetrable, so the question is how much time do you think you can reasonably buy (or need to buy)? Often you only have to do enough so the attacker picks on someone else.

You could suggest something like https://github.com/nowsecure/android-vts which has been open-sourced to check for various Androd platform vulns.   I was also interested in whether testing for known unpatched vulnerabilities would correlate more strongly than just root detection with fraud/risk?

Anyone know of actual studies of these released publicly?

-Jason