Google says attackers are still using "versioning" to bypass Play Store's malware checks

Cal Jeffrey

Posts: 4,181   +1,427
Staff member
Why it matters: Companies such as Epic Games and even the Biden administration have criticized Apple for maintaining a walled garden and not allowing sideloading in iOS. However, one solid reason for keeping the gates closed is one of Google's most persistent problems – versioning. Using dynamic code loading, hackers can supply apps vetted through the app store with malicious updates via a third-party server, and there is little the store can do about it.

The Google Cybersecurity Action Team (GCAT) notes in this month's Threat Horizons report that Google Play continues to have a known malware problem. Malicious app developers have been using "versioning" to upload malware to seemingly innocuous apps.

First, the threat actor uploads a harmless app to Google Play. The software contains no malware, so it doesn't trigger flags during the automated vetting process. Then the attackers send malicious updates via an owned or compromised server using dynamic code loading (DCL). So the once-safe app becomes a backdoor to the device allowing hackers to exfiltrate personal information, including user credentials.

"Campaigns using versioning commonly target users' credentials, data, and finances." reads the report. "In an enterprise environment, versioning demonstrates a need for defense-in-depth principles, including but not limited to limiting application installation sources to trusted sources such as Google Play or managing corporate devices via a mobile device management (MDM) platform."

Google has known about the attack vector for a while, but it's hard to mitigate since the malicious software completely bypasses Google Play's checks. You may recall that about a year ago, the store purged several supposedly safe antivirus apps when security researchers found that the developers were using DCL to update the programs with the banking trojan Sharkbot.

However, even when Google removes these bad apps, more eventually spring up, while many others remain available thanks to sideloading through alternative app stores. GCAT's report mentions that Sharkbot remains a common problem with Android apps because of DCL. Sometimes it will find versions of Sharkbot modified with reduced functionality to reduce the chance of getting ejected by the automated checks. However, fully functional editions can run rampant on third-party app stores.

Mitigation ultimately falls to the Android end-user or a company's IT administrator. Google recommends only downloading software from Google Play or other trusted sources. Alternatively, Android Enterprise or third-party Enterprise Mobility Management solutions have built-in tools that allow admins to selectively manage app distribution on company devices. Google additionally suggests leveraging Marketplace allowlists properly to help limit risks.

Permalink to story.

 
They should never become a walled garden like Apple. It is the best feature Android has over iOS.
 
This has absolutely nothing to do with sideloading in iOS. You can lock an app that was installed through the official store from making any major updates that were not pushed through the store.

Allowing apps that outside of the official store is why I stick to Android.
 
"if it ain't broke, don't fix it"
I never get up upgraded app, if it works OK, so why bother?
and especially true with M$
 
This article misleads in its subtitle and first paragraph. The versioning attack discussed here is completely unrelated to sideloading or walled gardens.
And there IS something the Android Open Source Project can do about it: restrict the sources from which an app can dynamically load code, and only give access to the source the app originally came from, or sources explicitly whitelisted by the user.
 
Yeah, they're actively working on demolishing that wall for Apple as well.

Because they actually believe it benefits the user. While in reality the only one it benefits is the malware maker. Way to go, above and beyond.
 
Back