While stuck in hotel rooms last week, I was fascinated to see so many talking heads on TV outraged by the brazen attack on Jeff Bezos. Even more surprising is that Mr. Bezos is being criticized for being successfully attacked.
It’s really difficult to understand why this news is so shocking. These attacks are what nation states, organized crime syndicates, and advanced competitive intelligence operators do. Targets can be CEOs, elected officials, law firms, family offices, professional sports teams, etc. It really just depends what the job is, and where the highest ROI can be found. It’s not shocking to many of us. We are only shocked by your shock.
I don’t bring this up to highlight that computer security and risk management professionals know more about cyberattacks than the average person. Rather, I bring it up to point out that computer security and risk management professionals really stink at communicating the dangers and ubiquity of these attacks and risks.
Dwell Time
This brings me to Dwell Time. In cybersecurity circles, Dwell Time is a metric that measures the period during which an adversary has unfettered access to a breached system — the time when you haven’t figured out yet that the adversary is in your computers. It’s an important metric, because bad guys can work freely to find and steal information until they are discovered and removed.
But, there might just be a different and more significant dwell time. Perhaps we need to measure, and reduce, the time it takes for computer security and risk management professionals to learn about a critical vulnerability, until the industry understands and acts accordingly.
WhatsApp and a Specific Example of Dwell Time
In the case of Mr. Bezos, he was using WhatsApp, a consumer app that has been accurately described as more secure than SMS. WhatsApp was built to ensure that certain file types, like mp4 files, are automatically rendered by the receiver’s device. This means fun videos play automatically. It’s like an auto-click. In this circumstance, the app seemed to have caused Mr. Bezos’ phone to auto-click on a malicious file. He had no choice in the matter. Mr. Bezos acted exactly how many of our elected officials, corporate executives, and forward-deployed military personnel have acted and continue to act.
There was a great deal of discussion last year about this vulnerability and the way NSO Group (allegedly) exploited it with their Pegasus spyware. Facebook sued them. It was all over the news. It is the kind of technique that has proven to be very valuable to intelligence communities in both public and private sectors. It provides a clear example of how targeted attacks are so effective. It is a pretty simple attack to articulate, and yet we, as an industry, tend to communicate with the general public like this: “A buffer overflow vulnerability in the WhatsApp VOIP stack allowed remote code execution via a specially crafted series of RTCP packets sent to a target phone number.” Although I’m certain Mr. Bezos is a very smart guy, I’m not sure it is reasonable to assume that he would understand his phone was auto-clicking on malware because of WhatsApp after reading that warning. As a result, we gave the attackers more time to work.
Dwell Time in Cryptography
Even in applied cryptography — a sector with unusually high standards for what is considered “secure enough” — this kind of Dwell Time remains a lingering issue. Let’s take cryptographic hash functions as an example: a cornerstone of practically all modern security protocols from TLS, IKE, SSH, and VPNs to E2E messaging and more. Way back in 1996, cryptographers started publicizing the first flaws in the MD5 hash function. Despite this, MD5 quickly became the industry standard hash function. Unfortunately, in crypto, these sorts of attacks tend to improve. Sure enough, by 2008, the attacks had become so powerful and cheap that the first fake, yet widely accepted, SSL certificates based on an MD5 vulnerability were made public. But, if fast forward all the way to 2012 — nearly 15 years since the first warnings from cryptographers — we find the Flame malware actively exploiting in the wild an MD5 vulnerability in none other than Microsoft’s own software update authentication mechanism.
You might hope the applied crypto community has learned its lesson. Yet, here we are in 2020 playing the very same game all over again with the successor to MD5, the SHA-1 hash function. The first serious attacks on SHA-1 were publicized back in 2005. True to form, by January 2020, the same (more devastating) type of attack that Flame used against MD5 now costs as little as 45k USD to mount against SHA-1, a price well within reach for more sophisticated threat actors. Yet, the phasing out of SHA-1 remains very much a work in progress: SHA-1-based certificates are still available for purchase from trusted CAs, SHA-1 remains the default hash function for authenticating PGP keys, and (as of January 2002) about 450K IMAP email servers still rely on SHA-1 to authenticate themselves to clients. In fact, Git — a tool used to host and develop a large chunk of the world’s larger software projects (like Windows, Linux, Android OASP) — still relies on SHA-1 to guarantee the integrity of all hosted files. In fact, even MD5 still crops up from time in unexpected places. NIST’s Software Reference Library (a database of signatures of “known” software used, e.g., in forensic analysis of compromised system) still relies on MD5 to generate its signatures to this day.
The New Dwell Time
In the case of WhatsApp, we understood that the attack was covered by reporters interested in cybersecurity, but it still didn’t make an impression on Mr. Bezos or the experts advising him. Months have gone by since it happened because it was obvious that use of consumer products can have serious consequences for organizations with serious security needs. Years can often go by before organizations understand cyber risks and take them seriously. This is the kind of Dwell Time that has significant societal and economic impact. It’s the period during which all adversaries have access to compromised technology across all companies, industries, and geographies.
Perhaps people are just too tired of hearing about breach after breach that they no longer listen. Many corporate executives simply resign themselves to the inevitable breach and focus on response rather than prevention. Just the other day, I was in a discussion where a CISO admitted that they knew that it was going to be a bad day when their Slack instance would be breached, but that his coworkers thought Slack is fun and would be mad if they couldn’t use it. I’m afraid the computer security industry will once again be “shocked by your shock” when bad things happen on fun and flexible business products like Slack and Microsoft Teams that do not protect sensitive data with end-to-end encryption.
It’s true that risk management is the process of understanding and managing — not eliminating — risks to systems and organizations. But, we should learn our lessons faster, and we should take the risks more seriously. As an industry, we need to be better at giving the necessary information to our elected officials, corporate executives, and forward-deployed military personnel. A good start is for industry to put trust in Zero Trust systems. Products and processes are available that do not rely upon the good intentions of service providers to protect the data they monetize. We can use math to keep service providers from accessing and, thereby, exposing data. This is a simple message that we should be able to communicate to users, executives, and legislators.
Because of our industry’s inability to communicate and teach, we are lengthening the dwell time for offensive attacks used by nation states, organized criminals, and competitive intelligence professionals to infiltrate and gather corporate intelligence and intellectual property that will be exploited at the expense of our economy and national security.