StrandHogg 2.0 Exploit Explained – Why Users and Android App Developers should care

It’s 10:00 PM. Do you know where your Activities are? There’s a new vulnerability that can be exploited on millions of Android devices, and it’s a pretty nasty one, too. In a nutshell, this design flaw allows an attacker to present their own Activity (page) on top of another app’s, potentially confusing the user into giving away their private data. The vulnerability has been dubbed StrandHogg 2.0 and was recently disclosed by Promon, a Norwegian security firm.

The StrandHogg 2.0 vulnerability theoretically affects all Android devices running Android versions as old as Honeycomb (3.0) and up to Android 9 Pie (9.0). Based on the latest Android version distribution statistics, that means that approximately 91.8% of all Android devices are vulnerable to StrandHogg 2.0. The vulnerability was assigned CVE-2020-0096 and was given a severity level of “critical.” It doesn’t require any special permissions to work and can function almost entirely without user interaction. All a user has to do is open an app with malicious code hidden away in it, and then they’re vulnerable to exploitation.

Promon was kind enough to send us their proof of concept app and its source code so we could best explain how the exploit works, why it matters to users, and how developers can protect their apps against it.

---

How It Works

Say you’re using Gmail and you click a web link. If you go to your recent apps screen, you may notice that the web page appears to be “inside” Gmail. The preview shows the website, but the app icon and name are still from Gmail. This is something that happens when an app/Activity launches another app/Activity in the same task. Now imagine that you didn’t purposely open that link. To you, it looks like it’s just part of the Gmail app. This is the behavior that StrandHogg 2.0 exploits.

We’re going to have to leave out some details here, but here’s roughly how this exploit works. For the following, let’s assume the attacker wants to get the user’s Gmail login.

1. The user downloads a malicious app (of course, without knowing it’s malicious) and opens it.
2. In the background, the app opens Gmail, puts a look-alike login Activity on top of it, and then launches another Activity.
3. The user opens Gmail and sees what looks like Gmail’s login screen but is actually the attacker’s phishing Activity.

The final Activity launched in step 2 can be anything that avoids suspicion. The app could fake a crash and go back to the home screen, or it could just open to its main Activity as if nothing happened. The only suspicious thing the user might see is a bunch of opening animations as all the Activities launch. The worst part: It won’t even look like Gmail was opened.

Source: Promon

Of course, an attacker can do more than just showing a fake login screen. A malicious app could present a permissions prompt instead, tricking the user into granting unwanted permissions. While requesting any special permissions like Accessibility might make the user suspicious, it’s possible to do a lot of damage with something like Storage Access.

---

The Technical Bits

This next section is a high-level overview of how StrandHogg 2.0 works. Promon won’t release the full details for another few months, so we can’t share exactly how this exploit is implemented. There are some technical details that we can talk about, though.

In a nutshell, StrandHogg 2.0 hijacks Android’s Context.startActivities() API method, using three Intents.

• The first Intent is the one that launches, in our example’s case, Gmail. It’s flagged with Intent.FLAG_ACTIVITY_NEW_TASK.
• The second Intent is the malicious one. In our example, it’s for the look-alike login Activity. This Intent has no flags.
• The third Intent is the distraction. It makes sure the user isn’t suspicious of Gmail just randomly opening instead of the app they tapped (i.e. the one launching the attack). It’s flagged with Intent.FLAG_ACTIVITY_NEW_TASK.

All of these Intents are then passed in an array to the startActivities() method.

The second Intent’s lack of flags is the key here. By doing so, we’ve basically just replicated the Gmail example from above. The task is technically Gmail’s, but the topmost Activity is the attacker’s. When the user then clicks Gmail’s home screen icon, the attacker’s Activity displays instead of Gmail’s.

---

Proof of Concept

With the information that Promon sent us, we were able to replicate their proof of concept. Here’s a screen recording from a Samsung Galaxy Note8 running Android 9 Pie showing it in action.

---

Mitigation Techniques and Issues

Now, simply replicating the above in code won’t actually work. It’s not a complete example, and there are a few other things that an attacker has to do to make it work, which we can’t share. But they’re not particularly hard to guess on your own, and that’s part of what makes this attack so dangerous. StrandHogg 2.0 is a relatively easy exploit to implement, and difficult to mitigate.

