POODLE attacks on SSLv3

security-warningThe attack, POODLE, is similar to the BEAST attack and also allows a network attacker to extract the plaintext of targeted parts of an SSL connection, usually cookie data. Unlike the BEAST attack, it doesn’t require such extensive control of the format of the plaintext and thus is more practical.

Fundamentally, the design flaw in SSL/TLS that allows this is the same as with Lucky13 and Vaudenay’s two attacks: SSL got encryption and authentication the wrong way around – it authenticates before encrypting.

A complete description of the flaw can be found at: ImperialViolet

Here some counter measurements that can also be found in the original article.

Chrome users that just want to get rid of SSLv3 can use the command line flag –ssl-version-min=tls1 to do so. (We used to have an entry in the preferences for that but people thought that “SSL 3.0” was a higher version than “TLS 1.0” and would mistakenly disable the latter.)

In Firefox you can go into about:config and set security.tls.version.min to 1. I expect that other browser vendors will publish similar instructions over the coming days.
As a server operator, it is possible to stop this attack by disabling SSLv3, or by disabling CBC-mode ciphers in SSLv3.

Bash Code Injection Vulnerability

This vulnerability is also know by the following name: Shell Shock

Update: again new vulnerabilities found, CVE-2014-7186 and CVE-2014-7187

Update: information on CVE-2014-7186

Update: online ShellShock vulnaribility test system: ShellShock research

Update: First patch round wasn’t complete, look at CVE-2014-7169

bash shellshockPartial information CVE-2014-7169:

“GNU Bash through 4.3 bash43-025 processes trailing strings after certain malformed function definitions in the values of environment variables, which allows remote attackers to write to files or possibly have unknown other impact 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. NOTE: this vulnerability exists because of an incomplete fix for CVE-2014-6271.”

Update: information on CVE-2014-6278

() { _; } >_[$($())] { echo hi mom; id; }

Update: information on CVE-6277
will segfault if vulnerable

() { x() { _; }; x() { _; } <<a; }

Original information CVE-2014-6271:

This vulnerability CVE-2014-6271 could allow for arbitrary code execution. Certain services and applications allow remote unauthenticated attackers to provide environment variables, allowing them to exploit this issue.

How does this impact systems:

This issue affects all products which use the Bash shell and parse values of environment variables. This issue is especially dangerous as there are many possible ways Bash can be called by an application. Quite often if an application executes another binary, Bash is invoked to accomplish this. Because of the pervasive use of the Bash shell, this issue is quite serious and should be treated as such. Visit your Linux distribution website and make sure you upgrade as soon as possible.

Diagnostic Steps:

To test if your version of Bash is vulnerable to this issue, run the following command:

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

If the output of the above command looks as follows:

vulnerable
this is a test

you are using a vulnerable version of Bash. The patch used to fix this issue ensures that no code is allowed after the end of a Bash function. Thus, if you run the above example with the patched version of Bash, you should get an output similar to:

$ env x='() { :;}; echo vulnerable'  bash -c "echo this is a test"
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
this is a test

Common Configuration Examples:

The below list is not exhaustive, but is meant to give some examples of how this issue affects certain configurations, and why the high level of complexity makes it impossible to specify something is not affected by this issue. The best course of action is to upgrade Bash to a fixed version.

Package Description
httpd CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.
Secure Shell (SSH) It is not uncommon to restrict remote commands that a user can run via SSH, such as rsync or git. In these instances, this issue can be used to execute any command, not just the restricted command.
dhclient The Dynamic Host Configuration Protocol Client (dhclient) is used to automatically obtain network configuration information via DHCP. This client uses various environment variables and runs Bash to configure the network interface. Connecting to a malicious DHCP server could allow an attacker to run arbitrary code on the client machine.
CUPS It is believed that CUPS is affected by this issue. Various user supplied values are stored in environment variables when cups filters are executed.
sudo Commands run via sudo are not affected by this issue. Sudo specifically looks for environment variables that are also functions. It could still be possible for the running command to set an environment variable that could cause a Bash child process to execute arbitrary code.
Firefox We do not believe Firefox can be forced to set an environment variable in a manner that would allow Bash to run arbitrary commands. It is still advisable to upgrade Bash as it is common to install various plug-ins and extensions that could allow this behavior.
Postfix The Postfix server will replace various characters with a ?. While the Postfix server does call Bash in a variety of ways, we do not believe an arbitrary environment variable can be set by the server. It is however possible that a filter could set environment variables.

Frequently Asked Questions:

This FAQ is for the vulnerability CVE-2014-6271 in Bash.

Do I need to reboot or restart services after installing this update?
No, once the new bash package is installed, you do not need to reboot or restart any services. This issue only affects the Bash shell during startup, not already running shells. Upgrading the package will ensure all new shells that are started are using the fixed version.

Are other shells vulnerable to this issue?
Red Hat has tested other shells for this issue. We could not reproduce the behavior seen in Bash. If similar issues are discovered in other shells we will release updates as appropriate.

Are there any possible mitigations against this issue?

Workaround: Using mod_security:

The following mod_security rules can be used to reject HTTP requests containing data that may be interpreted by Bash as function definition if set in its environment. They can be used to block attacks against web services, such as attacks against CGI applications outlined above.

Request Header values:

SecRule REQUEST_HEADERS "^\(\) {" "phase:1,deny,id:1000000,t:urlDecode,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

SERVER_PROTOCOL values:

