Live data from Hacker News

Ubiquiti developer charged with extortion, causing 2020 “breach”

krebsonsecurity.com

81–90 of 239 posts

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#81
post #46
post #14

> Investigators say they were able to tie the downloads to Sharp and his work-issued laptop because his Internet connection briefly failed on several occasions while he was downloading the Ubiquiti data. Those outages were enough to prevent Sharp’s Surfshark VPN connection from functioning properly — thus exposing his Internet address as the source of the downloads. Not the first time I’ve read about a VPN unable to…

Proper opsec is you blackhole all traffic when the vpn isn’t active.

I prefer to have separate VPN'd network that never routed to other connection.

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#82

The funny thing is that krebsonsecurity.com are the ones that published the false information in the first place. Good summary of the whole saga by Crosstalk youtube channel which covers mostly Ubiquiti: https://www.youtube.com/watch?v=paLm0tP5GbI

Wait. So his big "whistleblower" source for this article in April was actually the hacker? https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirm... Bad on Krebs for not at least mentioning this.

Like newspapers of old, he should put a retraction at the top of that old article.

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#83
post #71

For me a company of their size and, what I would expect, maturity, this new announcement does not satisfy me or provide me much assurance. Consequently I am still happy I have been recommending people against Ubiquiti since the original announcement from Krebs. * Why was it so easy for a lead engineer to get access to a root AWS user without anyone else being notified? I.e. AWS GuardDuty provides FREE alerting for wh…

> Most of these settings can be set and managed from AWS Organisations for free, and backed up with alarming and alerts for Guard Duty trivially. Makes me wonder, why are they even settings? Why aren't they just always on?

I've found that every one of these security incidents always has someone come in and say:

"Why didn't they just ..."

Where the problem is that the "..." is the subset of non-default security configurations that would have stopped this specific insider(!) attack. They never mentioned that:

- You can't predict which attack you'll be hit with, so you have to implement every non-default / optional security setting or feature in order to be "protected". This is a metric ass-ton of work, typically on the order of multiple man years of up front effort, and then with ongoing multiple FTEs required (e.g.: for separation of roles).

- While you're not actually under insider attack, this provides zero business benefit that can be measured in dollars.

- The people implementing the protection against insider attack are the same people that the protection would typically be designed to stop. No one person can be trusted to do this. Not even any one team. Just organising the Byzantine security required for this is a project manager's nightmare.

- Insider attacks by senior technical staff are stupidly difficult to protect against. I've never seen any org that could survive an intelligent, motivated attacker that already has significant admin rights. Even the FAANGS would take a significant "hit" in this scenario. Ubiquiti is nowhere near their scale or capabilities in this space.

- All that stuff described like "QR codes in a safe" are hilarious to me. Every time I've tried to implement even 1/10th of that, everyone who ought to be responsible for the secure handling of this kind of key material ran away screaming from any personal responsibility. Literally nobody ever wanted to deal with anything even vaguely similar.

- Many of complex delegation systems and IAM technologies suffer from permission-role inversion. Often the CEO/CIO/CTO has virtually no access to the technology stack, but the junior intern from the subcontractor has the keys to the castle and could delete the whole org for shits and giggles. But, you see, he's not "allowed to". But he has the physical permissions. That he's not supposed to use. Because he was told to. You see?

- Now you're going to say that the senior staff should have the admin rights, and delegate the appropriate rights to the junior staff. Oh, you sweet summer child. That requires responsibility! (see above). It also requires that they learn, manage, and monitor something as technically complex as AWS IAM. But you see, senior people are busy people. They're busy with meetings. With memos. And more importantly, they're busy playing politics and jostling for the next promotion. The fiddly security rule stuff they just delegate to the juniors. That's the ticket to the next pay grade!

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#84
post #3

Hopefully this gets upvoted more but it somewhat repairs my view of Ubiquiti's brand now that more details have come out about what actually happened. I hope the courts will determine the full extent of the truth

Aren't they still serial and uncaring GPL violators?

IIRC FCC disallow to open radio related source even though it's GPL. I don't know Ubnt opens other sources.

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#85
post #42

Earlier quoted context omitted.

I give Krebs a little credit here because the "whistleblower" from his original article was really an insider that was part of the investigation into the breach. Obviously this source was also the hacker, but knowing that was impossible. Now, I believe Krebs should at least acknowledge he made this mistake, sadly he hasn't here yet.

From my cursory reading of Brian Krebs' blog, most posts seem written by a ghostwriter.

what makes you think that?

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#86

For me a company of their size and, what I would expect, maturity, this new announcement does not satisfy me or provide me much assurance. Consequently I am still happy I have been recommending people against Ubiquiti since the original announcement from Krebs. * Why was it so easy for a lead engineer to get access to a root AWS user without anyone else being notified? I.e. AWS GuardDuty provides FREE alerting for wh…

You assume anyone except the hacker knew anything about AWS.

Our firm subcontracts to other firms. I am among other thing resident Sysadmin which means I get to do everything related to AWS.

Out of 6 contracts we had, where firm had their project on aws I got root credentials in 4 cases. out of 4 i only managed to convince 2 to take their account security more seriously and lock things down.

What I am trying to say is that what happened at Ubiquiti is far more comon than people realize.

Because when all is said and done you still need someone who thinks like sysadmin.

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#87

Earlier quoted context omitted.

it sounds like a misconfigured VPN to me, like he didn’t have the interface set to block traffic on failure.

if a security tool lets the user shoot themselves on the foot it's a problem of the security tool not of the user.

To be clear, at least ExpressVPN has a "prevent traffic going through outside the VPN" mode which would handle this case, and it's on by default.

I am not sure how it's implemented, but it's pretty easy to imagine someone deciding to not use it cuz "it's slow/annoying" or whatever.

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#89

Makes me wonder if (at least some of) the posts dunking at the company leadership and the engineering in various comments around the internet had also been him.

I think there's a fair chance that whatever someone's mental/emotional state, if a workplace could motivate someone to act as extremely as he did, there are others similarly disenfranchised.

Re: Ubiquiti developer charged with extortion, causing 2020 “breach”

#90
post #22
post #14

> Investigators say they were able to tie the downloads to Sharp and his work-issued laptop because his Internet connection briefly failed on several occasions while he was downloading the Ubiquiti data. Those outages were enough to prevent Sharp’s Surfshark VPN connection from functioning properly — thus exposing his Internet address as the source of the downloads. Not the first time I’ve read about a VPN unable to…

Most come with a killswitch, so if it wonks out you can't access the net.

That sounds like a race condition that gives you a false sense of security. It only takes one leaked packet…
Post reply on HN