• United States



Six key defenses against Shellshock attacks

Sep 29, 20144 mins
Data and Information SecurityInternet of ThingsNetwork Security

Experts from the SANS Institute offer advice of defending against Shellshock attacks

The number of attempts by hackers to compromise computers through the Shellshock vulnerability is rising, but companies have options for defending against attackers.

Shellshock is the name given to a set of at least six vulnerabilities in GNU Bash, the default command shell found in Linux, Unix and Mac OS X. The flaws in Bash, which stand for Bourne Again SHell, include CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 and CVE-2014-6278.

Security vendor Cloudflare reported Monday that it has counted more 1.5 million distributed-denial-of-service attacks against the Shellshock flaw daily on its network.

Web application firewall vendor Incapsula reported Monday that over the four days since Shellshock was made public Sept. 25, it has deflected more than 217,000 exploit attempts on over 4,115 domains. Incapsula has documented attacks originating from more than 890 IP addresses worldwide.

So, what should companies do to defend against attackers? Experts from the SANS Institute, which provides data, network and cyber security training, offer the following advice:

Use multiple scripts. Paul Henry, a senior instructor at SANS, found he needed multiple scripts in order to test for the half-dozen flaws. He found that the scripts released by vendors for their products were not enough.

“They (the scripts) are simply not tight enough. You’re missing machines,” Henry said. “People need to be really careful and thorough in their scanning. Think it through.”

Fortunately, vulnerability-scanning tools include scripts to test for the various flavors of the Bash vulnerability, so companies should make sure they have all available scripts before testing.

Test using DHCP. One way to exploit the flaw is through a dynamic host configuration protocol (DHCP) message carrying an exploit string.

“You can essentially exploit your own systems by sending an exploit string, like for example a ping, from a DHCP server,” Johannes Ullrich, director of the SANS Internet Storm Center, said. “If a system in your network is vulnerable, it will ping the DHCP server that you’ve set up.”

Apply vendor-supplied rules. Firewalls and intrusion detection and prevention systems need to be updated with the latest rules to block attacks targeted at Bash flaws. Cisco-owned Sourcefire, Juniper Networks, IBM and F5 Networks are among the vendors who have released updates.

Companies that use the popular open-source Bro or Snort intrusion prevention systems (IPS) should install the latest rule set available from the respective community sites.

“The rules out there are pretty good in the sense that they’re unlikely to miss a lot of exploit attempts,” Ullrich said. “The only problem will be false positives.”

Install the latest patches. Many patches sent by vendors are functional, but incomplete. Nevertheless, companies have been advised to apply what is available. Patching once and then forgetting about the problem won’t solve this bug. Instead, system administrators will need to stay on top of vendor-provided patches to update the fixes already in place.

Because of the many variations of Linux, SANS recommends recompiling the patch source code on a test system configured identically with the target machine to avoid causing a problem with software running on the latter computer.

“If you misapply a patch on the wrong (operating system) kernel, you could break something,” Henry said. “My personal preference is to compile on the machine that I’m going to be trying to patch Bash.”

Monitor system logs. Companies need to step up monitoring of server logs to catch anomalies pointing to exploitation attempts or successes. In particular, companies should monitor for outbound pings and outbound Internet relay chat (IRC) and HTTP connections.

“Those are the big ones right now,” Ullrich said.

Companies should be “very cautious” with outbound traffic from an internal server, Henry said. “Normally, a server is going to respond to a query, but the server should not be initiating a new connection by itself to the Internet.”

Check IoTs devices. Companies that use Internet of Things (IoTs) devices, which include DVRs, VoIP phones and consumer-off-the-shelf (COT) hardware, such as modems, routers and video cameras, should ask the respective vendors whether their products are vulnerable. Affected hardware that won’t get patched should be replaced.

Fortunately, very few IoTs devices use Bash. The majority runs instead a set of tools called BusyBox.

“There’s a huge population of vulnerable devices, but only a few of them are exposed and exploitable,” Ullrich said.