
Droppers Is How Android Malware Keeps Sneaking into the Play Store - 0xbxd
https://www.bleepingcomputer.com/news/security/droppers-is-how-android-malware-keeps-sneaking-into-the-play-store/
======
davidhyde
I don't have an Android phone so excuse my nativity but does Android allow an
app to request more permissions AFTER it has already been installed and
requested the original perms? If so, why? Additionally, if users cannot deny
individual perms then they will have to make an all-or-nothing-decision about
an app.

Why not just allow them to disable specific perms on install and provide
stubbed generic data to the app if it uses those perms?

~~~
IChrisI
Requesting permissions for everything your app can possibly do at install time
makes apps look scary. Here's an example.

Imaging a messaging app. It needs permission to read and write to your text
messages - not so bad.

Maybe there's a feature where you can quick-reply from the message
notification. Now it needs permission to draw over other apps.

Maybe it's smart enough to not DING! during a phone call. Now it needs
permission to "make and manage phone calls".

Maybe there's a feature where it suggests a "here's my location" response when
somebody texts you "where are you?". Now it needs permission to access your
location.

Contact integration? Camera integration? Access storage? These are all things
that a messaging app might reasonably want to do. But seeing a big list of
permissions, including things like "draw over other apps" and "make and manage
phone calls" is scary to an end user. Especially for an app that's only
supposed to be handling SMS.

~~~
amelius
I really hate it when I need to send a single file or photo, an app suddenly
"needs access to my filesystem" and I have to grant that access.

OSes should allow me to create a sandbox for an app, so I can grant them
access (and the app will not "break"), while still being secure.

~~~
scarface74
That shows the larger problem with Android. An app shouldn’t need access to
your _file system_ to send a photo. It should bring up a system provided photo
picker and once the user chooses a set of files, the OS should give it a read
only access to the file.

If a photo management app needs access to your photos, you should be able to
give it access to your photo library.

~~~
amelius
I don't think that's the solution because apps may easily "bribe" the user
into giving the app more access than it strictly needs. The bribing goes like:
"sorry, but if you don't give me full access, then you can't use me". Simple,
but very effective in most cases.

A better solution (imho) is to make the app think it has access, while in
reality its access is limited to a sandbox.

~~~
scarface74
That’s still a problem with the OS. Why does any app need access to _the_ file
system instead of the users photo library or access to certain files in a
document store where the app only has read access to files that the user
explicitly chooses in a system provided file picker or can write files to a
location that the user chooses?

------
isolli
Naive question: why is Apple iOS not affected by this?

~~~
gnomewascool
iOS bans loading external executable code.

> 2.5.2 Apps should be self-contained in their bundles, and may not read or
> write data outside the designated container area, nor may they download,
> install, or execute code which introduces or changes features or
> functionality of the app, including other apps. Educational apps designed to
> teach, develop, or allow students to test executable code may, in limited
> circumstances, download code provided that such code is not used for other
> purposes. Such apps must make the source code provided by the Application
> completely viewable and editable by the user.

[https://developer.apple.com/app-
store/review/guidelines/#sof...](https://developer.apple.com/app-
store/review/guidelines/#software-requirements)

(Edit: obviously the ban is via reviewing apps in the store, not on the
software level.)

~~~
pilif
_> obviously the ban is via reviewing apps in the store, not on the software
level_

it's also on the software level. If you are an app and want to mark parts of
your memory as executable, you need a special entitlement that requires a
signature from Apple. Only a very small amount of OS-bundled apps (Safari for
example) and no third-party app have this entitlement.

This is a reason why for a long time web-views embedded into apps couldn't
make use of JIT compiled JavaScript: Because the web view was loaded in-
process with your app, there was no way to execute any of the compiled code.

Only with WKWebView this was fixed by running the webview in a secondary
process that has the necessary entitlements and then rendering the view inside
of your process. Getting there took Apple quite some time though.

Only static code loaded from disk is marked executable, but that's not
writable in memory and it's only loaded into memory when it has a valid code
signature signed by Apple.

So unless you manage to get Apple to sign your dynamically loaded payload,
even if you sneak the functionality past app-review, there's no way to execute
it.

------
amaccuish
I don't get why this isn't blocked. If you're updating executable code, you
should have to do it via Google Play. If it's just resources, sure, go ahead,
but code?

~~~
jessaustin
If the app is structured as an interpreter running scripts, it seems easy to
deliver another script. On other platforms (not sure about Android) similar
tricks can be played with compiled libs.

~~~
cornholio
Clearly, a remote controlled interpreter should not pass the Google Play
verification, but I understand how detecting it can be a hard problem.

~~~
KMag
Well, enumerating all program states is a superset of the halting problem.
False positives, false negatives, and sometimes taking an infinite amount of
time to get an answer: choose at least one. (Technically only true if the
phone had an infinite amount of memory, but gigabytes of memory are enough to
craft an input that would take well beyond the heat death of the universe to
get an answer.)

In other words, even if you had some algorithm could somehow look at a program
state and with 100% accuracy determine if that state was the start of an
interpreter main loop, there would be at least one program where you couldn't
be certain that you'd run your algorithm on every program state.

~~~
cornholio
I stopped myself from typing "Halting problem" because essentially, antivirus
software should not exist for the same reasons. Yet antiviruses clearly work -
it's the entire premise of the article that Android is more vulnerable to
droppers than classic computers running antiviruses.

So the same techniques used by antiviruses, be it heuristics, signatures of
known interpreters and droppers, simulated execution could be used by app
stores to drastically reduce bad actors. The fundamental weakness will always
be there for advanced, unique malware.

~~~
jessaustin
AV itself is much less effective than many people believe. That's true in
general, and this case is no exception. The conclusion of TFA:

 _" Interestingly enough, we have also observed that most AV's also failed in
detecting the dropper campaigns (sometimes for years), meaning that some
awareness needs to be raised on the topic,"_

------
a_c
I imagine the malware distribution situation is much more prevalent in markets
where google's existence is nil. Would love to know how, if any, app is
reviewed in such markets (e.g china?)

------
sharcerer
Can somebody tell whether this happens on iOS/macOS ? Though, I am an Android
user but I would like to know.

~~~
ccnafr
Rarely, and malware devs must go through various loops to load a third-party-
hosted app/code on a device

~~~
sharcerer
Though, the report of apps which dupe users have been there for iOS too,much
less, probably due to various factors like: low % marketshare, better vetting
process as you said. How is the app-uploading mechanism different for iOS,
Android? Is it too do with the fact that Android has a more open system.

------
theweb1
Seems Apple ios is still the best for now, Android is seriously fu __ed up
with less security, gosh!

