25

When I use my bank's Android application, the app notices that my phone is rooted and puts up a message with a big red "danger" symbol and a message saying "vulnerable device." I totally understand that they do this, because financial institutions always like to be on the safe side. The bank can then say "We warned you!" if someone with a rooted device gets their online banking compromised.

Now, I realize that my phone is less secure than a non-rooted Android device. I believe everyone will readily agree with this. (How much less will obviously depend on many things.)

But the thought I have is, is this really any different from using net banking in a browser running on a Windows desktop? I mean, Windows is also "rooted" in the sense that you have the ability to give "root" (administrative) privileges to any app you want?

So in the sense that they are complaining that my phone has the ability to give "root" permissions to apps, isn't this just like using online banking on a desktop OS that also has that ability?

What if I used online banking from a browser app on my phone? Would this be safer than the app?

Would using online banking in a browser app on my phone be any different from doing it on a browser on a Windows desktop? (Both are browsers running under a "rooted" OS.)

Fiksdal
  • 3,076
  • 3
  • 18
  • 29
  • 2
    A rooted phone just gives the user the ability to become superuser (and give that privilege to apps). The security level of the device now depends on that user's stupidity and vulnerability to social engineering (hey why don't you give that innocent-looking app root access?). – André Borie Apr 30 '16 at 09:42
  • 7
    @AndréBorie Yes. And from the bank's perspective, they can pretty much take for granted that some or many of their users are "stupid" (or lack knowledge, to be nicer). But since all Windows desktop systems also are "rooted", is the risk any different there? – Fiksdal Apr 30 '16 at 09:46
  • 5
    Also, FWIW, I've definitely used root access on my phone to **patch vulns would otherwise have made my device less secure**, and done it months before the official patches became available. So, I don't know about *your* phone, but mine is *more* secure because I rooted it, not less... – CBHacking Feb 20 '18 at 20:21

3 Answers3

21

It's All About the Security Model

We see reference to "Checking for jailbroken/rooted device" in nearly all Mobile Application Security Checklists (e.g OWASP). When comparing it to desktops or web browsers we have to keep in mind that they have different threat models.
For example on desktop machines when designing an application we already know that there are other applications that have administrator privileges.

To give you an example, the security model for operating systems like Windows or Linux doesn't prevent an application from accessing another application's directories or memory.

Now in mobile context, taking Android as an example, the operating system prevents applications from accessing each others' directories and root privilege bypasses this security control. So by rooting your device you are making a change in your device that may not be foreseen by the application developers and its risks may not be taken into consideration.

Now going back to OWASP's Mobile Security Project (Dangers of Jailbreaking/Rooting), rooting methods are categorized as follows:

  • Userland Exploits: jailbroken access is only obtained within the user layer. For instance, a user may have root access, but is not able to change the boot process. These exploits can be patched with a firmware update;
  • iBoot Exploit: jailbroken access to user level and boot process. iBoot exploits can be patched with a firmware update;
  • Bootrom Exploits: jailbroken access to user level and boot process. Bootrom exploits cannot be patched with a firmware update. Hardware update of bootrom required to patch in such cases;

And the risks are:

General Mobile

  1. Some jailbreaking methods leave SSH enabled with a well-known default password (e.g., alpine) that attackers can use for Command & Control;
  2. The entire file system of a jailbroken device is vulnerable to a malicious user inserting or extracting files. This vulnerability is exploited by many malware programs, including Droid Kung Fu, Droid Dream and Ikee. These attacks may also affect unlocked Windows Phone devices, depending on the achieved unlocking level;
  3. Credentials to sensitive applications, such as banking or corporate applications, can be stolen using key logging, sniffing or other malicious software and then transmitted via the internet connection.

iOS

  1. Applications on a jailbroken device run as root outside of the iOS sandbox. This can allow applications to access sensitive data contained in other apps or install malicious software negating sandboxing functionality;
  2. Jailbroken devices can allow a user to install and run self-signed applications. Since the apps do not go through the App Store, Apple does not review them. These apps may contain vulnerable or malicious code that can be used to exploit a device.

Android

  1. Android users that change the permissions on their device to grant root access to applications increase security exposure to malicious applications and potential application flaws;
  2. 3rd party Android application markets have been identified as hosting malicious applications with remote administrative (RAT) capabilities.

Non-technical Risks

  1. Software updates cannot be immediately applied because doing so would remove the jailbreak. This leaves the device vulnerable to known, unpatched software vulnerabilities;
  2. Users can be tricked into downloading malicious software. For example, malware commonly uses the following tactics to trick users into downloading software;
    Apps will often advertise that they provide additional functionality or remove ads from popular apps but also contain malicious code;
    Some apps will not have any malicious code as part of the initial version of the app but subsequent "Updates" will insert malicious code.

