StrandHogg Pwns 80% of Android Phones; Google Fiddles While Platform Burns

Norwegian researchers have found a huge vulnerability in 80% of all Android phones. Hackers have been quietly exploiting “StrandHogg” for months–if not years.

And Google’s failed to patch it. Instead, it has been trying to play whack-a-mole with malicious dropper apps (and doing a piss-poor job of it).

This is bad. Really bad. In today’s SB Blogwatch, we wonder if the grass is greener on the iOS side of the fence.

Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Led boomer.

You Say Strandhögg, I Say StrandHogg

What’s the craic? Dan Goodin reports—“Vulnerability in fully patched Android phones under active attack by bank thieves”:

 The vulnerability allows malicious apps to masquerade as legitimate apps that targets have already installed and come to trust. … Running under the guise of trusted apps already installed, the malicious apps can then request permissions to carry out sensitive tasks, such as recording audio or video, taking photos, reading text messages or phishing login credentials. Targets who click Yes … are then compromised.

Researchers said … they found 36 apps exploiting the spoofing vulnerability. … Google has removed malicious apps from its Play Market, but … the vulnerability appears to be unfixed in all versions of Android. … Google representatives didn’t respond to questions.

The vulnerability is most serious in versions 6 through 10 … about 80% of Android phones. … A user’s only defense is to click No [and] to be highly suspicious of Android apps available both in and outside of Google Play.

And Kelly Sheridan adds, “Bug enables malware to pose as any legitimate Android app”:

 Researchers … dubbed the bug “StrandHogg,” an old Norse term for a Viking coastal raiding tactic. A successful attacker could exploit the vulnerability to take over a legitimate application and run malicious processes without the user’s knowledge.

Researchers found StrandHogg when its customer, an Eastern European security firm, noticed a trend of money being siphoned from accounts at Czech banks. … The bug has been undergoing analysis throughout the spring and summer, though malicious apps could have been exploiting the flaw long before this.

The malicious applications exploiting StrandHogg don’t directly come from Google Play. Victims have to first download the legitimate application, which serves as a dropper to download future malware.

Who discovered it? Promon’s John Høegh-Omdal, Caner Kaya, and Markus Ottensmann tag-team to tell us about “The StrandHogg vulnerability”:

 All top 500 most popular apps are at risk. Real-life malware is exploiting the vulnerability.

By exploiting this vulnerability, a malicious app … can attack the device and trick it so that when the app icon of a legitimate app is clicked, a malicious version is instead displayed. … When the victim inputs their login credentials within this interface, sensitive details are immediately sent to the attacker.

[It’s] possible for a malicious app to ask for permissions while pretending to be the legitimate app. … The attack can be designed to request permissions which would be natural for different targeted apps to request … lowering suspicion from victims. Users are unaware that they are giving permission to the hacker and not the authentic app.

This exploit is based on an Android control setting called ‘taskAffinity’ which allows any app – including malicious ones – to freely assume any identity in the multitasking system. [This] study significantly expands upon research carried out by Penn State University in 2015, where researchers theoretically described certain aspects of the vulnerability. Google, at the time, dismissed the vulnerability’s severity.

In spite of Google’s Play Protect security suite, dropper apps continue to be published and frequently slip under the radar, with some being downloaded millions of times before being spotted. [For example] the malicious CamScanner app … has been downloaded more than 100 million times.

Promon adheres to Google’s 90-day disclosure timeline. We submitted our report to Google this summer.

OMFSM! So not only did Google pooh-pooh the 2015 report, it’s done nothing about patching the vulnerability for three months? Heed SuperKendall’s super rant:

 Android is just a bad choice currently. … There needs to be some third party that cares way more about end user security than Google does.

Device makers and Android providers in general are just playing with people’s lives by promoting Android as something the general populace should use. It is simply not fit security-wise for the places it is being deployed.

How can anyone who knows better in good conscious recommend an Android device to someone like a non-technical relative? You are just rolling dice with their data.

What you can do is make sure that anyone who doesn’t understand technology is using a platform that is far more serious about keeping user data secure and apps separated by real barriers. This attack we are seeing here, simple is not possible on iOS. … That is the harsh reality that apparently the technical community is unwilling to face while feeding snake oil to the masses because they like how it tastes.

And the researchers don’t walk away without criticism. aexcorp punishes Promon:

 WTF were they thinking? Active exploitation means the window is no longer useful. Might as well tell the world.

But as for the suggestion to “use iOS”? reanjr just scoffs:

 Don’t use an iPhone if you want security. They just got over patching a much more critical security flaw in iOS.

Essentially the same flaw, except it was installed by visiting a website, and it didn’t require any human to click “approve”. Apple is objectively worse at security than Google.

Is there a practical workaround? Other than “be highly suspicious”? siliconaddict suggestifies:

 Tap NO to any privilege request—any. Then just go into the app’s properties and approve it.

Yes its a PITA. … But if you are mindful of it instead of auto accepting everything that shows up on screen its fine until it gets patched.

After initial privileges are granted you shouldn’t get a ton of these. So anything new should generate suspicion.

Meanwhile, quicker than you can say, “OK boomer,” here’s Canberra1:

 IBM Mainframes solved this problem, oh, 50 years ago. … I don’t get why IBM lessons have to be reinvented anew.

And Finally:

“Led Zeppelin cut into little pieces and re-assembled” (OK boomer)

Previously in And Finally

You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites… so you don’t have to. Hate mail may be directed to @RiCHi or [email protected]. Ask your doctor before reading. Your mileage may vary. E&OE.

Image source: Promon AS

Richi Jennings

Richi Jennings

Richi Jennings is a foolish independent industry analyst, editor, and content strategist. A former developer and marketer, he’s also written or edited for Computerworld, Microsoft, Cisco, Micro Focus, HashiCorp, Ferris Research, Osterman Research, Orthogonal Thinking, Native Trust, Elgan Media, Petri, Cyren, Agari, Webroot, HP, HPE, NetApp on Forbes and Bizarrely, his ridiculous work has even won awards from the American Society of Business Publication Editors, ABM/Jesse H. Neal, and B2B Magazine.

richi has 545 posts and counting.See all posts by richi

Cloud Workload Resilience PulseMeter

Step 1 of 8

How do you define cloud resiliency for cloud workloads? (Select 3)(Required)