The internet is yet again feeling the aftereffects of another “net shattering” vulnerability: a bug in the shell ‘/bin/bash’ that widely affects Linux distributions and is trivial to exploit. The vulnerability exposes a weakness in bash that allows users to execute code set in environment variables, and in certain cases allows unauthenticated remote code execution.
Possible vectors for attack include:
Authenticated SSH sessions: (think of a git server where a user may have ssh account access, but the ssh access is restricted, and suddenly that user is allowed to run commands on that box)
cgi scripts that invoke or use bash (by setting a HTTP header to code designed to exploit this vulnerability, you can get the web server to run code).
Already, real-life exploits are emerging and operations people everywhere are scrambling to patch up their Linux servers. Infrastructure that lives in the cloud especially is at risk, since the IP-ranges for Amazon and other cloud providers are already known, and these servers are already constantly being scanned and attacked by automated systems thousands of times on a daily basis.
At Threat Stack, we specialize in protecting Linux by providing deep-auditing and alerting on cloud Linux infrastructure, and as such I thought it would be interesting to demonstrate how a user could leverage this vulnerability in a real-life application via the cgi-bin attack vector.
Naturally, when I asked myself the question: “what vulnerable web app do I know that still heavily uses cgi-bin scripts to drive their web application?”, Nagios first came to mind. 😉 To create a scenario where I could demonstrate this bug, I set up a VM using a vagrant Nagios setup I found on Github, and installed the Threat Stack agent on that “server”.
The first thing I did was set about reading the Nagios web user interface cgi-bin code to look for a possible attack vector. I quickly found a vulnerability that I could use to pair with the bash bug to provide a compelling exploit. If you drop a “ssi” file, e.g. “common-header.ssi”, the web app will execute that code in order to generate a custom header or footer (presumably for branding purposes or to include additional data), and does this by executing a “system()” call on that file:
Awesome! I dropped a simple bash script into “/usr/share/nagios3/htdocs/ssi/common-header.ssi” to set up conditions for my Nagios “exploit”:
I then crafted a simple “exploit” using curl, by setting my user agent to a string that would get executed by this script on my vulnerable server:
This exploit works as follows:
- It makes a curl connection to the “summary.cgi” page served by Nagios.
- It sets the commands an attacker wanted to run in the User Agent string, which consisted of downloading a script and saving it to /tmp/exploit.sh, and running that script.
- The script itself contained some code that spawned a netcat shell binding to bash, added a cron job to make sure netcat is running, and also attempted to add an ssh key to the user’s home directory.
Running the exploit, I immediately saw some activity from Threat Stack about the network activity: one alert about new process activity from netcat, and another about Nagios spawning a curl process:
Neither of these things are good! By pivoting into the details about the process that triggered each alert, I was able to get a pretty good picture of what happened.
The first thing I investigated was the netcat process, and used the Threat Stack “TTY timeline” which allows us to reconstruct what happened around that process:
Here, you can see Nagios running, then executing “common-header.ssi”, and “./tmp/exploit.sh” running leading up to spawning a netcat bind shell — definitely not good! (Hint: the commands are listed in reverse order)
Walking up the process tree and seeing the processes spawned by the Nagios cgi-bin summary.cgi script confirmed this:
Though this exploit is admittedly contrived, it illustrates one of many attack vectors that could be leveraged in real-life applications that are widely used on Linux today.
Lessons to be learned are:
- Patch quickly! This is not a bug to be trifled with. It’s easy to exploit, and this bug is so new that we have no idea what other attack vectors will emerge in the near future.
- Always be monitoring! Who knows how long this vulnerability was actually known by nefarious parties. With proper monitoring, you have a good awareness of what network and application activity is happening on your box. If your web server ever starts spawning a shell, this is a bad thing 🙂