SHA-1 Sunsetting, Google, and Your Next Steps.

What is happening, and what was happening?

The SSL Industry and the CA/B Forum have planned for the "sunsetting" (depreciation) of the SHA-1 signing algorithm for quite some time. However, their plan was mainly formed around Microsoft's desires to phase it out in 2017, alongside the end-of-life for Windows XP. This was widely understood to be the approved plan for CAs to follow, and the preparation for moving from SHA-1 to its successor, SHA-2, wouldn't be necessary for many months from now.

However, Google recently made an announcement, in stark contrast to Microsoft's plan, that they are implementing their own SHA-1 sunsetting timeline, which will begin on September 26th 2014.

This timeline has three distinct stages, which will result in degraded visual indicators in Google Chrome (padlock, green-bar) for SHA-1 signed certificates meeting specific criteria (this is discussed in the section "What certificates are affected?" below).

This means it is now necessary to educate and assist our partners and customers on how to make the transition away from SHA-1.

Why?

First, let's understand what SHA-1 does. Both SHA-1 and its successor, SHA-2, are specific types of signing algorithms. Signing algorithms are used as part of the identity validation role that SSL certificates perform. They are mathematical functions (referred to as a "hash") which, when performed, should calculate a persistent and unique value for each file. So, for instance, the Word doc this text is stored in has a unique SHA-1 hash value. If I change a single part of this file – add an extra period somewhere, change a letter, etc. – it will produce a different SHA-1 hash value.

When a certificate is downloaded from a server to the client's browser, a hash is taken of it. The type of hash taken (SHA-1, SHA-2, MD5, etc.) depends on how the certificate is signed. The hash calculated by the browser is compared to the hash value provided by the server, which has been verified by the Certificate Authority (CA) at the time of issuance. If they match, the identity of the certificate and server are verified.

When is this happening?

Google's policy involves three distinct steps, the first beginning on September 26th. On this date, only customers with SHA-1 signed certificates expiring in 2017 are affected. However, the amount of affected certificates will expand in November, and again in Q1 2015. The full details on what certificates are affected is in the below section, "The Nitty Gritty."

What certificates are affected?

Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169)

Red Hat has been made aware of a vulnerability affecting all versions of the bash package as shipped with Red Hat products. 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.

Update: 2014-09-29 05:00 UTC

Malware is circulating that exploits this vulnerability. For more details, see this article.

Update: 2014-09-26 05:15 UTC

Red Hat has become aware that the patch for CVE-2014-6271 is incomplete. An attacker can provide specially-crafted environment variables containing arbitrary commands that will be executed on vulnerable systems under certain conditions. The new issue has been assigned CVE-2014-7169.

Updated bash packages that address CVE-2014-7169 are now available for Red Hat Enterprise Linux 5, 6, and 7, Red Hat Enterprise Linux 4 Extended Life Cycle Support, Red Hat Enterprise Linux 5.6 Long Life, Red Hat Enterprise Linux 5.9 Extended Update Support, Red Hat Enterprise Linux 6.2 Advanced Update Support, and Red Hat Enterprise Linux 6.4 Extended Update Support, and Shift_JIS for Red Hat Enterprise Linux 5 and 6. See alsoResolution for Bash Code Injection Vulnerability via Specially Crafted Environment Variables (CVE-2014-6271, CVE-2014-7169) in Red Hat Enterprise Linux.

Diagnostic Steps

Red Hat Access Labs has provided a script to help confirm if a system is patched against to the Shellshock vulnerability. You can also manually test your version of Bash by running the following command:

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

If the output of the above command contains a line containing only the word vulnerable 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.

Java based Cross platform malware targeting Apache Tomcat servers in the wild

Takashi Katsuki, a researcher at Antivirus firm Symantec has discovered a new cyber attack ongoing in the wild, targeting an open-source Web server application server Apache Tomcat with a cross platform Java based backdoor that can be used to attack other machines.

The malware, dubbed as "Java.Tomdep" differs from other server malware and is not written in the PHP scripting language. It is basically a Java based backdoor act as Java Servlet that gives Apache Tomcat platforms malicious capabilities.

Because Java is a cross platform language, the affected platforms include Linux, Mac OS X, Solaris, and most supported versions of Windows. The malware was detected less than a month ago and so far the number of infected machines appears to be low.

You may think that this type of attack only targets personal computers, such as desktops and laptops, but unfortunately that isn’t true. Servers can also be attacked. They are quite valuable targets, since they are usually high-performance computers and run 24x7.

Java worm seeks out for the system having Apache Tomcat installed-running and then attempts to log-in using the password brute-force attack using combinations of user names and passwords.

After installation, the malware servlet behaves like an IRC Bot and able to receive commands from an attacker. Malware is capable of sending-downloading files from the system, create new processes, update itself, can setup SOCKS proxy, UDP flooding i.e. Can perform massive DDoS Attack.

They have mentioned that the command-and-control servers have been traced to Taiwan and Luxembourg. In order to avoid this threat, ensure that your server and AV products are fully patched and updated.

                                                                                                                   Source: TheHackerNews.com