Blog|Login|Chinese German Japanese|Follow @imperva
December 01, 2011
 Top Cyber Security Trends for 2012: #9

Imperva's Application Defense Center (ADC) locked themselves into a room recently with several bottles of single malt.  The output?  The ADC identified the top security trends for 2012, nine altogether. Yes, you're supposed to have 10 in order to have a nice, rounded list.  But our purpose isn't emulating Kasey Kasem, we want to help business, consumers and security professionals identify future threats to, as Wayne Gretsky put it, "know where the puck is going."

On December 14th, Imperva's CTO Amichai Shulman (NOT pictured above) will be hosting a webinar, talking you through the ADC's predictions.  To register, click here.

 

Trend #9:  SSL Gets Hit in the Crossfire

While a growing number of web applications are delivered over the HTTPS protocol (HTTP over SSL), attackers are increasingly focusing their attacks against the various components of SSL. We are seeing a rise in attacks which target the worldwide infrastructure that supports SSL. We expect these attacks to reach a tipping point in 2012 which, in turn, will invoke a serious discussion about real alternatives for secure web communications.

Ironically, while attackers are keeping busy attacking SSL, they are also abusing its privacy features in order to conceal their own mischievous deeds. We therefore expect to see more general purpose web attacks being launched over SSL connections.

First, a little background.  The Secure Sockets Layer (SSL) is cryptographic protocol is the de facto standard for providing data integrity and confidentiality for web transactions over the Internet (sometimes SSL is used interchangeably with the term HTTPS which is the application of SSL protocol to HTTP traffic). SSL encrypts pieces of application layer data over TCP connections providing confidentiality. It can also be used to test for the identity of the server, the client or both. SSL uses an efficient cryptographic algorithm for encrypting data and a computational intensive protocol for authentication and key exchange (the key is used by the encryption algorithm). The key exchange protocol employs asymmetric cryptography a methodology that requires the existence of a worldwide Public Key Infrastructure (PKI). PKI defines a procedure for binding digital certificates with respective websites by means of a chain of Certificate Authorities (CA). The binding is established through a registration and issuance process that ensures non-repudiation.

In the last couple of years, we have seen a growing awareness for attacks against confidential (e.g. Firesheep) and authenticity (Man in the Middle attacks, Phishing). As a result, web application owners are constantly extending the use of SSL to more applications, and to more parts of their applications. A good example is the evolution of the Google interface. At first, only the login page was encrypted. In the next stage, the whole Gmail service supported encryption – by default. Google has now even added the search functionality to be accessed via HTTPS.

With the growing usage of SSL, attackers are increasingly targeting the SSL layer. Unfortunately, most of the research community is focused on pointing out inherent protocol vulnerabilities, or common implementation mistakes that could potentially be attacked. While, the attacker community is focused on other, more practical types of attacks:

  • Attacks against PKI. Over the past year, attackers have repeatedly compromised various CA organizations. These include, DigiNotar, GlobalSign, StartSSL, Comodo and Digicert Malaysia. These attacks were a direct consequence of the commoditization of certificates, where smaller, less competent organizations have started to obtain a bigger share in the Certificate Authority market. As it stands now, any CA can issue a digital certificate for any application – without any required consent from application owner. A hacker, who gains control on any CA, can then use it to issue fraudulent certificates and impersonate any website. Additionally, there are concerns that some root CAs (whose trust is hardcoded into browser software) are inherently dubious (e.g. controlled by unfriendly governments). Some efforts are made to amend PKI issues but they are far from broad acceptance (Another worthy example is the convergence project  http://convergence.io/) 
  • The theft of issued certificates. We believe this attack will prevail over the next year as application certificates are no longer limited to being stored by the application. This is the consequence of the monolithic nature of SSL. While SSL prevents access to traffic by attackers it has no built-in mechanisms that restrict access to it by collaborative 3rd parties. For example, proxies, load balancers, content delivery networks (CDNs) need to access the certificate’s private key in order to access application data. Also DLP and WAF solutions require similar key access. In these cases, it would be preferable that the intermediate proxies would be able to look at message headers, or to be able to read traffic without changing it. However, this granularity is not supported by SSL. As a result, the digital certificate is now stored in many locations - some residing outside of the site's physical environment and out of the application’s owner control. These open up additional attack points which implies a higher success rate for attackers. 
  • Denial of Service attacks. The heavy computational burden incurred by the SSL-handshake process leaves SSL-protected resources prime candidates for effective Denial of Service (DoS) attacks. Together with an increased consumption of computer resources per session, a multitude of simple attacks can be devised very efficiently.

In addition to the attacks against SSL and its infrastructure, hackers will leverage SSL to carry out their attacks with increased confidentiality. For example, intermediate proxies cannot add headers to indicate original sender IP address – leading to the loss of traceability. Another problem is the loss of information when following a link from an SSL page to a non-SSL page. An attacker can exploit this implementation in order to cover the tracks of various Web attacks. Furthermore, many security devices which require inspection of the Web traffic lose this sort of visibility due to the encryption of the traffic.

 


Comments

Verify your Comment

Previewing your Comment

This is only a preview. Your comment has not yet been posted.

Working...
Your comment could not be posted. Error type:
Your comment has been saved. Comments are moderated and will not appear until approved by the author. Post another comment

The letters and numbers you entered did not match the image. Please try again.

As a final step before posting your comment, enter the letters and numbers you see in the image below. This prevents automated programs from posting comments.

Having trouble reading this image? View an alternate.

Working...

Post a comment

Comments are moderated, and will not appear until the author has approved them.

« How Anonymous Is Funding Operation Robin Hood | Main | Top Cyber Security Trends for 2012: #8 »