Live data from Hacker News

Ubiquiti developer charged with extortion, causing 2020 “breach”

krebsonsecurity.com

21–30 of 239 posts

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

#21
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 sounds like a misconfigured VPN to me, like he didn’t have the interface set to block traffic on failure.

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

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

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

#23
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

[deleted]

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

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

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

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

#25

Earlier quoted context omitted.

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

Setting up the local routing table so the main interface routes everything except the VPN connection through the VPN. VPN goes down? No route to host. And there are probably a dozen other ways to stop such leakage too. Most commercial VPN providers these days offer something like this, usually branding a it “kill switch” or something.

>Most commercial VPN providers these days offer something like this, usually branding a it “kill switch” or something.

seems like surfshark has it, but it isn't very reliable

https://www.reddit.com/r/surfshark/comments/r8rfb8/kill_swit...

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

#26

Earlier quoted context omitted.

This doesn't sound too good for VPN users

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.

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

#27

Earlier quoted context omitted.

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

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

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

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

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.

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

#29
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 when an AWS root IAM account is logged in or used, this account should be under lock and key and when used, confirmed and audited by relevant persons or teams.

Start edit/

* Furthermore on the root account being easily accessed, the root account in the companies I've worked at had MFA enabled, and the QR code is locked in a safe only accessible by two people agreeing it needs to be accessed in a break glass situation, where warranted.

/End edit

* Why was he also able to delete critical CloudTrail logs and reduce their retention to 1 day? I.e. These logs should be in a S3 bucket or other environment where such changes cannot be made. Alternatively, they should be shipped to a redundant service that manages this risk to prevent data deletion

* Why did Ubiquti not announce they were compromised sooner? The hack started in early December, Ubiquiti noticed the compromise on Dec. 28. Ubiquiti told the market on January 11th. Is that a satisfactory turn around? Giving them some credit for the XMas break I'll say this partially understandable.

All the AWS configuration I'm speaking of above, I would describe as Security 101.

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. That a company of Ubiquiti's size and maturity had such basic risks not managed is still a concern.

I understand AWS Organisations can be difficult to set up for legacy AWS accounts, but even with that said, setting the alarms and monitoring up that would help manage the risk associated to the questions above is not difficult and should have been in place.

That Ubiqitui would only find relief ultimately from the developers poor OpSec rather than Ubiquiti's own security policies and procedures provides a commending perspective of their internal security posture.

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

#30

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.

I’d be willing to bet that for most of the VPNs that are getting advertised by YouTubers (NordVPN, SurfShark, ExpressVPN, PIA, et al) it’s 100% marketing and they don’t actually care whether their “kill switch” works 100% of the time.

After all, they are not as trivial to implement as it sounds.

Post reply on HN