If you haven’t heard already, the online superbug called ShellShock (biggest ever, bigger than “Heartbleed”) was made known to the public few weeks ago.
Majority of RapidOps clients whose websites are hosted with Greenlight or Anchor, you’re safe. Both hosting providers have confirmed with us that they’ve added a patch to their systems to resolve this threat.
But if you are not hosted by either of the above, we strongly recommended that you get in touch with your hosting provider as soon as possible for a ShellShock update.
For those more curious, here are some more details about ShellShock, the ‘most dangerous threat to internet security’
• What is Shellshock Bug?
Shellshock is a nickname given to a bug in Bash (Bourne Again Shell) command-line interpreter AKA shell. The Bash shell is widely circulated as the default command-line interpreter on many operating systems including most flavours of Linux, UNIX, some flavours of BSD, and Apple OSX.
The Bash shell is also found on many other operating systems like Windows and Android; however it is not installed and/or used by default on these operating systems.
Since announcement of initial Shellshock bug (CVE-2014-6271), related bugs in Bash been found by various security researchers.
• Who all are Vulnerable?
Technically, all the existing Bash users are vulnerable. However, only users who are connected to the Internet are exposed to remote exploitation. Additionally, attacker needs some of the software to provide a route through which Bash can be reached.
Operating Systems running Internet servers are the most vulnerable and likely to be prime target. Home users who have Bash on a PC may also be exposed if they use untrusted networks.
By Default, the average Internet user running operating systems like Windows, Mac, Android or iOS is not vulnerable. But compromise of Internet servers trusted by those users could facilitate other attacks on clients by server, and confidential user data on servers might exposed to the attackers.
• Where Does the Bug Occur?
The bug was found in Bash’s parsing code. There was an error in the way Bash parses environment variables during its initialization sequence. Anything that can manipulate environment variables has potential to be a vector for Shellshock vulnerability.
• How does it make you vulnerable?
The Bash bug allows an attacker to perform same commands as an authentic user. This gives attacker ability to do nearly anything that a normal user can do. An attacker that has access to a remote vector will able to remotely inject Bash commands on system without the authentication.
Note that the attacker is limited to privilege level of the user running Bash instance. However, once an attacker has access in system, they have multiple options for escalating privileges and potentially gaining root access.
• How much serious is it?
When the bug was first publicly disclosed, several hundred thousand web connected servers were readily vulnerable to exploitation. This is our conservative estimate; it is very likely that many of these servers have since been compromised.
This bug is bit trivial to exploit. Special tools and custom code is not required. It is also easy to understand, from a conceptual level. Proof-of-concept scripts, demos and kits are already widely available.
The outcome of exploitation is very severe. It typically allows command injection, remotely, without authentication. Once a vector is found, arbitrary code execution is often trivially obtained.
This bug has existed in the Bash code for over two decades. It’s possible that various individuals have discovered this bug and kept it private. It is also possible that this bug has been used in the wild for malicious purposes prior to its public discovery. And it is equally possible that this bug was unknown to the world prior to its public discovery.
The combination of the large number of vulnerable servers, accessibility of exploit tools and the severe outcome of successful exploitation, means that this vulnerability is extremely severe.
• What security teams can do to protect themselves?
Patch your operating systems. Obtain the latest patches from your vendor and patch your Bash to the latest version. Bear in mind that patches may be reissued by the maintainer and new patches are expected for Bash vulnerabilities which remain unpatched.
Check your exposure. RedHat has an excellent guide on how to determine if your operating system is unpatched and exposed.
If you cannot patch Bash, or a patch is not available for your platform, consider switching to another shell.
Update your network and server security products. Make sure your IPS systems are updated with the correct rule sets to detect and prevent exploitation attempts.
Maintain vigilance against rogue servers and access points in your network and on your premises.
• How effective can IPS be against these vulnerabilities?
IPS and other types of network based detection are very effective for detecting and preventing Shellshock exploits. The string sequence required to trigger the vulnerability is very distinctive and is fairly easy to parse out. The possibility for false-positives is also relatively low, because the malicious data appears in a specific set of places and the string sequence is rarely used elsewhere.
• I’m running Windows OS. Am I safe?
In general, yes. At this time, there is no evidence that an exploitable Windows vector exists, although it is possible.
While it is possible to install Bash on Windows, it would require a specific set of configuration settings and applications (typically Cygwin or WAMP) to create a situation that has the potential of resulting in a working vector for this vulnerability.
• I’m on a Mac OS. Am I vulnerable?
Strictly speaking, yes, and Apple released an update to fix the initial vulnerabilities. In practice, you need to have enabled services, i.e. a web server with CGI, which the typical Mac user does not.
• I’ve applied the patch. Am I secured now?
Not completely. All major Linux distributions now have patches available for CVE-2014-6271 and CVE-2014-7169, the two original issues. Several other related vulnerabilities in Bash remain unpatched. There are no public reports yet of attacks exploiting neither these vulnerabilities nor any known proof of concept attacks and they are more difficult to exploit.
Even the patches for the two main vulnerabilities are not yet stable. Last week Bash maintainer issued a new version of the patch. This version is stricter than the initial patch and was written by Red Hat developers who claimed the initial patch was inadequate. The stricter patch runs a greater, though still small, risk that existing Bash scripts will no longer work. Other vendors, including FreeBSD, NetBSD and VMWare, have gone even further, issuing patches which disabled the vulnerable functionality outright, making incompatibilities more likely.
We hope above information will help RapidOps clients and other to protect themselves and their infrastructure.