Thursday, October 2, 2014

The Am I Vulnerable To Shellshock Checklist

There are a ton of people sharing a test to see if your shell is vulnerable to shell shock. However, exploiting the shellshock bug (unlike heartbleed) requires multiple failure points.

It is impossible to precisely define these failure points, and this has the internet in much more fear than is actually warranted. Are you concerned about your vulnerability to the shellshock bug? Perhaps after reading this checklist you will change your mind.

Disclaimer: This checklist is not comprehensive, and will not necessarily be up to date. This checklist attempts to be accurate for the vast majority of servers as of the time it is written. Use your own brains too.

1. Are you on a unix system?

This includes mac, freeBSD, solaris, and linux. If no, you are not vulnerable. Otherwise, proceed to step 2.

2. Are you on a server or a personal computer?

Only servers, or personal computers with server software installed, are likely to be vulnerable. If you don't know, you can probably call yourself safe. Otherwise proceed.

3. Are you using apache mod-cgi or restricted ssh sessions?

If you are using apache mod-cgi proceed to step 4. As for ssh, of course all ssh sessions are restricted except for root, but don't be concerned just yet. In this case the type of restricted ssh session we are referring to means that you have a file in ~/.ssh/authorized keys that limits a user with a key to a specific command. If you are using this on your server proceed to step 5. Otherwise go to step 6. Note that realistically anyone using mod-cgi should patch, just in case. It's really crazy not to if you are using mod-cgi at all.

4. Are you using bash scripts in your cgi bin?

If you use !#/bin/bash then you need to patch. If not, go to step 12.

5. Do any malicious parties have an authorized key to your server?

If so you are vulnerable. If not, you are vulnerable to non-malicious parties doing more than they are supposed to, which is another but less severe type of vulnerability. Patch before they do non-malicious things by breaking out of their session restrictions.

6. Congratulations, you have no mass-targetable vulnerabilities!

At this point you are only vulnerable to targeted attacks from parties that specifically dislike you. Remember that you have a lot to worry about should this be the case, and shellshock might not be the most important thing to patch. exec($_REQUEST(...)) comes to mind as something a bit more pressing than shellshock. Continue to step 7.

7. Do you have any open ports to custom apps?

Noncustom apps could have vulnerabilities too, but so far none have yet come up aside from the two mentioned. For this reason we'll look at custom apps only - web services, database services, etc. If you don't, you are probably completely safe from shellshock! Otherwise proceed to step 8.

8. Do your custom apps set any environment variables based on user input?

This is unlikely. In fact, github searches reveal that php codebases are about 10x more likely to be executing arbitrary user input as setting it in an environment variable. If your custom apps and the libraries they use aren't doing this, you are completely safe from shellshock exploits. Otherwise, keep going on to step 9.

9. Are there high restrictions to setting these environment variables?

Take a moment to reflect on the restrictions of your last answer. When users can set environment variables on your system, do they need to be on a certain IP? Do they need a password? These things might protect you adequately. If not, you may be surprised to hear that we still aren't at an exploit yet and you'll need to go to step 10.

10. Could your custom app run any system commands after setting these variables?

Defining this failure point is difficult and varies from app to app. Some apps like PHP may set an environment variable in a process only responsible for a single page load. Other apps might set it in a persistent daemon. Any processes spawned from these places will inherit the environment variables. Should such a process invoke a system command (even something harmless like `ls`), proceed to step 11. Otherwise, you are safe, but in dangerous waters since custom apps usually change over time.

11. Is your user's default shell bash?

This is either possible with a unix user's configuration, or with a symlink from /bin/sh to /bin/bash. If neither of these things have happened, go to step 12. Unfortunately, if bash is your default shell, you are vulnerable.

12. Are any of your invoked commands bash?

By this I mean, does /bin/sh every invoke the command 'bash ...'? Note that environments are inherited across processes, so you are equally vulnerable if sh launches a process that launches bash. If not, you are in severely dangerous waters but are technically probably safe for now. Congratulations for being right on the edge! To everyone else, you need to patch.


Its far worse than I thought!


thought noone ever. As you can see, the shellshock attack only has certain avenues of effective attacks, and severely limited avenues to targeted attacks. You likely have higher things to worry about, like updating your wordpress site and protection from XSS attacks. There are probably more websites storing passwords in cleartext than websites vulnerable to shellshock.

A blogger claimed to have found three thousand vulnerable servers, but never responded to my comment asking how many total servers had been scanned in the process. Until the answer comes out, we can only assume from the author's tone that it is "very low." The checklist here supports this.

I already made my disclaimer, this list might have some holes for niche servers. Anyone with critiques of my checklist are welcomed and I'll do my best to correct inaccuracies.

No comments:

Post a Comment