Some Security is Better Than None

You can feel for it (it is grooved and next to the camera which may also be grooved) and it’s not that much harder once you get used to holding the phone, but I’d say the thumb is more naturally inclined to bend on the x-plane to hit the sensor? Maybe just me being clumsy.

@simonb I wonder how much of that weighting is because the market does favour Samsung, OnePlus, Pixel or just because Monzo is techy? I wouldn’t be surprised if it was 100% in two more years, now I look at how many cheap phones have fingerprint now.

1 Like

You cannot draw over (correctly configured) banking apps

Trust me, with superuser privileges, you can. If you are an Android user and happy to fork over your legacy bank balances I can prove it to you, just leave me your phone for a few minutes. :smiling_imp:

In fact you don’t even need to draw over other apps, if you’ve got superuser privileges you can steal the credentials directly out of the apps’ memory.

The fact that this particular malware (which I took as an example) goes after the low hanging fruit and doesn’t do a good job doesn’t mean it isn’t possible.

1 Like

Are you talking device administrator or root? Because it’s a hated fact that my legacy bank app won’t work if the device is rooted, and they actively search and block workarounds.

https://www.reddit.com/r/Android/comments/4yoq63/running_barclays_app_on_rooted_android_using/

Edit: Not saying it’s impossible, but this is one multiple posts on the web trying to get the app to work

1 Like

I’m mainly talking about root, though I’m pretty sure some damage is possible by being a device administrator, however that will no doubt be logged and apps can detect that.

As a malware developer I will actively search (and find) a workaround which will have the time to do plenty of damage before they figure it out (if they ever do so) and block it. That stupid restriction of theirs is doing more to hurt legitimate usage (power users with rooted devices) than malicious use.

Presumably their root detection looks at user space tools like sudo/su and leftovers from consumer-grade root programs… what if the malware uses its own rooting method (instead of using an off the shelf one) and only leaves the bare minimum for the malware to function (simply embedding itself into an important shared library or even the kernel itself)? I’m willing to bet a compromised kernel will bypass any and all “root detection” methods. :wink:

Just looked at that post and seems like I’m right:

Barclays app uses a native library to detect root by sending a request to escalate to root (triggering SuperSU, etc.) and seeing the response, and by looking in the filesystem for /system/xbin/su and its variants.

Wouldn’t prevent any custom malware that uses a root exploit to install itself without installing the su & sudo binaries. Just a joke really, this harms legitimate usage but any malware developer worth their salt can bypass this in 5 minutes. :joy:

1 Like

If you’re going that far… as far as I know, GCHQ and MI5 are not after me? :laughing:

But the crooks will happily use such a method if it gives them good $$$. The fact that most malware out there is garbage and does nothing more than display ads on your lookscreen doesn’t mean good malware doesn’t exist. :wink:

1 Like

A compromised kernel will fail secure boot unless it’s OEM unlocked. You can’t do that without getting into the phone - and switching that option on requires extra verification.

Far easier if you get that kind of access to simply compromise someone’s email account.

2 Likes

A compromised kernel will fail secure boot unless it’s OEM unlocked. You can’t do that without getting into the phone

We’re assuming an attacker with physical access here, so it should be doable on most phones, but even if the kernel can’t be compromised and you still manage to get root you can put your malware in a shared library loaded by most system components; as far as I know Android (and Linux in general) has no way of maintaining a chain of trusted binaries like Apple and Windows can, so a compromised shared library will work just fine.

Far easier if you get that kind of access to simply compromise someone’s email account.

Why only go after the email if you can go after everything? :smiling_imp:

The point being it’s not really doable even with physical access. The phone is protected against that. If it’s not unlocked and you somehow manage to modify the system partition it’ll simply fail to boot - that rules out being able to get root.

So you need to unlock the bootloader first… but that requires changing a setting in developer options that’s protected by a passcode.

So to compromise a device you’d not only have to have the device but their security information and fingerprints too. Or you get really sophisticated and start removing chips from the board (even that’s not trivial as the data is all encrypted using keys in the secure element).

A modern mobile phone is hardened against physical attack precisely because they’re used to hold financial data.

that requires changing a setting in developer options that’s protected by a passcode

We assume there is no passcode or that the attacker knows it, otherwise we wouldn’t be having this discussion at all - that’s the whole point I’m trying to make, the main security should be protected by your phone PIN, and if that is compromised then all bets are off.

1 Like

Uhh… no that’s moving the goalposts.

You said:

If you are an Android user and happy to fork over your legacy bank balances I can prove it to you, just leave me your phone for a few minutes. :smiling_imp:

I’m saying for the vast majority of users that’s simply untrue. Unless the user has already compromised the device (by for example running an unlocked bootloader or rooting it themselves) you won’t get anywhere.

As soon as you assume the attacker knows all the security, you might as well say my house isn’t secure because you can assume the attacker has my keys and alarm codes. It’s not a sensible threat model.

I’m saying for the vast majority of users that’s simply untrue. Unless the user has already compromised the device (by for example running an unlocked bootloader or rooting it themselves) you won’t get anywhere.

Wouldn’t really count on that either. The vast majority are running an outdated Android version and I’m sure there are some vulnerabilities in there that would allow an attacker to get in via USB. To be fair, even a system-wide passcode wouldn’t protect against that though.

so if a system-wide passcode does not provide total protection the addition of an app passcode would add an extra layer of protection?

Not really, as the system-level exploit would allow you complete control over the device, so you’d be able to install malware; no different from what I explained above.

3 Likes

Barclay’s doesn’t just block rooted devices, but also non-rooted OSes they don’t like.

1 Like

Non-rooted devices. The OS will just be Android, I assume. But yes, I’ve had that happen to me (a Moto with the intel chip, app side-loaded fine {back in the days I was counting pennies daily, before anyone jumps to point out the security risk}).

I have one of these high end Samsung but I dont use the fingerprint due to it’s terrible positioning next to the camera lens.

1 Like

You may be compelled to do so with Monzo as while they plan to introduce a fingertip lock for technical reasons (i.e. they say it is hard work) they do not plan an alternative, and hope demand for it will die off as more users replace their phones with newer models including this hardware. Accessibility issues for those unable to use this technology due to medical conditions may not be being addressed, we will have to wait and see.

1 Like

I don’t see how it doesn’t fall back on the phone unlock code if fingerprint login doesn’t work. I can’t unlock the app with gloves on for example. I can’t think of any app that doesn’t have a fall back, I think it should be standard to go for fingerprint with fallback of phone unlock code

1 Like

it looks (from some of their comments) that it does not have fallback to an alternative within their app, so if it falls back to relying on the OS if no screenlock is enabled with say a PIN then it won’t fallback to anything. You would have to enable an OS based PIN which would protect every app, rather than have PIN protection for just that app.