Live data from Hacker News

Ubiquiti developer charged with extortion, causing 2020 “breach”

krebsonsecurity.com

31–40 of 239 posts

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

#31

Earlier quoted context omitted.

If you're going to commit multiple felonies: using coffee shop wifi instead of your home connection.

While wearing a hoodie and a face mask and probably some other accessories

like this? https://www.freepik.com/free-photo/hacker-with-anonymous-mas...

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

#33

I wonder why the developer had access to so many resources on AWS and GitHub? Can’t these excessive permissions be removed? Why it was undetected for such long time?

He wasn’t just any dev but the cloud lead.

Accounts and actions like this are easily managed in AWS GuardDuty since they were so foreign from the user benchmarks. Outside of the normal security standards you'd expect of next level monitoring from companies such as CrowdStrike.

It took Ubiquiti weeks to notice these issues and he used the AWS root account, this account should be actively secured and alerted for abuse using AWS GuardDuty or similar.

I've made my own top level comment raising where I have more questions than answers from this announcement.

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

#34
post #28

Earlier quoted context omitted.

What is the proper way to ensure 100% bulletproof VPN connections without leakage?

use tor. it's specifically designed to avoid traffic leaks (as long as you don't open an external application). I trust that far more than whatever "killswitch" VPN providers have, or properly implementing a home rolled solution with iptables/network namespaces/raspberry pis. the "bouncing your traffic across 3 servers to obfuscate tracking" is a nice bonus as well.

That wouldn't solve this problem. The VPN issue was a 'killswitch' mode that was turned off, or didn't work 100% of the time. You could encounter the same issue with Tor. They didn't have their IP leak via webrtc or some special protocol, it was the VPN app itself with the bug.

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

#35
post #4

> 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. Ouch! Opsec is very easy to screw up.

How would one have prevented their IP from leaking?

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

#36
post #3

Earlier quoted context omitted.

Aren't they still serial and uncaring GPL violators?

Just being practical here: who isn’t? That is companies that sell hardware with gpl code that actually respect the gpl well.

My $50 TP-Link router came with a card in the box explaining their GPL compliance and giving me a link to their changes. I would think if I'm going to blow hundreds on Ubiquiti gear, they could at least match TP-Link when it comes to actually following the law.

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

#37
post #28

Earlier quoted context omitted.

What is the proper way to ensure 100% bulletproof VPN connections without leakage?

use tor. it's specifically designed to avoid traffic leaks (as long as you don't open an external application). I trust that far more than whatever "killswitch" VPN providers have, or properly implementing a home rolled solution with iptables/network namespaces/raspberry pis. the "bouncing your traffic across 3 servers to obfuscate tracking" is a nice bonus as well.

I'm confident enough that 3 letter agencies control most of the network that I'd feel safer using vpn.

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

#38

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

> it somewhat repairs my view of Ubiquiti's brand

It shouldn't. Everything I read still speaks to their toxic culture and their inability to focus on a product before releasing 10 new ones.

I buy their switches and APs, but their routers are still garbage.

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

#39
post #4

> 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. Ouch! Opsec is very easy to screw up.

How would one have prevented their IP from leaking?

Used a public wifi access point from a computer bought second hand with cash.

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

#40
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…

Presumably this is an OS-level thing, that it helpfully tries to fall back? If so, I suppose it could be mitigated either by a software control that prevents using the bare connection, or by running the VPN elsewhere, for example on your router. (I see posts elsewhere in the thread now describing how to do this with iptables.)

what I heard some naugthy people say is that one way to deal with these kind of issues is to have two virtual machines, one that connects to the vpn and a second one (without host networking) that can only access internet through the first one.

the firewall on the gateway vpc has to be on drop by default and only forward traffic from the 2nd vpc to the vpn interface.

the gateway vpc should NEVER provide DHCP or DNS to the second vpc since this is the easiest way to shoot your foot off since a single dns request may give your identity away.

that or use qubes os.

Post reply on HN