Slingshot Orbit of Technology

There is now word of a new security hole discovered in a basic protocol used for encrypting web traffic. Its name is POODLE, which stands for Padding Oracle on Downgraded Legacy Encryption, and it was discovered by three Google security researchers—Bodo Moller, Thai Duong, and Krzysztof Kotowicz – they published a paper (.pdf). POODLE instead targets the clients allowing a man-in-the-middle attack to decrypt “secure” HTTP cookies and is estimated that SSLv3 accounts for between 1% and 3% of all Internet traffic. Heartbleed and Shellshock were vulnerabilities that allowed an attacker to hack a server. This makes the third major vulnerability released on the Internet this year and is another warning that this level of vulnerability discovery may be the new shape of things to come.

POODLE affects SSLv3 or version 3 of the Secure Sockets Layer protocol, which is used to encrypt traffic between a browser and a web site or between a user’s email client and mail server. POODLE is a death blow to this version of the protocol; it can only reasonably be fixed by disabling SSL v3.0 altogether. It’s not as serious as the recent Heartbleed and Shellshock vulnerabilities, but POODLE could allow an attacker to hijack and decrypt the session cookie that identifies you to a service like Twitter or Google, and then take over your accounts without needing your password.

A test for your browser is available at this link

To exploit the vulnerability, you must be running javascript, and the attacker has to be on the same network as you—for example, on the same Starbucks Wi-Fi network you’re using. This makes it less severe than an attack that can be conducted remotely against any computer on the Internet.

How to test for SSL POODLE vulnerability?

$ openssl s_client -connect google.com:443 -ssl3

If there is a handshake failure then the server is not supporting SSLv3 and it is secure from this vulnerability. Otherwise it is required to disable SSLv3 support.

How to disable the SSLv3 support on Nginx?

In nginx configuration, just after the “ssl on;” line, add the following to allow only TLS protocols:

ssl_protocols TLSv1.2 TLSv1.1 TLSv1;

How to disable the SSLv3 on Apache?

SSLProtocol +TLSv1 +TLSv1.1 +TLSv1.2

Here are some additional articles:

• POODLE Attack and SSLv3 Support Measurement
• Imperial Violet – Poodle Attack on SSLv3
• Dancing Poodles

There’s a whole list of Shellshock PoCs here on Github including the one for OpenVPN – Shellshocker PoCs. The exploit walkthrough is available here, including the OpenVPN config and log output – OpenVPN ShellShock PoC.

The Shellshock Bash bug, the gift that just keeps on taking, could also sting OpenVPN users, according to researcher Fredrick Stromberg. Pre-authentication vectors affect communication through the popular and formerly secure VPN platform, he says.

Shellshock affected the crucial and ubiquitous *nix component Bash up to and including version 4.3. Mullvad chief technology officer Stromberg described the flaw in a forum post overnight, adding that he disclosed the vulnerability to OpenVPN sometime last week.

“OpenVPN servers are vulnerable to Shellshock under certain configurations,” Stromberg said. “OpenVPN has a number of configuration options that can call custom commands during different stages of the tunnel session. Many of these commands are called with environmental variables set, some of which can be controlled by the client.

“One option used for username+password authentication is auth-user-pass-verify. If the called script uses a vulnerable shell, the client simply delivers the exploit and payload by setting the username. This attack vector is pre-auth.”

A proof of concept for the exploit has surfaced online. Those using OpenVPN can dodge Shellshock by preventing Bash from running scripts. OpenVPN’s Gert Doering told Threat Post OpenVPN was vulnerable only on systems where /bin/sh points to /bin/bash, or when scripts running bash as an interpreter were called explicitly.

As this was posted, Apple had not yet released a security patch to update the version of Bash so lets look at upgrading Bash via Homebrew instead.

Homebrew is a package manager, similar to apt or yum, which allows Mac users to install open-source packages from the command line. To install, paste this line into your Terminal.

ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

Then, run:

brew doctor
brew update

And type:

brew install bash
sudo sh -c 'echo "/usr/local/bin/bash" >> /etc/shells'
chsh -s /usr/local/bin/bash
sudo mv /bin/bash /bin/bash-backup
sudo ln -s /usr/local/bin/bash /bin/bash
which bash
bash --version

You will need to restart your Terminal/iTerm and confirm the version:

exit
which bash
bash --version

If desired change the rights of the moved backup file:

sudo chmod a-x /bin/bash-backup

Don’t forget to run the test code to confirm your Bash is patched.
[Exploit 1] [Exploit 2] [Exploit 3]

Update 09/29/2014: If you didn’t patch the bug manually, you can download and install Apple’s patch for OS X Mavericks here.

Update 09/30/2014: he updates are available for the other OS X versions:

• OS X Lion
• Mountain Lion

The version after applying this update will be:

• OS X Mavericks:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin13)
• OS X Mountain Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin12)
• OS X Lion:  GNU bash, version 3.2.53(1)-release (x86_64-apple-darwin11)

It looks to me like this is still an incomplete fix. The third vulnerability I’d like to report is the feature itself in bash that allows functions to be passed in the environment, e.g.

env ls='() { echo vulnerable; }' bash -c ls

A friend of mine said this could be a vulnerability gift that keeps on giving. CVE-2014-7169 was discovered very quickly after CVE-2014-6271. Do you think that’s the end of it?

via: http://seclists.org/oss-sec/2014/q3/748