My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Worm Backdoors and Secures QNAP Network Storage Devices

Published: 2014-12-14. Last Updated: 2014-12-14 18:21:38 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

Shellshock is far from "over", with many devices still not patched and out there ready for exploitation. One set of the devices receiving a lot of attention recently are QNAP disk storage systems. QNAP released a patch in early October, but applying the patch is not automatic and far from trivial for many users[1]. Our reader Erich submitted a link to an interesting Pastebin post with code commonly used in these scans [2]

The attack targets a QNAP CGI script, "/cgi-bin/authLogin.cgi", a well known vector for Shellshock on QNAP devices [3]. This script is called during login, and reachable without authentication. The exploit is then used to launch a simple shell script that will download and execute a number of additional pieces of malware:

"emme" [sha1 611bd8bea11d6edb68ed96583969f85469f87e0f]:

This appears to implement a click fraud script against advertisement network "JuiceADV". The userid that is being used is 4287 and as referrer, http://www.123linux.it is used. The user agent is altered based on a remote feed.

"cl" [sha1 b61fa82063975ba0dcbbdae2d4d9e8d648ca1605]

A one liner shell script uploading part of /var/etc/CCcam.cfg to ppoolloo.altervista.com . My test QNAP system does not have this file, so I am not sure what they are after.

The script also created a "hidden" directory, "/share/MD0_DATA/optware/.xpl", which is then used to stash some of the downloaded scripts and files.

Couple other changes made by the script:

  • Sets the DNS server to 8.8.8.8
  • creates an SSH server on port 26
  • adds an admin user called "request"
  • downloads and copies a script to cgi-bin: armgH.cgi and exo.cgi
  • modify autorun.sh to run the backdoors on reboot

Finally, the script will also download and install the Shellshock patch from QNAP and reboot the device. 

Infected devices have been observed scanning for other vulnerable devices. I was not able to recover all of the scripts the code on pastebin downloads. The scanner may be contained in one of the additional scripts.

[1] http://www.qnap.com/i/en/news/con_show.php?op=showone&cid=342
[2] http://pastebin.com/AQJgM5ij
[3] https://www.fireeye.com/blog/threat-research/2014/10/the-shellshock-aftershock-for-nas-administrators.html

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
4 comment(s)
My next class:
Network Monitoring and Threat Detection In-DepthSingaporeNov 18th - Nov 23rd 2024

Comments

As usual, you're all over it. As you said, we'll be seeing the echoes of this one for a long time to come, it's just too pervasive.

FWIW, here's my review of this attack:
http://blog.sekur1ty.org/2014/12/a-little-shellshock-fun.html
> sets DNS-server to 8.8.8.8

Nothing malicious about that:

Name: google-public-dns-a.google.com
Address: 8.8.8.8

Name: google-public-dns-b.google.com
Address: 8.8.4.4

unless you are watching your own DNS-server logs for "unusual" requests.
Bypassing your own DNS-server will avoid any updates to your logs.
[quote=comment#32763]> sets DNS-server to 8.8.8.8

Nothing malicious about that:
[/quote]

Except that it bypasses any logging and filtering you might be doing in your own DNS servers. It's why we block all outbound DNS at my $DAYJOB except for those coming from our external DNS proxies. Once upon a time I used to watch the firewall logs for any outbound DNS queries being blocked as they were often an indicator of a compromised system. These days, however, someone decided using dnsmasq as a DNS client was a really swell idea so I've got a herd of linux desktops doing attempting to do their own root DNS lookups instead of only using the forwarders DNS tells 'em to. (sigh)

Oh well.

It's still worth noting any IPs any confirmed malware tries sending DNS to and then watching the firewall logs for other DNS queries to those IPs (maybe watching for ANY traffic to those IPs with snort or something similar).
QNAP has a Security Bulletin on how to detect and remove the infection from affected systems:
http://www.qnap.com/i/en/support/con_show.php?cid=74
It is not pretty though.
It requires the user to ssh into the NAS to fully remove the malware.
A reinitialization does not clear it all.
Organizations with dedicated IT staff should be fine following the cleanup instructions.
Home users may find this more difficult (assuming they notice anything is wrong in the first place).

Diary Archives