Year: 2015

The Wounded Warrior Project’s purpose is to “raise awareness and enlist the public’s aid for the needs of injured service members” in our country. This past weekend, the nation watched the 116th edition of the massive football rivalry between the Cadets of the United States Military Academy and the Midshipmen of the United States Naval Academy. To celebrate that, and to support the Wounded Warrior Project, Palo Alto Networks hosted several injured veterans, and their families, in a luxury suite at the game.

Our Federal Chief Security Officer, U.S. Army Major General John Davis (Retired), and I had the opportunity to thank the brave men and women before the game; and host these Wounded Warriors, their families, and, yes, one good-looking support dog in the suite for the day. We were honored, but humbled, to have the chance to support the Wounded Warrior Project’s critical mission and ongoing work.

These injured veterans and their families have borne the burden of our past wars. They have stood up to fight for the things they believe. Army Chaplain Matthew Pawlikowski, in his opening prayer before the game, said it best:

“Gathered on this gridiron, we are grateful for such rough and rugged souls as these cadets and midshipmen, strong in spirit and in sinew. We are especially mindful of our first-class cadets and midshipmen, bristling on the brink of becoming soldiers, sailors, marines, ready today to happily visit violence on each other, and if need be, some day, sometime soon, on the enemies of the world, so that our citizens, our ally citizens, indeed the same citizens of all countries, can sleep safe and sound in peace.

For those of us who have fought, who can fight, who will fight, our country’s wars pray for peace more than those who have never served can ever know, for we willingly face the horrors from which others are thankfully spared.

But if peace on earth be not granted us in this season of our lives,
then we pray, almighty god, that on these fields of friendly strife,
be sown the seeds that on other fields on other days will bear the fruits of victory.  

Amen.”

Our injured veterans know this story all too well. You can support them and the Wounded Warrior Project by getting involved. Learn how by visiting the Wounded Warrior Project website.

Rick Howard

[Palo Alto Networks Blog]

This is the tenth in our series of cybersecurity predictions for 2016. Stay tuned for more through the end of the year.

There are few areas of cybersecurity that present more promise than the concept of sharing threat intelligence to make online communities, and the Internet as a whole, a safer place.

No single organization is capable of achieving complete visibility into the threat landscape. But by joining together and sharing threat intelligence across the industry, we can enhance our collective immune system. The challenge, as is often the case, has been around putting that into practice.

There have been pockets of innovation, such as the Information Sharing and Analysis Centers (ISACs) or security vendors sharing intelligence between their customers. But as attackers continue to conduct successful cyberattacks around the world, this is clearly not enough. Current efforts provide value, but they are often cumbersome and only accessible to larger and more sophisticated security operations teams. There is essentially a high “barrier to entry,” with manual analysis required to consume, verify, analyze and implement any changes to an organization’s policy, even with adequately shared intelligence.

This requirement has limited the number of organizations who share intelligence, meaning we have less of it available than we should. Now, imagine a world where every security team can turn their network into a sensor and automatically implement protections for new attacks as they happen. This puts malicious actors at a disadvantage, requiring them to spend immense resources to discover new exploits, construct new malware, and employ new techniques.

The past year has shown us early indicators that 2016 will be the year organizations truly embrace – and reap the benefits of – shared threat intelligence. We will see this change the way both security vendors and the security community at large operate. I anticipate three specific changes:

1. Threat intelligence is not intellectual property

Organizations have historically been hesitant to share data on threats. From a security vendor side, this stems from a common belief that their product differentiation is dependent on keeping this intelligence a closely guarded secret.

From a user perspective, many organizations have also operated under the assumption that sharing intelligence with their competitors could expose sensitive information or put them at a competitive disadvantage. But, in 2016, we will see more vendors come to the realization that their users, and the community, have come to expect more from them. In order to offer the best protections possible, vendors will begin to share intelligence with each other on a wider scale.

2. Public and private data sharing

There has never been more focus from the United States government on the sharing of threat intelligence, with President Obama directing the Department of Homeland Security (DHS) to lead the charge to enable public and private entities to share intelligence with each other inExecutive Order 13691.

This coming year will see the result of these efforts formalized and put into practice, withInformation Sharing and Analysis Organizations (ISAOs) being established and intelligence shared across private, non-profit and government agencies. Spurred by this innovation, we will see governments beyond the U.S. adopt similar policies.

