Malware that can steal data, track location, and perform click fraud was inadvertently built into apps via an infected third-party library, highlighting supply chain risk.

Google Android Green Robot over black and white background
Source: Marc Bruxelle RF via Alamy Stock Photo

Malware that can steal data and commit click fraud has hitched a ride into 60 mobile apps, via an infected third-party library. The infected apps have logged more than 100 million downloads from the official Google Play store and are available in other app stores in South Korea, researchers have found.

Goldoson, discovered and named by researchers at McAfee Labs, can perform a variety of nefarious activities on Android-based devices, they said in a blog post. The malware can collect lists of applications installed, as well as sniff out the location of nearby devices via Wi-Fi and Bluetooth. It also can perform ad fraud by clicking advertisements in the background without the user's consent or knowledge, the researchers said.

Some of the popular apps affected by Goldoson include L.POINT with L.PAY, Swipe Brick Breaker, Money Manager Expense & Budget, Lotte Cinema, Live Score, and GOM. The researchers found more than 100 million downloads of infected apps on Google Play, and 8 million on ONE, South Korea's leading mobile app store, they said.

McAfee reported the infected apps to Google, which quickly notified developers that their apps were in violation of Google Play policies and that they needed to fix their apps, the researchers said. They do not mention in their post if they contacted the ONE app store.

Some apps were removed from Google Play outright while others were updated by the official developers. McAfee is encouraging users of any of the affected apps — a list of which is in the post — to update them to the latest version to remove any trace of Goldoson from their devices.

"While the malicious library was made by someone else, not the app developers, the risk to installers of the apps remains," SangRyol Ryu of McAfee's mobile research team wrote in the post.

How Goldoson Works

The Goldoson library registers a device right after it infects it, acquiring remote configurations from a command-and-control server (C2) as the app runs simultaneously. It evades detection by both varying and obfuscating the library name and the remote server domain with each application; developers dubbed it "Goldoson," because this is the first domain name they found, they said.

A remote configuration contains the parameters for each of the app's functionalities and specifies how often it runs the components.

"Based on the parameters, the library periodically checks, pulls device information, and sends them to the remote servers," Ryu wrote.

Goldoson's ability to collect data from all the apps on the device comes from a permission called "QUERY_ALL_PACKAGES," that it requests from the device. Users of devices with Android version 11 or above installed appear to be more protected from this query, with only about 10 percent of the cases observed by McAfee demonstrating vulnerability, the researchers said.

The malware requests permissions to access location, storage, or the camera at runtime from devices running Android 6.0 or higher. If location permission is allowed, the infected app can access not only GPS data but also Wi-Fi and Bluetooth info from devices nearby, which gives them more accuracy in locating the infected device, especially indoors, the researchers noted, adding that the ability to identify or discover the location of users puts them at risk for further malicious activity.

Goldoson can also load Web pages without the user knowing — a functionality that attackers can abuse to load ads for financial gain, the researchers said. In technical terms, this works because the library loads HTML code and injects it into a customized and hidden WebView, then produces hidden traffic by visiting the URLs recursively, they explained.

Goldoson sends data it collects from devices out every two days to the attackers, who can change this cycle using remote configuration.

Third-Party Mobile App Component Risk

The existence of Goldoson demonstrates once again how swiftly malicious activity can spread when it's a part of third-party or open source components that developers build into applications without knowing that they are infected, the researchers noted.

This was well documented in the Apache Log4j debacle — in which a logging library used in nearly all Java environments was found to contain an easily exploitable vulnerability. The repercussions of Log4j — which has been declared an endemic cyberthreat by the Department of Homeland Security because of how many existing applications remain vulnerable — likely will be felt for years to come.

Indeed, this ability to gain a large malicious footprint quickly and without organizations or developers knowing — and thus before they can react — has not been lost on attackers. In response, they increasingly are targeting the software supply chain with malware or exploits for Log4j and other known vulnerabilities — and will continue to do so as their successes mount, observes a security expert.

"Attackers are becoming more sophisticated in their attempts to infect otherwise legitimate applications across platforms," says Kern Smith, vice president for the Americas for sales engineering at mobile security firm Zimperium.

Demand for Transparency

Transparency across organizations and developers' teams appears to be the best way to mitigate software supply chain issues, experts said.

Both developers and organizations using applications that include open source or third-party components "need to assess the risks of these applications and their components, especially as it pertains to a software bill of materials (SBOM)," which provides an inventory of what comprises software components, Smith says.

Indeed, developers should be willing to reveal what libraries and other components are used in applications they develop and deliver to protect users and prevent compromise via infected or vulnerable components, McAfee researchers said.

Developers of external libraries also need to be transparent about their code so organizations and developers leveraging them can understand their behavior and thus be aware quickly of any issue that may arise, they said.

About the Author(s)

Elizabeth Montalbano, Contributing Writer

Elizabeth Montalbano is a freelance writer, journalist, and therapeutic writing mentor with more than 25 years of professional experience. Her areas of expertise include technology, business, and culture. Elizabeth previously lived and worked as a full-time journalist in Phoenix, San Francisco, and New York City; she currently resides in a village on the southwest coast of Portugal. In her free time, she enjoys surfing, hiking with her dogs, traveling, playing music, yoga, and cooking.

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights