Bank complains about rooted Android. Is it really any worse than a Windows desktop?

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.

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.

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.