This blog post has been in the works for a while, but after the latest snafu with Ubiquiti, I’m calling it quits and going back to Cisco.
What happened
Yesterday, Brian Krebs posted an article that the Ubiquiti breach was “catastrophic” according to a whistleblower. Yikes. We all knew the breach was bad, but it turns out, it’s worse than we thought. There’s a lot to unpack here so we’ll go through it.
According to Adam, the hackers obtained full read/write access to Ubiquiti databases at Amazon Web Services (AWS), which was the alleged “third party” involved in the breach. Ubiquiti’s breach disclosure, he wrote, was “downplayed and purposefully written to imply that a 3rd party cloud vendor was at risk and that Ubiquiti was merely a casualty of that, instead of the target of the attack.”
So attackers were able to access the databases within AWS but Ubuqiti just put blame on AWS (indirectly) being attacked, not them.
“They were able to get cryptographic secrets for single sign-on cookies and remote access, full source code control contents, and signing keys exfiltration,” Adam said.
This is actually very worrying. “Signing keys” for those who aren’t familiar with modern software development tell the OS “hey, I’m legitimate! I came directly from Ubiquiti!” These keys being compromised means that anyone can create a malware package, sign it with Ubiquiti’s keys, distribute it, and your Ubiquiti devices won’t straight out reject the software because it’s properly signed. The only difference will be the file hash.
Adam says the attacker(s) had access to privileged credentials that were previously stored in the LastPass account of a Ubiquiti IT employee, and gained root administrator access to all Ubiquiti AWS accounts, including all S3 data buckets, all application logs, all databases, all user database credentials, and secrets required to forge single sign-on (SSO) cookies.
What’s worrying here is that they gained access to a Ubiquiti IT employee’s LastPass account. That means either a weak password was used, the IT employee was successfully phished, and there’s a lack of MFA used/enforced within Ubiquiti. Also having full access to the S3 data buckets is a big deal because a lot of data could be stored in there – from software updates, to code, to anything else.
Adam says Ubiquiti’s security team picked up signals in late December 2020 that someone with administrative access had set up several Linux virtual machines that weren’t accounted for.
“Picked up signals in late December”… so these systems could have been setup earlier in the month, in November, maybe earlier. This is why it’s very important to actively scan your networks for rogue devices!
When security engineers removed the backdoor account in the first week of January, the intruders responded by sending a message saying they wanted 50 bitcoin (~$2.8 million USD) in exchange for a promise to remain quiet about the breach. The attackers also provided proof they’d stolen Ubiquiti’s source code, and pledged to disclose the location of another backdoor if their ransom demand was met.
Holy sh!t. Remember what I said about the signing keys? With the source code, attackers can put in malware, sign it, then use their backdoor to distribute it.
If you have Ubiquiti devices installed and haven’t yet changed the passwords on the devices since Jan. 11 this year, now would be a good time to care of that.
It might also be a good idea to just delete any profiles you had on these devices, make sure they’re up to date on the latest firmware, and then re-create those profiles with new [and preferably unique] credentials. And seriously consider disabling any remote access on the devices.
I decided to go a step further. I’m completely removing Ubiquiti from my network. It’s a security risk at this point. I’ve already replaced my USG (with a more powerful device…from 2012!). I am replacing my 8 port switch with a Cisco 2960 48 port PoE+ switch ($150 off eBay).
Get off Unifi.
