top ten ways to defend your network against the latest ssl ... · top ten ways to defend your ssl...

5
TOPIC: DEFENDING YOUR NETWORK TOP TEN WAYS TO DEFEND YOUR SSL EXPLOITS NETWORK AGAINST THE LATEST Staying on top of the latest web exploits is a job in itself, but that responsibility usually falls on a network admin who has countless other responsibilities, too. This article discusses many recent SSL-related exploits, explaining them in real-world terminology (and baseball analogies) and offering some simple steps you can immediately take to protect your network. In a “Man-in-the-Middle” (MITM) attack, an attacker intercepts communications between a website and its visitor. Once the attacker has convinced the two parties that they are talking directly to each other, it becomes possible to alter the data in transit and manipulate the exchange for the attacker’s benefit. Hypertext Transfer Protocol Secure (HTTPS) is a ubiquitous protocol for secure communication over the web, allowing you to layer HTTP on top of the SSL/TLS protocol. Securing the connection provides protection against MITM attacks, because HTTPS can encrypt not only the data exchanged during the secure session but also the URL request, query parameters, headers, and cookies. This heightened security makes HTTPS especially suited for high-risk interaction such as e-commerce transactions and communications over unencrypted Wi-Fi networks. In practice, even if a site is largely configured to use HTTPS, across-the-board implementation is necessary to close all potential attack vectors. In home security, locking your front door is a great first step, and it may deter some potential burglars. But if you leave a small bathroom window on the In step 1, you set up your server to serve all pages via HTTPS. The next step is to implement HTTP Strict Transport Security second floor unlocked, you run the risk of a small burglar with a tall ladder taking advantage of that. And once the burglar is in the house, it doesn’t matter how he got in — the potential for damage is the same. Similarly, loading unsecured scripts or cookies, using HTTP on a login or landing page, and switching between secure and unsecure pages on a given site all open the door to exploitation by a clever hacker. Thanks to advances such as HTTPS support for Google’s SPDY protocol to reduce page load latency, previous concerns about SSL/TLS slowing website performance have been laid to rest. SSL Pulse reports that currently less than 20% of the Internet’s most popular websites have a secure implementation of HTTPS, leaving a large majority of the web vulnerable to MITM attacks. Make sure your site isn’t on the wrong side of that statistic. 1: STANDARDIZE ON HTTPS 2: USE STRICT TRANSPORT SECURITY WHENEVER POSSIBLE

Upload: dinhnga

Post on 02-Apr-2018

228 views

Category:

Documents


6 download

TRANSCRIPT

Page 1: TOP TEN WAYS TO DEFEND YOUR NETWORK AGAINST THE LATEST SSL ... · TOP TEN WAYS TO DEFEND YOUR SSL EXPLOITS ... attacks. Make sure your site ... from a website is due to a failure

TOPIC: DEFENDING YOUR NETWORK

TOP TEN WAYS TO DEFEND YOUR

SSL EXPLOITSNETWORK AGAINST THE LATEST

Staying on top of the latest web exploits is a job in itself, but that responsibility usually falls on a network admin who has countless other responsibilities, too. This article discusses many recent SSL-related exploits, explaining them in real-world terminology (and baseball analogies) and offering some simple steps you can immediately take to protect your network.

In a “Man-in-the-Middle” (MITM) attack, an attacker interceptscommunications between a website and its visitor. Once the attacker has convinced the two parties that they are talking directly to each other, it becomes possible to alter the data in transit and manipulate the exchange for the attacker’s benefit.

Hypertext Transfer Protocol Secure (HTTPS) is a ubiquitous protocol for secure communication over the web, allowing you to layer HTTP on top of the SSL/TLS protocol. Securing the connection provides protection against MITM attacks, because HTTPS can encrypt not only the data exchanged during the secure session but also the URL request, query parameters, headers, and cookies. This heightened security makes HTTPS especially suited for high-risk interaction such as e-commerce transactions and communications over unencrypted Wi-Fi networks.

In practice, even if a site is largely configured to use HTTPS, across-the-board implementation is necessary to close all potential attack vectors. In home security, locking your front door is a great first step, and it may deter some potential burglars. But if you leave a small bathroom window on the

In step 1, you set up your server to serve all pages via HTTPS. The next step is to implement HTTP Strict Transport Security

second floor unlocked, you run the risk of a small burglar with a tall ladder taking advantage of that. And once the burglar is in the house, it doesn’t matter how he got in — the potential for damage is the same. Similarly, loading unsecured scripts or cookies, using HTTP on a login or landing page, and switching between secure and unsecure pages on a given site all open the door to exploitation by a clever hacker.

