Hacker News Reader

Comment by oedmarap | Hacker News Reader

> Meanwhile, temporary exceptions will be granted to dedicated banking and digital wallet apps so that they can “obtain broad visibility into installed apps solely for security based purposes.”

I'm sorry but why does a banking app need to see a list of system-wide packages? And for what security-purpose? If all apps were tightly sandboxed in the first place then this wouldn't be a problem that requires edge-case solutions.

Either way, based on the same quoted paragraph, my prediction is that Facebook will now roll out a dedicated wallet app; along with regular wallet functionality it will gleefully take advantage of this exact loophole.

View on HN

Banking apps sometimes integrate 3rd party AV / threat detection SDKs (there are several available, e.g. https://www.wultra.com/malwarelytics which is part of a bigger banking security SDK solution). Sandboxing isn't the only problem on Android - a lot of malware is using Accessibility to control the device and read what's on your screen. Then there are overlays that can be drawn over your app (e.g. display a fake login over your app). Access to notification content. Reading SMS content (2FA). Different combinations of other permissions, device manager rights etc. Or even simple attacks like launching a fake app just when you launch the real one (phishing). Google is trying to limit a lot of these permissions, at least from apps installed from Google Play but so far they are still pretty widespread with malware hidden on Google Play targeting banking apps.

> Banking apps sometimes integrate 3rd party AV / threat detection SDKs

Do they do the same thing on iOS?

I don't think so - or if they do, then the functionality won't be very effective. A lot of the most common attack vectors have never existed in iOS. Applications on iOS can't draw over other apps, you can't implement your own accessibility service, you can't launch apps from the background without user interaction, you can't install apps outside of the App Store, you can't run a service in the background for unlimited time, you can't implement your own keyboard (key logger), or read SMS messages, notifications, system events and a lot of other things have never been accessible to developers on iOS. I haven't heard about banking malware on iOS. But on Android you can find hundreds of examples and even right now there are several circulating on Google Play. The openness of Android OS has advantages and disadvantages, but Google has been heavily limiting most of these options recently.

i imagine keyboard apps are another doozy

So Google should make new app category something like "Very sandboxed app", rather than this.

As far I know they more or less stop at detecting if the device has been jailbroken or not and if it has, refusing to function.

3rd party AV sdks? This reeks of snake oil. They should just stop treating the device as a hardware security anchor. And how is it still ok that most android phones in the wild do not get security upgrades, let alone timely ones?

It is snake oil. But they want it and this makes it tricky for Google.

Fuck 'em?

The tricky part IMHO is that with safetynet google is selling snake oil themselves. If they are claiming that security does not count as fair use to spy on the userfor others, ... .As much as I like security awareness. In the end it means patronizing users in order to control the ecosystem. The problem with banking and google is that we cannot escape this ecosystem without losing a lot of commodity. Why not do it like Apple and put annoying popups before each install process if apps want spying permissions. The only reason can be that google wants us to not be aware...

I don't believe this is the only reason. If it were, they would be blocking logins through mobile web browsers since there's no JavaScript API that dumps the list of installed apps. All those same attack vectors could exist on top of the users web browser as far as I know.

They don't have to block the login completely but they may treat it as less trusted and require additional authorization for, say, an outgoing wire transfer. Of course, this assumes banks are doing actual risk modeling not just security theater.

Can't they do this for apps too? Treat them as "less trusted", instead of doing all that bullshit with shipping bundled scanners, and the insane policies that make it impossible for me to take a screenshot of transaction details in the app...

(Yes, I know. My role as a user isn't to have opinions - it's to dutifully enjoy the software as-is, and visit the "offers" section on a regular basis.)

A less trusted app is annoying to use.

But it would also be more useful.

My supermarket's loyalty app refuses to run on rooted devices, I imagine they are using something like this to detect if the device is rooted (e.g. looking for Magisk). It makes no sense, because all it does is show what offers are available that week (which you can also see on their website) and provide the same QR code that is on the physical card. I imagine some PM at whatever agency they used decided they wanted to make it secure (and upsell that to the client), and installed some nonsense SDK like this.

My bank's app have no issues with my phone being rooted :-) Fortunately Magisk Hide fixes it.

Brute forcing coupon and gift card codes and selling them is a big business.

Big business means it would've been defeated or just completely worked around - truth is that if you're doing this at scale you'd just reverse engineer how the application talks to the backend and replicate that in your software.

Just like DRM, it inconveniences legitimate use while doing little to defend against malicious use.

And attackers going after banking apps to perform credential stuffing attacks is one of the largest attack types currently.

Google already allows online banking apps to block screenshot functionality, which is in my opinion total bullshit. The owner/user of a device should always be able to take a screenshot if they want. At least every bank has a market based need to allow regular browsers to sign in to online banking, to support desktop clients, so one can just ignore the provided bank's app if you want.

All apps can do this as far as I know. Firefox for Android has an option to disable screenshots in private tabs.

It's to prevent malicious applications taking a screenshot of sensitive information. I've seen other apps doing this on, for example, credit card info entry screens.

Then limit to sensitive information, not every screen.

Then prevent malicious apps from doing that without preventing the user.

I wonder if they’re “finger printing” the device to determine whether a login is likely to be legitimate or not?

Couldn't they just generate a unique fingerprint then?

It wasn't a banking app, but I recently came across the first app I've seen that, in addition to SafetyNet, also checked if the Magisk Manager app was installed to try to detect if the phone was rooted. I wouldn't be surprised if it was for this purpose.

If known spyware/malware applications are found, the banking app should not run for protection of the user.

Computers are compromised all the time and but so far as I know banking at insertbankhere.com doesn't involve giving your browser tab root privileges on your machine in order to run its own antivirus. It's an improper separation of concerns.

Your bank also doesn't concern itself with the type of locks on your door or your car alarm. Just because something gives someone a handle on matters like the ability to see what apps are installed on your device doesn't mean its appropriate to use it.

Not allowing the bank app inappropriate access to your device means they aren't tempted to leak or misuse it.

Reply on news.ycombinator.com