This article will address Mobile App Protection against Shellshock. Since last Thursday, Shellshock has been making waves across the web with breaking news and a major threat to organizations at large. So unless you’ve been living under a rock, you probably heard about Shellshock, a.k.a. Bashdoor. However, for those of you who aren’t really 100% sure what Shellshock is, I’d like to give an easy-to-understand explanation.
First, you need to understand what environment variables are. Wikipedia defines environment variables as “a set of dynamic named values that can affect the way running processes will behave on a computer”. To clarify, environment variables are a list of settings that each process inherits from its parent, they can also be used to pass information. The parent will create an environment variable with information and will then run the child process which will now have that information in an environment variable.
A shell is a program on your computer that allows you to run commands and interface with the operating system. In *nix operating systems there are different shells, the most popular one in Linux is BASH (Bourne Again Shell). It’s also very popular on many other Unix-based systems.
In the above image you can see some examples of environment variables. A little known fact is that environment variables can also contain functions.
Mobile App Protection Against Shellshock
The shellshock bug allows a malicious attacker to run a command without the user’s permission.
In the above example I added a command after the function definition. The problem is that the command was run as soon as I spawned a new shell (!) despite the fact that I never even called this function. This is because the shell parses all environment variables when it’s starts. If the parsed variable contains a function definition and code following it (like in the example above), the shell will execute this code during the parsing phase.
You might be thinking, this doesn’t seem like such a big deal. After all, someone still needs access to my system in order to add a malicious environment variable and if they already have access to my system, they can do a lot more harm than adding malicious commands to environment variables.
What makes this vulnerability a big deal, is that there are many web-facing services which use environment variables to pass information to inner services. A notable one is CGI (Common Gateway Interface) which is a way for web server software – such as Apache – to communicate with applications on the server.
Before you continue reading, you should to be familiar with HTTP, if not, you can read about it here.
CGI receives input from several facilities including HTTP headers passed from a user’s browser. Now, when CGI calls an application, it provides these HTTP headers to the called application using environment variables. A typical field from an HTTP header can look like this:
application/x-www-form-urlencoded
The above is a content-type header. But what if I send the server a content-type header with the following content (Do not run this command on your system!):
() { :; }; rm -rf/*
If the CGI application calls the shell in any way (whether by calling a shell script or running system(), popen(), exec() etc.) a new shell session will be started. Now, if the default shell is bash (which is very likely), then all environment variables will be parsed and the shell will run “rm -rf/*” which will erase all files in your system, assuming that the CGI application is running under a user with sufficient privileges.
There are different ways to prevent these attacks from succeeding but the single best way is to upgrade bash on your system to a version which has been patched.
Take care and check in soon for additional vulnerabilities and discussions. And remember, Appdome’s All-in-One Mobile Security Suite provides Mobile App Protection against Shellshock.