Thanks to advances such as HTTPS support for Google’s SPDY protocol to reduce page load latency, previous concerns about SSL/TLS slowing website performance have been laid to rest. SSL Pulse reports that currently less than 20% of the Internet’s most popular websites have a secure implementation of HTTPS, leaving a large majority of the web vulnerable to MITM attacks. Make sure your site isn’t on the wrong side of that statistic.

1: STANDARDIZE ON HTTPS

2: USE STRICT TRANSPORT SECURITYWHENEVER POSSIBLE

Page 2: TOP TEN WAYS TO DEFEND YOUR NETWORK AGAINST THE LATEST SSL ... · TOP TEN WAYS TO DEFEND YOUR SSL EXPLOITS ... attacks. Make sure your site ... from a website is due to a failure

(HSTS), a web security policy whereby web servers inform web browsers that they should only interact with the server using HTTPS-protected connections. This is necessary because a browser has no way to know whether a plain HTTP response from a website is due to a failure to implement SSL/TLS security, or the result of a malicious hack. An SSL-Stripping Man-in-the-Middle attack relies on converting a secure HTTPS connection into a plain HTTP connection and thereby compromising the subsequent data exchange.

Another benefit HSTS provides is aiding in safeguarding your site’s cookie-based login credentials that are otherwise exposed to attackers sniffing your site.

The HSTS header on your website tells visiting browsers that they should only use SSL/TLS connections for the specified period of time (e.g., “Strict-Transport-Security: max-age=2592000” tells the browser to use only HTTPS for the next 2,592,000 seconds, or 30 days). Because an attacker can theoretically strip out the HSTS header on someone’s first visit to a site, some browsers consult a list of all HSTS-enabled sites. These lists are not comprehensive, slightly limiting the protection afforded by HSTS, but it is still a useful layer of security. (Going back to our home security analogy from step 1, you wouldn’t refuse to lock your front door just because you knew the lock on the upstairs bathroom window was broken.)

if we don’t fully understand it. “Undecillion” is not a word we are familiar with. When numbers get that big, people start expressing them in scientific notation, and our brains translate it to “a lot.” If the number in superscript is large enough, we may translate it to “a whole lot.”

So one point is that 128-bit encryption provides roughly “a whole lot” of distinct keys. The second, more important, point is that gains in key complexity are exponential, which means you get a lot of bang for your bit-buck. Computers are getting faster and smarter, and even the outlandish 340 undecillion number is expected to eventually become susceptible to exhaustive key searches, more commonly known as “brute force attacks.” So let’s say, hypothetically, that eventually computers get to where they can crack a 128-bit key in one second. That does not mean they would be able to crack a 256-bit key in two seconds, or even two minutes or two hundred years. No, if it took one second to crack a 128-bit key, it would take roughly 10 nonillion years — that’s 10 with 30 zeroes after it — to crack a 256-bit key.

The takeaway for this section: computers are much closer than we ever thought they would get to cracking 128-bit encryption, but 256-bit encryption is significantly more complex and unsusceptible to brute force attacks.

Imagine two friends, Tom and Bill. They have a great friendship and trust each other completely. There’s a third person, Al, who is jealous of this friendship and wants to cause some problems. So Al steals Tom’s cell phone and sends Bill a text message asking a sensitive question. Because Bill trusts Tom and thinks he is interacting with Tom, he answers the question openly and honestly. Al then uses this information in all sorts of nefarious ways, which does severe damage to Tom and Bill.

Sadly, what we’ve just described is not the plot of an upcoming super-intense action movie starring Channing Tatum and Kiefer Sutherland (with Clint Howard as Al). No, it is a real-world analogy for Cross-Site Scripting (XSS), where an attacker exploits established trust between a browser and a website. One of the underlying security mechanisms on the web is the premise of “same-origin policy,” meaning that after trust is established with a website, permission is granted by that site to access resources on a client computer. XSS is a common security vulnerability that seeks to steal session cookies by injecting compromised content into the stream of data coming from the website, disguised as coming from the “same origin.” This code injection gives the attacker access to information that is being shared in the connection and compromises the interaction. Using JavaScript or other scripts, malicious code can steal additional data from the client computer or otherwise wreak havoc. While XSS itself isn’t new, it continues to evolve and mutate as a viable attack vector.

The solution is HttpOnly, first introduced in Microsoft Internet Explorer 6 in 2002. HttpOnly is a flag included in a Set-Cookie HTTP response header that prevents the cookie from being accessed through a client-side script. All current versions of

