Hacker News Reader

Comment by Daniel_sk | Hacker News Reader

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.

View on HN

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...

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.

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.

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

> 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.

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

i imagine keyboard apps are another doozy

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.

Reply on news.ycombinator.com