Remember Heartbleed ? Shellshock can be attributed to the same "weight category", with the same stylish name, albeit without a cool logo (someone from the marketing department of this vulnerability would have to do this). But Shellshock has the potential to become as important a bird as Heartbleed. And now I would like to put together all the necessary information that will help all who wish to cope with the situation and avoid possible problems due to the seemingly unobvious threat.

To begin, let me share with you some information from the blog of Robert Graham , who conducted an excellent vulnerability analysis. Consider the following HTTP request:

target = 0.0.0.0/0 port = 80 banners = true http-user-agent = shellshock-scan (http://blog.erratasec.com/2014/09/bash-shellshock-scan-of-internet.html) http-header = Cookie:() { :; }; ping -c 3 209.126.230.74 http-header = Host:() { :; }; ping -c 3 209.126.230.74 http-header = Referer:() { :; }; ping -c 3 209.126.230.74 

If we apply it to the range of vulnerable IP, we get the following result:
')


Simply put, Robert made a bunch of remote machines ping it, simply by sending a specially crafted request to the network. The concern is that he forced these machines to execute an arbitrary command (in this case, an innocuous ping), which opens up tremendous opportunities.

What is bash and why do we need it?

You can skip this section if you are already in the subject. But if you are not familiar with Bash , I recommend reading the information below to understand the overall picture. Bash is a command shell (interpreter) widely used on Linux and Unix systems, usually connected via SSH or Telnet. Bash can also work as a parser for CGI scripts on a web server, for example, on Apache. Bash has its history since the 1980s, where it evolved from earlier implementations of the command shell (the name comes from the Bourne shell ) and is incredibly popular. Of course, there are other interpreters, but Bash goes by default on Linux and Mac OS X, which, as you understand, are very widespread. This interpreter is even recognized as "one of the most common utilities in Linux systems." The prevalence of Bash is the main reason why Shellshock is so dangerous.

This graph gives a visual representation of the omnipresence of bash:



Half of the Internet works on Apache (usually installed under Linux), and this is really very, very much. In the same article, it is reported that we have already crossed the line of 1 billion active websites, and since many of them are located on mass hosting, we are dealing with a huge number of installed copies of Bash. And besides web servers, do not forget about the many other servers and devices running Linux. But back to this later.

Bash is used for a wide range of system tasks, from configuring websites to managing firmware in peripheral devices such as webcams. Such opportunities should not be open to everyone, and theoretically available only to authorized users who have certain access rights. In theory.

What is the essence of vulnerability?

The severity of the situation can be estimated from the following quote from the NIST vulnerability database :

It is clear that it has been possible to follow the rules of the environment. The HTTP Server has been set to meet the privilege of bash execution.

Vulnerability assigned the level of "10 out of 10", that is, there is no place worse. Add to this the ease of executing an attack (Access Complexity low) and, more importantly, no need for authentication to use Bash using CGI scripts . Let's understand the essence of the bug itself.

The main danger lies in the possibility of arbitrarily setting the environment variables inside the Bash interpreter, which defines the definition of functions. Problems begin at the moment when Bash continues to process interpreter commands after defining a function, which allows an attack with code injection. Take only one line from Robert’s example:

http-header = Cookie:() { :; }; ping -c 3 209.126.230.74

The function definition is () { :; }; () { :; }; and the interpreter command is ping and its parameters. When processing this line with the Bash interpreter, any command can be executed. In the context of the web, this can be done through a mechanism such as a CGI script and optionally through the request header. More information can be found on the seclists.org page, it’s also established that the path and query string can also be a potential attack vector.

Of course, the situation can be mitigated simply by disabling the operation of CGI . But in many cases, this will have a too serious impact on your website and, at a minimum, will require extensive testing to ensure that it works.

The above HTTP request is simple and efficient, being only one of many possible uses of this protocol. If we take into account Telnet and SSH, and, obviously, even DHCP, the scale of the problem grows many times, despite the fact that we are talking only about attacks on web servers. So far, there is a danger only after authentication with SSH , but later we will find other attack vectors.

It must be remembered that the possibilities of intruders extend far beyond the limits of pinging specific addresses, as in the example of Robert, this is just a small example of the very possibility of controlling remote machines. The question now is this: what harm can attackers do when executing various commands in the interpreters of remote machines?

What are the potential consequences?

Getting access to the interpreter has always been a big victory for an attacker, because it is equivalent to gaining control over the server (with the appropriate rights). Access to internal data, reconfiguration of the environment, the spread of malware and so on. The possibilities are almost endless and automated. There are already many examples of exploits that can be easily applied against a large number of machines.

Unfortunately, when it comes to the execution of arbitrary code in the shell of half of the Internet web servers, the possibilities are extremely great. One of the most obvious and worst is getting access to internal files . The files with passwords and configurations will be of the greatest interest, but access will be possible in general to all files.

The same applies to the ability to write files to a remote machine. This is one of the easiest ways to replace pages on someone else’s website, not to mention the spread of malware. Or how about this?



When it comes to worms, it means malicious software that creates its own copies on the target system. An example of a very effective worm is the Samy XSS worm, which infected millions of web pages in less than one day.

The danger of Shellshock is also in the fact that an epidemic of infections may start this way, especially at an early stage, until most of the machines have closed this vulnerability. The infected machines themselves will look for new victims and infect them. And all public machines are now subject to danger, and now there will be no salvation anywhere if penetrating corporate firewalls. People are already exploiting it right now. The real arms race between those who want to use the gap and those who want to close it is in full swing.

What versions of bash are vulnerable?

All versions for the last almost 25 years, including 4.3. Compare with Heartbleed, the dangers of which have been exposed to the OpenSSL version for the last two years. Yes, people update versions, but this is not done systematically, and anyway, Shellshock threatens a much larger number of machines than Heartbleed.

Alas, the vulnerability may persist in future versions. There are already information about patches that were not very effective . So this vulnerability needs to be monitored very carefully, it is not one of those things that you can forget about after installing the patch.

When was the vulnerability discovered?

The first mention I found was in a very short note on seclists.org , published on Wednesday around 14-00 GMT. More information was posted on the same resource an hour later. So this is very “fresh” news, and it is too early to talk about the mass appearance of exploits in the “wild” nature. But this can happen very soon, the probability increases with each passing hour.

As mentioned above, the vulnerability exists in all versions of Bash created over the past 25 years. So, theoretically, all this time, knowledgeable people could use it.

Are our devices under threat?

The question is interesting, because there are many devices that potentially use Bash. I mean the “Internet of Things” (IoT), when the assignment of the IP address of every little thing, from plug to door lock and light bulb , is becoming more widespread. Many “internet stuff” use embedded versions of Linux with bash. The same devices have already shown serious security holes, for example, with LIFX light bulbs you can get identification data via Wi-Fi . So, even without vulnerabilities like Shellshock, we found ourselves in a situation where, by connecting various devices and objects to the network, we get a lot of new vulnerabilities in areas that were previously completely safe.

This poses many new challenges. For example, does anyone think about putting patches on light bulbs regularly? Given the "durability" of such devices, it is unlikely someone will be engaged in supporting firmware. Recall the Trendnet camera story a couple of years ago. Undoubtedly, a huge number of them are still connected to the network, because from the point of view of software updates, they are much easier to install and forget. There is a Twitter account entirely dedicated to the publication of images from such cameras , when their owners do not even know that they are being shot. This is a big problem, because updating the software of peripheral devices is often difficult, so over time more and more devices and objects with all sorts of vulnerabilities will surround us.

But the Bash interpreter is also already present in many familiar devices, for example, home routers. When was the last time you updated its firmware? Of course, if you are reading this text, then you are probably one of those who regularly deal with such things. But ordinary users do not even think about it.

Everything works on Microsoft software, do we have to worry?

The short answer is no, the long one is yes. Despite the fact that there are versions of Bash for Windows, for this ecosystem, this utility is not any widespread. It is also unclear whether the Shellshock vulnerability has a Windows version of Bash.

However, the fact that you are working exclusively in a Windows environment does not mean that Bash is absent on the machines serving the individual tasks of your network. As an explanatory picture I want to give an illustration from the post of Nick Kraver :



As you can see, traffic passes from your Windows environment through non-Windows devices. There may be components that have privileges over the firewall, which can be done then with the help of Shellshock?

I am a sysadmin, what can I do?

Firstly, it is very easy to determine if you are at risk. You just need to execute this command in your interpreter (he allowed himself to change the original command a little - approx. Pkruglov):

 env X="() { :;} ; echo busted" bash -c "echo stuff" 

If "busted" is displayed, then the vulnerability is present.

Of course, you need to close the hole first. The patch will significantly reduce the risk of executing someone else's code at the end of the Bash function. For a number of Linux distributions, for example, Red Hat , instructions have already appeared, so do this as soon as possible (in fact, patches have already been released for most distributions - pkruglov).

Instructions for upgrading intrusion detection systems (IDSs) have already appeared, and they should immediately be adopted by various organizations, especially those in which long-term testing should be carried out before installing patches. The Qualys provider has offered its own way to detect attacks, and probably many other IDS providers are working on this problem.

More cardinal ways include replacing Bash with another interpreter, or blocking the system at risk. Both methods can have far-reaching consequences, they should not be used thoughtlessly. But this is what could be the main feature of Shellshock: the quick adoption of difficult decisions that can have a serious impact on the real business, in order to avoid potentially much more significant damage.

Another question arises much more acutely: Has Shellshock been exploited by anyone earlier? It is difficult to determine if the attack vectors were not fixed. And often this will not happen if the attack is carried out via HTTP or POST request. To the question “were we attacked through Shellshock?” The most frequent answer would be : we have no evidence that we have closed this vulnerability. This leaves website owners and other systems in an unpleasant suspense as to whether they have been compromised.

I am a user, what can I do?

Depends on the specific situation. If you are using Mac OS X, then this vulnerability will be easily (and, hopefully, quickly) closed using the standard update mechanism. You can easily check whether you are at risk by using the test :



This is a simple test, although I doubt that the average user Mac will easily follow the advice and recompile Bash.

More troubling are devices whose software updates are difficult, for example, routers. The problem is aggravated by the fact that routers are often leased by providers and users do not have access to the control panel. Multiply this by a huge number of models. In this case, the flashing of the router is also not included in the list of usual cases of the average user.

In short, the tips to users are as follows: install security updates, do not ignore the advice of your provider and the suppliers of your hardware with firmware. Beware of letters requesting information or giving instructions on how to launch software, such messages often come during phishing attacks that exploit "trendy" user fears.

Total

Apparently, we are only at the very beginning of our study of the depths of this vulnerability. Of course, there have been many parallels with Heartbleed, and in some ways it even helped us. Using the example of Heartbleed, we know that the situation can deteriorate very quickly, and we will rake the consequences for a very long time .

But in this case, things can be much worse than with Heartbleed. If that vulnerability allowed remote access to a small amount of data in the memory of an infected machine, then Shellshock makes it possible to inject arbitrary code, which is potentially much more dangerous. In this regard, I agree with Robert:



I suppose it will take a day or two, and we will understand that these were still only flowers.

UPD. In continuation, new vulnerabilities have been discovered in bash www.linux.org.ru/news/security/10892232
Universal script for checking for vulnerabilities github.com/hannob/bashcheck