Over the past year there has been a great focus on information and computer security and, as such, a great deal of new vulnerabilities have been found. In fact, finding security vulnerabilities has become so important, that companies like Google, Facebook, Microsoft and others have created programs that offer rewards to anyone who finds security vulnerabilities on their software (http://tinyurl.com/mq2meu6 , http://tinyurl.com/p95cpth ).
New vulnerabilities by year (1988 - 2014)
When a new vulnerability is found, it is reported under a common vulnerability exposure (CVE) tracking number to the NVD (http://nvd.nist.gov). Once reported, it will be analysed and receive a CVSS score (http://tinyurl.com/qzesna3). These scores, varie from 0.0 (low) to 10.0 (high) depending on factors like exploytability and impact.
During this past year, three critical vulnerabilities were found. Each one with a different attack vector but, all capable of compromising the security of systems exposed to the internet.
Heartbleed (CVE-2014-0160)
In April, a bug was found on the most widely used library to secure communications between peers on a network, the OpenSSL library (https://www.openssl.org/). Due to its origin, it has become known has the Heartbleed bug (http://heartbleed.com).
By exploiting this bug, an attacker is able to read arbitrary chunks of memory from the process on the server that is executing the OpenSSL library. By doing this, an attacker can obtain the private and secondary keys used to encrypt the traffic between the peers. With this information, it is then possible decrypt the traffic. Since this is a bug on a feature of OpenSSL, it leaves no trace of being exploited.
Its origin resides on a the implementation of the function used to keep the channel between the peers open, the heartbeat function. This function allows the peers to send at most 64KB (65536bytes) of information to the other peer. The information is then reflected back in order to access if the other peer is still there.
Heartbeat normal operation
The bug resides in the fact that this message contains a length field that is not compared with the actual message size to check if they match. Since the length is not checked, it is possible to send a very small message (ex: 1byte) but state in the length field that the message is of size 64KB. When the the message is reflected back, the attacker will receive the original message plus 65535bytes (64KB – 1byte) of random memory from the server. He can then execute this attack multiple times until he has gathered enough memory to get the desired content.
Heartbleed attack
OpenSSL is used by the most popular webservers on the Internet, Apache and nginx. These, combined, represent arround 66% (http://tinyurl.com/l4kvsjy) of the webservers. By this number, it is possible to grasp how serious this bug really was.
Currently, new releases of OpenSSL have been made available that correct this problem.
Shellshock (CVE-2014-6271)
In September, a 25 year old bug on the GNU Bourne-again shell (bash) was found. The bash is the most popular command line and, is present on all Linux and OS X operating systems. By exployting this bug, an attacker may execute arbitrary code on a server using specially crafted requests.
The bug resides on the way that the bash handles a special type of variables called environment variables (http://tinyurl.com/mtpe5m5). When the bash evaluates these vairables, if it is set with a function (small program) that starts with a special sequence of characters ( “() { :;};” ), it will not stop when the function ends but, in fact, will continue to evaluate the variable until all its content is parsed. This behaviour causes the execution of the code after the function ends which, in some cases, may be controlled by an attacker to, for example gain an iligit access to the server.
Following, we have an example on how to test if a bash is vulnerable to this bug.
Shellshock bug test example
In the above example, an environment variable x is crated with the value ‘() { :;}; echo vulnerable’, after, a new bash get’s called and executed (bash –c “echo this is a test”). Once it starts to execute, it parses the content of the environment variables defined in the system, which includes x, that contains the attack. So, if a vulnerable bash is being executed, the output would be the result of command echo “vulnerable” (the malicious code) followed by “this is a test”.
Although there are many ways to explore this vulnerability, the most common is by using an HTTP request (generated by the web browser and other similar tools). During a normal, non-malicious requests, a user sends an HTTP request to a webserver and expects a reply that contains some type of content.
Each HTTP request is composed of multiple fields that are read and interpreted by the webserver. To process these fields, the webserver will most likely call other small programs. To pass the fields to these programs, it will store them on environment variables.
HTTP request example
Since the HTTP requests are generated on the user side, he can craft special requests to execute arbitrary code on the webserver. On the following example, the User-Agent field has been replaced by content that can cause the server to try and contact another server (evilserver.com).
Malicious HTTP request
By broadcasting this message to a network, an attacker would be able to identify the webservers that are vulnerable to the Shellshcok bug.
Malicious HTTP effect
Due to simplicity and wide spread utilization of the bash on servers, security experts consider that this bug is even more dangerous than Heartbleed (http://tinyurl.com/o57dj8e).
Following the discovery of the shellshock bug, several other simillar bugs have been found (http://tinyurl.com/nngb368). In order to fix them, vendors have released patches that prevent their exploitation, so, if you haven’t updated your bash in since September, you should!
Poodle (CVE-2014-3566)
Less than a month after shellshock, researchers at Google release a paper called “This POODLE Bites: Exploiting The SSL 3.0 Fallback” (http://tinyurl.com/p9bxcdk). In it, they describe a flaw on SSLv3 protocol (in cipher-block-chain mode) and how to exploit it.
This flaw is know as POODLE, which stands for Padding Oracle On Downgraded Legacy Encryption and, by exploring it, an attacker will be able to obtain a session cookie of another user, and thus, impersonate the user to a service.
Since the discovered flaw resides on the protocol itself and not on the implemetations or the ciphers that are used, it actually invalidates its use.
Altough most secure communications use TLS (sucessor of SSL), many web servers and web browsers will downgrade to SSLv3 (or older) if they detect problems in the negotiation of the TLS session. This beaviour allows an attacker (assuming that he is able to perform man-in-the-middle attack) to interfere with the connection between both and, force them to downgrade to SSLv3. Once this is accomplished, he will then be able to decrypt the traffic between both by executing the POODLE attack.
SSLv3 Message format 1
SSLv3 in CBC (cipher-block-chain) starts by adding a message autentication code (MAC for short) in order for the receiver to check for the integrity (i.e if the content was modified or otherwise tampered with). Next, it has to split the message into 8 or 16 byte blocks (depending if the cipher is AES or DES) to be encrypted. However, since not all messages have a size that is multiple of these values, padding is added to the end of the message. Because the protocol does not specify the content of the padding, a set of random bytes is added as a pad. In order to know the size of the padding, one last byte that indicates its size is also added.
After being padded, the message is splited into blocks. Each block of clear text is then encrypted seperatly using a secret key and the previous block (an initialization vector is used to encrypt the first block). The process ends when the last block is encrypted.
CBC Encryption
Decrypting a message follows the reverse process. It starts by decrypting the last block using the previous block and the secret key. Then each encrypted block is used to decrypt the next block. Once the final block is decrypted, the last byte of the pad is read (size of the padding), the padding is striped of the message and the integrity of the message is verified. If for some reason the verification of the integrity fails, the message is rejected and the connection is closed.
CBC Decryption
Note that the padding is not verified in this process, and that if a message is rejected, the channel used to communicate is closed. The POODLE attack is based on these two facts.
To execute the POODLE attack, an attacker has to have the ability to perform a MITM (man-in-the-middle) attack and alter the traffic on the “wire”. Once the attacker is able to this, he will replace the padding block with another block (for example, the cookie block) and observe the response from the server. Since the padding itself is not checked, if the server accepts the message, he will have decrypted the last byte of message (he knows the size of the padding). He will then alter the message and repeat the process for the next byte and so on until the block is decrypted (http://tinyurl.com/kju8l2m).
The probability that a server will accept a modified message and decrypting one byte of information from the block is 1/256. Meaning that for a block of n bytes, we have at most 256*n to decrypt the block. This number may seem big, but with the current internet connection speeds, it is quite small.
SSLv3 is a protocol with 15 years that is still used for legacy reasons. Due to dificulty of performing this attack, the POODLE has a score of 4.6 in the CVSS, which rates it has a Medium risk vulnerability. However, this attack actually invalidates the use of the SSLv3 protocol and since the flaw resides on the protocol, the only solution is to disable to possibility to downgrade to it.
During the first ten months of 2014, three vulnerabilities with a great impact have been found. With little more than one month left until the end of the year, do you think that a new major vulnerability will be found? And what about 2015 and beyond? Are your systems and teams prepared to deal with this new reality?
