Igexin Advertising Network Put User Privacy at Risk
The Lookout Security Intelligence team has discovered an advertising software development kit (SDK) called Igexin that had the capability of spying on victims through otherwise benign apps by downloading malicious plugins. Over 500 apps available on Google Play used the Igexin ad SDK. While not all of these applications have been confirmed to download the malicious spying capability, Igexin could have introduced that functionality at their convenience. Apps containing the affected SDK were downloaded over 100 million times across the Android ecosystem.
It is becoming increasingly common for innovative malware authors to attempt to evade detection by submitting innocuous apps to trusted app stores, then at a later time, downloading malicious code from a remote server. Igexin is somewhat unique because the app developers themselves are not creating the malicious functionality - nor are they in control or even aware of the malicious payload that may subsequently execute. Instead, the invasive activity initiates from an Igexin-controlled server.
The apps that contain the SDK included:
- Games targeted at teens (one with 50M-100M downloads)
- Weather apps (one with 1M-5M downloads)
- Internet radio (500K-1M downloads)
- Photo editors (1M-5M downloads)
- Educational, health and fitness, travel, emoji, home video camera apps
Lookout users are protected from this threat. We informed Google of the functionality of Igexin, and the apps were subsequently removed from the Play Store, or replaced with updated versions with the invasive features removed.
Background
Typically, mobile apps use advertising SDKs to make it easy for app developers to leverage advertising networks and deliver ads to customers. Like many ad networks, the Igexin service promotes its targeted advertising services that leverage data collected about people such as their interests, occupation, income, and location.
Lookout researchers began investigating suspicious traffic as part of a routine review of apps that communicate with certain IPs and servers that previously served malware. The traffic on its own is not unusual, as many types of malware generate traffic to legitimate services for a variety of reasons.
We observed an app downloading large, encrypted files after making a series of initial requests to a REST API at http://sdk[.]open[.]phone[.]igexin.com/api.php, which is an endpoint used by the Igexin ad SDK.
This sort of traffic is often the result of malware that downloads and executes code after an initially "clean" app is installed, in order to evade detection. The encrypted file downloads and the presence of calls within the com.igexin namespace to Android's dalvik.system.DexClassLoader (used to load classes from a .jar or .apk file) were enough to warrant more in-depth analysis for possible malware hiding in its payload.
Collection of personal data Users rely on apps' permissions (which are shown in Google Play), mobile security solutions such as Lookout Mobile Endpoint Security, and privacy policies to assess whether the personal data collected by an app is reasonable given its purpose or functionality. For example, people might expect a social location-sharing app to access location and Wi-Fi names, where they would not expect such features in a gambling app. Most people have an expectation that a limited amount of information about them may be shared with advertisers, as disclosed in the privacy policy.
The app developer is ultimately responsible for disclosing in the app privacy policy all personal information the app collects. The developers also are responsible for vetting embedded third-party code and disclosing the data collection capabilities of all embedded third-party code in the privacy policy.
It is likely many app developers were not aware of the personal information that could be exfiltrated from their customers' devices as a result of embedding Igexin's ad SDK. It required deep analysis of the apps' and ad SDK's behavior by our researchers to make this discovery. Not only is the functionality not immediately obvious, it could be altered at any time on the remote server.
SDK functionality
Not all versions of the Igexin ad SDK deliver malicious functionality. The malicious versions implement a plugin framework that allows the client to load arbitrary code, as directed by responses to requests made to a REST API endpoint hosted at http://sdk[.]open[.]phone[.]igexin[.]com/api.php.
Both requests to and responses from this endpoint are encoded JSON data. Below is a decoded response from this API, directing the client to download and run code in two encrypted JAR files:
The relevant fields in these response messages are:
Upon receiving this type of response from the server, the SDK will decrypt the file(s), with the key provided by the API call, and save it on the device. It then leverages Android's dalvik.system.DexClassLoader and reflection to load the specified class from the JAR file:
All plugins are expected to contain a class which implements the com.igexin.push.extension.stub.IPushExtension interface. This interface defines a boolean init(Context) method which is called to initialize the plugin.
Note that all API traffic is encoded (not encrypted), and sent and received in plain text.
Plugin FunctionalityThe functionality contained in the downloaded classes is completely under external control at runtime, and it may change at any time and can vary based on any factors chosen by the remote system operator. Users and app developers have no control over what will be executed on a device after the remote API request is made.
The only limitations on what could potentially be run are imposed by the Android permissions system. That said, the most serious behavior we've observed from these plugins has been call log exfiltration.
We have noted a significant number of downloaded plugins register a PhoneStateListener through their init methods if the following conditions are met:
- A setting stored in an internal SQLite database is enabled
- The app has "android.permission.READ_PHONE_STATE" permissions
This PhoneStateListener will save:
- The time of the call
- The calling number
- The call state (idle, ringing, or off hook)
This data is periodically sent to the http://sdk[.]open[.]phone[.]igexin[.]com/api.php endpoint in an HTTP request body. The messages, when decoded, will be in the following format:
If we Base64 decode the BIData, we can observe data collected through the PhoneStateListener is formatted as pipe-separated records:
Field four is the time of the call, and field six is the call state. The fifth field contains the Base64 encoded and RC4 encrypted phone number that called.
The second field contains part of the key which was used for XOR encryption (the other part is hard coded in the application).
With the key, we can decrypt the s6GYbkAUkOQPwK4P string to a valid phone number.
Authors
Christoph Hebeisen
Christoph Hebeisen leads the Security Intelligence Research division at Lookout. In this role he oversees the company's suite of research activities, which cover malware, device compromise, network threats, phishing and threat intelligence services. Previously he worked as a security researcher and later manager of the Vulnerability Research team at TELUS Security Labs. Christoph holds a Ph.D. in Physics and investigated ultrafast molecular dynamics using powerful, short laser pulses before turning his attention to security.