Here’s an interesting math lesson (well, interesting if you’re the kind of person who reads white papers about network vulnerabilities): simple logic tells you that a 256-bit encryption key is twice as secure as a 128-bit key. Or, more specifically, that there are twice as many distinct keys in 256 bits as there are in 128 bits. In this case, though, logic would be wrong, and we’d have to turn to math for the answer. Because the numbers we’re dealing with are impossibly large, let’s use some smaller numbers to demonstrate the principle.

Let’s look at the difference between 4-bit keys and 8-bit keys. With four bits, each one containing either a 1 or a 0, there are 16 distinct keys. (Specifically: 0000, 0001, 0010, 0100, 1000, 0011, 0110, 1100, 0101, 1010, 1001, 0111, 1011, 1101, 1110, and 1111.) When you go to eight bits, you don’t double the number of distinct keys — you square it. Eight-bit encryption gives us 256 distinct keys, 16 times as many as 4-bit encryption. If we double again from 8-bit to 16-bit, we go from 256 keys to 65,536.

What is the point of this math lesson? There are a few points. One is that 128-bit encryption provides an enormous number of distinct keys — roughly 340 undecillion, or 340 with 36 zeroes after it. Compare that to the roughly 1,000,000,000,000 distinct keys in 40 bits. Years ago, 40-bit keys were commonly used to encrypt data, because people thought (and rightly so) that one trillion was a huge number of keys. We probably don’t really comprehend how many one trillion is, but just realize that you would have to earn one million dollars a year for one million years to earn one trillion dollars. So yes, one trillion keys is a lot, but “trillion” is a number we are familiar with, even

4: USE httpONLY COOKIES3: 256-BIT ENCRYPTION

TOPIC: DEFENDING YOUR NETWORK

Page 3: TOP TEN WAYS TO DEFEND YOUR NETWORK AGAINST THE LATEST SSL ... · TOP TEN WAYS TO DEFEND YOUR SSL EXPLOITS ... attacks. Make sure your site ... from a website is due to a failure

TOPIC: DEFENDING YOUR NETWORK

The Transport Layer Security (TLS) protocol, the successor to the SSL protocol, includes a feature that can compress the data being exchanged between server and browser in order to reduce the bandwidth and latency issues that occasionally occur when encrypting and decrypting large amounts of data.

CRIME (“Compression Ratio Info-leak Made Easy”) is a potential exploit targeting cookies over connections using the HTTPS and SPDY protocols that employ TLS data compression. An attacker can recover the content of secret authentication cookies and subsequently hijack an authenticated web session. The vulnerability is caused by a combination of plaintext injection and data leakage because of the compression. In essence, the hacker compares the size of the ciphertext sent by the browser while goading the browser into making several connections to the site. By careful examination of each exchange the attacker can deduce parts of the encrypted communication and compromise the session.

The way to prevent CRIME is to disable TLS compression using the protocol negotiation features of TLS, either on the website server or in the browser (or, ideally, both). Most browsers have taken steps to mitigate the danger of this exploit, but site admins should ensure the security of their visitors by disabling the compression option altogether. The speed benefits of TLS compression do not justify the risk of exploitation, just as the speed benefits of driving your car 150 mph (241 km/h) do not justify the risk of accident.

A cipher suite uses a specific combination of authentication, encryption, and algorithms to negotiate the security settings for a SSL/TLS network connection. More specifically, each cipher suite defines a key exchange algorithm, a bulk encryption algorithm, a message authentication code algorithm, and a pseudorandom function. When a TLS handshake occurs to establish a web connection, the client sends a list of the cipher suites that it supports in order of preference. The server selects a cipher suite from the list for its response and the subsequent exchange.

Here’s a real-world analogy for cipher suites: picture the third-base coach for a baseball team giving signs to his team. A batter and any base runners will look to the coach for signs telling them to bunt, hit-and-run, steal a base, etc. There are a few ways the coach could go about giving these signs — we’ll call them “cipher suites” for ease of analogy:

• One “cipher suite” is that if there is no play being put on, the coach gives no sign. If calling for a bunt, he gives the bunt sign (e.g., touching the bill of the cap). This is a weak cipher

The SSL/TLS protocol has a useful feature called session renegotiation. This feature allows a client and server to use an existing connection to negotiate new parameters, generate new keys, and so forth, during the session. The fact

modern browsers support HttpOnly, so using the HttpOnly flag when creating a cookie protects you from XSS even if your code is vulnerable.

suite, because a) the opposing team knows that if the coach gives a sign, something is going on, and they have a chance to guess what it is; and b) once the coach touches the bill of his cap and the batter bunts, the opposing team now knows that the bill of the cap is the bunt sign.