SecRule REQUEST_LINE "\(\) {" "phase:1,deny,id:1000001,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST names:

SecRule ARGS_NAMES "^\(\) {" "phase:2,deny,id:1000002,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

GET/POST values:

SecRule ARGS "^\(\) {" "phase:2,deny,id:1000003,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271 - Bash Attack'"

File names for uploads:

SecRule  FILES_NAMES "^\(\) {"  "phase:2,deny,id:1000004,t:urlDecode,t:urlDecodeUni,status:400,log,msg:'CVE-2014-6271  - Bash Attack'"

These may result in false positives but it’s unlikely, and they can log them and keep an eye on it. You may also want to avoid logging as this could result in a significant amount of log files.

Workaround: Using IPTables:

A note on using IPTables string matching:

iptables using -m string --hex-string '|28 29 20 7B|'

Is not a good option because the attacker can easily send one or two characters per packet and avoid this signature easily. However, it may provide an overview of automated attempts at exploiting this vulnerability.

Note: Despite of the above workarounds, We strongly recommends to apply the security advisory which fixes this issue.

Remote resources:

ShellShock exploitation vectors
ShellShock Proof of concept code

The Heartbleed Bug

CVE-2014-0160 – Heartbleed Bug

CVE-2014-0160 HeartbleedThe Heartbleed Bug is a serious vulnerability in the popular OpenSSL cryptographic software library. This weakness allows stealing the information protected, under normal conditions, by the SSL/TLS encryption used to secure the Internet. SSL/TLS provides communication security and privacy over the Internet for applications such as web, email, instant messaging (IM) and some virtual private networks (VPNs).

The Heartbleed bug allows anyone on the Internet to read the memory of the systems protected by the vulnerable versions of the OpenSSL software. This compromises the secret keys used to identify the service providers and to encrypt the traffic, the names and passwords of the users and the actual content. This allows attackers to eavesdrop on communications, steal data directly from the services and users and to impersonate services and users.

What leaks in practice?

We have tested some of our own services from attacker’s perspective. We attacked ourselves from outside, without leaving a trace. Without using any privileged information or credentials we were able steal from ourselves the secret keys used for our X.509 certificates, user names and passwords, instant messages, emails and business critical documents and communication.

How to stop the leak?

As long as the vulnerable version of OpenSSL is in use it can be abused. Fixed OpenSSL has been released and now it has to be deployed. Operating system vendors and distribution, appliance vendors, independent software vendors have to adopt the fix and notify their users. Service providers and users have to install the fix as it becomes available for the operating systems, networked appliances and software they use.

Why it is called the Heartbleed Bug?

Bug is in the OpenSSL’s implementation of the TLS/DTLS (transport layer security protocols) heartbeat extension (RFC6520). When it is exploited it leads to the leak of memory contents from the server to the client and from the client to the server.

You can check if you’re vulnerable via the following link: http://filippo.io/Heartbleed/

Source: heartbleed.com

Update:

Make sure that you only update your password if that site is no longer vulnerable.

But suggestions by Yahoo and the BBC that people should change their passwords at once – the typical reaction to a security breach – could make the problem worse if the web server hasn’t been updated to fix the flaw, says Mark Schloesser, a security researcher with Rapid7, based in Amsterdam, Netherlands.

Doing so “could even increase the chance of somebody getting the new password through the vulnerability,” Schloesser said, because logging in to an insecure server to change a password could reveal both the old and new passwords to an attacker.

Source: The Guardian

NTP reflection attacks

NTP reflection attacks across the Internet.

reflection-attackNTP is the Network Time Protocol, it is a relatively obscure protocol that runs over port 123 UDP and is used to sync time between machines on a network. If you have ever set up a home computer or server and been asked which time server you want to use, that is an NTP connection.

NTP is one of those set-it-and-forget-it protocols that is configured once and most network administrators don’t worry about it after that. Unfortunately, that means it is also not a service that is upgraded often, leaving it vulnerable to these reflection attacks.

How do NTP reflection attacks work?

Similar to DNS amplification attacks, the attacker sends a small forged packet that requests a large amount of data be sent to the target IP Address.

In this case, the attackers are taking advantage of the monlist command. Monlist is a remote command in older version of NTP that sends the requester a list of the last 600 hosts who have connected to that server. For attackers the monlist query is a great reconnaissance tool. For a localized NTP server it can help to build a network profile. However, as a DDoS tool, it is even better because a small query can redirect megabytes worth of traffic:

[user@server ~]# ntpdc -c monlist [hostname]
remote address          port local address      count m ver code avgint  lstint
===============================================================================
localhost.localdomain  53949 127.0.0.1              1 7 2      0      0       0
tock.usshc.com           123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      53
198.52.198.248           123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      54
rook.slash31.com         123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      55
eightyeight.xmission.c   123 xxx.xxx.xxx.xxx        1 4 4    5d0      0      56

 

Most scanning tools, such as NMAP, have a monlist module for gathering network information and many attack tools, including metasploit, have a monlist DDoS module.

How can you protect your servers? The easiest way to update to NTP version 4.2.7, which removes the monlist command entirely. If upgrading is not an option, you can start the NTP daemon with noquery enabled in the NTP conf file. This will disable access to mode 6 and 7 query packets (which includes monist).

By disabling monlist, or upgrading so the the command is no longer there, not only are you protecting your network from unwanted reconnaissance, but you are also protecting your network from inadvertently being used in a DDoS attack.

NTP security notice


Reference: NTP public service project