Category: #IT/CYBER/TECHNOLOGY

Mobile app creators are often looking for ways to monetize their software. One of the most common ways to do this is by displaying advertisements to users or by offering in-app purchases (IAPs). Mobile monetization platforms create software libraries that authors can embed into their apps to start earning money quickly. We previously highlighted the dangers of installing apps that enable IAPs using SMS messages, as these apps typically have access to all SMS messages sent to the phone.

While not all SMS-based IAP applications steal user data, we recently identified that the Chinese Taomike SDK has begun capturing copies of all messages received by the phone and sending them to a Taomike controlled server. Since August 1, Palo Alto Networks WildFire has captured over 18,000 Android apps that contain this library. These apps are not hosted inside the Google Play store, but are distributed via third party distribution mechanisms in China.

Background

WildFire captures many samples of mobile malware that intercept and upload SMS messages. Most of these are created by malware authors who set up command and control (C2) servers with third party hosting providers and frequently update their locations to avoid detection.

Among these malware we have found many that are created by “mobile monetization” companies who distribute apps that provide little value but have a high cost to the user. These apps are often installed by tricking users into clicking a pop-up, only to find later that a charge has appeared on their phone bill. Antivirus programs typically identify these apps as malware, the topic of this blog is something different and harder to detect.

Taomike is a Chinese company that aims to become the biggest mobile advertisement solution platform in China. They provide an SDK and services to help developers display rich advertisements with a high pay rate. Taomike has not previously been associated with malicious activity, but a recent update to their software added SMS theft functionality. The apps this library is embedded in may be legitimate and have significant functionality, but their developer’s choice to use this library has put them at risk.

Technical Details: SMS Theft

Not all apps that use the Taomike library steal SMS messages. Our analysis indicates that only samples that contain the embedded URL, hxxp://112.126.69.51/2c.php have this functionality. This is the URL to which the software uploads SMS messages, and the IP address belongs to the Taomike API server used by other Taomike services. We have captured around 63,000 Android apps in WildFire that include the Taomike library but only around 18,000 include the SMS theft functionality.

We believe there are different versions of the Taomike SDK and only some of them include SMS uploading behavior. Based on our data, the version that contains the SMS stealing functions is newer and was released around August 2015. Apps that use earlier versions of the library appear to be safe.

The Taomike library is called “zdtpay” and is a component of Taomike’s IAP system.

Because Android apps are required to list the permissions they need in their manifest file, we can see that this library requires both SMS and network related permissions. The library also registers a receiver named com.zdtpay.Rf2b for both the SMS_RECEIVED and BOOT_COMPLETED actions with highest priority of 2147483647.

Figure 1. Registered receiver for SMS_RECEIVED

The registered receiver Rf2b reads SMS messages whenever they arrive. The message body and sender phone number are collected as shown in Figure 2.

Figure 2. SMS body and sender number read

If the device has just booted, it will start the service MySd2e, which then registers a receiver for Rf2b as shown in Figure 3.

Figure 3. MySd2e Service registers receiver for Rf2b

SMS information collected by the receiver is saved in a hashmap with “other” as the key and sent to a method that uploads the message to 112.126.69.51 as shown in Figure 4.

Figure 4. Information uploaded to IP Address used by api.taomike.com

All SMS messages sent to the phone are uploaded, not just those that are relevant to Taomike’s platform. Figure 5 shows a packet capture of a test message upload. The message content is “hey test msg” as circled with dashed red box.

Figure 5. SMS uploaded via HTTP in pcap

The Taomike library makes contact with the following URLs, but only the “2c.php” path is used to capture SMS messages. The rest appear to be used for other parts of the IAP functionality in the library.

• http://112.126.69.51/2c.php
• http://112.126.69.51/imei_mobile.php
• http://112.126.69.51/install_report.php
• http://112.126.69.51/error.php
• http://112.126.69.51/rixian.php
• http://112.126.69.51/order_mo.php
• http://112.126.69.51/order.php
• http://112.126.69.51/order_status.php
• http://112.126.69.51/tdstatus.php

Risks and Mitigation

We have captured over 18,000 samples that contain the SMS stealing library since August 2015, meaning the number of affected users is considerable. We expect the number of affected apps and users to increase as more developers incorporate the newer version of Taomike library.