3. Campaigns, not samples

We will see an evolution in what is being shared, with a move toward more adversary- and campaign-oriented intelligence. Traditional efforts have been focused on indicators such as hash values, which provide minimal actionable value to the organizations receiving them. Instead, we will see more effort around malware family and adversary attribution, which provide the context needed to understand the threat and develop relevant protections against them. Simply sharing data will no longer be good enough; we have to share the right intelligence, with actionable recommendations.

The coming year represents the fruition of the great promise in threat intelligence sharing. The world is changing, and both vendors and users must adopt a more proactive stance to sharing, lest they risk being left in the dust by those who do.

We have a responsibility as a security community to do everything in our power to prevent cyberattacks, which includes sharing as much intelligence as possible. While there is a great deal of momentum in 2016, we can do more to reap the benefits of this trend. Ask yourself how your organization can integrate and contribute to keeping our community safe online.

Want to explore more of our top 2016 cybersecurity predictions? Register now for Ignite 2016.

[Palo Alto Networks Blog]

In October 2015, we discovered a malicious payload file targeting Apple iOS devices. After investigating, we believe the payload belongs to a new iOS Trojan family that we’re calling “TinyV”. In December 2015, Chinese users reported they were infected by this malware. After further research, we found the malware has been repackaged into several pirated iOS apps that are available for download via multiple channels. In this blog, we will discuss how the TinyV Trojan spreads and how it works.

Repackaging and Spreading

TinyV was repackaged into some pirated iOS apps for jailbroken devices. Infected iOS apps include “Watermelon Player (西瓜播放器)”, “Youku (优酷)”, “iQiYi (爱奇艺)” and others. After repackaging, these apps were uploaded to websites for downloading.

The infected Watermelon Player was available from its official website xigua[.]com. It is advertised as an app for watching pirated videos online for free. The infected versions of Youku, iQiYi, and other apps were hosted on third party iOS app download sites such as iosqgg[.]com and piqu[.]com (which belongs to a tool named “PiQu Apple Helper 批趣苹果助手”). They were advertised as modified ad-free versions of those popular video players (in China).

Figure 1. Watermelon Player’s official website hosts the infected app

Figure 2. A third party website hosting infected “ad-free” video players

Figure 3. Another third party iOS app downloading website hosting infected apps

When using an iOS device to access piqu[.]com to download the pirated version of Youku, a URL like the following is accessed:

• itms-services://?action=download-manifest&url=https%3A%2F%2Fappsre.com%2Fdj_plist_data.php%3Fdata%3DYmlkPWNvbS55b3VrdS5Zb3VLdSZu…

This URL will re-direct the iOS device to download a PLIST file hosted in “appsre[.]com” and then to install an enterprise app described by this PLIST file. According to the PLIST file, the IPA installer file to be downloaded is “pq_com.youku.YouKu.5.0.ipa”, which is also hosted on appsre[.]com.

Figure 4. The infected app installer was actually hosted on appsre.com

TinyV is repackaged differently than prior iOS or OSX malware such as WireLurker. In Watermelon Player’s iOS installer file, “com.xiaoxiaov.ipa”, there are actually two executable files. One is the main executable Mach-O file we expect and the second is Mach-O dynamic library file named “xg.png”. In the main executable file’s import table, the last import entry is “@executable_path/xg.png”. Which means after the app is executed, the xg.png file will be loaded (and the code in it will be executed). Note that the main executable and the xg.png were not compiled in the same environment as the xg.png was infected by the XcodeGhost malware while the main executable wasn’t.

Similarly, in the infected version of Youku, there are some extra Mach-O dynamic library files named “dj.png”, “macro_off@2x.png” and “zippo_on@2x.png” in addition to its main Mach-O executable file “YoukuiPhone”. The TinyV author modified the original YoukuiPhone file, added “@executable_path/zippo_on@2x.png” and “@executable_path/dj.png” to its imports table.

Figure 5. Import table of the infected app’s main executable

The loaded xg.png will invoke its -[hlNDkcAzamMgoaQm downloadDeb] method to connect with the C2 server wx[.]iosyy.me and fetch configuration information. The configuration supplied by the C2 specified a “debUrl” that points to the URL of a ZIP file, and specified a “shName” with the value “zipinstall”.

