Live data from Hacker News

Ubiquiti developer charged with extortion, causing 2020 “breach”

krebsonsecurity.com

11–20 of 239 posts

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

#11
post #7

Earlier quoted context omitted.

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

Assuming you're talking about corporate VPN: not using VPN. Things like BeyondCorp. And obviously take away access once that person left the company. https://beyondcorp.com/ https://cloud.google.com/beyondcorp/

The question was how to stop a VPN from leaking the real IP address when the VPN connection fails.

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

#12

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.

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

#13
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?

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

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

#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 mask someone’s ip when they were on a wonky connection.

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

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

This doesn't sound too good for VPN users

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

#16
> Investigators say they were able to [subvert the attacker’s VPN] because his Internet connection briefly failed on several occasions while he was downloading the Ubiquiti data. Those outages were enough to expose his real address.

Ahem, how convenient! Call me a paranoid Internet-forum dwelling cyber-loon, but that smells an awful lot like parallel construction.

When the authorities log the start and end times of every TCP session at both ends they don’t need a VPN leak to correlate traffic corresponding to “GET /secrets” from the client with a response from the server.

It feels like a disgruntled and sophisticated Ubiquiti employee is the last person who get caught out by a DNS leak while waiting for their VPN to come back up after a flap.

On the other hand, I guess if you’re crazy enough to behave this criminally, you can be forgiven at least for not thinking straight in terms of opsec.

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

#17
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.)

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

#18
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.

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

On Linux, use network namespaces https://www.wireguard.com/netns/ . Create a separate VPN namespace and have wgN be the only non-loopback interface there, then run your application in that namespace. This also solves WebRTC-style leaks. Physical isolation is even better (e.g. using a spare Raspberry Pi).

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

#19
post #7

Earlier quoted context omitted.

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

Assuming you're talking about corporate VPN: not using VPN. Things like BeyondCorp. And obviously take away access once that person left the company. https://beyondcorp.com/ https://cloud.google.com/beyondcorp/

This has nothing to do with a company-supplied VPN. This person was an employee using a third party VPN specifically to hide his identity from Ubiquiti.

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

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

This doesn't sound too good for VPN users

It's an operating system issue. OS's are really difficult to give absolute invariants that you can trust. If network connectivity security is vital, then the only real solution is to setup your environment in a VPN or on a separate box that will lose the adapter routing info if it goes down.
Post reply on HN