Ubiquiti's Breach Notification: The 'No Evidence' HedgeBeing 'Not Currently Aware' Customer Data Was Stolen Doesn't Mean It's Safe
When a breached business says it has "no evidence" that attackers either stole data or used it to commit fraud, take the claim with a grain of salt.
See Also: Stopping BEC and EAC
Unfortunately, many organizations pepper their data breach notifications with a variety of weasel words, including the "no evidence" hedge. Such spin seems designed to minimize any role the organization might have had in preventing or rapidly detecting the breach and to hide the fact that the organization could - and should - have done better by having in place systems that could have provided solid evidence about what happened and when.
"Without good logs, it is very difficult to investigate an incident and confidently identify what happened."
Take Ubiquiti, which makes internet-connected cameras and other IoT technology. It discovered in December 2020 that its cloud-based repositories had been breached for at least two months.
"We recently became aware of unauthorized access to certain of our IT systems hosted by a third-party cloud provider," Ubiquiti said in a Jan. 11 breach notification.
"We are not currently aware of evidence of access to any databases that host user data, but we cannot be certain that user data has not been exposed," the IoT device manufacturer said.
"As a precaution, we encourage you to change your password," the company added, also advising customers to "enable two-factor authentication on your Ubiquiti accounts if you have not already done so."
Left unsaid is that Ubiquiti apparently failed to put the right mechanisms in place that would have allowed it to definitively determine whether attackers had accessed user data. The organization also neglected to mention that its attacker was attempting to extort the manufacturer - reportedly for 50 bitcoins, worth $2.9 million - in exchange for not dumping its stolen source code and other data.
Breached: Cloud-Based Repository
On March 30, cybersecurity blogger Brian Krebs first reported on that extortion attempt and identified the unnamed cloud provider as Amazon Web Services.
Of course, Ubiquiti is responsible for securing its data no matter where it chooses to store that data. Furthermore, most cloud-based database providers - including AWS, Elasticsearch and MongoDB - by default only allow users to spin up new instances that do not publicly expose any data and that have strong security controls in place. So if an attacker gained access to Ubiquiti's AWS data, either Ubiquiti's administrators disabled built-in security controls or the attacker managed to hack into Ubiquiti and obtain legitimate credentials.
The latter approach is what happened to Ubiquiti, an unnamed security professional inside the company told Krebs. One or more attackers compromised a Ubiquiti administrator's LastPass password management account and used it to gain remote, administrator-level access to the organization, including its AWS resources, said the source, whom Krebs has code-named Adam.
"They were able to get cryptographic secrets for single sign-on cookies and remote access, full source code control contents, and signing keys exfiltration," the source said.
'Catastrophically Worse Than Reported'
Adam told Krebs that in whistleblowing complaints to both a Ubiquiti hotline and a European privacy regulator, he reported the breach being "catastrophically worse than reported" and exacerbated by Ubiquiti not knowing the full extent of what attackers touched - as well as not forcing customers to change their credentials.
"Ubiquiti had negligent logging (no access logging on databases), so it was unable to prove or disprove what they accessed, but the attacker targeted the credentials to the databases and created Linux instances with networking connectivity to said databases," according to the complaint reportedly filed by Adam.
“The breach was massive, customer data was at risk, access to customers’ devices deployed in corporations and homes around the world was at risk," Adam's complaint added, noting that attackers had obtained information that would have enabled them to remotely log into any Ubiquiti device anywhere in the world, unless users had changed their password or activated two-factor authentication.
In response, Ubiquiti on Wednesday issued an updated breach notification, in which it still declined to state definitively whether an attacker had accessed customer data, although it said it believed the attacker had not done so because the attacker hadn't mentioned it in the extortion attempt.
Ubiquiti also said it did not pay the attacker's ransom.
As Krebs reported on Sunday, in its updated breach notification Ubiquiti declined to deny anything that Adam had alleged.
Must-Haves: Logging and Monitoring
Ubiquiti certainly wouldn't be the first company that failed to have in place robust logging and monitoring. The same was true in 2010, for example, when attackers exploited two zero-day vulnerabilities in Nasdaq's systems to eavesdrop on the 230 corporate board members who used the exchange's Directors Desk product to discuss confidential information.
When the details of that attack came more fully to light in 2014, cybersecurity expert Brian Honan told me that the breach problems were compounded by Nasdaq's failure to have visibility into what was happening on its systems.
"The core of the problem here is the lack of logging and proactive monitoring of systems and networks," said Honan, who's president of Dublin-based cybersecurity consultancy BH Consulting. "Without good logs, it is very difficult to investigate an incident and confidently identify what happened and even … who may be behind the attack."
It's important to learn from how other organizations get breached. As demonstrated by the attack against Nasdaq 11 years ago - and many more since then - organizations must gather sufficient log data and retain it for a sufficient period of time if they're going to more quickly detect attacks, stop breaches and clearly explain to regulators and victims what happened, when it happened and the risk now posed.
In other words, organizations can do the right thing when attempting to better prevent, detect and respond to breaches (see: To Survive a Data Breach, Create a Response Playbook).
Or they can fall back on weasel words.