11 ms·

Cloak and dagger – a new kind of attacks for Android

157 points by elsombrero 9y ago

etjossem 9y ago
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?
- devinl 9y ago
  One thing that is kind of unique about this vulnerability is that users can actually prevent attacks from happening by checking the permissions on an untrustworthy app because google has permissions controls built in for the features that are being abused here. The heart of this vulnerability is more in that these settings aren't clear on their implications and there are bad defaults. Disclosing to users seems to be a responsible thing to do since users can prevent an attack on their own device (especially given google's response of "working as intended").
  - etjossem 9y ago
    This is insightful, thanks. In this specific case, you're absolutely right that users themselves can take steps to mitigate the risk. If users come to understand the real meaning of granting permissions as a result of this disclosure, that's better for everyone. Definitely a factor to take into account, particularly when deciding how the information will be publicized.
- tptacek 9y ago
  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.
  - etjossem 9y ago
    Like it or not, the average smartphone user's security is at the mercy of their vendor. The pace and priority of updates is not up to the typical device owner, nor do security researchers have any say - it's up to Apple and Google. Fully exposing flaws in the software they write can have a real impact on millions of people who don't have much of an alternative. If you as a security researcher reasonably believe the vendor has neglected to patch the vulnerability, and you release exploit details, you have made things less safe for security-unaware users. There's no way around that. You already gave the vendor the opportunity to fix the problem. Now you are giving attackers the tools they need to take advantage of it. You and I might care about abstract principles of corporate responsibility, but the typical user just wants to avoid getting phished, and I can't help but feel open disclosure has a lot of potential to harm them. I hope it's worth it.
    - sgift 9y ago
      > If you as a security researcher reasonably believe the vendor has neglected to patch the vulnerability, and you release exploit details, you are amplifying the current harm it's inflicting. At least the public now has a fair chance to evaluate if they want to use their devices despite this vulnerabilities.
      - etjossem 9y ago
        That's true, but it glibly ignores the reality of vendor lock-in. The average non-infosec human is not going to switch devices because of a vulnerability whitepaper. This "vuln-insensitive user" is better served by giving the vendor a longer timeline to take care of the issue, rather than releasing exploit details two weeks after someone changed a status on a ticket.
        AstralStorm 9y ago
        Then fight the lock-in, in court if necessary. Tort lawyer will have some fun with it if you can show you cannot evade losses of secure data. I am pretty sure the line of defence will be weak "no warranty" claim that has nothing to do with lock in.
- vvanders 9y ago
  If you look at the timeline it details they disclosed the exploit and Google marked as won't fix which seems fair game for public release at that point.
- stordoff 9y ago
  The issues are marked as "won't fix". The only responsible course of action, IMO, at that point is to publicly announce the vulnerability.
- Jare 9y ago
  Malicious actors may find the vulnerability just like researchers did, so if the issue is not being fixed, the only responsible thing is to inform everyone of the potential danger they _already_ are in, and let them decide. The bells & whistles of giving it a fancy name, domain, etc suggest an additional layer of intent with the disclosure, but that's a separate issue because they have followed reasonable procedures beforehand.
  - etjossem 9y ago
    Malicious actors and users will be alerted in equal measure, but the typical Android phone owner will tend to do nothing in response to a new security paper, while malicious actors will tend to write exploit scripts. That's the main concern going through my mind when I see this. It would be different if the average user was a business, a developer, a security professional - but this isn't Heartbleed and we're talking about normal people this time. Are they even going to read this, and if so, what can they do besides keep an eye on their permissions?
    - Jare 9y ago
      > Malicious actors and users will be alerted in equal measure You have to assume malicious actors will find the vulnerability on their own, if they haven't already. They are already alerted.
      - etjossem 9y ago
        Absolutely, but widespread disclosure does nothing to stop that from happening, and may actually enable less-sophisticated attackers to do things they weren't capable of before.
        AstralStorm 9y ago
        Assuming those less sophisticated attackers don't just buy the exploit from more sophisticated ones.
    - plaguuuuuu 9y ago
- larma 9y ago
  Everything but the info about apps becoming the permission granted automatically by Play Store was already used by malware over a year ago. https://www.skycure.com/blog/accessibility-clickjacking/ https://www.skycure.com/blog/accessibility-clickjacking/
- omgtehlion 9y ago
  Absolutely responsible. They should have went public earlier, like August_22nd_2016 + 90days (this is what google themselves does)
tptacek 9y ago
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.
- forgotpwtomain 9y ago
  Why do they need a specific target in-this case, it appears from the video like they can overlay the keyboard and simply grab all keyboard input? > that's something that should be straightforward for app stores to screen for. Also wouldn't it be relatively viable to gain update access to a popular existing application or to provide an innocuous application at first and then push a patch enabling this vulnerability?
  - StavrosK 9y ago
    > they can overlay the keyboard and simply grab all keyboard input? Keyboards have variable heights, widths, etc, so they at least have to know what the keyboard looks like.
    - Gudin 9y ago
      Most of users use same and default keyboards. Even if you use different keyboard, with click heatmaps, they could find out keyboard layout and specs.
- ggggtez 9y ago
  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.
izacus 9y ago
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 9y ago
  Not everyone is using android >6, or am I missing something?
  - yegle 9y ago
    Targeting a higher API should still allow you to install on lower version at least that's my understanding of API targeting (not an Android dev so might be wrong).
  - sturmen 9y ago
    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.
snorlaxle 9y ago
The impact of this vulnerability would not have been as bad if only android let the user disable background apps easily and reliably.
- swiley 9y ago
  It's so ironic that their argument for preventing user's control of their phones is security.
