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 no less important bird than Heartbleed. And now I would like to put together all the necessary information that will help everyone to cope with the situation and avoid possible problems due to an unobvious, at first glance, threat.

To get started, 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 a range of vulnerable IPs, we get the following result:



Simply put, Robert made a bunch of remote machines ping him by simply sending a specially formed request to the network. Anxiety is caused by the fact that he forced these machines to execute an arbitrary command (in this case, harmless 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 topic. But if you are not familiar with Bash , then I recommend that you read the information below to understand the big picture. Bash is a command shell (interpreter), widely used on Linux and Unix systems, usually with connection via SSH or Telnet. Bash can also work as a parser for CGI scripts on a web server, such as Apache. Bash dates back to the 1980s, where it evolved from earlier shell implementations (the name comes from the Bourne shell ) and is incredibly popular. Of course, there are other interpreters, but Bash comes by default on Linux and Mac OS X, which, as you know, is very widespread. This interpreter is even recognized"One of the most common utilities in Linux systems." It is the prevalence of Bash that is the main reason why Shellshock is so dangerous.

This graph gives a clear idea of ​​the ubiquity of Bash:



Half of the Internet runs on Apache (usually installed under Linux), and it really is very, very much. The same article says that we have already crossed the line of 1 billion existing 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 the 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 by the following quote from the NIST vulnerability database :

GNU Bash through 4.3 processes trailing strings after function definitions in the values ​​of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution.

Vulnerabilities are assigned a level of “10 out of 10”, that is, there is nowhere worse. Add to this the ease of attack (Access Complexity is low) and, more importantly, the lack of authentication needed to use Bash using CGI scripts . Let's understand the essence of the bug itself.

The main danger is the ability to arbitrarily set environment variables inside the Bash interpreter, which defines functions. Problems begin when Bash continues to process interpreter commands after defining a function, which allows for an attack with code injection. Take just one line from Robert's example:

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

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 is also found there that the path and query string can also be a potential attack vector.

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

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

It must be remembered that the capabilities of attackers extend far beyond pinging specific addresses, as in Robert's example, this is just a small example of the ability to control remote machines. Now the question is: what harm can attackers do by executing various commands in the interpreters of remote machines?

What are the potential consequences?

Gaining access to the interpreter has always been a big victory for the attacker, because this is tantamount to gaining control of 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 so many examples of exploits that can be easily applied against a large number of machines.

Unfortunately, when it comes to executing arbitrary code in command interpreters of half of the Internet web servers, the possibilities are extremely great. One of the obvious and most nasty is accessing internal files.. Files with passwords and configurations will be of most interest, but access can be obtained 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 with someone else’s website, not to mention the spread of malware. Or how do you like this? When it comes to worms, it implies 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 also lies in the fact that in this way an epidemic of infections can begin, especially at an early stage, while on most machines this vulnerability is not closed. The infected machines themselves will look for new victims and infect them. And now all public machines are in danger, and when penetrating corporate firewalls, there will be nowhere to be saved. People are already exploiting it right now. The real arms race is now in full swing between those who want to exploit the gap and those who want to close it.

What versions of Bash are affected?

All versions for the past almost 25 years, including 4.3. Compare with Heartbleed, which has been exposed to OpenSSL over the past two years. Yes, people are updating versions, but this is not being done systematically, and anyway, Shellshock threatens a much larger number of machines than Heartbleed.

Alas, the vulnerability may persist in future versions. Already there is information about the patches, which 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 article on seclists.org , published on Wednesday around 2:00 p.m. 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 massive emergence of exploits in the "wild". 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 at risk?

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 the plug to the door lock and light bulb , is becoming more widespread . Many “Internet stuff” use embedded Linux versions with Bash. The same devices have already shown serious security holes, for example, Wi-Fi identification data can be obtained from LIFX bulbs . So even without vulnerabilities like Shellshock, we found ourselves in a situation where, by connecting all kinds of devices and objects to the network, we get many new vulnerabilities in areas that were previously absolutely safe.

This presents us with many new challenges. For example, does anyone think about putting patches on light bulbs regularly? Given the "durability" of such devices, it is unlikely that anyone will be engaged in supporting firmware. Remember the story with Trendnet cameras that happened a couple of years ago. Undoubtedly, a huge number of them still remain connected to the network, because from the point of view of updating software they are much easier to put and forget. There is a Twitter account entirely devoted to the publication of pictures 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 we will be surrounded by more devices and objects with all kinds of vulnerabilities.

But the Bash interpreter is also already present in many familiar devices, such as home routers. When was the last time you updated its firmware? Of course, if you read this text, then you are probably one of those who regularly does such things. But ordinary users don’t even think about it.

Everything works for us on software from Microsoft, we need to worry?

The short answer is no, the long answer is yes. Despite the fact that there are versions of Bash for Windows, this utility is not widespread for this ecosystem. It is also unclear whether Shellshock's Windows version of Bash is vulnerable.

However, the fact that you work exclusively in a Windows environment does not mean that Bash is not available on machines that serve specific tasks on your network. As an explanatory picture, I want to give an illustration from Nick Craver 's post :



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

I am a system administrator, what can I do?

First, it’s very easy to determine if you are at risk. You just need to execute this command in your interpreter (allowed myself to slightly modify the original command - approx. Pkruglov):

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

If “busted” is displayed, then the vulnerability is present.

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

Instructions for updating Intrusion Detection Systems (IDS) have already appeared, and they must immediately be adopted by various organizations, especially those in which long-term tests are needed before installing patches. Qualys provider has proposed its own way to determine the attack, and probably many other IDS providers are working on this problem.

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

Another question is much more acute: has Shellshock been operated by anyone before? It is difficult to determine if attack vectors were not fixed. And often this will not happen if the attack is carried out through an HTTP or POST request. To the question “were we attacked through Shellshock” the most common answer would be: we have no evidence that we have closed this vulnerability. This leaves owners of websites 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 use Mac OS X, then this vulnerability will be easily (and, hopefully, quickly) closed using the standard update mechanism. Checking if you are at risk is easy with the test :



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

More worrying are devices whose software updates are difficult, such as routers. The problem is aggravated by the fact that routers are often provided for rent by providers and users do not have access to the control panel. Multiply this by a huge number of models. At the same time, flashing the router is also not included in the list of usual cases of the average user.

In short, the tips for users are: install security updates, do not ignore the advice of your provider and the suppliers of the equipment you use with the firmware. Beware of emails asking for information or giving instructions on how to launch the software, such messages often come during phishing attacks that exploit “fashionable” user fears.

Total

Apparently, we are only at the very beginning of our study of the depths of this vulnerability. Of course, many parallels were drawn 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 be scooping up the consequences for a very long time .

But in this case, everything 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, Shellshock makes it possible to inject arbitrary code, which is potentially much more dangerous. In this regard, I agree with Robert: I believe a day or two will pass, and we will understand that these were just flowers. UPD In continuation - new vulnerabilities were discovered in bash





www.linux.org.ru/news/security/10892232 A
universal script for checking for vulnerabilities github.com/hannob/bashcheck