By Jason Gu, Veo Zhang, and Seven Shen
We have disclosed this security issue to Google, who verified that they have protections in place against ZNIU courtesy of Google Play Protect.
The Linux vulnerability called Dirty COW (CVE-2016-5195) was first disclosed to the public in 2016. The vulnerability was discovered in upstream Linux platforms such as Redhat, and Android, which kernel is based on Linux. It was categorized as a serious privilege escalation flaw that allows an attacker to gain root access on the targeted system. Dirty COW attacks on Android has been silent since its discovery, perhaps because it took attackers some time to build a stable exploit for major devices. Almost a year later, Trend Micro researchers captured samples of ZNIU (detected as AndroidOS_ZNIU)—the first malware family to exploit the vulnerability on the Android platform.
The ZNIU malware was detected in more than 40 countries last month, with the majority of the victims found in China and India. We also detected the malware in the U.S., Japan, Canada, Germany, and Indonesia. As of this writing, we have detected more than 5,000 affected users. Our data also shows that more than 1,200 malicious apps that carry ZNIU were found in malicious websites with an existing rootkit that exploits Dirty COW, disguising themselves as pornography and game apps, among others.
Figure 1: Porn app where ZNIU hides
We worked on a Proof-of-Concept (PoC) for Dirty COW last year and found out that all versions of the Android OS were susceptible to exploitation, while ZNIU’s leveraging of Dirty COW only works on Android devices with ARM/X86 64-bit architecture. However, this recent exploit can bypass SELinux and plant a root backdoor, while the PoC can only modify the service code of the system.
We monitored six ZNIU rootkits, four of which were Dirty COW exploits. The other two were KingoRoot, a rooting app, and the Iovyroot exploit (CVE-2015-1805). ZNIU used KingoRoot and Iovyroot because they can root ARM 32-bit CPU devices, which the rootkit for Dirty COW cannot.
The ZNIU malware often appears as a porn app downloaded from malicious websites, where users are tricked into clicking on a malicious URL that installs the malware-carrying app on their device. Once launched, ZNIU will communicate with its C&C server. If an update to its code is available, it retrieves it from the C&C server and loads it into the system. Simultaneously, the Dirty COW exploit will be used to provide local privilege escalation to overcome system restrictions and plant a backdoor for potential remote control attacks in the future.
Figure 2: ZNIU infection chain
After entering the main UI of the device, the malware will harvest the carrier information of the user. It then transacts with the carrier through an SMS-enabled payment service, allowing the malware operator to pose as the device owner. Through the victim’s mobile device, the operator behind ZNIU will collect money through the carrier’s payment service. In one of our samples, we saw in its code that payments were directed to a dummy company, which, based on network traffic, we were able to locate in a city in China censored in the picture below. When the SMS transaction is over, the malware will delete the messages from the device, leaving no sign of the transaction between the carrier and the malware operator. If the carrier is outside China, there will be no possible SMS transaction with the carrier, but the malware will still exploit the system to plant a backdoor.
Figure 3: Transaction request sent by the malware to the carrier
Based on our analysis, the malware only appears to victimize users subscribed to China’s carriers. Moreover, even though the malware operator can set the amount higher to gain more money from the exploitation, every transaction amount is deliberately set in small amounts (20 RMB or 3 USD monthly) to avoid being noticed.
Figure 4: Screenshot of the SMS transactions
Since the Android OS is enforcing user interaction when it comes to granting permission for other apps to access the SMS feature of the device, ZNIU needs root privilege to make its scheme work. The malware also needs to plant a backdoor and remotely load additional malicious code later on to continue profiting from its victims.
A Closer Look at the ZNIU Rootkit
The ZNIU rootkit may be integrated into malicious apps through an independent broadcast receiver.
Figure 5: Snipper of ZNIU code activated on the network
The malware can easily inject the rootkit to a third party app without changing its other components. This practice is considered helpful for a massive malware distribution.
The malware operator encrypts and packs ZNIU’s malicious DEX codes for protection, which is an attempt to shield it from static reverse engineering. After further investigation, we found out that it uses the broadcast receiver to activate the exploit code once the user connects the device to a network or by simply plugging it into a power source. The malware then directly transmits and executes the malicious native codes.
Figure 6: ZNIU native codes
The main logic of ZNIU’s native code works as follows:
1. Collect the model information of the device.
2. Fetch appropriate rootkits from the remote server.
3. Decrypt the exploits.
4. Trigger exploits one by one, check the result, and remove exploit files.
5. Report if the exploit succeeded or failed.
Figure 7: ZNIU network activity
The URL of the remote exploit server, as well as the communication between client and server, were also discovered to be encrypted. But after using string decryption, details of the malicious exploit server were further explored, revealing that its domain and server host is located in China. The link of the malicious exploit server can be found in the appendix.
Figure 8: The backend exploit management server
Once downloaded, the rootkit ‘exp*.ziu’ will be decompressed into ‘exp*.inf’ with the help of ZLIB.
Figure 9: ZLIB decompressing a ziu file
All files needed by the rootkit are packed in one. inf file, with a filename that starts with ‘ulnz’ and contains several ELF or script files.
Figure 10: Structure of the inf file
The ZNIU rootkit can arbitrarily write to vDSO (virtual dynamically linked shared object), which exports a set of kernel space functions to the user space so that applications perform better. The vDSO code runs in a kernel context, which does not have a SELinux limit.
ZNIU uses public exploit code to write shellcodes to vDSO and create a reverse shell. Then it patches the SELinux policy to disarm restrictions and plant a backdoor root shell.
Figure 11: Dirty COW patching vDSO code
Users should only install apps from the Google Play or trusted third-party app stores and use mobile security solutions such as Trend Micro™ Mobile Security to block threats that may leverage Dirty COW from app stores before they can be installed. Users can also check with their device manufacturer and/or phone carriers to get the patch for this vulnerability.
Trend Micro’s Mobile App Reputation Service (MARS) already covers Android and iOS threats using leading sandbox and machine learning technology. It can protect users against malware, zero-day and known exploits, privacy leaks, and application vulnerability.
Enterprise users should also consider installing a solution like Trend Micro™ Mobile Security for Enterprise. This features device management, data protection, application management, compliance management, configuration provisioning, and other features so employers can balance privacy and security with the flexibility and added productivity of BYOD programs.
We are currently monitoring ZNIU’s activity, and we will update the blog entry for further findings and analyses. A list of Indicators of Compromise (IoCs) comprising related hashes (SHA256), package names, and app labels, can be found in this appendix.
With additional analysis by Jason Gu, Veo Zhang, and Seven Shen
Updated as of September 27, 2017, 2:30 AM PDT. Further observation revealed more than 300,000 malicious apps that carry the ZNIU malware in the wild, with more than 140,000 of those apps possessing unique labels. We also discovered that some of the samples’ app labels had confusing symbols and characters inserted in their names. This was deliberately done to avoid detection. The appendix for these additional samples can be found here.
from TrendLabs Security Intelligence Blog http://ift.tt/2xCfwKJ