CVE-2014-6271 And You: A Tale Of Nagios And The Bash Vulnerability

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/, 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/” 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 🙂

Continue reading how security is more and more embedded within ops and best practices on how to do so, here