Akamai Diversity
Home > Martin McKeay

Recently by Martin McKeay

Summer SOTI - Web Attacks

Continuing Changes

Welcome to the second blog post for the Summer 2018 State of the Internet / Security. If you've read the SOTI / Security report before, much of what you see here should be familiar, though the time frame we're looking at is the six months from November 2017 to April 2018, instead of the last quarter. The numbers are bigger and give us a better idea of the long-term trends we're seeing.

Summer SOTI - DDoS by the numbers

Time for a Change

The State of the Internet / Security report has been the home for Akamai's research on DDoS, attack traffic and Internet threats for over three years. While the report has evolved and expanded its scope considerably over that time, the content and how it's presented have only seen moderate changes. But as of the Summer 2018 Web Attack report, you'll see significant changes in how we present this content.  

Dealing with Petya

Akamai is aware of and is tracking the malware threat known as "Petya". Petya is ransomware spread using several methods, including PSexec, Windows Management Instrumentation Command-line (WMIC), and the EternalBlue exploit used by the WannaCry family of ransomware. The malware spreads via port 139 and 445; it probes IP addresses on the local subnet for vulnerable systems.

Prepare for the Worst, Hope for the Best

Leading up to the U.S Presidential Election last week, the oracles of the security world were warning of all the possible types of attacks we might see during the day of decision making.  We were preparing for attacks against voting machines, disinformation spread through social media platforms, more email leaks, and above all Distributed Denial of Service (DDoS) attacks against everyone from the White House to news sites around the globe.  Yet none of these seem to have materialized.

How 2015 Security Trends Will Influence 2016

I've always hated security 'predictions'; they range from scientific guesses to self-serving marketing drivel, trending mostly towards the latter.  But they do serve a purpose when done right, in that they draw attention to the trends currently happening and how they might play out in the future.  Given that there's been more focus on the field of computer security in 2015 than in any year before, it's probably not a bad idea to look at how some of the most important trends of 2015 are going to play out in the coming year.

 It's not a prediction, but rather a statement of fact to say that computer security is only going to become more important in the coming year and gain even more public attention.  We are at the start of a wave of changes that no one can accurately predict.  Security professionals around the globe have lamented for years that business leaders haven't paid enough attention to our advice, but that's changing rapidly and caught many people off-guard.  One of the things we need to be able to do is to understand some of the trends of today and where they might lead to tomorrow.  Which is why predictions can actually be valuable, if taken with a grain (or perhaps a block) of salt. 

