> 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
Ubiquiti developer charged with extortion, causing 2020 “breach”
21–30 of 239 posts
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#22> 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…
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#23> 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”
#24> 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?
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#25Earlier 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.
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”
#26Earlier 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.
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#27Earlier 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.
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#28> 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?
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#29* 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”
#30Earlier 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.
After all, they are not as trivial to implement as it sounds.