💾 Archived View for dioskouroi.xyz › thread › 29455730 captured on 2021-12-05 at 23:47:19. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
________________________________________________________________________________
The funny thing is that krebsonsecurity.com are the ones that published the false information in the first place.
Good summary of the whole saga by Crosstalk youtube channel which covers mostly Ubiquiti:
https://www.youtube.com/watch?v=paLm0tP5GbI
I give Krebs a little credit here because the "whistleblower" from his original article was really an insider that was part of the investigation into the breach. Obviously this source was also the hacker, but knowing that was impossible.
Now, I believe Krebs should at least acknowledge he made this mistake, sadly he hasn't here yet.
From my cursory reading of Brian Krebs' blog, most posts seem written by a ghostwriter.
Wait. So his big "whistleblower" source for this article in April was actually the hacker?
https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirm...
Bad on Krebs for not at least mentioning this.
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.
Start edit/
/End edit
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.
While I agree this is demonstrative of overall less than adequate security practices, I’m unsurprised that a company that started with making hardware and only later added cloud functionality beyond a website/store was not initially setup as you described. What you described is the sort of setup I’ve been involved in the transition from what Ubiquiti has and what you just described, and it can be quite a lot of work to make that transition, if the industry involved didn’t have regulatory risk management drives, it’s entirely possible that it would have been considered more expensive than it was worth.
Ubiquiti now has public evidence their security posture is inadequate and there will be pressure for them to demonstrate they have changed this situation.
It’s very difficult to completely prevent malicious actors engaging in deliberate efforts to infiltrate and plan actions like this once they have any measure of access and trust. What matters now is how they respond to it.
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.
Proper opsec is you blackhole all traffic when the vpn isn’t active.
Personally I’d feel most comfortable with a separate hardware VPV solution that won’t let anything through leaving the local software to do its thing.
Most come with a killswitch, so if it wonks out you can't access the net.
Kill-switches are a misnomer. What you really want is a firewall external from your "target" system that blackholes all traffic not to the VPN gateways IP address. Than make sure packets traveling the parent interface are ONLY VPN traffic or nothing in case of the tunnel dropping (wireshark is good here.)
Are killswitches actually fast enough? Serious question, I don’t know much/anything about networking internals.
I never trust killswitches and when I want to ensure I don’t leak anything, I bind to the VPN interface instead, but I don’t know if that actually gives better security?
Speed should not be a problem and hardware solution should not have to be a better solution, ideally. Shame that has to be brought up still.
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.
Even if you did that, if I have oversight of the network in a country, like a 5+ eyes level of oversight and you were in a 5+ eyes country, I'd still be able to see where you are and what you would be doing.
Road & Rail networks have a lot in common with digital networks, when you think about it.
Personally I'd have a machine in a foreign country and used that either via an app or friend in front of the machine to do the download(s) with a time delay to avoid obvious links and then sneak it back across the border in bits.
Insecure home networks can be useful, and there is no limit to the number of times and algo's that can be used to encrypt files Russian Doll style.
Foreign country's which do not data share or extradite have their uses, but media like news orgs, Youtube and others can be helpful for establishing what hackers have been extradited. Assume all country's have hackers attacking the US or some other country and then look for missing news stories, YT videos and that sort of thing.
Then look into what relations are like between the two country's and go from there.
If you do your research or homework there shouldnt be any risks.
I dont think the hackers behind this have ever been caught.
https://www.bbc.co.uk/iplayer/episode/m0010s10/the-trick
https://web.archive.org/web/20120719071718/http://www.norfol...
VPNs are not intended to mask illegal behavior. The assumption is no one will care enough to try to get the real IP. So blatantly breaking the law throws that out the window.
Yeah and I don’t trust that a vpn would really care for my $5 a month or whatever when faced with state actions that if it came to that.
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.
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.
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.
There’s a huge gap in operational security for a hack of this size.
At minimum, use a burner IP address and hardware from Craigslist.
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).
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...
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.
So few people are actually using Tor that correlation-based traffic analysis has very good odds of revealing identities: get the list of employees, pick out those whose connections have accessed Tor at the time of attacks, and you'll have a very short list of suspects.
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.
>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.
No you won't, because tor isn't a VPN. In fact it specifically tells you not to use it with other browsers/applications[1]. It's a combo of a browser + tor client. The browser has its proxy set to the tor client, so the only way it can reach the internet is via tor. Getting that to behave properly is far easier/reliable than trying to get it to work for every application/os/hardware configuration.
[1]
https://2019.www.torproject.org/docs/faq.html.en#CompatibleA...
tor is great if you don't mind 99% of websites not working on it
I'm confident enough that 3 letter agencies control most of the network that I'd feel safer using vpn.
they were able to infiltrate various NGOs (that host tor nodes) and/or set up fake NGOs, but they weren't able to infiltrate and/or set up fake VPN providers?
If you're going to commit multiple felonies: using coffee shop wifi instead of your home connection.
And don't buy a latte with a credit card
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...
No like this.
https://i.ytimg.com/vi/KEkrWRHCDQU/maxresdefault.jpg
Briefly... Internal firewall on your PC, like iptables. Block all ports except the VPN port.
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://cloud.google.com/beyondcorp/
The question was how to stop a VPN from leaking the real IP address when the VPN connection fails.
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.
How would one have prevented their IP from leaking?
Used a public wifi access point from a computer bought second hand with cash.
not necessarily. tons of ways to still be identified
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.
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._
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.
But who configures AWS GuardDuty and who does it report to? Presumably the root account owner? In that case, wouldn't that be the cloud lead?
He was part of the team investigating the hack.
_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.
lol so much wrong with this:
using surfshark
talking to FBI
being a terrible extortionist
devising such a terrible way to make money
If he wanted 20 btc all he had to do was put up one of those shitty livestream YouTube scam videos that you always see (Elon Musk was a 2020 favorite). And he would not have been arrested either.
