
Cloak and dagger – a new kind of attacks for Android - elsombrero
http://cloak-and-dagger.org/
======
izacus
Note that Android O now clearly shows a warning when an app is rendering an
overlay - probably the reason why the issues were marked wontfix.

As usual, getting the fix on the older versions is a whole different story.

The other Google failing here is the whole permission thing - since 6.0
Android apps need to ask for permissions for drawing over other app. However,
for some really baffling reason Google still lets us publish APKs that target
API below 6.0, which automatically triggers fallback mode which grants
permissions at install time. Why I have no idea.

~~~
retox
Not everyone is using android >6, or am I missing something?

~~~
sturmen
Android applications take 2 SDK versions into account: 'target SDK' and
'minimum sdk'. The target value allows you to use APIs up to that version but
also uses that version's toolchain, thereby enforcing any behavior changes or
new requirements (in a backwards compatible fashion). Minimum SDK is just
that: the absolute lowest Android version the app will run on.

A brand new blank slate app will be configured with a target SDK of 25 (latest
Nougat) and a minimum SDK of 14 (Ice Cream Sandwich iirc). This means it will
run on ancient devices but also be able to use the latest Nougat APIs (when
available.) However, because it is targeting 23+ (6.0), it will force you to
use runtime permission prompts and stuff.

------
tptacek
This seems like a refinement of "tap-jacking", which is a pretty well-known UI
redressing attack for Android apps, and works in a way that is somewhat
similar to "clickjacking" on web pages --- an invisible frame is rendered on
top of the application that captures inputs (as opposed to an opaque frame
that obscures the legitimate application and tricks you into interacting with
it).

The big limitation on these attacks is that you have to install a malicious
application _and then_ trick people into getting to a situation where the
application can interact with a specific target; that's something that should
be straightforward for app stores to screen for.

~~~
ggggtez
I agree. Once you've got the malicious app, it's already too late. As they
point out, Facebook could arguably tap jack all your passwords too. Known
issue, so pretending it's a new issue by giving it a new name is silly.

~~~
tutufan
I'm less concerned with whether it's original and more with whether it's a
serious silent attack on my phone (yes?). And whether Google intends to fix
the problem (no?).

------
etjossem
From the section marked "Responsible Disclosure":

> Current — All the attacks discussed by this work are still practical, even
> with latest version of Android (Android 7.1.2, with security patches of May
> 5th installed).

Honest question - does HN feel this is actually responsible disclosure? A
large number of Android devices seem to be vulnerable to the issue, and the
whitepaper includes exploit details. Is the intent to force Google to pay
attention to the issue?

~~~
tptacek
There's no such thing as "responsible disclosure".

The term is, quite literally, an Orwellian scheme to promote vendor interests
as if they were naturally shared by those of researchers and users. A more
neutral term is "coordinated disclosure". We can discuss how carefully
coordinated things are, but there is --- to say the least --- a lot of
disagreement about how much responsibility researchers have for coordinating
this kind of stuff with vendors who shouldn't be shipping vulnerable code in
the first place.

A warning in advance, though: this is a pretty boring discussion to be having
on a thread about a new kind of vulnerability. Better that we should be
talking about the merits of the paper itself.

~~~
rtpg
I don't get this logic that much.

Your neighbor left their door unlocked. You have their phone number. You can
call them to tell them first, and make a funny FB post about the event
afterwards. Or you could just post about it on FB.

Not to mention that the users of the software are the ones who suffer the
most. Seems pretty ethical to at least try to get the issue fixed.

~~~
rahkiin
A better analogy would be: You discover that all doorlocks of some vendor can
easily be opened without the key, including your neighbors. So you tell the
vendor. The vendor does nothing about it for 6 months, so you decide to tell
everyone who has the lock instead so they can fix/change it.

~~~
rtpg
Would that not fall into responsible disclosure? Maybe the definition I have
is different

I would think that if you make an honest and serious attempt to coordinate
with the vendor, it's responsible.

~~~
omginternets
I think his point is rather that "responsible" is a weasel-word.

------
snorlaxle
The impact of this vulnerability would not have been as bad if only android
let the user disable background apps easily and reliably.

~~~
swiley
It's so ironic that their argument for preventing user's control of their
phones is security.

------
IshKebab
Android should totally disable draw-on-top while security-sensitive UI
elements are visible like password fields and permission dialogs. Seems like
an easy fix.

~~~
AstralStorm
It already does for permission dialogs. The problem is all the legacy
applications which do not require the explicit permission check dialog on
runtime. (Targets older API than 24)

Then there is this accessibility thing which can actually click on the
permission dialog and does not require one itself. (Only a check in settings,
which is not protected against overlays.)

------
rubatuga
As cynical and unoriginal as I may sound, I could only expect such an exploit
for android, and not iOS.

