HACKER MEDICINE

The first part of the WSTR 2015 is finally available, and dedicates a chapter to 2014 vulnerabilities and how they have changed our vision of threat response. You can read the first part of the WSTR here.

The good news is that we have discovered fewer vulnerabilities in 2014 than in 2013 (we have observed a 3.6% decrease). However, the bad news is that it doesn’t mean the discovered vulnerabilities were less dangerous. Three words are enough to make any IT manager shiver to the thought of what they have had to endure in 2014: Heartbleed, Shellshock, and Poodle.

Heartbleed is by far the vulnerability we have heard the most about. Discovered in April 2014, this bug received quite a lot of media attention as it impacted both users and servers, and didn’t require a man-in-the-middle position to exploit the vulnerability. It has been a year since the discovery of Heartbleed, and this bug is still raising concerns as it seems that many organizations didn’t remediate properly to the situation.             
 

Shellshock and POODLE were discovered later in 2014 – POODLE got a second round of attention in December when we discovered the vulnerability could affect TLS connections as well. Although less dangerous than Heartbleed, these vulnerabilities remained critical for website security and required immediate attention.

The 3 vulnerabilities shared a key similarity: they were related to technologies and software which have been widely accepted and used around the world, leading to serious and potentially dramatic data breaches if no action was taken to fix them.

This should, however, not be a reason to start panicking and foreseeing the end of website security as we know it today. Although its implementation has revealed critical flaws last year, the SSL/TLS protocol itself remains trusted and secure.

Furthermore, what the first part of the WSTR highlights here is:

1. No matter what, we remain in a very fast-paced, rapidly-evolving sector with numerous third-parties – including hackers – and constant changes in norms and standards. To be realistic, these vulnerabilities discovered in 2014 are not the first and not the last we will hear about.
2. We have learned from these vulnerabilities, and we are moving forward to a new type of management of our infrastructures. We can notably mention the faster response time of Microsoft and other major actors of the sector during such critical times, as well as the rise in awareness about the lack of funding for some Open-source projects and the dangers of re-using code as a general practice. What Tim Gallo jokingly refers as the “dirty secrets of application development” in pages 19-20 of the WSTR, part 1.  

Reusing code is indeed a well-known but deliberately concealed risk of Open-source projects. It is a convenient habit that no one really wanted to bring out from the shadow until Heartbleed put it under the spotlight. Yet instead of blaming each other for not having detected such a fatal flaw in OpenSSL, the website security industry didn’t stay inactive, and tried its best to learn and evolve. As Tim Galo underlined in the report, it had made everyone realize how we need a better organization of our network infrastructures. “Better enforcement of configuration, policy, and patching across entire infrastructures will help. The moving of infrastructure to the cloud also helps an overworked IT professional manage these issues as well”. The Core Infrastructure Initiative is, for example, a very positive result of the industry leaders’ reaction to Heartbleed.

Symantec strongly encourages such initiatives. We believe it is vital to react quickly, develop threat intelligence, document previous vulnerabilities and share as much data as possible in order to fight against the ever-evolving threat landscape. The WSTR we publish every year belongs to such initiatives and we would like not only every IT manager and application developer to read it, but also employees and individuals. Because we’re all concerned by the security of our data at some point – even if at different levels.

I jumped at the opportunity to write this blog – as my son’s name is Luke and therefore, “Luke, I am your father”.

Let’s remember that tense moment in Garbage Compactor 3263827:  after narrowly escaping Death-By-Dianoga, imminent demise again confronts Leia, Luke, Chewbacca and Han as the garbage compactor starts doing what garbage compactors do best.  The young rebels frantically call C3PO and R2D2 to shut down all the compactors on the detention level – and in those gripping minutes leading to their narrow escape, even the most hyperaware geeks all totally missed evidence that the Imperial IT/IS department made some pretty bad decisions about SSL certificates. 

For two decades, SSL has been the guardian of encryption and validation on a very public internet, but also within enterprises – even evil enterprises like the Death Star.  And while the chronology means that SSL couldn’t have been in use a long time ago, in a galaxy far, far away, luckily the timing is fiction while SSL best practice is fact. 

This little lesson’s worth the effort.  Come, let me get you some SSL context: 

To save his colleagues in the compactor, R2D2 got access to a Death Star control system.  The Death Star’s systems believed that R2D2 was a legitimate agent of the Empire, and allowed him access.  Now, let’s presume that the data exchange which ensued between system access and compactor shutdown was over an encrypted channel (a classic implementation of encryption of data in motion in a server-to-server model).  Encryption wouldn’t have prevented R2D2 from doing anything – since he already had access to the network.

Had the Death Star’s systems required a digital certificate – what we now call SSL or TLS – for validation, not just encryption, the result might have been very different for not just our rebel friends, but ultimately for the Rebel Alliance and the Empire too – and for millions of Star Wars fans, in any galaxy for that matter. 

After all, losing track of Death Star plans isn’t Imperial IT’s only problem.  They also failed to observe best practices for usage of specific certificate types within their space station, as encryption couldn’t have prevented R2D2’s access.  Only the validation function of SSL could have resolved that. 

Stick with me here.  Use the Force.  Trust your feelings.  Let go.

Effectively, R2D2 was a man-in-the-middle.  Er, droid-in-the-middle.  But don’t let “MITM or DITM” distract.  If the Death Star’s server-to-server authentication demanded domain-validated certificates, the clever R2D2 could have easily obtained one of those since he literally was a man-in-the-middle.  (Think about all the various DV authentication methods – R2 could’ve faked any of them).  And upon system access, R2 just presented his DV certificate upon connecting the Death Star network and – ta da, he’s avoided any Imperial entanglements.  (As I’m writing this, I realize that the Empire would likely have obtained the very first ever TLD, presumably for .ge for galactic empire – making R2’s DV cert’s Common Name to be something like r2d2.deathstar.ge)

Now, if Death Star IT/IS had configured its systems to demand organization-validated (OV) or Extended Validation (EV) certificates for server-to-server communication, R2 would have either failed to connect (by having a DV cert) or failed OV/EV verification (since he couldn’t have proven that he’s a member of the Empire). 

No OV/EV = no (suitable) cert presented = this isn’t the droid you’re looking for = dead rebels.

Moreover, Imperial IT/IS would’ve been even smarter if they’d have selected any of Symantec-branded SSL certificates, which only come in OV and EV flavors – as the Symantec SSL validation and issuance infrastructures have never been compromised – since clearly the Death Star has its own breach problems.

Moral of the story:   demand Symantec OV or EV certificates, even for server-to-server usage.  And may the Force be with you.