IshKebab 9y ago
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.
- mtgx 9y ago
  Would this disrupt apps like LastPass, etc?
- AstralStorm 9y ago
  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 9y ago
As cynical and unoriginal as I may sound, I could only expect such an exploit for android, and not iOS.

157 points by elsombrero 9y ago

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?

devinl 9y ago
One thing that is kind of unique about this vulnerability is that users can actually prevent attacks from happening by checking the permissions on an untrustworthy app because google has permissions controls built in for the features that are being abused here. The heart of this vulnerability is more in that these settings aren't clear on their implications and there are bad defaults. Disclosing to users seems to be a responsible thing to do since users can prevent an attack on their own device (especially given google's response of "working as intended").
- etjossem 9y ago
  This is insightful, thanks. In this specific case, you're absolutely right that users themselves can take steps to mitigate the risk. If users come to understand the real meaning of granting permissions as a result of this disclosure, that's better for everyone. Definitely a factor to take into account, particularly when deciding how the information will be publicized.
tptacek 9y ago
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.
- etjossem 9y ago
  Like it or not, the average smartphone user's security is at the mercy of their vendor. The pace and priority of updates is not up to the typical device owner, nor do security researchers have any say - it's up to Apple and Google. Fully exposing flaws in the software they write can have a real impact on millions of people who don't have much of an alternative. If you as a security researcher reasonably believe the vendor has neglected to patch the vulnerability, and you release exploit details, you have made things less safe for security-unaware users. There's no way around that. You already gave the vendor the opportunity to fix the problem. Now you are giving attackers the tools they need to take advantage of it. You and I might care about abstract principles of corporate responsibility, but the typical user just wants to avoid getting phished, and I can't help but feel open disclosure has a lot of potential to harm them. I hope it's worth it.
  - sgift 9y ago
    > If you as a security researcher reasonably believe the vendor has neglected to patch the vulnerability, and you release exploit details, you are amplifying the current harm it's inflicting. At least the public now has a fair chance to evaluate if they want to use their devices despite this vulnerabilities.
    - etjossem 9y ago
      That's true, but it glibly ignores the reality of vendor lock-in. The average non-infosec human is not going to switch devices because of a vulnerability whitepaper. This "vuln-insensitive user" is better served by giving the vendor a longer timeline to take care of the issue, rather than releasing exploit details two weeks after someone changed a status on a ticket.
      - AstralStorm 9y ago
        Then fight the lock-in, in court if necessary. Tort lawyer will have some fun with it if you can show you cannot evade losses of secure data. I am pretty sure the line of defence will be weak "no warranty" claim that has nothing to do with lock in.
vvanders 9y ago
If you look at the timeline it details they disclosed the exploit and Google marked as won't fix which seems fair game for public release at that point.
stordoff 9y ago
The issues are marked as "won't fix". The only responsible course of action, IMO, at that point is to publicly announce the vulnerability.
Jare 9y ago
Malicious actors may find the vulnerability just like researchers did, so if the issue is not being fixed, the only responsible thing is to inform everyone of the potential danger they _already_ are in, and let them decide. The bells & whistles of giving it a fancy name, domain, etc suggest an additional layer of intent with the disclosure, but that's a separate issue because they have followed reasonable procedures beforehand.
- etjossem 9y ago
  Malicious actors and users will be alerted in equal measure, but the typical Android phone owner will tend to do nothing in response to a new security paper, while malicious actors will tend to write exploit scripts. That's the main concern going through my mind when I see this. It would be different if the average user was a business, a developer, a security professional - but this isn't Heartbleed and we're talking about normal people this time. Are they even going to read this, and if so, what can they do besides keep an eye on their permissions?
  - Jare 9y ago
    > Malicious actors and users will be alerted in equal measure You have to assume malicious actors will find the vulnerability on their own, if they haven't already. They are already alerted.
    - etjossem 9y ago
      Absolutely, but widespread disclosure does nothing to stop that from happening, and may actually enable less-sophisticated attackers to do things they weren't capable of before.
      - AstralStorm 9y ago
        Assuming those less sophisticated attackers don't just buy the exploit from more sophisticated ones.
  - plaguuuuuu 9y ago
larma 9y ago
Everything but the info about apps becoming the permission granted automatically by Play Store was already used by malware over a year ago. https://www.skycure.com/blog/accessibility-clickjacking/ https://www.skycure.com/blog/accessibility-clickjacking/
omgtehlion 9y ago
Absolutely responsible. They should have went public earlier, like August_22nd_2016 + 90days (this is what google themselves does)

tptacek 9y ago

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.

forgotpwtomain 9y ago
Why do they need a specific target in-this case, it appears from the video like they can overlay the keyboard and simply grab all keyboard input? > that's something that should be straightforward for app stores to screen for. Also wouldn't it be relatively viable to gain update access to a popular existing application or to provide an innocuous application at first and then push a patch enabling this vulnerability?
- StavrosK 9y ago
  > they can overlay the keyboard and simply grab all keyboard input? Keyboards have variable heights, widths, etc, so they at least have to know what the keyboard looks like.
  - Gudin 9y ago
    Most of users use same and default keyboards. Even if you use different keyboard, with click heatmaps, they could find out keyboard layout and specs.
ggggtez 9y ago
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.

izacus 9y ago

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 9y ago
Not everyone is using android >6, or am I missing something?
- yegle 9y ago
  Targeting a higher API should still allow you to install on lower version at least that's my understanding of API targeting (not an Android dev so might be wrong).
- sturmen 9y ago
  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.

snorlaxle 9y ago

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

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

IshKebab 9y ago

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.

mtgx 9y ago
Would this disrupt apps like LastPass, etc?
AstralStorm 9y ago
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 9y ago

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