• In a more complex “cipher suite,” the coach gives a sign every time, but most of them are meaningless. It’s only if he touches the bill of his cap, for example, that a bunt is being called for. Touching his belt buckle is a decoy sign that means nothing. This eliminates the first problem of the opposing team knowing something is up every time the coach gives a sign, but it doesn’t address the second issue of reverse engineering signs.

• In a “cipher suite” much more like what coaches actually use, there is some sort of “indicator” given before a sign. So touching the bill of the cap may be the bunt sign, but it is meaningless unless the indicator sign is given first. For example, if the indicator is touching the belt buckle, then a touch of the bill cap means nothing, but a touch of the belt buckle followed by a touch of the bill cap means to bunt. To make things more complex, teams will sometimes throw in other wrinkles: the coach has to give the indicator twice, or the third sign given after the indicator is the actual sign, etc. A combination of those two examples would mean that if the coach did indicator-decoy-bunt-decoy-steal-indicator-steal-bunt-steal-decoy-bunt, the sign would be “steal” because that was the third sign given after the second instance of the indicator. This “cipher suite” makes it much harder for opponents to decrypt the signs — enough so that they don’t bother trying. The key is that the coach and his players know some information that the opponents don’t — the algorithm, if you will.

Just as with baseball signs, there are actual cipher suites that are weak, and there are some that are strong. In 2011, security researchers developed a theoretical attack called BEAST (“Browser Exploit Against SSL/TLS”) that uses a Java applet to violate same-origin policy constraints and decrypt an HTTPS session between a browser and an e-commerce website. Browser vendors responded by addressing holes exploited by this attack in their latest versions. The best way that site admins can mitigate the danger from BEAST is to disable all weak cipher suites that are being recognized by their site, relying on the RC4 cipher by default. For more information on weak cipher suites, and how DigiCert’s free Certificate Inspector can help you identify where you have weak cipher suites enabled in your network, go to http://www.digicert.com/cert-inspector-vulnerabilities.htm#weak_cipher_suites_h3.

5: DISABLE TLS COMPRESSION (AND “TAKE A BITE OUT OF CRIME”)

6: DISABLE WEAK CIPHER SUITES

7: UPDATE YOUR SERVERS TO SUPPORT SECURE RENEGOTIATION

Page 4: TOP TEN WAYS TO DEFEND YOUR NETWORK AGAINST THE LATEST SSL ... · TOP TEN WAYS TO DEFEND YOUR SSL EXPLOITS ... attacks. Make sure your site ... from a website is due to a failure

that renegotiation is not directly associated with the channel creates a vulnerability that allows a third party to intercept and manipulate the data being passed between the client and the server — a classic Man-in-the-Middle attack. HTTP, SMTP, IMAP, and other protocols that rely on SSL/TLS can all be subsequently exploited. The attack initiates a renegotiation between the MITM and the server while the client is operating under the assumption that the connection is still in the initial negotiation stage.

This vulnerability led to the creation of a specific exploit known as the TLS Renegotiation Man-In-The-Middle attack (TLS Renego MITM, which is easier to write but not much easier to say). Many system manufacturers have released patches to fix this issue, which was first discovered in 2009. However, a large percentage of sites (including prominent e-commerce websites) have still not installed the necessary patches, leaving themselves open to this attack. Not only are these sites vulnerable, but they are likely to encounter connectivity issues — which cause revenue-generation issues — in the future as they fall farther out of industry compliance.

The way to protect against TLS Renego MITM is to make sure your servers support secure renegotiation. All of your servers should also be running current versions of the SSL/TLS protocol. Because it is currently impossible for the client browser to know if a given server is still using the obsolete versions of SSL/TLS, it becomes incumbent on server admins to provide adequate protection for this attack surface. An alternative is to disable renegotiations altogether.

secure, and then let DigiCert’s tool take a look and double-check your work.

Once you have optimized your site you still have one important step — running an SSL installation diagnostics tool, such as the DigiCert’s free Certificate Inspector. A good SSL test will examine installed certificates, protocol support, key exchange, and cipher strength. It can examine your SSL configuration and prescribe further steps to take to improve your overall security and eliminate attack surfaces. These tests should be run on a frequent basis to ensure that no settings have been inadvertently changed, and that ongoing updates to your site haven’t broken important safeguards.

To use another baseball analogy, every once in a while there will be news of a pitcher who changed teams and subsequently learned that he had been “tipping his pitches.” A team will pick up on the fact that, for example, when he is going to throw his changeup, the webbing of his glove will flare a bit as he presses the ball deep into his palm before pitching. So from then on, that team knows when they are going to get a changeup, which drastically improves their chances of hitting it. It’s not until the pitcher goes to a new team that has figured out his “tips” that his new pitching coach will tell him about them.