The infected apps are not limited to a single developer or third party store as many developers appear use the Taomike library. Some of the infected apps purport to contain or display adult content.

We do not know how Taomike is using the stolen SMS messages, but no library should capture all messages and send them to a system outside the phone. In version 4.4 of Android (KitKat) Google began preventing apps from capturing SMS messages unless they were defined as the “default” SMS app.

Users outside of China and those that only download apps from the official Google Play store are not at risk from this threat.

To protect Palo Alto Networks customers from the Taomike SMS stealer, we’ve made the following protections available:

• Palo Alto Networks WildFire will automatically identify and block malicious APK samples containing the SMS stealing Library
• Threat Prevention signature 14798 will detect and block the malicious C2 communication, including the SMS upload traffic from Taomike library
• Palo Alto Networks AutoFocus users can identify and investigate this threat using theTaomike tag

Conclusion

Even popular third party monetization platforms are not always trustworthy. When developers incorporate the libraries into their apps they need to carefully test them and monitor for any abnormal activities. Identifying monetization and advertising platforms that behave poorly and abuse their users is something that our industry must to do ensure the safety of all mobile devices and their users.

Acknowledgement:

We greatly appreciate the help from Rongbo Shao from Palo Alto Networks in working on the Threat Prevention signature. We would also like to thank Ryan Olson, Benjamin Small, Richar Wartell, and Chris Clark from Palo Alto networks in publishing the discovery.

Shawn Jin, Zhi Xu and Claud Xiao

[Palo Alto Networks Blog]

Today is Back to the Future day, and the date above, as all fans of the iconic movie know, is what was programmed into the DeLorean time machine. The concept of time travel has long fascinated me, and thinking about this special day got me also thinking about how we deal with cyber threats.The approach to endpoint security still relied upon by most organizations has been largely unchanged for decades. That’s right, signature based malware detection is very old technology. It relies on prior knowledge of a threat in order to detect and eradicate it. Even newer approaches require prior knowledge in the form of indicators of compromise (IOCs) or behavioral patterns to look for. This approach poses significant challenges when it comes to preventing security breaches. If your approach is based on detecting the fact that something bad has occurred, then how can you prevent that bad thing from happening? Do you need a time machine for that?

It turns out our researchers here at Palo Alto Networks have solved that problem. We launched Traps about 12 months ago with the goal to redefine endpoint security by providing the much-needed ability to prevent advanced threats on the endpoint. Traps has been performing amazingly well when it comes to preventing previously unknown threats, without the need for any product updates. The reason for this is because it focuses on preventing the core techniques that are used by all exploits. And we didn’t need a time machine to get there.

Let’s examine the evidence

Exhibit A:

A Traps customer in the banking industry recently reported to us that Traps successfully prevented an Adobe Flash exploit from April 2015. This, in and of itself, is not unusual because we know that Traps prevents exploitation of unpatched vulnerabilities all the time. The interesting part of this story is the version of Traps the customer was running. An early Traps customer, they still had a system running Traps v2.3.6, which was released about a year before this vulnerability and the associated exploits became known. So a version of Traps from March 2014, never updated, prevented a zero day exploit in April 2015.

Exhibit B:

In July 2015 a series of Adobe Flash zero day vulnerabilities were disclosed as the result of an unfortunate data breach. The public was left waiting for patches while attackers began exploiting those vulnerabilities. Even organizations that deployed every security patch immediately upon release were left vulnerable for weeks. However, those organizations running Traps were never vulnerable, regardless of whether patches were deployed. Traps simply prevented the exploit techniques leveraged by all of these exploits.

Figure 1. Adobe Flash zero day timeline, July 2015

I’ll leave it to you to examine the evidence and make your own conclusions. Is the technology that underlies Traps fundamentally powerful and innovative? Or does someone on our R&D team have a DeLorean in the garage? Either way, Traps is redefining the endpoint protection market by enabling organizations to truly prevent unknown exploits and malware.

To learn more about Traps, visit our resources page.

Sebastian Goodwin

[Palo Alto Networks Blog]

We see a lot of RFPs as enterprises and service providers go through the process of modernizing their security infrastructures. The requirements typically include these specifications relating to scale:

• Device throughput and latency
• Number of sessions
• Sessions per second
• Number and speed of network interfaces
• VLAN capacity
• Central management capabilities
• Rule base size
• Logging capacity

