Shellshock, the vulnerability in the Bourne Again Shell (Bash), is taking a new twist and is now being actively exploited in network-attached storage (NAS) devices, according to a new report from FireEye.
The Shellshock vulnerability, first reported Sept. 24, could enable an attacker to inject arbitrary commands into a system where Bash is used. Bash is widely deployed on Linux operating systems, which are found in a wide variety of embedded devices, including NAS boxes.
FireEye reported that, starting on approximately Sept. 26, it began noticing Shellshock-related attacks against NAS devices. The attackers were not just scanning for vulnerable systems; they were also actually attempting to inject code that would allow them to retrieve files.
Currently, FireEye is only aware of a single NAS vendor being targeted: QNAP. While the QNAP NAS devices are targets, James T. Bennet, a staff research scientist at FireEye, told eWEEK that QNAP has already issued a patch.
While FireEye has discovered the attacks, it hasn’t sat idly by and let customer data be stolen. Although FireEye has seen the Shellshock NAS attack attempt to deliver backdoor code, “as far as we can tell, no data was stolen since FireEye blocked the attack from successfully completing,” Bennet said. “If the attacker had been successful, they would have access to any file on the file system—we have no info on what they were after specifically.”
The attacks monitored by FireEye were against universities and research institutes in Korea, Japan and the United States.
Determining whether a NAS devices has been infected via Shellshock is currently somewhat of a manual process.
“We are not aware of any scanner or script to do this for you; however, it is actually fairly easy for a system administrator to know if they have this particular backdoor installed on their NAS,” Bennet said.
He recommended steps a NAS administrator can take to find a NAS Shellshock infection:
1. Check if the following Secure Shell (SSH) key was added to the file at /root/.ssh/authorized_keys:
AAAAB3NzaC1yc2EAAAADAQABAAABAQCmm9yrZmk82sex8JLLeWs/y4v6iI4cxgqm6Y3sDkT/d5WJZ39pm6k6x8Z7mTKyVWJUSV2MOcwzfUuk10jmaT9PO0Og0mAEv5ZQwFKPZaMvXkI/6B/LQx//RkCWLA7l68/8kKeTV/1bU/iLu/kK4xVFVTQFDh4H72cGCuovslTzqaSZjDDkrDx2uGkWXFejoOBCeGm8aDjZchcekAJBlnHhc56N6vjjwNlDi2gw1pmD+gmNafUYQoimbGPPfKK84TZIBlnNdFIBfz/YbAn4Vib/5HJb9JdFVt+sKiVzm4EPVrY4WwRIvhugmPwlazGcYFZQpB6FFJ2FDmlQAQUugyiv [email protected]
2. Check for the existence of any of the following files:
once
term_i686
term_x86_64
3. Check for a process named term_i686 or term_x86_64 listening on a TCP port or having an established TCP connection to another host.
Aside from patching for Shelldhock and then making sure a device has not already been infected, NAS administrators can take other steps to limit risk.
“The best thing you can do, aside from patching is to not leave your NAS directly exposed to the Internet; it is asking for trouble,” Bennet said. “At a minimum, restrict access to only IPs/networks you trust, disabling unneeded services as well as monitoring access logs for unauthorized activity.”
Sean Michael Kerner is a senior editor at eWEEK and InternetNews.com. Follow him on Twitter @TechJournalist.