An honest yet pointed question: what permissions does your bank's 2FA app request? My guess is, as a bank, they're doing the right thing. However, permissions overreach is a real issue that even "legitimate" apps are exploiting to vacuum as much user data as possible.
What solution would you recommend? Strangely, those are all banks I have never heard of. My employer had no search results on that site. I guess they aren't doing everything wrong.
> My guess is, as a bank, they're doing the right thing.
In my country, banks used to mandate use of a "security module". I decided to see what this thing was doing and caught it intercepting every single network connection.
Exactly. I would never ever install a bank's app on my phone.
Aside from almost certainly being closed-source it was probably developed by the cheapest off-shore bidder for the project. But who knows? That's the point. They won't tell you anything because they "take security very seriously."
Right now, Google Play is the wild west. The app store admins are far too lenient when it comes to things like this. No vetting of apps. No inspection of source code for red flags. And the sketchy apps can be rated five stars by a bunch of bots artificially inflating its popularity. Clown show.
I know the App Store isn't immune but I'm having a hard time remembering a time when an app on iOS was reaching into other app's data or doing something like a keylogger system-wide. Often it's things like "It's listening to you, grabbing your clipboard, etc". While far from "good" or "ok", it's a far cry from some random app being able to steal my banking session.
That happened once, it's not like every few months or year where hear of a new instance of something like that and it's still not reaching outside itself into other apps as far as I know. So yeah, it could steal the banking login info of the banking app it managed to get injected into but it's not like "iFart" can reach in and grab your bank creds.
No doubt, I'm not downplaying the severity of the xcode inject issue. I'm just saying it has only happened once before that we know of and it still isn't a "breakout"/"escape"-type exploit that we see so often in Android-land.
People who constantly say that [large company] does nothing to block malicious/spam content are underestimating how motivated the bad actors are and how many there. And when it comes to measures to prevent this stuff, there's a balancing act to be done. Because things that make it harder for malicious actors also makes it harder for everyone else and will increase the false positive rate.
I would love to encounter these lenient admins/moderators. We just seem to be getting our app at work suspended all the time for the most random things. One time, the whole app was suspended and we needed to create a new app identifier in the play store, because no one was replying to our case :/ I agree that it is a true clown show.
I guess it’s like SEO: the bad actors are the ones motivated to invest in adapting while “normal people” will have to hire a specialist or risk suffering the consequences
Not just google play. Big tech companies are the greatest gift for scammers ever. People have made so much money scamming users of these sites, whether twitter ,Facebook, YouTube, apps... anything. The reason has to do with how content is moderated. If you spam Reddit, the admins will handle it almost as soon as it is reported and will come down really hard, but the lag time between when Google is aware of of a threat and then acts and when the threat goes live, is long enough for scammers to make a lot of money. Paying for moderation is expansive. Apple is willing to make the large investment in quality control to protect its users, but most companies either outsource or automate as much as possible, so a lot of garbage gets through.
Would it be unreasonable to answer that with "F-Droid"?
I guess the implicit (and reasonable) assumptions of your question are that the source code is fully reviewed by the people running the app store, and it is a "store" in the sense that people routinely pay money for the apps available there.
Half of the "extraordinary number and breadth of system permissions it required" listed in the article seem benign
* android.permission.INTERNET
* android.permission.FOREGROUND_SERVICE
* android.permission.RECEIVE_BOOT_COMPLETED
* android.permission.WAKE_LOCK
The rest are fishy, but not really anything that facilitates a virus.
* android.permission.QUERY_ALL_PACKAGES - allows you to enumerate what apps are installed
* android.permission.SYSTEM_ALERT_WINDOW - google says it's used for overlays. for a TOTP app this seems plausible for stuff like showing the code while you're entering it into the app that's requesting it
* android.permission.REQUEST_INSTALL_PACKAGES - I'm not even sure what this permission does. You can install an apk from chrome/firefox, which doesn't have this permission.
* android.permission.DISABLE_KEYGUARD - disables lockscreen. unless the attacker also has physical access, this is pointless.
> You can install an apk from chrome/firefox, which doesn't have this permission.
I thought they just ask the OS to open the file, and when it happens to be a .apk file, Android brings up the package installer. Is that not how they do it?
Cloaking is real but is itself a fun signal. Most apps (outside of the chinese market) don't use cloaking so observing behavior that seems like cloaking can be strong signal that an app is malicious even if you cannot determine what the behavior actually is.
If "requests a lot of permissions" was sufficient to get apps taken off the Play store then we'd see way more "Help, Google took down my app and I'm mad" posts on HN, even if you did is based on comparisons to other same-category apps.
The permission model is messy but made much worse by the volume of SDK code that is actually in most apps today. SDKs ship as big blobs with their own manifests and if you build in the SDK then you are collecting their permissions even if you aren't using the code that needs it. And given that virtually zero consumers choose apps based on permissions, there is little incentive to pare down the list to the minimum needed.
android.permission.RECEIVE_BOOT_COMPLETED is really the only thing suspicious in that list since this is used for a few more old school malicious behaviors. Complaining about android.permission.INTERNET is frankly hilarious since that permission no longer does anything (every app has access to the internet).
Is that true? I was under the impression that this changed years ago since virtually every app requested it anyway.
Apps could always send content over the internet by sending an intent to a browser with relevant GET parameters to whatever server is consuming the data.
«To perform network operations in your application, your manifest must include the following permissions: ... .INTERNET and ... .ACCESS_NETWORK_STATE»
Though yes, applications (with particular regard to those that did not open network sockets internally) could use intents to have other applications perform network operations.
Anti-virus is a scam. Same as anti cheat and DRM. It's a bandaid that only works for already known and databased attacks. You can simply modify how the virus is packaged and have it no longer detected.
The true solution really is app review in the case of mobile apps. Google has the power and money, they just don't care.
Let's definitely not put the name of the app in the title, so people are forced to visit our shitty site loaded with dozens of tracking domains and scripts.
It sucks to see your open source work being abused like this, and there's seemingly nothing we can do about it.
Every now and then I scour the play store to see if I can find any Aegis clones. We've reported a couple that didn't have a link to the source code and/or were linking proprietary libraries (as per our license), but they're still up. Of course, those cases aren't as bad as this one where actual malware was included, but it's pretty telling about the state of the Google Play Store.
Either way Google should be contacting the relevant police in the country the owner of the account lives. A developer account is not free so someone had to pay, if the credit card was stolen then also report that to Visa etc.
If Google doesn't have enough information then maybe they should require a government ID to get a developer account. I mean Facebook requires ID for some users.
I looked into using this app a while back because I liked the UI. But Im a bit hesitant because the app is completely free (and no ads) just wonder what the incentive is for them? Anyone have any idea on who made this?
> Vultur is among the first Android threats to record a device screen whenever one of the targeted apps is opened. Vultur uses a real implementation of the VNC screen-sharing application to mirror the screen of the infected device to an attacker-controlled server
> The typical modus operandi for Android-based bank-fraud malware is to superimpose a window on top of the login screen presented by a targeted app. The “overlay,” as such windows are usually called, appears identical to the user interface of the banking app, giving victims the impression they’re entering their credentials into a trusted piece of software. Attackers then harvest the credentials, enter them into the app running on a different device, and withdraw money
(Also: some disable sandboxing through rooting - yet do not use the device consistently)
73 comments
[ 2.7 ms ] story [ 142 ms ] threadBanks can and will do everything wrong.
* https://reports.exodus-privacy.eu.org/en/reports/fr.creditag...
* https://reports.exodus-privacy.eu.org/en/reports/fr.lcl.andr...
* https://reports.exodus-privacy.eu.org/en/reports/com.caissee...
* https://reports.exodus-privacy.eu.org/en/reports/fr.banquepo...
* https://reports.exodus-privacy.eu.org/en/reports/com.fullsix...
In my country, banks used to mandate use of a "security module". I decided to see what this thing was doing and caught it intercepting every single network connection.
Do you supply source and repeatable build info?
Aside from almost certainly being closed-source it was probably developed by the cheapest off-shore bidder for the project. But who knows? That's the point. They won't tell you anything because they "take security very seriously."
This is not true, apps are reviewed now. IMO this is theater and useless, though.
> No inspection of source code for red flags.
This is also untrue, Google scans apps for known malware. Not sure how this was missed, though.
> And the sketchy apps can be rated five stars by a bunch of bots artificially inflating its popularity.
This is true. It's also a problem on the App Store and similar sites.
The App Store is not immune to these issues, either:
https://twitter.com/jonathandata1/status/1486458526767661060
It usually starts with xcode injecting malware, since the building process is so opaque and undocumented, they get away with it.
That happened once, it's not like every few months or year where hear of a new instance of something like that and it's still not reaching outside itself into other apps as far as I know. So yeah, it could steal the banking login info of the banking app it managed to get injected into but it's not like "iFart" can reach in and grab your bank creds.
Relevant subtweet: https://twitter.com/0xabad1dea/status/1487093037352333317
People have all the time problems publishing for all the stupid reasons.
At the same time people publishing malware or spyware are not cought.
I guess the implicit (and reasonable) assumptions of your question are that the source code is fully reviewed by the people running the app store, and it is a "store" in the sense that people routinely pay money for the apps available there.
* android.permission.INTERNET
* android.permission.FOREGROUND_SERVICE
* android.permission.RECEIVE_BOOT_COMPLETED
* android.permission.WAKE_LOCK
The rest are fishy, but not really anything that facilitates a virus.
* android.permission.QUERY_ALL_PACKAGES - allows you to enumerate what apps are installed
* android.permission.SYSTEM_ALERT_WINDOW - google says it's used for overlays. for a TOTP app this seems plausible for stuff like showing the code while you're entering it into the app that's requesting it
* android.permission.REQUEST_INSTALL_PACKAGES - I'm not even sure what this permission does. You can install an apk from chrome/firefox, which doesn't have this permission.
* android.permission.DISABLE_KEYGUARD - disables lockscreen. unless the attacker also has physical access, this is pointless.
I thought they just ask the OS to open the file, and when it happens to be a .apk file, Android brings up the package installer. Is that not how they do it?
Also if there is any way to access even the slightest NSFW content and the app is not Chrome then forget about getting it listed.
it is trivially easy to evade scanning
-obfuscation
-renaming
-a long web of external obfuscated files
-a blank or unregistered domain which is activated and calls a script as soon as it goes live (this is the most effective way)
The permission model is messy but made much worse by the volume of SDK code that is actually in most apps today. SDKs ship as big blobs with their own manifests and if you build in the SDK then you are collecting their permissions even if you aren't using the code that needs it. And given that virtually zero consumers choose apps based on permissions, there is little incentive to pare down the list to the minimum needed.
android.permission.RECEIVE_BOOT_COMPLETED is really the only thing suspicious in that list since this is used for a few more old school malicious behaviors. Complaining about android.permission.INTERNET is frankly hilarious since that permission no longer does anything (every app has access to the internet).
This is incorrect. If an app doesn't specify this permission in its manifest, it cannot access the internet.
Apps could always send content over the internet by sending an intent to a browser with relevant GET parameters to whatever server is consuming the data.
«To perform network operations in your application, your manifest must include the following permissions: ... .INTERNET and ... .ACCESS_NETWORK_STATE»
Though yes, applications (with particular regard to those that did not open network sockets internally) could use intents to have other applications perform network operations.
The true solution really is app review in the case of mobile apps. Google has the power and money, they just don't care.
Most of the commercial industry is, but don't forget about ClamAV[1] and other open-source projects.
[1] https://www.clamav.net/
I wasn't attempting to discuss its quality but oppose slapping "scam" label on every AV there is.
Every now and then I scour the play store to see if I can find any Aegis clones. We've reported a couple that didn't have a link to the source code and/or were linking proprietary libraries (as per our license), but they're still up. Of course, those cases aren't as bad as this one where actual malware was included, but it's pretty telling about the state of the Google Play Store.
If Google doesn't have enough information then maybe they should require a government ID to get a developer account. I mean Facebook requires ID for some users.
With all those permissions it demands, people must have reported it earlier.
I know they all spy on me, but I do trust that they won't steal my bank credentials and drain my accounts.
Another bit of advice, never do banking on your phone.
https://arstechnica.com/gadgets/2021/07/new-bank-fraud-malwa...
> Vultur is among the first Android threats to record a device screen whenever one of the targeted apps is opened. Vultur uses a real implementation of the VNC screen-sharing application to mirror the screen of the infected device to an attacker-controlled server
> The typical modus operandi for Android-based bank-fraud malware is to superimpose a window on top of the login screen presented by a targeted app. The “overlay,” as such windows are usually called, appears identical to the user interface of the banking app, giving victims the impression they’re entering their credentials into a trusted piece of software. Attackers then harvest the credentials, enter them into the app running on a different device, and withdraw money
(Also: some disable sandboxing through rooting - yet do not use the device consistently)