Our products have no problem meeting those requirements, but as we respond to these RFPs, it seems that the true objective of security at scale is not well-served by the questions. Security at scale is not simply a matter of speeds and feeds. The goal is to achieve effective, operationalized security at ever-growing scale and in highly dynamic environments. The success factors are in these areas:

• Expanded definition of throughput
• Security policy
• Automation
• Orchestration

Let’s take a closer look at each of these areas:

Throughput

The relevant metric for scaling with respect to throughput is in terms of application visibility, application control and threat prevention. Ports and protocols have become irrelevant in terms of their ability to control what users actually do on a network. Therefore it only makes sense that throughput requirements are defined in terms of the security objectives: controlling who can do what, where and when on the network.

Security Policy

The relevant metric here is not how many rules can be configured. Security policy in traditional port-based firewalls involves translating the requirements of an application or service into port, protocol and IP address rule definitions. As an example, enabling Sharepoint requires opening TCP ports 80, 443, 16500–16519, 22233–22236, 808, 32843, 32844, 32845, 5725, UDP 389, 53, 464, 49152-65535, 2015–5000, with the correct source and destination IPs associated with each rule definition. Because large-scale networks are dynamic, it is common practice to use “any” in place of explicit addresses. As more services are enabled and more ports are opened up, the network is exposed to those ports being exploited for malicious purposes. Compounding the problem, rules often stay in place after they are no longer needed. In short, more rules don’t make for more security – quite the opposite.

Our approach to security policy that scales starts with policy definitions that are directly based on applications and business processes. Take the example of SharePoint. Rules are based on business requirements – who needs access, to what specific subfunctions (e.g., admin, docs, calendar), and what content (file types) should be allowed in the context of user identity and subfunction. This approach to application enablement is easier to configure and test, and it maps directly to policy objectives. Policy maintenance is also scalable. Using Dynamic Address Groups, our platform learns when application services are no longer needed (such as when servers are decommissioned or moved) and the rules adjust accordingly. Policy stays in sync with the network and the business.

Automation

When you are thinking about scale, automation should be top of mind. There are a couple of dimensions to automation. First, there is automation in terms of response to threats. The threat world has become fully automated. Attackers have managed to automate malware creation, dissemination and use – as evidenced by our threat intelligence cloud, which finds thousands of new malware variants every day. In order to be effective, a security platform must scale in terms of automated detection and response to these threats.

Automation is also a requirement for effective incident response – the means provided for correlating events, prioritizing response and recovery. What we see in many products are disparate sets of uncorrelated logs, which make it time-consuming and difficult to determine which events require investigation, and a lack of support for conducting investigations.

Some of the ways our platform delivers security at scale through automation include:

1. WildFire threat intelligence cloud: the largest, most automated APT defense system in the world.
2. Integrated logs: no need cross check events in multiple logs.
3. AutoFocus: actionable threat intelligence.
4. Automated correlation engine: connects isolated network events to reveal attacks and compromised hosts.

Orchestration

As service providers and enterprises move to software-defined networking (SDN) and network function virtualization (NFV), the need to embed and orchestrate security is apparent. We have seen that in traditional, physical networks the challenge of achieving security at scale is untenable using traditional port-, protocol- and IP address-based approaches. In a dynamic, virtualized world, the limitations of traditional approaches are even more pronounced.

An application-oriented approach to security policy provides a foundation for software-defined, orchestrated security. We have leveraged several fundamental advantages of our platform architecture to enable security orchestration in a software-defined world:

• Security policy is abstracted away from elements tied to the physical world of networking (ports, protocols, etc.).
• A full set of APIs enabling programmatic control of policy and configuration.
• Dynamic Address Groups enabling our security platform to automatically instantiate policy where and when it is needed.
• In-depth integration with leading orchestration platforms: VMware NSX, OpenStack, and Cisco ACI, as well as public cloud (Amazon AWS).

Final Thoughts

When the time comes to modernize your security infrastructure and perhaps issue an RFP to your short list of suppliers, you really should “think outside the box” when it comes to security at scale. Think about how the solution will enable you to scale policy, business process enablement, threat response and security orchestration.

Jonathan Lewis

[Palo Alto Networks Blog]