One can count countless risks for each platform ranging from web, mobile applications, desktop applications, etc. and comparing these platforms in terms of security is not trivial. It may be highly reliant on specific platforms (Android vs iOS, Windows vs Linux) and also reliant on users behaviors (Having a mobile device with lot's of junk applications vs having a mobile device only with known apps). In each context we try take measures in order to reduce our risks and once a platform becomes too insecure we may stop providing service on it (e.g telephone banking via landline phone or USSD).

Going back to your question about using your mobile phone's web browser vs using mobile banks native application, the risks depend on implementation of mobile banking application and the type of malware that may be present on your mobile phone.

Silverfox
  • 3,369
  • 2
  • 19
  • 39
  • 1
    Detailed answer, thanks. I think one of your points is that that browsers in Windows, as well as the bank's webapp there, are *designed* to run in a system where other applications have administrative privileges. Thus that browser and webapp may have built in defenses against *some* threats on such a platform. The Android app, on the other hand, may be, in terms of security, only designed to run on a non-rooted device. Was that one of your points, or did I misunderstand? – Fiksdal Apr 30 '16 at 10:46
  • 1
    @Fiksdal True, that's what I was trying to say, although you may find some exceptions to this, but ultimately mobile devices have some security controls that are not present on desktops and vice versa, and by rooting your device you're potentially bypassing some of these controls, and the mobile application is notifying you about this. (Even though these controls may not be present on desktops at all) – Silverfox Apr 30 '16 at 10:54
  • Alright, I'm glad I got that right. That part of your answer is very relevant in terms of OP. – Fiksdal Apr 30 '16 at 11:10
  • 1
    Can an app with only user-level access on either Windows or Android (or any OS?) really guard itself against another app which has root access? How would that work? Or is there some other side-effect to rooting you are referring to? – Alexander O'Mara Apr 30 '16 at 15:12
  • Also, rooted devices do not necessitate the inability to update the OS, it depends on the OS. For example, may Android users root and replace the OS with something like CyanogenMod. – Alexander O'Mara Apr 30 '16 at 15:14
  • 1
    @AlexanderO'Mara Applications can't defend themselves apart from techniques like data encryption, but what I meant was that the OS protects the applications with permissions it defines and then when you give root permission to a specific application, it can access anything and bypasses that security control that was put in place. – Silverfox Apr 30 '16 at 15:18
  • The OWASP Mobile Security Project has been trying to remove those requirements. There's no reason why a bank or any mobile app shouldn't run on a jailbroken or rooted device. They are more at-risk on a jailed or non-rooted device because all of the same reversing, subverting, and memory-dumping techniques still apply. – atdre May 01 '16 at 17:56
  • @atdre I can't see how the same techniques apply on a non-rooted device, even for simple tasks like pulling applications database via adb you'd need root permission, one of our other concerns here is malware having root access too. Rooted device has its risks which are different from non-rooted devices but I have to agree it's not as big of as a red flag as it may seem to be. It's threat is conditional. – Silverfox May 01 '16 at 18:14
  • @Silverfox: That's ok, it's a common misconception. See more thorough analysis of the repackaging problem, as well as the conceptual hooking techniques (applies to Android as well as iOS) here -- http://security.stackexchange.com/a/98326/140 -- but also here -- http://www.frida.re/docs/ios/#without-jailbreak -- and here -- http://www.frida.re/docs/android/ – atdre May 01 '16 at 21:39
  • 2
    `The security model for operating systems like Windows or Linux ... does prevent applications from accessing each others' memory.` This is actually **FALSE**! Assuming you're talking about same-user scenarios (say, a music player and an email client running as the same user, rather than under two different users), one process can read (and even write!) memory of another. For example, see Windows' [ReadProcessMemory](https://msdn.microsoft.com/en-us/library/windows/desktop/ms680553(v=vs.85).aspx). To prevent this, untrusted apps have to be sandboxed (as non-root mobile apps are). – CBHacking Feb 20 '18 at 20:28
  • @CBHacking you're right, I'll edit my post to reflect this. – Silverfox Feb 22 '18 at 15:55
  • @CBHacking I'm not sure about Windows, but Linux often prevents this with the ubiquitous Yama LSM. It modifies `ptrace` and related syscalls (like `process_vm_writev`) so they cannot be used on sibling processes, only on child processes. In the most strict mode, it prevents the calls from being made at all. **However**, even if this were not true, Android naturally runs each app with a different UID, which prevents a given application from interfering with another. – forest Feb 23 '18 at 04:42
  • -1 This answer is about as accurate as [dihydrogen monoxide warnings](https://en.wikipedia.org/wiki/Dihydrogen_monoxide_parody). All facts are true, but it completely misinforms anyone reading the answer about the riskiness of mobile root vs desktop root (or administrator or whatever). It also doesn't even mention normal rooting and only talks about using exploits made by some third party. – Luc Mar 29 '19 at 15:39
  • @Luc I'll be more than happy if you could edit the answer and apply your suggested fixes/improvements. More specifically, which part do you think misinforms the readers? – Silverfox Mar 29 '19 at 17:28
4

Applications in Android are assigned different UID/GIDs in the underlying Linux and are thus isolated from each other in that way. Contrast that to a standard desktop application where all programs run by the user typically have the same permissions (in the absence of AppArmor or SELinux configuration for Linux). Is Windows not similar? Browsers provide some sand-boxing capabilities but only from other browser-run code and even this environment is riddled with cross-site avenues for potential exploitation.

Rooting enables the user to authorize an arbitrary application to have elevated privileges. This certainly presents a threat and bothers the banks because they feel it is out of their control. But it is within the user's control. The important point is that the competency and actions of the user are always out of the bank's control. Presumably anyone who roots their phone is likely to have at least some elevated understanding of the risks and concomitant understanding of mitigation. So, sure, the bank doesn't know who else the user is sleeping with - with elevated privileges - or how savvy they are. On the other hand, rooting enables counter-measures that can enhance security. If the user is careless, rooting can leave them very exposed.

Even without root privilege, any application can present a display that pretends to be the banking application and bait the user into providing authentication credentials. How this is accomplished successfully is admittedly challenging but definitely possible for many potential victims.

I believe that the dogma that root makes a phone "insecure" - an ill-defined term - is misleading and banks should focus their attention on other matters.

FWIW, I use root, among other reasons, to configure iptables, because interestingly, stock Android does not allow me to selectively authorize applications for Internet access. And we can all guess what interests are served by that circumstance.

Bill Michaelson
  • 141
  • 2
  • 1
    "*Browsers provide some sand-boxing capabilities*" It is not clear from your answer, but mobile browsers are no different in that regard. Firefox on mobile is almost identical to Firefox on desktop. Right now, you answer sounds as though mobile needs that separation because there is no browser sandboxing. I also think you overestimate the "cross-site avenues for potential exploitation": for a ransom site, *maybe*, but for banking websites? Definitely not the case. Similarly with the rooting, you describe how it works on mobile, but on desktop a user can also give admin rights to any software. – Luc Mar 29 '19 at 15:29
  • 1
    Almost forgot to welcome you to the site! Your answer is accurate and now that I'm done reading I've upvoted; these were just some things I noticed while reading :). – Luc Mar 29 '19 at 15:31
  • Thanks, yeah, I suppose my response might induce some head-scratching. I sought to contrast the browser experience on a desktop with that of an Android native app, but you are of course correct in your observation about Firefox. In fact, it is why I sometimes prefer using a browser on Android rather than the custom apps that many service providers try to coerce users to use. – Bill Michaelson Apr 04 '19 at 16:58
  • Your last sentence holds the key point I was trying to make: Desktop users control which apps have elevated procedures, just as in the case of rooted Android. As to whether banking web sites are typically XSS vulnerable, I agree that it is less likely than other sites but I can indistinctly recall seeing a number of unnecessary references to third party web sites while using bank services, FWIW. – Bill Michaelson Apr 04 '19 at 17:20
2

I agree with the information provided by @Silverfox. Financial institutions certainly aim to reduce the risk of fraud by basing their security policy on a threat model which is unique to the targetted device.

Many online banking systems have adopted Multi-factor Authentication (MFA) to prove their user's identity. This means that an attacker who obtains your username/password combination is unable to access your account (it would require them to either obtain the verification code, or spoof/compromise a previously "trusted PC").

Privilege escalation allows the adversary to break the isolation and access any sensitive data. Since the phone is now a critical part of the user authentication scheme, a rooted device is a much greater risk to the financial firm since if it is compromised. For example, the malware can steal credentials from the banking app, or even obtain the SMS verification code which is sent as part of the MFA, deleting it immediately to hide the traces from the user.

However, one important thing to consider is that these runtime environment checks can often easily be bypassed. There are various methods and APIs for doing the check, but for example, many applications will roughly do this: check to see if the "su" binary exists, if so, then it is assumed that the device has root privileges. By trivially renaming "su", it is quite possible to bypass this type of check.

For better results, many modern Android applications will use something along the line of Google SafetyNet API to do remote attestation and check the device's compliance status. Additionally, there are third-party solutions under the umbrella of Mobile Device Management (MDM) applications, which are typically deployed by large enterprises who share the risks of their employees carrying sensitive data, for example having their work email app get compromised if a rooted device gets infected.

Amir
  • 29
  • 1
  • Good point about the device being used as a factor in multi-factor authentication. I think, however, that the question is if using _only_ the rooted device is more dangerous than using _only_ a Windows desktop. – S.L. Barth Feb 20 '18 at 14:17
  • 1
    @S.L.Barth, It sounds to me like he's implying that using a rooted device is indeed more dangerous than using a Windows desktop. The multi-factor authentication issue alone is huge. Also, having a rooted Android phone means that the pin/password/fingerprint/face recognition can trivially be bypassed if you ever get your phone stolen. A Windows desktop probably does have a similar software locking issue, but the possibility that you'll get your Windows desktop physically stolen is also much lower. And even if your computer gets stolen, you won't lose your second factor for authentication. – Stephan Branczyk Feb 20 '18 at 14:57
  • 1
    "*the phone is now a critical part of the user authentication scheme*" Right, but you know what's more critical than a second login factor? The application itself. If your desktop is pwned, it's game over regardless of any second factor. So if you have admin permissions on your desktop already, what's the big deal with also having admin permissions on your phone? "*malware can [obtain] the SMS verification code*" You don't need root for that, that permission can be given to any app. This answer does not give a single argument why mobile admins are more dangerous than Windows admins. – Luc Mar 29 '19 at 15:44