Monthly Archives: April 2014

29 04, 2014

The Reports are in: Hacked Websites are a Big Problem

Websense2014Report

The big boys have weighed in and both the Cisco’s 2014 Security Report  and the Websense 2014 Threat Report have identified a major contributor to cyber-crime: hacked legitimate websites.  The Cisco report accurately refers to these attacks as High Efficiency Infection Strategies because as the image below illustrates, a single website can attack a variety of devices. Websense re-affirms the popularity of this attack method by pointing out that 85% of malicious links are hosted on hacked legitimate websites.

Websites can launch attacks upon multiple device types 's (image from Cisco's 2014 Security Report)

Websites can launch attacks upon multiple device types ‘s (image from Cisco’s 2014 Security Report)

At 6Scan we see the magnitude of the effort behind these attacks and the damage they can inflict. There is a constant barrage of malicious traffic against the sites we secure. Why? Because using hacked websites to disseminate malware is a high-efficiency infection strategy.  A compromised web site, or web server, is the bad guys’ honeypot — it’s out there just waiting for victims to show up. Many new customers come to us after they have been targeted. Once breached, these sites become platforms for serving malware until inevitably they are blacklisted by browsers or desktop anti-virus. 

In many cases these small businesses have much more to lose than bigger companies. Large firms have insurance, recovery strategies and adequate resources to survive a breach, even one that is large scale and highly visible. Smaller firms, The Fortune 15 Million, don’t always have this cushion. In many cases they stand to lose everything. This is why 6Scan offers a free service to assess website security. It’s also why we focus on fixing vulnerabilities before they become breaches.

Stay safe.

 

21 04, 2014

Heartbleed’s Long Dangerous Tail

dangeroustail

It’s been two weeks since the Heartbleed bug was disclosed, and, here at 6Scan, we’re encouraged that 99% of the sites we scan, and 100% of the sites we protect, are unaffected by this critical vulnerability.

Unfortunately, the 1% of sites we scan that are affected represents thousands of destinations with millions of monthly page views. We’ve researched these sites and grouped them by Alexa rank (see image below). The vast majority are part of the internet’s “long tail” small sites – ranking outside Alexa top 1,000,000 – that serve niche communities and special interests.

It’s tempting to marginalize these vulnerable sites because of their size, but don’t. Left unchecked, these small sites put everyone at risk.

Why? Breaching small sites is an essential part of the black-hat economy. They provide the resources for hosting phishing pages, infecting consumers, avoiding malicious IP black listing, launching DDOS attacks and many other nefarious activities. Protecting these sites, and their visitors, is critical for ongoing viability of the internet.

While Heartbleed had many of us primarily concerned with larger properties and institutions running vulnerable Open SSL versions, it’s important to remember that small sites pose a threat as well.  If you’re concerned about the smaller sites that you visit, there are a variety of tools available that claim to provide information on a website’s Open SSL status, including this one.

The chart below shows the breakdown of effected Heartbleed websites by Alexa rank. 1.3% of the vulnerable sites are within the top 100,000 most trafficked sites on the internet. As a reference point the 100,000 ranked site would average about 25,000 unique page views per month. What makes the long tail so dangerous is than over 90% of the sites still affected are outside the top 1 million.

heartbleed.Alexa_-300x186

 

8 04, 2014

OpenSSL Heartbleed Bug Analysis

Background

Yesterday the security engineers at Codenomicon disclosed a high severity security vulnerability in one of the most used SSL libraries in the world – OpenSSL.

According to advisory published on openssl.org the vulnerability exists on 1.0.1, 1.02-beta, 1.01f and 1.02-beta1 versions and seems to impact millions of servers, please upgrade to the latest version of openSSL 1.0.1g.

What’s Heartbleed bug?

OpenSSL implements Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) protocols which designed to secure traffic from unauthorized attackers. An extension called Heartbeat is being used to keep connection alive between client and server that use TLS connections, the security vulnerability found in that extension and that’s the reason the researches named the bug as “Heartbleed”.

How the bug behaves

We downloaded the latest version with the security fix (1.0.1g) and one version before (1.0.2-beta1), searched for the function who handles the process of heartbeat extension, and performed a diff between the two versions.

openssl-heartbleed-300x131

 

* Comparison between vulnerable OpenSSL 1.0.2-beta1 against the latest fixed version 1.0.1g (Click on the picture above to see it correctly)

From the above comparison we can learn a lot about the heartbleed security bug, on the left you can see the old vulnerable version:

/* Read type and payload length first */

hbtype = *p++;
n2s(p, payload);
pl = p;

The first line, extracts the type of the heartbeat message received, second line extracts from received message the length of the received message, the code doesn’t check if the length given by the remote client is correct.

/* Allocate memory for the response, size is 1 bytes
* message type, plus 2 bytes payload length, plus
* payload, plus padding
*/
buffer = OPENSSL_malloc(1 + 2 + payload + padding);
bp = buffer;

/* Enter response type, length and copy payload */
*bp++ = TLS1_HB_RESPONSE;
s2n(payload, bp);
memcpy(bp, pl, payload);
bp += payload;
/* Random padding */
RAND_pseudo_bytes(bp, padding);

r = ssl3_write_bytes(s, TLS1_RT_HEARTBEAT, buffer, 3 + payload + padding);

As we can see later on that function, it allocates memory based on the given unchecked length from the remote client, generates a response and send it back to the remote client. That means we can actually give length up to 65K without providing a message in that size, then the function will build response message and try to copy payload in the size provided by the client, that will cause copy of 65K of memory that may contain important information about the server such as encryption keys, user names password, etc.

Conclusion

We highly recommend for all sys admins to check and verify they have the latest version of openSSL (1.01g), in the near future it seems we’ll have a lot of interesting stories about it, hold tight.