Mitigation can’t just involve blacklisting all apps that use startActivities(), since there are plenty of legitimate uses for it. It’s also really difficult to automate a detection algorithm for it. Malicious developers can employ all sorts of tricks to make their implementation of StrandHogg 2.0 effectively invisible to services like Google Play Protect. StrandHogg 1.0 required the attacker to add an attribute in the malicious app’s AndroidManifest.xml, which was relatively easy to detect. StrandHogg 2.0, on the other hand, functions entirely in Java/Kotlin.

Taking into account obfuscation, reflection, and even just different coding styles, it seems impractical to automatically properly detect an app making use of this exploit. What’s more is that if a user is the subject of a StrandHogg 2.0 attack, they may not even know. If you open Gmail and you see its login screen, you might just think your session expired and enter your login details without a second thought.

When we contacted Google for a response, a spokesperson offered the following statement:

“We appreciate the work of the researchers, and have released a fix for the issue they identified. Additionally, Google Play Protect detects and blocks malicious apps, including ones using this technique.”

This sounds good, and hopefully it has at least some effect against StrandHogg 2.0 attacks. It’s worth noting, though, that Google Play Protect did not detect our proof of concept app as malicious, even after performing a manual scan.

Promon says that they “have not observed any real-life malware utilizing the StrandHogg 2.0 vulnerability,” but there’s no guarantee that this is the first time the exploit has been discovered. For that reason, Promon recommends that developers go ahead and protect their apps by setting their launcher Activity’s launchMode flag to either singleTask or singleInstance. Either of these flags will prevent task injection, which is what StrandHogg 2.0 relies on. However, having your Activity use one of these flags can cause issues with certain app flows, so it’s not always desirable.

Promon is also promoting its own “In-App Protection by Promon SHIELD” product which sounds like a library that app developers can implement to monitor the tasks in your app’s process to check for irregular insertions. Because there’s no truly effective developer or user mitigation strategy, it’s pretty important that manufacturers implement the patch to fix this ASAP.

Thankfully, Promon followed responsible disclosure guidelines before making this exploit public (and it’s still not fully public—Promon is waiting 90 days before fully disclosing how StrandHogg 2.0 works). Google has since backported patches for this exploit to Android 8.0 Oreo, Android 8.1 Oreo, and Android 9 Pie with the May 2020 Android Security Patch Level (SPL). Users on Android 10 and above aren’t vulnerable, though we’re not entirely sure why that’s the case. It likely has something to do with Android 10’s new restrictions concerning launching Activities and how Google integrated that into the task stack. Promon says that “on Android 10 the attack is entirely ineffective, and the activities are split into different tasks and into separate task stacks according to adb shell dumpsys activity activities.”

If your device manufacturer is still providing security updates (you can read more about how the security patch process works here), you should pester them for an update as soon as possible. Otherwise, you’ll just need to be careful about which apps you download and run (although you should be doing that anyway).

For more details and use-cases of StrandHogg 2.0, check out the official announcement on Promon’s website. For custom ROM developers, you can find the relevant AOSP commits for preventing StrandHogg 2.0 attacks here and here.

---

Disclosure Timeline

Here is the disclosure timeline that Promon shared in its StandHogg 2.0 document:

• Dec 4, 2019 – Reported issue to Google
• Dec 4, 2019 – Shared a PoC «malicious app» and video with Google
• Dec 4, 2019 – Google confirmed receiving the report
• Dec 9, 2019 – Google set the severity of the finding as «Critical»
• Dec 9, 2019 – Google confirms that they are able to reproduce the issue
• Feb 14, 2020 – We inform Google the 90-day disclosure is nearing in the beginning of March, and ask for status on their side
• Feb 14, 2020 – Google responds that April is the soonest they can roll out a fix
• Feb 14, 2020 – We inform Google we are working on mitigations
• Feb 14, 2020 – Google responds. They are working on remediations, and ask if we can share what mitigations we are recommending
• Feb 17, 2020 – We inform Google that we can hold back the disclosure until April. We request the CVE number
• Feb 17, 2020 – We share our mitigation strategies, as well as how we envisage a platform mitigation
• Mar 23, 2020 – Google responds with the CVE ID (CVE-2020-0096)
• Mar 23, 2020 – Google responds that general availability of the fix for Android will be available in May
• Mar 23, 2020 – Google asks if we will consider delaying disclosure to May
• Mar 27, 2020 – We respond that we will delay disclosure until May
• Apr 22, 2020 – Google informs us that the May Security Bulletin is scheduled to contain a patch for the vulnerability

The post StrandHogg 2.0 Exploit Explained – Why Users and Android App Developers should care appeared first on xda-developers.

from xda-developers https://ift.tt/2ZOZRpR
via IFTTT