Using third-party SDKs to detect repackaged malicious Android applications

Catalin-Valeriu Lita , Doina Cosovan

SecurityScorecard

Abstract:

It is a well-known fact that malware for Android usually comes in the form of a legitimate application repackaged with additional malicious code.

In order to develop Android applications as fast as possible, developers currently rely on additional Software Development Kits (SDKs) for a variety of functionality. According to SafeDK, an average Android application uses at least 10 different SDKs. These SDKs provide support for functionality such as advertising (Mopub), reporting crashes (Crashlytics), accessing social networks (Facebook), reporting analytics (Firebase), performing payments (Braintree), gathering location-based data (Radar), developing UI (Flutter), and so on. Some of these SDKs contact domains belonging to companies developing the SDKs in order to upload data / information about the application or the user using it. From there, this information reaches the owners of the Android applications embedding those SDKs.

Therefore, an application repackaged by an attacker might report information that could alert the application owners that something is amiss in the case of repackaged applications. This creates an opportunity for the owners / developers of Android applications to easily find out when their applications are being abused by attackers. Since the name and package can uniquely identify an Android application, the repackaged application changes them. The third-party SDK usually reports such identifying information which can alert the owner / developer monitoring the reported data. From here, these identifiers can be used to discover the repackaged malicious versions of their applications so that actions can be taken to take down the applications from markets or notify the infected users about the infection.

We stumbled upon some use cases in which the attackers perform some changes to SDKs embedded in the application in order to prevent this from happening. One such change involves changing the domains of those applications to non-existent domains. The new domains usually are the old domains with the addition, removal, or duplication of a letter. These domains can be registered by the attackers themselves or by third-parties, but if the domains are not registered then someone else can register them for other purposes. Depending on the purpose of the SDK, these registrations might leak sensitive information about the users. We were able to sinkhole some of these domains and this way we could provide other interesting statistics.

For the purpose of this presentation we would like to document the use cases in which the attackers apply such changes as well as to provide some recommendations for the application owners / developers so that they can use the information gathered by the third-party SDK they use in order to discover when their applications are abused by threat actors.