In the same way, it is important to get information from a trusted third party about any pitches you might be tipping on your server. You do everything you can to make sure you are

Every network is full of third-party software fulfilling critical functions. If something isn’t “broken” the tendency is not to fix it, leading to many organizations with extremely old versions of software running in their network. This can create serious holes in an otherwise well-protected environment.

Attackers are routinely sniffing your network for attack surfaces left exposed by outdated software, in many cases stumbling upon vulnerabilities as they conduct scans across the entire face of the web. A poorly managed network can easily be vulnerable to dozens of potential exploits.

The one sure way to prevent exploits via third party software is to exercise extreme prejudice when testing and installing new software. If a piece of software isn’t critically important, simply uninstall it. Once a given program has outlived its usefulness, get rid of it. Programs that you decide to keep need to be monitored as part of a regular maintenance schedule. Patch management software and version management systems can also provide important reminders when you fall behind on your updates.

The Certificate Authority (CA) that you select will impact the ease-of-use, speed of issuance, uptime, OCSP/CRL latency, and

Because web applications running on your site often bypass your firewall, SSL encryption, and other security measures to tie straight in to your most mission-critical processes and data, it is imperative to also conduct penetration tests (pentests) inside your network.

A vulnerability scanner run from inside your network can reveal many vulnerabilities that are not immediately detected by an external scan. You need to pressure test the connections between your servers and the scripts running on them to discover weak points and potential buffer overflow issues. If you are concerned about possibly disrupting production servers and important e-commerce engines, you can sometimes pentest development environments without compromising the smooth functioning and integrity of your day-to-day operations.

Cleaning up the software running on your network, especially insecure web applications, not only is important for auditing purposes, but can save you from experiencing a catastrophic attack in the very heart of your IT operations.

TOPIC: DEFENDING YOUR NETWORK

8: CHECK YOUR SITE USING A WEB SERVER TESTER

9: STAY CURRENT WITH THIRD-PARTY SECURITY UPDATES

PICKING THE RIGHT SSL VENDOR (HINT: IT’S DIGICERT)

10: CONDUCT YOUR OWN PENETRATION TESTS

Page 5: TOP TEN WAYS TO DEFEND YOUR NETWORK AGAINST THE LATEST SSL ... · TOP TEN WAYS TO DEFEND YOUR SSL EXPLOITS ... attacks. Make sure your site ... from a website is due to a failure

©2014 DigiCert, Inc. All rights reserved. DigiCert is a registered trademark of DigiCert, Inc. in the USA and elsewhere. [v0113]

a variety of features that make your network more secure and simple to manage. At DigiCert®, we understand that most of our customers are not SSL experts, because managing their organizations’ certificates is just a small part of their jobs. With DigiCert, you don’t have to be an expert — between our online tutorials and instructions and immediate access to our award-winning technical support team via email, chat, or telephone, you have access to experts whenever you need it.

DigiCert has been providing SSL Certificates and SSL management tools for over a decade. We assisted in creating the Extended Validation Certificate and worked with Microsoft to develop and promote the use of Subject Alternate Names in SSL Certificates. Unlike other CAs who offer dozens or even hundreds of products unrelated to SSL, we started our business on a core of authentication and encryption and have built it out from there. This focused energy results in better products and unmatched support.

In addition to DigiCert’s award-winning in-house technical support team, we also have some of the fastest certificate issuance times out of any CA — with EV certificates typically issued in a matter of hours and standard certificates in less than 20 minutes! And when you call us on the phone, a real person will answer, and that person will be able to help you with your issue. No phone queues, not outsourced support, no endless transfers where you have to explain the same issue to six different people. Just real, great support. Experience the “DigiCert difference” for yourself by calling 1-855-800-3444 or visiting www.digicert.com.

DigiCert is a premier online trust provider of enterprise security solutions with an emphasis on authentication, PKI, and high- assurance digital certificates. Headquartered in Lehi, Utah, DigiCert is trusted by a continually growing clientele of more than 80,000 of the world’s leading government, finance, education, and Fortune 500® organizations. DigiCert has been recognized with dozens of awards for providing enhanced customer value, premium customer support and market growth leadership. For the latest DigiCert news and updates, visit digicert.com, like DigiCert on Facebook® or follow Twitter® handle @digicert.

TOPIC: DEFENDING YOUR NETWORK

About DigiCert, Inc.