Thursday, April 17, 2014

Heartbleed Check Added to ZULU

Many of you already regularly use ZULU, our free service for analyzing any URL to determine it's overall risk and we've just made it better by adding a 'heartbleed' check.  ZULU operates by applying a variety of checks to the content, URL and host for a given web page, along with doing the same for external page elements. You will now note that the Content Checks section includes a Heartbleed OpenSSL Check.
Vulnerable Result Shown for Heartbleed OpenSSL Check
For more information on why heartbleed is such a serious vulnerability, take a look at our earlier blog which details how exploitation occurs. In a nutshell, the heartbeat TLS extension allows one machine to send a small packet to another to keep a TLS connection open. That request includes a small message, which the responding machine subsequently includes in the reply. The problem occurs as the request also includes a parameter indicating the size of the message, which is not properly validated in some versions of OpenSSL. Therefore, if the size value is larger than the actual size of the message, the response will also include random data from memory to fill the void. This is a serious data leakage issue as the response could include sensitive information such as passwords, cookies and even private encryption keys. The impact of this vulnerability is also exacerbated by the fact that OpenSSL is such a popular SSL implementation, leaving many popular websites vulnerable.

Now when you run a ZULU scan, as part of the overall content checks, we also send a heartbeat request to port 443 on the server. We check to see if an SSL server is present and if it will respond to a request where the specified message size does not match the actual length of the message. If that's the case, the report will state 'Heartbleed OpenSSL Result: Vulnerable' in the report and the overall score will be adjusted accordingly.

- michael

Tuesday, April 8, 2014

Why you should care about the OpenSSL heartbleed vulnerability

Yesterday, researchers from Google and Codenomicon made quite a splash when they revealed details of a vulnerability in OpenSSL's implementation of the heartbeat extension, which they have affectionately dubbed heartbleed.  In short, heartbleed represents a classic example of a simple programming oversight - not properly validating the length of a message, which leads to a serious memory leak.

Why is this such a big deal?

Breadth and depth - Heartbleed impacts the most common implementation of SSL/TLS (OpenSSL), which is used on the majority of web servers. In fact, according to Netcraft, in April 2014, Apache and nginx, two of the most popular web servers that both include vulnerable Open SSL implementations, account for 66% of active web servers. As for depth, the impact of the vulnerability is significant and trivial to exploit. A simple request will return up to 64 KB of random data from server memory. This data could include extremely sensitive information such as private encryption keys and authentication credentials. To make matters worse, there are no logs of such requests, so a victim won't even know that they were attacked and the exploit can be sent over and over, retrieving new data every time.

How does it work?

The heartbeat extension is defined in RFC 6520 and was added to the TLS protocol to provide a simple means of keeping a TLS session alive. Think of it as a small packet that the client sends to the server to let it know that it's still around. The problem occurs, because that simple packet includes the length of the payload that it's sending, which isn't properly validated. If the actual payload is smaller that the payload length value, the server will return random data from memory to fill the void. There is already plenty of PoC exploit code for this vulnerability readily available on the web if you want to test your own servers.  Let's break down a sample heartbeat request to illustrate the vulnerability (some hexadecimal values have been converted to decimal in the description).

|18 03 02 00 0A 01 40 00 4D 49 43 48 41 45 4C|
|#1| #2  | #3  |#4| #5  |         #6         |

#1 - Type = 24
#2 - Version = 0x302
#3 - Data length = 10 (#4 + # 5 + #6)
#5 - Total payload length (16,384 bytes)
#6 - Data ('MICHAEL')

The problem?

In this example, the data length is 10 bytes, while the total length of the payload is set to 16,384 bytes. Due to improper bounds checking, the server ultimately returns both the data sent in the heartbeat request, along with whatever else happens to come after it in memory. In the screenshot below, you can clearly see the heartbeat payload ('MICHAEL') sent to a vulnerable server, is followed by random browser headers - likely from a recently requested webpage on that server.

Data leakage from a web server vulnerable to the OpenSSL 'heartbleed' attack 

The verdict

This is a serious threat. Use freely available tools such as this handy web app to quickly check your servers to determine if you're vulnerable. If you are, either upgrade OpenSSL to 1.0.1g or recompile your existing OpenSSL version with -DOPENSSL_NO_HEARTBEATS compile time option.

- michael

Friday, April 4, 2014

Corporate users dive into March Madness

Here in the ThreatlabZ, we track stats and trends for all Zscaler customers. While our primary focus is on malicious traffic, it's intriguing to also track surges of traffic caused by non-security events.  We weren't surprised to see the NCAA basketball March Madness games cause peak traffic in both the Streaming Media and Sports categories.  There are clearly no shortage of users that participate in bracket-ology.

The graphic below shows the spike in Sports and Streaming data, which shows an interesting bandwidth trend when viewed as a percentage of total traffic seen on that particular day.  To benchmark normal traffic, I also calculated Pre-Madness traffic shown as March 17th. The first two full days of the tournament occurred on Thursday March 20th and Friday March 21st. I omitted the weekend games as Zscaler receives corporate traffic so a drop in overall traffic on the weekend is already predictable.

The typical amount of Sports Streaming data doubles during the first Round.

On Thursday and Friday (March 20th and 21st), the initial two full days of the tournament, Sports and Streaming traffic nearly doubled, primarily due to March Madness. The third round (March 27th and 28th) wasn't quite as popular. Perhaps our customers has already had their brackets busted at that point! The surge in traffic during the opening round is an impressive stat when you consider that Zscaler receives traffic from enterprises all over the world and March Madness is a US based event. A single sporting event, in one country can actually be popular enough that it can cause a significant spike in traffic for a given category on a global scale

User's have more than one way to watch these games.  The use of mobile devices like the iPad, iPhone and Android devices are responsible for a significant portion of this traffic spike as well.  Below is the Sports and Streaming traffic seen from mobile devices during this time-frame.

User's preferred to watch the games on their iPad devices.

While companies may not want to block access to such content, they may also not be aware of the percentage of bandwidth that can be consumed during a major sporting event. It's always worthwhile to keep track of such spikes and ensure that QoS controls are in place to ensure that such traffic is at least throttled to ensure that it doesn't negatively impact business critical activities.