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
Ubiquiti developer charged with extortion, causing 2020 “breach”
31–40 of 239 posts
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#32Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#33I 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.
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”
#34Earlier 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.
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#35> 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.
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#36Earlier 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.
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#37Earlier 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.
Re: Ubiquiti developer charged with extortion, causing 2020 “breach”
#38Hopefully 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 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> 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”
#40> 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.)
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.