Live data from Hacker News

Whistleblower: Ubiquiti Breach “Catastrophic”

krebsonsecurity.com

501–510 of 815 posts

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#501
post #192

Earlier quoted context omitted.

TP-Link is a Chinese company. Doesn't inspire much confidence..

And Cisco does? With it’s known back doors from the NSA?

Never, ever happened. Ever.

You're conflating "NSA secretly rerouting shipping company deliveries to end-users, installing their firmware, then senting it on" with "Cisco willingly did that".

Cisco was unaware, and once aware (thanks to Snowden), Cisco took steps to try to prevent it, by altering shipping destinations, at the last minute, on route.

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#502
post #78

Earlier quoted context omitted.

The root account credentials should be used to create a privileged IAM user and then physically locked away in a box after setting up a hardware MFA device (plus a backup MFA) for the root account: https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practi... The privileged IAM user should then be used to administer other IAM users and roles. All IAM users should be required to have hardware security keys like Yubi…

> (plus a backup MFA) IAM doesn't even let you register more than 1 MFA device.

AWS SSO does now, thankfully.

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#504

Earlier quoted context omitted.

But how fast a determined attacker will be able to utilize acquired physical key? Is something like kidnapping in the threat model for companies like ubiquiti?

> Is something like kidnapping in the threat model for companies like ubiquiti? I doubt it. That's going to raise some blinking red flags on the radar of organizations you don't want to be on the radar of. Not just three-letter federal organizations, but three-letter news organizations too. The current situation is Yet Another Security Breach that will be forgotten about in 15 minutes. But a kidnapping is interesting…

[deleted]

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#505

Earlier quoted context omitted.

Just verifying my understanding: this will make it impossible to reach the device from ui.com or otherwise off-network, but an attacker could: 1. use leaked SSO keys to forge an SSO token 2. craft a malicious webpage 3. get an unsuspecting UDMP user (e.g., me) to navigate to that page 4. run scripts on that page that would access & interact with the UDMP from the browser within the network, using the forged SSO Is th…

So SSO is disabled here. You just use a local account. IE, I go to https://192.168.27.1 to get to my UDMP and the account to auth is locally stored.

Hmm, I followed your steps and my ui.com account can still log into the device.

I have also created a local account, that I can use to log in alongside my ui.com one, but I cannot disable my ui.com SSO from being able to sign into the device.

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#506
post #28

Earlier quoted context omitted.

Aka plausibile deniability

I have never ever seen "plausible deniability" keep someone out of trouble. I have seen attempts at applying it several times, but never successfully. As an excuse for why to not do the right thing I really hate "plausible deniability".

Under GDPR, a failure to know about (detect) a breach (and then report it yourself) is in itself a violation. Likewise, failing to have suitable organisational and technical measures in place to protect the data is a breach.

I'd certainly argue your inability to account for processing operations after having been breached through lacking knowledge of what was done due to a lack of logs was therefore a breach.

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#508
post #7

> “The breach was massive, customer data was at risk, access to customers’ devices deployed in corporations and homes around the world was at risk.” > “They were able to get cryptographic secrets for single sign-on cookies and remote access, full source code control contents, and signing keys exfiltration,” Maybe putting your network control plane in 'the cloud' isn't such a good idea after all... Edit: Just re-read…

> Maybe putting your network control plane in 'the cloud' isn't such a good idea after all...

Uh. AWS? GCLOUD? Those have network control planes, maybe not for physical networks, but a control plane nevertheless.

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#509

> ”Ubiquiti had negligent logging (no access logging on databases) so it was unable to prove or disprove what they accessed” Perversely, this is exactly the logging that you want to have in place in case of a breach. You can then (factually) make the statement that ”we have no evidence any customer data was accessed.”

Can you provide more information regarding a system that can log these types of breaches (and all other activity, as required) and that would be deemed "safe" and reliable post-breach? i.e.: A system that can provide logging and that can *assert* that all logs, even in the event of a breach, are asserted CIA?

Re: Whistleblower: Ubiquiti Breach “Catastrophic”

#510
post #477
post #463

Earlier quoted context omitted.

This is what I do. I host a controller in AWS on an EC2 instance in my account. It works great.

Out of interest, why wouldn't you host it on something like a raspberry pi? Having your local network depend on an external network makes my old school sysadmin bones tingle for some reason.

The Ubiquiti controller is not needed for general operation, unless you're using a guest hotspot. Otherwise if it's offline you just lose ability to do configuration and it's data/stats logging.
Post reply on HN