So here is my view on how the top 5 security trends of 2015 will develop in 2016.

    2013 DDoS Analysis For Europe

    This year, we decided to do something a little different to accompany the year-end State of the Internet Report. In addition to the analysis we do on the numbers for the world as a whole, we're breaking out a particular region to look at in more detail. Although it is not the target of the largest number of attacks, we chose Europe because, like the rest of the world, it is seeing a growing number of attacks.
    As of 31 March 2014, the UK officially has a governmental Computer Emergency Response Team (CERT) that is responsible for being the central point for communication between a variety of governmental and business within the confines of the UK, as well as beyond. While this is the 'birthday' of CERT-UK, the organization has already been working hard since November to create infrastructure and hiring personnel, this was simply an official date to say "We're open for business."

    Looking forward to Forward Secrecy

    Akamai is constantly looking for ways to improve the security of our platform and protect our clients' traffic. We're currently looking into an encryption mechanism called Perfect Forward Secrecy, or simply Forward Secrecy. We prefer to use the term "Forward Secrecy" because nothing in security is perfect and we'd rather not imply that it could be. Akamai plans to include Forward Secrecy as a capability our customers can start using in the first half of 2014.

    If you're connecting to a web site securely, you're probably using an encrypted connection over HTTPS, which uses SSL to encrypt traffic between the browser and the servers you're connecting to. The browser and the server negotiate the level of encryption to be used between them as part of the initial connection. This process includes the creation of a session key that is used to encrypt all further communications and deleted afterward. However this key needs to be communicated between server and browser, which is done using public key encryption and encrypting the session key with the private portion of the SSL key of the server. 

    The weakness in this method of passing the session key between the server and the browser is that the entire communication stream can be decrypted if the stream is captured and the key used to encrypt the session key is known. While it's extremely useful to be able to use this capability with some network devices that require access to the traffic, such as Intrusion Detection Systems (IDS) and Web Application Firewalls (WAF), it has weaknesses. For example, it is possible for an attacker to capture the traffic and crack the private key offline, thereby gaining access to the session key and the entire encrypted communication. The ability to crack the private key once seemed to be an extremely time consuming process, but the use of graphics cards as fast cracking processors, the invention of quantum computing and revelation of weaknesses in the randomization process of some encryption techniques make the cracking of private keys much less time consuming than it used to be. And if enough computing power is applied, even the strongest keys can eventually be undone. Finally, the owner of the encrypting server can be forced to give up the private key, as is the case when a subpoena or other legal document is served to a service provider.

    Which is where Forward Secrecy comes into play. While the communication of the session key is normally done using the private key of the server, when Forward Secrecy is involved, the session key is communicated using a temporary, or ephemeral, encryption key that is discarded once the session is over. This means that rather than having to crack one key which grants access to all communication encrypted with that key, an attacker would have to crack each key for each session individually, greatly increasing the time required to gain access to the communications of secure traffic.

    So why isn't Forward Secrecy used everywhere?  There are two main problems with this solution. The first is that it is only supported by two algorithms: Diffie-Hellman (DHE) and (ECDHE). These algorithms aren't supported by all browsers, though the latest versions of all browsers do support them. The second issue is that these algorithms are currently slower and require 10-15% more computing power in order to use. This may not sound like a lot of additional CPU usage, but for any high capacity server, 10-15% is a huge hit to be able to support.

    Akamai supports our clients' in their efforts to secure communication with their customers.  As such, we are constantly looking for ways to improve their security, with Forward Secrecy one way to provide greater security. Despite the name, nothing in security is ever 'perfect', but Forward Secrecy greatly increases the level security over normal SSL session key communications. Akamai will continue to research additional ways to secure all the traffic for which we are responsible.

    For more information on Perfect Forward Secrecy, read the PFS Wikipedia page or Ivan Ristic's SSL Labs posting.

    Additional resources:

    https://en.wikipedia.org/wiki/Perfect_forward_secrecy

    https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy

    https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection

    http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html

    https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-defa%20ult/10151590414803920

    http://googleonlinesecurity.blogspot.co.uk/2011/11/protecting-data-for-long-term-with.html

     

    Martin McKeay is a Senior Security Evangelist at Akamai

    Take a Byte out of CRIME

    On September 21, 2012 at the 8th annual Ekoparty Security Conference in Buenos Aires, Argentina, security researchers Juliano Rizzon and Thai Duong released their latest SSL vulnerability and the accompanying attack tool. Called CRIME (Compression Ratio Info-leak Made Easy), their tool exploits a weakness in the compression algorithm used by encryption protocols SSL/TLS and SPDY.  Similar to the tool the pair released in 2011, BEAST, CRIME is a client-side attack and uses weaknesses in the compression technology to enable an attacker to compromise the encrypted data tunnel between the browser and the origin server. The initial use of the vulnerability has been to steal user application cookies, allowing the attacker to impersonate the end user.

    While this vulnerability and tool have gotten much attention in the month leading up to the presentation, the attack is of limited usefulness in reality.  First, the attack requires that the attacker be able to serve malicious traffic to the user and intercept traffic from the user to the web server. Typically this requires being on the same network segment as the targeted system. Second, less than half of servers on the Internet that use SSL/TLS and SPDY have compression enabled. Third, of the major browsers in use, only Chrome and Firefox allowed the use of the compression with SSL/TLS and SPDY when the tool was announced. By the time the tool had been released, all major browsers had been patched and no longer allowed the use of compression with the encryption protocols.

    Akamai has reviewed the vulnerability information and as verified that we do not support compression for SSL/TLS on our platform. We do have compression enabled for SPDY, and will be patching to correct the issue at the next available opportunity in the patching cycle. According to Ivan Ristic at Qualys, approximately 7% of browsers were vulnerable to the attack and only .8% of the pages on the Internet support SPDY, making this a low risk vulnerability.

    Customers can check themselves with `openssl s_client -connect control.akamai.com:443 < /dev/null |grep Compr`, substituting the site of their choice for control.akamai.com.

    For more information on this vulnerability, please read the following articles:
    - https://community.qualys.com/blogs/securitylabs/2012/09/14/crime-information-leakage-attack-against-ssltls
    - http://www.imperialviolet.org/2012/09/21/crime.html
    - http://isecpartners.com/blog/2012/9/14/details-on-the-crime-attack.html

    Martin McKeay is a security evangelist at Akamai