Figure 6. The extra Mach-O dynamic library accesses a URL supplied by its C2 to download a malicious payload

In the infected Youku, “macro_off@2x.png” will access another page on the same C2 server to get its configuration. This time the “debUrl” value is encrypted with an XOR algorithm. Despite the attempt at obfuscation, after decrypting with the key “0xaf”, the same URL is shown.

Malicious Behaviors

After getting configuration from its C2, TinyV will download a ZIP file from the given “debUrl” value. The ZIP file examined here was hosted on another C2 server, apt[.]appstt.com. While we were writing this report, the URL returned a 404 error. However, when we initially investigated it in late October, the URL was still alive and a “deb.zip” file was downloaded.

In the deb.zip, there are 4 files:

• safemode.deb, which is the official MobileSafety tweak provided by Saurik
• freeDeamo/usr/bin/locka, which is a Mach-O executable that implemented malicious behaviors;
• freeDeamo/Library/LaunchDaemons/com.locka.plist, which is a PLIST file used to config “locka” as a launch daemon in iOS;
• freeDeamo/zipinstall, which is a shell script file.

After downloading and decompressing this ZIP file, xg.png will execute the zipinstall script to install locka and com.locka.plist as a launch daemon as detailed below.

1. Copying locka to /usr/bin, changing its user and group to root:wheel, and changing its file permission to 755;
2. Copying com.locka.plist to /Library/LaunchDaemons/, changing its user and group to root:wheel, and changing its file permission to 644;
3. Executing /bin/launchctl to load the com.locka.plist.

Figure 7. The malicious executable file is installed as a launch daemon

The locka file implements the main malicious behaviors of TinyV, including:

• Connecting with its C2 server to get remote commands
• Installing specified IPA file or DEB file(s) in the background
• Uninstalling specified IPA app or DEB package(s) in the background
• Changing the /etc/hosts file

Figure 8. Some of the functions in locka

Just like the previously discovered Trojan YiSpecter, this locka implemented IPA file installation and uninstallation via iOS private APIs is defined in the MobileInstallation framework.

Figure 9. TinyV invokes private APIs

Another interesting characteristic of this Trojan is the code in locka was obfuscated with name mangling and junk code insertion techniques, which made it much harder to reverse engineer.

Figure 10. The malicious code is inserted with a lot of junk code

It’s also worth noting that we found a function named “ClassStaticFunctionHook” that implemented a runtime hook by itself in a piece of repackaged code. Right now the function is only used to hook an advertisement SDK’s code. However, it could be used to implement much more dangerous behaviors in the infected apps. Previously discovered iOS malware uses the CydiaSubstrate framework to hook. This is the first time we have seen a real world iOS malware sample implement standalone hooking functionality.

Infections

On December 12, TinyV began to promote an iOS jailbreak tweak named “XZ Helper (协奏助手)”. Many victims in China found the XY Helper tweak on their iOS devices. Because of TinyV’s code implementation and variety of C2 server commands, even if a victim deleted the promoted tweak, TinyV would immediately install it again. Some victims discussed this abnormal phenomenon in forums including Weiphone and Zhihu. So far we have only observed the malware infecting users in mainland China.

Mitigation

As always, we suggest iOS users do not jailbreak their devices or install any enterprise apps from untrusted sources.

Palo Alto Networks has updated WildFire signatures to block all related C2 domains.

Acknowledgements

We would like to thank CDSQ from WeipTech for sharing infection cases with us.

Appendix

SHA-256 of samples

09fb33e3fe30e99a993dbf834ea6085f46f60366a17964023eb184ee64247be9 deb.zip

b564a919ef7a7f64c5023cbae709a86201e3d78b1604b63296466448167aaba4 locka

bdb452b56b21d3537de252d612b2469c752b2a9f7e0cc0d45624bedf762cfc7b com.xiaoxiaov.ipa

4242b0055bc53125cef00f12320eaaebeb7c55eb54303b21e8a5f9e54cc7735e pq_com.youku.YouKu.5.0.ipa

96f5698271c9b79e78a6f499bd74b4eb78d00f7247db5dcb3b65ba8ecbf4a098 pqcom.qiyi.iphone.ipa

c6ec85a4aedfdd543f1c20fdf1ed15923e257c9664fd8c5ea38826dd47c0322d pq_weixin63820151203.ipa

Claud Xiao

[Palo Alto Networks Blog]