Good summary of the whole saga by Crosstalk youtube channel which covers mostly Ubiquiti: https://www.youtube.com/watch?v=paLm0tP5GbI
Bad on Krebs for not at least mentioning this.
He is mentioned in this article.
> be platformed
> Fuck notdan
I don't think that this comment belongs on HN - it's not civil, not in the spirit of HN, and it appears to be factually incorrect.
Even if the neo-nazi is still dyed in the wool, I certainly don't think that being curious about that person's perspective justifies being doxed.
Also, fuck Nazis.
And the Krebs article was on April 4th. It seems BleepingComputer broke the story and Krebs just re-reported the news.
Kreb's first article was on March 30 https://krebsonsecurity.com/2021/03/whistleblower-ubiquiti-b...
Kreb's second article was on April 4th https://krebsonsecurity.com/2021/04/ubiquiti-all-but-confirm...
BleepingComputer's article didn't come out until the email from Ubiquiti on April 1 and quotes Kreb's article on March 30
I mean, he added an update already from later in the month, and he clearly knows now.
Now, I believe Krebs should at least acknowledge he made this mistake, sadly he hasn't here yet.
* 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.
* 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.
* 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.
Our firm subcontracts to other firms. I am among other thing resident Sysadmin which means I get to do everything related to AWS.
Out of 6 contracts we had, where firm had their project on aws I got root credentials in 4 cases. out of 4 i only managed to convince 2 to take their account security more seriously and lock things down.
What I am trying to say is that what happened at Ubiquiti is far more comon than people realize.
Because when all is said and done you still need someone who thinks like sysadmin.
There were a lot of smart and experienced people at Ubiquiti when I worked there.
Nick Sharp manipulated his way into total control over everything and wouldn't let anyone outside of his isolated team touch it. Nick was hired out of his job at Amazon because he was supposed to be the AWS expert. He used that to lock out anyone but himself and a trusted team.
It didn't matter that others knew better. Nick controlled it.
This always cracked me up. From what I can tell, he was a mid level dev on the Alexa web api team. He knew AWS sure, but he did not have the cred at all to justify the position and responsibility he was given at Ubiquiti.
Management abdicated its responsibility.
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.
I had never heard of GuardDuty so I got curious.
It doesn't seem like there's a free tier available for it: https://aws.amazon.com/guardduty/pricing/
In fact at larger scales it seems pretty expensive even.
Thank you for the correction.
All the same the point I was trying to drive is when the service is incredibly effective, both in practice and cost, it should in nearly all instances be implemented.
Edit: I wanted to amend my statement but the window to make those changes has passed.
That would also point to the CEO being too powerful when it comes to security, which is also a knock against the organization, but in a different way.
> * 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.
The "Cloud Lead" that Nick took over from gave zero fucks. He ran all the AWS stuff for Ubiquiti under his personal AWS account. Nick came in and started putting "proper" AWS structure and security in place, primarily by scaring Robert (the CEO) into giving him the keys to the castle (my own personal opinion of Robert is... not the greatest).
One thing to understand about Ubiquiti (at least during those times) is that the company had zero C-level execs. There was Robert.... and then nobody knows. I asked repeatedly why we didn't have a CTO, or a COO, or a CFO, or CMO or ANYTHING and I got nothing but shrugs and "idunno" as a response for the whole year I was there.
So when Nick came in, a very... let's just say "forceful" personality, he immediately won over Robert and ended up with carte blanche over pretty much all of Ubiquiti's cloud accounts. Which were basically... everything. All the UniFi Network services, UniFi Protect services, you name it. If it was connected to the cloud in any way, Nick had access to it.
So why wasn't anybody else notified? Simple. Because he was basically "god". If anybody was gonna be notified, it would've been Nick. He was the top of the totem pole company-wide when it came to AWS.
Also, for some perspective, at that time Ubiquiti kept all the hardware signing keys in a private GitHub repo that every employee had read access to. And they were in plain-text. So... yeah.
> * 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.
See above for the quality of security processes and practices this company had in place.
> * 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
See above. (re: "god") Nick answered only to Robert. And he'd already successfully hoodwinked him. He could do whatever he wanted. Eventually he fell from Robert's good graces, but seeing as Ubiquiti as a company didn't really have a ton of checks and balances, he kept his god-level access far longer than he should've.
> * 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.
Simple. Fear of share price falling. I was constantly given this as a reason we couldn't be transparent. Not by Robert, nor where he could hear. But it was pretty much well known that the company kept shit quiet for fear of the share price dipping.
> All the AWS configuration I'm speaking of above, I would describe as Security 101.
To keep with the metaphor, Ubiquiti couldn't even get Pre-school level security in place, much less 101. I have no idea how something even more massive hasn't happened yet. Must be dumb luck.
Speaking of, by the time I left the company, the team that was handling the door entry-way systems (UniFi "Access" I guess) had been caught with numerous security issues, not the least of which was logging user credentials in plain text (not just storing, but logging, in response to authentication events). They were also based in China and subject to Chinese laws around government access, so take that how you will.
And that doesn't really even cover most of it. That year took a toll on my physical, mental, and emotional health, not to mention put a crazy strain on my marriage. I'd rather honestly forget it, but the schadenfreude of what's going on is too delicious to ignore.
This is frankly worse than any of this other news. So there's essentially zero trust associated with the code signatures since any employee, past or present, can sign a payload. Wonderful.
Also, even though they may have had read access, not many knew it existed. But it wasn't super hard to find (I stumbled across it basically).
Oh and then there the whole metrics collection debacle, where the controller basically phoned home about the topology of every network that it managed. Even if you opted out. Opting out just meant they fuzzed your ID so any given record couldn't be linked back to PII. Which may or may not be legal, IANAL.
But either way it definitely wasn't clear that opting out meant data was still collected. Super sketchy.
We didn't have read access until Nick Sharp and his team took over GitHub permissions and gave everyone access. Wonderful security work.
> Oh and then there the whole metrics collection debacle, where the controller basically phoned home about the topology of every network that it managed. Even if you opted out. Opting out just meant they fuzzed your ID so any given record couldn't be linked back to PII. Which may or may not be legal, IANAL.
Nick Sharp was at the core of this too! He built the 'trace' system to collect all of these metrics and had all of these ideas about how to secretly collect the data in ways that would be hard for people to detect.
He pretended to be a principled person who stood for security and privacy, but whenever he saw an opportunity for political gain he abandoned all principles. He was the only person I knew at the company who was enthusiastic about collecting all of that data.
He basically dictated that you couldn't use any kind or repo+deployment pipeline except for what his team was building. Which wasn't actually functional for like 8 months. So we never even got a dev or staging tier to test against for months.
And then when I ended up with access to push things along, the actual apps for the trace system we're... not well implemented.
Ugh... I could bitch about this stuff for literal days but I gotta drop my kids off.
The quality/feature set is there and the software is well designed, even if not quite as networking beginner-friendly as Unifi has become. Mikrotik's RouterOS can do much the same tasks as Unifi's management console, and can configure for auto-adoption of APs/other hardware in the Mikrotik range just like Unifi does for their own hardware.
Most competitors (I see Aruba suggested) are priced much more into the enterprise/business buyer realm. Unifi has generally been keenly priced in this market, their latest Wifi 6 APs are just 99 dollars each (when in stock of course...). Microtik's pricing is generally comparable or cheaper than Unifi in my experience.
edit: Secondhand Ruckus/Brocade switches are solid, at least on the 7000 series the evaluation key has no time limit so you're not license-limited in what you can do with them. Switches are mostly <$250 on eBay if you're buying an ICX7150, ICX7250, etc. Yes, that includes PoE models.
Is it just software that's UniFi's weakness? Anything wrong with the hardware itself? I've had quite good luck with UniFi in my home myself but perhaps I'm not using all the features...
Nick's whole strategy was to find a problem, exaggerate it as much as he could get away with, and then offer himself as the hero who would fix it all.
He exaggerated or lied about everything he wanted to use for political advantage, right up to the end where he fabricated a hack and used Krebs to exaggerate it as much as possible for his own personal profit.
You have to realize he did the same thing during his time at Ubiquiti: Found problems he could use for political advantage, exaggerated them as much as he could get away with, and then amplified his lies until they were gospel. A lot of what you're saying has some roots in truth, but I can tell you have the exaggerated Nick Sharp version of events.
> There was Robert.... and then nobody knows. I asked repeatedly why we didn't have a CTO, or a COO, or a CFO, or CMO or ANYTHING and I got nothing but shrugs and "idunno" as a response for the whole year I was there.
This wasn't some big mystery. Everyone knew that Robert ran everything as CEO and the legal, marketing, and other teams operated out of the New York office.
> Nick came in and started putting "proper" AWS structure and security in place, primarily by scaring Robert (the CEO) into giving him the keys to the castle
Nick was hired specifically to run AWS. That was his job from the beginning. The old cloud team quit and Nick was recruited from his job at Amazon because supposedly he was an AWS expert.
The incident where he scared the CEO was the first of his political games to exaggerate or fabricate security incidents for political gain.
> So why wasn't anybody else notified? Simple. Because he was basically "god". If anybody was gonna be notified, it would've been Nick. He was the top of the totem pole company-wide when it came to AWS.
Yes, this. All of these news stories are missing the point that Nick was the cloud lead. You don't have to believe anonymous commenters. His LinkedIn profile will confirm it. He was recruited out of Amazon to lead the cloud efforts, but he was in over his head and had severe personal issues.
> at that time Ubiquiti kept all the hardware signing keys in a private GitHub repo that every employee had read access to.
This is another Nick exaggeration. It's true that older devices had hardware signing keys stored in a Git repo before the system was updated and keys rotated. However, those old keys were only accessible by a few people until Nick and his team took over GitHub and restructured permissions with the web portal they built themselves. In the process they made too many repos accessible to too many people.
> To keep with the metaphor, Ubiquiti couldn't even get Pre-school level security in place, much less 101. I have no idea how something even more massive hasn't happened yet. Must be dumb luck.
Ubiquiti's overall structure is far from perfect, but you were only there during the Nick Sharp era. Ubiquiti had a lot of people who took security and proper practices very seriously before Nick Sharp took over everything, but it was also a distributed company with a lot of isolated divisions. Nick Sharp got into power by taking the worst and oldest parts of the company and convincing people that everything was equally bad and that only he could fix it. If you got your security information from Nick Sharp, you'd think that Nick is the only person who can do anything properly at the company.
> Speaking of, by the time I left the company, the team that was handling the door entry-way systems (UniFi "Access" I guess) had been caught with numerous security issues, not the least of which was logging user credentials in plain text (not just storing, but logging, in response to authentication events). They were also based in China and subject to Chinese laws around government access, so take that how you will.
I also heard that, but I think it was just incompetence on their part. Nick was pushing the conspiracy that they were doing something with the Chinese government, but it doesn't follow that they'd do it by sending the data to AWS servers under his control. I think they just made a sloppy prototype to impress the CEO and got caught doing dumb stuff. I do blame the company for not cutting that team off, though. They had no idea what they were doing other than their ability to put together quick prototypes to impress the CEO.
If you're telling me I worked there at literally the worst possible time frame, I'd believe it. I may have my experience skewed through the perspective of Nick's influence, but tbh many of my issues were unrelated to him or his sphere of influence.
The C level thing may not have been a "big" mystery, but it was to me, and as somebody who was running the dev of a flagship software product (UniFi) it set off alarm bells that nobody I talked to could explain who was handling the roles of those execs. I'm not exaggerating when I say I effectively got "I dunno" as a response when I inquired, and I dug.
It is good to know, though, that what I experienced wasn't chronic for the entire company's existence.
To clarify on the China thing, I wasn't trying to imply that anything nefarious was actually happening. Just that it warranted some scrutiny when a security focused product was being developed on the Chinese mainland and by a team of Chinese citizens that are subject to CCP laws. Given some of the things that have happened around that country's involvement in tech in recent years, I don't think such scrutiny is unwarranted, especially when the team has a track record of security "goofs".
This right here is why I'll never use Ubiquiti gear. These devices are so obviously backdoored and like swiss cheese, they offer the complete opposite of security. Thanks for sharing the true facts.
I’d never use Ubiquiti’s switches, routers, etc. There are great alternatives there. But when I went to replace my APs earlier this year I still could not find anything less shady that still did what I needed.
Is there an alternative that does PoE w/ multiple APs that hand-off well? And decent hardware…
TP-Link has a similar offering but with similar problems.
OpenWRT on [consumer gear] is not an answer here. More effort goes into the plastic than the hardware. Never dealing with cheap NICs, bad SoCs, inadequate memory, garbage drivers, etc. again.
With that said I'm moving away from Ubiquity after years of broken pointless updates, years long outstanding bugs, and after this thread obvious massive lacking security.
I just only turn my controller on when I’m working now and occasionally have to re-adopt.
And alternatives likely have similar issues. It’s what naturally occurs when small businesses get large, and especially when companies go from embedded to SaaS development.
You really cannot have good security if the goal of your “cloud lead” is to ransomware you.
So yes - they did not have good security so they hired him to fix it :)
Makes me wonder, why are they even settings? Why aren't they just always on?
"Why didn't they just ..."
Where the problem is that the "..." is the subset of non-default security configurations that would have stopped this specific insider(!) attack. They never mentioned that:
- You can't predict which attack you'll be hit with, so you have to implement every non-default / optional security setting or feature in order to be "protected". This is a metric ass-ton of work, typically on the order of multiple man years of up front effort, and then with ongoing multiple FTEs required (e.g.: for separation of roles).
- While you're not actually under insider attack, this provides zero business benefit that can be measured in dollars.
- The people implementing the protection against insider attack are the same people that the protection would typically be designed to stop. No one person can be trusted to do this. Not even any one team. Just organising the Byzantine security required for this is a project manager's nightmare.
- Insider attacks by senior technical staff are stupidly difficult to protect against. I've never seen any org that could survive an intelligent, motivated attacker that already has significant admin rights. Even the FAANGS would take a significant "hit" in this scenario. Ubiquiti is nowhere near their scale or capabilities in this space.
- All that stuff described like "QR codes in a safe" are hilarious to me. Every time I've tried to implement even 1/10th of that, everyone who ought to be responsible for the secure handling of this kind of key material ran away screaming from any personal responsibility. Literally nobody ever wanted to deal with anything even vaguely similar.
- Many of complex delegation systems and IAM technologies suffer from permission-role inversion. Often the CEO/CIO/CTO has virtually no access to the technology stack, but the junior intern from the subcontractor has the keys to the castle and could delete the whole org for shits and giggles. But, you see, he's not "allowed to". But he has the physical permissions. That he's not supposed to use. Because he was told to. You see?
- Now you're going to say that the senior staff should have the admin rights, and delegate the appropriate rights to the junior staff. Oh, you sweet summer child. That requires responsibility! (see above). It also requires that they learn, manage, and monitor something as technically complex as AWS IAM. But you see, senior people are busy people. They're busy with meetings. With memos. And more importantly, they're busy playing politics and jostling for the next promotion. The fiddly security rule stuff they just delegate to the juniors. That's the ticket to the next pay grade!
Obviously we have to take the linked comment at face value.
Oh my sweet summer child. You haven't worked in large organizations with thousands of employees before, have you? Surely not if you think this is "Security 101".
At around ~1,000 staff though you quickly lose "insight" into platform security as it's delegated out to sub-orgs within a larger organisation.
Though I've not worked at any FAANG companies where I'd hope security is... erm, of a certain 'maturity'. E.g. Google and BeyondCorp.
But I've no desire to rehash leet code exams or get back in that space so likely will never go there :).
Not the first time I’ve read about a VPN unable to mask someone’s ip when they were on a wonky connection.
I can't believe someone can literally destroy its life for BTC. Imagine his family and close friends. His parents probably thought he was a tech wizard genius. And now he destroyed his reputation, his employer's, and he'll be behind bars for quite a few years. I hope he doesn't have kids.
And picture: he could have been the guy who did a great job "fixing" employer's lack of security. Have that on his resume, tell lessons learned on real world practice.
Why the hell would he even think about the FBI route in the first place?
This is not really a thing. It's very hard to get recognition or even a shared understanding of the risk mitigation. As everything else in the world, it's way easier to reward someone for things that happen (new functionality) than rewarding someone for preventing things happening (hack).
One was to strike a good balance here is a security roadmap. Write down the adverse outcomes that would be a problem for your business. Write down the possible mitigations, how much they cost to implement and how strong they are. Propose a plan that continuously improves security in a cost effective way. Highlight significant things you can’t defend against yet, and explain how you could address them sooner with more funding. Show the plan to leadership, get it approved, and get to work. Every month / quarter / sprint, write down what you did, show where you are the roadmap, and adjust the roadmap to reflect any changes in business priorities.
In brief, you move your physical eth/wlan device to a new namespace, and create the wg device in that namespace but then move it to the init ns.
By default (and without root) everything will use the init ns and only be able to reach the physical device via wg. If it's not active, nothing will even reach your NIC, nevermind the internet.
Let's say you have a Wireguard configuration, wg0 which runs off ens0. If your wg0 connection dies, for whatever reason (let's say the remote server goes down), your computer falls back to ens0.
What does "not having a connection to be maintained" change about this?
I guess, too much magic automation on top of this is not the best thing for opsec, including having some daemon that can disable your wireguard interface or reconfigure the network if it doesn't like something. You want your network configuration to be static and predictable, regardless of some temporary failures. Basic wireguard kernel primitives will give you that.
So... You'd have to do work to properly blackhole traffic when wg0 goes down. However long it takes to reconnect, you still will automatically fall back down to ens0 while it's down unless you do something to stop that.
Packets are always delivered to wg interface as long as it is marked as 'UP' (or 'enabled', if 'UP' sounds to you like having anything to do with some kind of "connection") when your routing table directs them there.
When they hit the wg interface when the other endpoint is unreachable for whatever reason, they are either dropped, or queued, or get ICMP unreachable response generated for them, depending on situation. This is done internally by wireguard.
If you wanted to not go through wg0 (whether it can reach the other wireguard peer or not) you'd have to remove the routes first.
(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.
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.
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?
If he did pay with paypal, that was his first mistake. Theoretically, you pay for your VPN with a gift card you bought with cash, maybe even one you got in another state and use anonymous email receiver to get your keys. Rotate accounts as project phases are completed.
Theoretically, use a purpose-built machine to keep fingerprints out of the mix, and as others have said, a killswitch using iptables/UFW to only allow traffic through the VPN gateway. Probably wouldn't have hurt to rotated the VPN egress points as well.
Theoretically, he should have been connecting this VPN over a public hotspot not his home network. I get that this wouldn't be conducive to downloading gigs and gigs of data, but if you're the one setting it up and monitoring/junking any logging on the other side, you could also afford to do this with an SBC (or several, again bought with cash) concealed at some location(s) that just pulls the information by slow drip over public connection via VPN. SBCs get tossed into Willamette as they're rotated.
The FBI cyber guys are good and creative but with a reactive situation like this I think old-fashioned gumshoeing, interviews and subpoenas would get them a long, long way. Once they had an inkling that it was an inside job, man, just relentlessly picking away at that with some face time would be really productive. Guaranteed that guy wasn't prepared for the bright light of honest incidental questioning, over and over, much less focused questioning. Not to mention, they are free to lie to your face in those interviews about what they do/don't know. Once they had a list of four people, start shoving out the subpoenas and see what clicks.
Part of their toolbox is also having an idea of what real attacks look like, knowing what those actors care about leaving behind or not concealing, and in the absence of those earmarks, they know they're looking at something "unusual". Now if I start telling you that I did find evidence of an attack of type Y where there absolutely is none, and you're all too eager to help me prove that theory, that's probably a bad sign. Did he have a plan of his own in place to frame some other ransom toolkit or plant seeds of a breach? I mean, what would you think if you walked into a company that got hit with a massive ransom demand, evidence of data theft, but no typical signs of a data breach from the usual suspects? State actor? Now this is serious. Was it their Exchange or RDP server in the closet? Oh, you're cloud-only? What platforms are we talking about? A state actor has zero-days into a major cloud platform?? MS? AWS? Now this is really serious. Or... maybe none of that is the case. Log files are all missing? Who made that decision? I mean, on and on it goes, but it seems pretty easy to see it unravelling once you start pulling on a thread.
If one was really interested, they could probably find some good information in PACER about the information that supported the indictment. Chances are he's already confessed and is attempting to plead out. They'll surely throw the book at him. Insider ransom jobs on US hardware companies are not a tolerable phenomenon.
There is a convoluted way to configure it so that it blocks VPN IP packets from going directly to the WAN, but I noticed it seems to terminate connections when some packet is lost.
I’m thinking after the fact, if the government asked them to log future events.
At minimum, use a burner IP address and hardware from Craigslist.
After all, they are not as trivial to implement as it sounds.
Last time I tried to use tor, I was getting like 32 kbit/sec, on top of a symmetric 100 mbit/second internet connection.
That was many years ago but I doubt they fixed the speed, very hard to do without centralized servers.
I am not sure how it's implemented, but it's pretty easy to imagine someone deciding to not use it cuz "it's slow/annoying" or whatever.
You need your firewall to block any internet access when the VPN is down.
I have something like that set up in a Docker container for my torrenting VPN system, so I never connect with my residential IP.
This is a proprietary application, not just using the OS-integrated VPN software. Given your comment, I imagine it sets up firewalls.
Ouch! Opsec is very easy to screw up.
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
If you connect to one of those, your IP is logged somewhere forever. These same agencies, depending on your country, can probably know who that IP belonged to at the time instantly, or quickly enough.
If the agency has a wiretap on the ISP's fiber, then they'll know even if you're not connected to one of their relays (you could use the unlisted bridges, but they probably know those anyway)
No you won't, because tor isn't a VPN. In fact it specifically tells you not to use it with other browsers/applications. 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.
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.
Then no thanks. I have a finite number of hours on this planet and I have no interest in spending more of them trying to configure network equipment with commands like
/ip firewall filter
add chain=forward action=fasttrack-connection connection-state=established,related \
comment="fast-track for established,related";
add chain=forward action=accept connection-state=established,related \
add chain=forward action=drop connection-state=invalid
add chain=forward action=drop connection-state=new connection-nat-state=!dstnat \
in-interface=ether1 comment="drop access to clients behind NAT form WAN"
Ubiquiti does a great job of having good defaults out of the box, a straightforward UI, and remote management. I could walk my mother through setting up Unifi equipment over the phone and even get so far as to grant remote access to me without ever leaving it in an insecure state. I wouldn't get past setting an IP address in the Mikrotik section before losing that.
Which UI? The UDM has two. Mobile devices have another. Some features are only available on one of the UIs, and when the feature is available on both, it often behaves differently. Sounds pretty straightforward to me.
I ended up buying a Protectli box (FW6E) with OPNsense preinstalled. It's been fantastic, and blows Unifi out of the water.
The fragmentation about Ubiquiti devices drives me crazy - I have the "wrong" consumer wifi AP or the "wrong" (pro)consumer router (take your pick), so half of the wifi AP functionality is disabled - but for no reasonable reason - just they have two (more?) product lines that don't work together and it's hard to realize until you get the products. Overall I've been pretty disappointed by my Ubiquiti hardware - I feel like it was advertised as higher performance and better functionality than it ended up being.
Nope, but I'd love a viable alternative. It seems like every company I look at has some big downside that makes me stick with Ubiquiti.
Although There is a web ui for mikrotik too, ubiquity’s was definitely slicker.
I’m not sure if it’s still ongoing, that’s why I asked if it was.
There's also some random community post here: https://community.amplifi.com/topic/3296/gpl-source-code-ava...
They're still in flagrant violation of the license for all the software they're stealing.
Side note: Free suggestion for a new startup. Make indictments pretty! What is it with all these fonts? Looks they really type this on a typewriter. Are all
court clerks just frustrated novelists?
I'm not from the US, but have met folks from the US. Essentially, the law firms change and digitize, the older institutions such as the courts, will be the last as they are full of people that are much older (judges) than the general workforce, and to them, there is no incentive to change what works, and what is comfortable to them.
Also, they are trained to argue. So you can't just go in there and easily change their mind.
EDIT: They still love to print paper.
Not sure anything more than a browser extension would be needed.
As a long time user of ubiquiti devices, I’m glad this was the actual story. It actually makes me feel a lot better since this kind of risk is extremely hard to defend against and unrelated to their hardware.
Maybe a good time to buy some 2yr leaps.
Fake vulnerability or not, this is the worst part about their devices these days.
Speaking of which, are there any semi-pro APs that still work without going through the vendor's servers?
Ubiquity works without their "cloud" if you install their management software on your computer (I use a VM on my server). In my experience, you don't even have to run their management software once you have the network configured. If you are paranoid, install their s/w on a VM, set up your network, and then shut down the VM. You should bring up the management VM periodically for software updates, but otherwise it runs fine.
The new one wants me to register somewhere...
Mind, I haven't checked in 6+ months. I just use the old software I still have on an older machine.
A lot of corporate leadership are extremely paranoid and that's why whistle blowing is such a dangerous activity.
How strong do we all feel most digital evidence gathered really is? How much faith do we have in the technical knowledge of the investigators? Or the courts to parse this type of evidence?
AWS provides all the tools to do this and it does not take that much work to implement. There is zero excuse for a company to allow cowboy shit like this.
Is it possible, technically yes, but the level of paranoia and mistrust required to prevent this kind of thing is never going to be supported by leadership or other engineers trying to do their jobs.
Should you lock up your root key effectively like you describe? Absolutely. Should you do other things to restrict access to sensitive data? Absolutely. But whatever you do, you’re not going to be able to avoid a sophisticated internal attacker without making normal work extremely difficult.
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.
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.
>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.
If it was An-Cheng or Stig I'd agree but given a lot of what Ubiquiti puts out... the bar isn't all that high. Given all of the dumb moves we know he made, it doesn't really surprise me that he would screw up guarding against a VPN dropout. It wouldn't even surprise me if Surfshark screwed up blocking while reconnecting, especially if it was DNS I can see someone making a boneheaded decision to switch name resolution back to the local network while trying to reconnect to lookup the address of the VPN endpoint. It's a consumer VPN, they only really care about hiding from DMCA notices and evading geo-blocks.
Now the Silk Road arrest of Ross Ulbricht on the other hand, that was a travesty of justice. Not that I think he was innocent or shouldn't be in prison, just that in a perfect world many of the prosecutors and federal agents involved would be in a cell beside him.
no parallel construction imo.
Other than that, I've never wanted it to do something that it can't do.
Oh, I know.
Sergey Aleynikov says "Hi."
His case was less about extortion, and more just grabbing what he could on the way out the door, but it was sloppy.
Sharp obviously never learned Goldman Corp. Comm. Rule #1:
"Don't talk to the press"
talking to FBI
being a terrible extortionist
devising such a terrible way to make money
Sort of like how they show a person trying to make enough to pay some medical bills or something.
Uh, you might want to take another look at the current price of bitcoin. Even at the time, that was around 750k to 1mm USD.
25 for the data not be release and 25 for him to tell them about the "backdoor" he used to access their system.