Estimated Reading Time: 4 minutes
Why SHA-1’s Demise Should be Your Motivation
This week, the OpenSSH Project Team announced that they would be deprecating SHA-1 as the default hashing algorithm in a near-future release. While many would look at this news as uneventful, I think it speaks volumes about one of the major issues the Information Security industry faces – that we completely suck at the concept of planned obsolescence. Now, I’m not talking about our comrades over in the IT world this time; I’m talking specifically about we security professionals who tend to turn a blind eye to your own old, outdated tech because of the latest blinky-shiny-next-gen-AI-gizmo that has everyone mesmerized.
Over the past couple of years, I’ve had the honor to sit on several panels and roundtable discussing the future of the security industry, and more often than not, things that we should be worried about but aren’t. These discussions invariably bring up Quantum Computing, and specifically Quantum Cryptography (QC), and the overall impact of such ‘futuristic’ technologies. While we are no doubt years-to-decades away from such computing capabilities becoming mainstream, I also think such technology is ‘close enough‘ for all of us to consider in our strategic roadmaps somewhere.
So, how does the elimination of SHA-1 even remotely relate to Quantum Cryptography? In more way than one may initially consider.
SHA-1 has been around since 1995, when your average desktop computer was running at about 33mhz. Back then, and for many years afterward, SHA-1 was more than resistant enough to handle even the most critical needs. However, several theoretical attacks were identified between 2005-2010, with the result being full deprecation of SHA-1 in 2013 by NIST. But yet, here we are mid-way through 2020, and we are only now getting rid of an algorithm that’s been known to be insecure for a decade.
Now, we can debate the ‘cost to break’ as much as you’d like, but the fact is, we’ve known its been weak and just getting more so as time passes, so why didn’t we do something sooner? If we look at other encryption or hashing algorithms (helllloooooo TLS 1.0), there are many others that are equally insecure due to poor implementations or weak key length – and this is without the potential impact that quantum machines will impose, and many that are still in use today.
Once again, we can debate how long it will be before quantum cryptanalysis is an actual, real thing, but that’s basically missing the point. We collectively have a history of ignoring the slow deterioration of security controls once they are deployed, regardless of it being encryption algorithms, key lengths, firewall rules, or anti-virus solutions. I’d even bet some portion of readers have SSH keys in their infrastructures that are years old, even though users have left, incidents have occurred, or .. oh yeah… algorithms have been deemed insecure.
So, in recognition of the years of service SHA-1 has given, perhaps it’s time to take that proverbial look in the mirror and ask yourself, “What really isn’t working anymore?”
Your future self will thank you for it.
Surprise! You’re Vulnerable!
Twice in the last two weeks, reports have come out following the disclosure of some fairly significant vulnerabilities within the open-source Salt Management framework. Subsequently, Cisco has patched its environment and VMware has issued patches, but it begs the question – What risks are you unknowingly facing due to open source projects being used in your commercial software?
I am personally a big fan of open source, both the vast array of solutions available and the fact that most large vendors do contribute back to the community. My concern, however, is about how we, as customers, know what open source projects our trusted partners have chosen to integrate and the overall risk those decisions have introduced into our environments. This is especially impactful when you factor in the recent studies that show over 70% of applications running today rely on outdated, vulnerable open-source code.
In one of my prior roles, in order to satisfy some very specific regulatory requirements, we stepped through each and every product we had running and developed a detailed list of ’embedded or mandated’ third-party code, such as Java, Adobe, PHP, etc. While many of these third-party/open-source solutions were common across the enterprise, the versions of the code varied wildly. Some were minor revisions behind, and of course, some were full releases behind, but others were years behind in releases, mandating highly insecure versions of products in order to ensure ‘compatibility’.
While this was certainly surprising, arguably, the most shocking aspect of the inventory was the open-source code that was not only abandoned but whose pedigree was questionable from the start. Yes, one of our main security controls used encryption libraries (including SSH tunneling) from an unknown source, with no public repository, and no documentation. When confronted, the vendor’s simple response was .. ‘trust us, it’s fine’. Their tune changed a bit when we pointed out the breach-of-contract clause and stated we would be replacing all of their gear at the end of the contract. Amazingly, in less than 18 months, a code revision was released which included a fully auditable (and commercial) encryption library.
While this is not the likely outcome in most cases, the risk is certainly something we all must be aware of. Most vendor/third-party agreements do not consider contractually obligating your vendors and partners to disclose to you when they are relying on open-source code for the products you use. Much like the VMware and Cisco situation, you could be unknowingly introducing risk into your environment due to their decisions. Our jobs are hard enough without surprises like this from our vendors.
Perhaps it’s time to update those RFI/RFP questionnaires and start asking such questions before you write them a check?
The Chronicles of a CISO Weekly Hotwash is a recap of critical stories and news that occurred over the past week. The goal is to hopefully share some insight and perspective on how these stories may impact our industry, our careers, or our companies.
Copyright © 2002-2020 John Masserini. All rights reserved.