Heartbleed. Cloudbleed. It’s not just the ominous image of websites “bleeding” data out into the wild, wild Web that makes internet users and cyber experts jump when they see or hear the names of these widely publicized security bugs.
Believing one’s data will be safe and private is what many users do whenever they register for a new website. Few think their accounts will ever be accessed by anyone but themselves.
But security leaks like the OpenSSL “Heartbleed” bug, discovered in 2014, and the more recent Cloudflare “Cloudbleed” bug, revealed last month, can dampen users’ trust that their data will automatically be safe with these websites, leading to questions like—should I change my password? How long should my password be? How can I protect my account on websites?
The answers to these questions lie in understanding the nature of security bleeds, and in the words of cybersecurity experts who know the world of web data inside and out.
Bleeding vs. Hacked
Just because a website is bleeding, does not mean it has been hacked. Security bugs that are labelled bleeds or leaks can be the result of faulty coding that creates an unintentional vulnerability, as in the cases of Heartbleed and Cloudbleed.
In the case of Cloudbleed, a mistake in the coding of Cloudflare’s HTML parser caused website data stored in Cloudflare’s servers to be “dumped” onto certain web pages after they had been parsed. This information would have come from and been leaked onto websites that use Cloudflare’s services—including major sites like Uber, OkCupid and Fitbit, according to RT.
This data, which could be seen by any user who visited those pages during an instance where it was leaking, appeared mostly as “random text at the end of the page,” according to Cloudflare’s blog post which further explained and quantified the impact of the bug.
Due to the types of information stored in the servers affected by this bug, it would have been possible for sensitive data like user passwords and authentication tokens to be included in this dumped text. However, Cloudflare’s impact analysis, published last Wednesday, indicated most of what was dumped were Cloudflare headers and, to a lesser degree, website cookies.
“We did not find any passwords, credit cards, health records, social security numbers, or customer encryption keys in the sample set,” Cloudflare’s announcement states. Their analysis was based on a representative sample of one percent of all customer requests processed during the time the bleed was occurring.
“Since this is just a sample, it is not correct to conclude that no passwords, credit cards, health records, social security numbers, or customer encryption keys were ever exposed,” the statement adds, though noting any leakage of this more sensitive data would not have been “widespread.”
In total, about 1.2 million data dumps occurred before the Cloudbleed issue was found, with about 80,000 instances ending up cached by search engine crawlers, according to Cloudflare. Cloudflare says they worked with multiple search engines to scrub this leaked data from all caches before announcing the discovery of the bug.
The real risk of a bleed
Sensitive data bled out onto web pages is only as dangerous as the “bad guys” who are willing to exploit it for their own gain.
Due to the unpredictable nature of when, where and what data was dumped via the Cloudbleed bug, a hacker would have had to discover the bug, purposely trigger leaks by sending a large amount of requests to a vulnerable web page and succeed in harvesting sensitive information from the dumped data.
Cloudflare looked into this possibility and determined there was “no evidence based on (their) logs that the bug was maliciously exploited before it was patched.” Their announcement states they would have been able to see suspicious increases in the amount of requests sent to certain web pages, and none were found. As of this writing, no major incidents of information from Cloudbleed being used maliciously have been reported.
Heartbleed, the other major data bleed in recent memory, had more casualties. This bug, which caused information that would normally be hidden to be sent between users’ computers and the servers of websites using OpenSSL, was exploited multiple times by hackers to steal information and hijack accounts.
In one case, 900 social insurance numbers of Canadian taxpayers were stolen through use of the bug, CBC News reported. In another case, the personal information of about 4.5 million patients was compromised when hackers used the Heartbleed bug to retrieve the credentials of employees at Community Health Systems Inc., logging into the employees’ accounts and stealing the data, according to Reuters.
It is difficult to predict when a bleed might occur and how truly dangerous it might be, but, according to cybersecurity experts, there are steps individual users can take to secure their own accounts, making them safer both before and after a bleed.
What users can do
One’s natural instinct when faced with a bleed is often to put a Band-Aid on it—“change your password” has been the echoed call all across the internet in the weeks since Cloudbleed was announced. And not without good reason, says Joshua Crumbaugh, founder and CEO of cybersecurity company PeopleSec.
“You have to assume your account is compromised,” Crumbaugh said in an interview with Forensic Magazine. Crumbaugh has worked for about a decade on what he calls “the offensive side of security” —he is a “professional hacker” who is hired by companies ranging from banks, to casinos, to professional sports teams to purposely hack into their systems in order to test their security and identify weaknesses. He says the risk of Cloudbleed leaking session tokens and other identifiers warrants a defensive response.
“With that session token, as a ‘bad guy,’ they can put that into the requests when they go to the website and they will be logged in as that user,” Crumbaugh said. “So absolutely, they should change their password, they should definitely implement multi-factor authentication if they don’t already have it.”
Brian Gill, vice president of Gillware Digital Forensics, agrees.
“With a breach this wide-reaching, it is better to err on the side of caution,” Gill told Forensic Magazine. “Users shouldn’t just change their passwords for sites affected by Cloudbleed, though. Many people re-use passwords for multiple sites and accounts. This could give a potential hacker the power to cause much wider-reaching damage.”
As Gill explains, a hacker who obtains a password for one website may end up with access to a user’s other accounts—even to their most vital accounts like their bank or workplace. Gill suggests using a password manager such as KeePass to generate and keep track of strong, varied passwords.
Not all cybersecurity experts believe putting a Band-Aid on this particular bleed is the best method, however.
“Asking people to replace all of their passwords for sites protected by Cloudflare … raises the possibility of strong passwords (that were likely never compromised) being replaced with weak ones,” notes cybersecurity expert and CEO of SecureMySocial Joseph Steinberg in a web column for Inc. magazine. Steinberg also points out, as Cloudflare did in their impact analysis, that the chance of many passwords actually being leaked by the bug is minute.
“Creating an exaggerated sense of urgency now will likely cause people not to change passwords down the road when a situation arises in which doing so is actually critical,” Steingberg continues, referring to a state of “cybersecurity fatigue” that will only make users more vulnerable to a serious future attack.
So how can users prepare for a future attack, even if they don’t change their passwords now?
“I would recommend people use stronger passwords,” Crumbaugh says, explaining that in many cases when passwords are accessed, they come in an encrypted form, which is more difficult to decrypt the longer the password is.
“We’ve been recommending for years now a 12-character minimum password, and focus more on the length than complexity,” he says. “It’s a total combination, so each new digit gets incrementally larger. That’s why we recommend length over complexity.”