Here at VMX Labs, learning that 60 mobile apps are carrying the same Android malware isn’t necessarily any more shocking than other potentially far-reaching malware attacks involving mobile devices. However, it’s an opportunity to illustrate to our readers why the actual code (or source of code) needs significant attention during the app development process. 

After all, the recent Goldoson malware, as reported by Bleeping Computer, appears to have extended its tentacles via the more than 100 million downloads associated with those 60 infected mobile apps. Just two of the larger apps involved were L.POINT with L.PAY and Money Manager Expense & Budget (both of which with more than 10 million downloads). Bleeping computer reports that the Goldoson malicious malware component is part of a third-party library that all the apps used. And thus, the mass production of headaches begins for many developers. 

Supply chain attacks like these, where attackers inject their code into free open source libraries (or libraries from untrusted sources) can be difficult for app developers to avoid, since even if they only use peer reviewed FOSS, injections of malware code into these libraries still can happen. Since this malware does not unfold its activity until the app is deployed, security scanners, even security reviews, and also those of the app stores do not find these attacks. To have any semblance of peace of mind, App developers need to have the ability to continuously monitor their app in the field, identify such problems when they unfold their activity, and remediate the threat ASAP. The affected third-party libraries are often a crucial part of an apps’ anatomy, so is its cybersecurity posture, to have this additional layer of control.

Discovered by McAfee, Goldoson reportedly collects data on a device’s apps, Wi-Fi and Bluetooth devices as well as the device’s location – all while also fraudulently and quietly clicking ads in the background. Once a user launches an app that used the infected library, Goldoson gets to working, telling it what data to steal and which ads to click. Involved apps that have been given lots of permissions from the user are the clear drivers for the most stolen data.  

Most consumers don’t realize that app stores such as Google Play are not responsible for securing individual apps that aren’t made by Google. That’s not their role. That’s illustrated by Google’s normal policy to simply remove apps that don’t comply with their policies due to known issues. This places the responsibility of mobile app security solely on the app developer. Ironically, the theme of frequent security problems associated with “third-party” anything, especially for mobile apps, continues not only with the need to remediate the related third-party library infection, but also with the fact that third-party Android app stores could still harbor the same malicious library.  

Further illustrating the significant threat that unmonitored or unvetted anatomy of a mobile app can cause, these types of attacks are fueling the industry’s push for a software supply chain that not only prioritizes knowledge surrounding the background of all its anatomy (also known as constituents) , but also the ability to determine when something is amiss with an app’s activity and needs to be remediated because something was overlooked in the initial software supply chain review. This can involve both open source code as well as proprietary code, as outlined in this TechTarget explanation.

5 things app developers can do to protect their code anatomy

  1. Research the reputation of the third-party library before integrating it into their code. This can include reading reviews and feedback from other developers, checking the security track record of the library, and looking into any security vulnerabilities or incidents that may have been associated with it. Examine the frequency of new code modifications, the existence of a security manifest and try to find a list of released patches that show if the code is actively maintained with security in mind.
  2. Run code validation tools over the library code to get a better understanding about the quality of the code and potentially even uncover vulnerabilities. 
  3. Actively monitor the app, including the library, in real time and watch out for unplanned behaviors that could indicate dormant malware from the supply chain to be activated. Tools like those utilized by Verimatrix XTD can help to ease this task.
  4. Keep the third-party library up-to-date: Developers should ensure that they are using the most up-to-date version of the third-party library, as this will typically include any security updates or patches. Of course the above mentioned monitoring and testing is needed after each update. 
  5. Harden their apps with cybersecurity tools like Verimatrix XTD, to protect against vulnerabilities or weaknesses being exploited to steal sensitive data, install malware, or launch other types of attacks.

With the majority of all mobile apps remaining unprotected from today’s latest threats, the VMX Lab team works to highlight the deep gap in confidence and security that this foundational failure can create – underscoring the vital role that app developers play in cybersecurity and how they can harness the cost-effective power of Verimatrix XTD to consistently combat it. Verimatrix XTD provides a library of defense and monitoring features, that among other capabilities, highlight suspicious behaviour of malware carrying libraries like the one described above.