Hacking News
-
@Bulb said in Hacking News:
@topspin said in Hacking News:
I didn’t really read / understand that article too well
. What’s going on, something about outsiders getting access by triggering password reset emails? How does that work?The article mentions some alternate e-mails, but doesn't really explain, so I was rather puzzled too.
Either someone did an unbelievably stupid thing of letting you specify an e-mail where to send the password reset link completely arbitrarily or … I think that's probably that.
The password reset endpoint would accept multiple email addresses and, as long as one of those was the correct email address for the target, it would send the recovery email to both. So yes, effectively that.
-
@Bulb said in Hacking News:
@Arantor said in Hacking News:
@Bulb my old employer did this.
So, consider the following. Company is a hosting company, with the various sources to be deployed hosted on said GitLab instance. Originally this was internal only.
Now consider allowing a customer you trust (
) to have access from outside the internal network, and not handle this by some form of tunnelling.All your internal users ca be tied to your internal auth but the external ones, um, weren’t.
… so a wrong reason, I see. In all the subcontracts I did, I always got a customer account for accessing their systems. Not doing it is … a
.They may have changed this since I left but it was changed to this vulnerable state while I was there and I raised concerns. But the client in question was paying enough bucks to make this happen. (Most other clients just paid for “do this thing, deploy it” and not have direct full access to the code on demand)
You correctly raised concerns. It should have been connected to some central auth.
@dkf said in Hacking News:
@robo2 said in Hacking News:
@dkf but wouldn't that only be relevant for the build/test agents/runners? You can still have those on premise while "the rest" of gitlab is hosted. We do this with github and azure devops.
With much of the higher end of hardware development, keeping the SCM repos on premises as well is common, as part of risk management (especially relating to corporate espionage). It's very different to software, where the main defense is typically just making the whole system so difficult to build and deploy that everything is quite safe even if the source code is out in the open...
When it's for risk management, sure the first thing you want to do is connect it to a central identity management, so you can centrally audit who has access where.
Except... you need to collaborate with selected outside experts (they might be the people who understand how to really make some of the modules on the ASIC) and you don't really want to trust most of your own staff either. Sally from Marketing doesn't need access, nor does Bertram in Accounts Payable. When faced with a real set of requirements like that, you operate an organisation within an organisation and don't trust the outer org at all. In theory you could allow identity assertions to be carried over, but that gets messy because AD federation gets messy (especially as the people who can set up the permissions aren't trusted).
The core concept here is that Central IT are part of the "not trusted" group in this scenario.
-
@Carnage said in Hacking News:
It's mildly amusing, but a lot of bean counters seem to think that it's cheaper as well. Dunno how it could be cheaper to let someone else hire staff to do the exact same thing and then also turn a profit from the job. If you can't do it cheaper inhouse you probably suck at IT.
Economies of scale. Running a large instance that handles hundred times more load isn't anywhere near hundred times more work. Not even ten times more. So a large company that needs a decent sized IT department anyway should be able to do it cheaper in house, but a small one might not be.
But a large company will want to be ISO-27001 certified and that means having a central identity management and therefore they won't be using the built-in identity management with the vulnerability anyway.
Though I do see the point for companies that don't really do IT because it's either not what they do, or they are too small to have a real need for it yet. A fixed rate cloud thingymabob works perfectly fine for them, and they don't have to hire IT staff.
The main issue is approving investments compared to expenses. Monthly expense is relatively easy to get approved compared to investment in buying servers where you need to shell out a large-ish sum of money up front and then estimate how long it will last and calculate amortization.
On the other hand employees have a monthly salary they get paid whatever they do, so often managers end up considering their work “free” and don't see that if they saved their time here, they could do something that would bring more profit to the company instead. Of course only until they need to hire another employee, that needs to be approved and is hard again because the salaries in this business are rather significant part of the costs.
-
@dkf said in Hacking News:
Except... you need to collaborate with selected outside experts (they might be the people who understand how to really make some of the modules on the ASIC)
You give them accounts in your central identity management system. Everybody I've encountered so far did it that way.
and you don't really want to trust most of your own staff either. Sally from Marketing doesn't need access, nor does Bertram in Accounts Payable.
You don't add them to the security group required for accessing the system, that's easy.
When faced with a real set of requirements like that, you operate an organisation within an organisation and don't trust the outer org at all. In theory you could allow identity assertions to be carried over, but that gets messy because AD federation gets messy (especially as the people who can set up the permissions aren't trusted).
That's why everybody gives their contractors and partners accounts in their own AD.
Well, it also works better in the online version, now called Entra. There you can have guest accounts where the user still authenticates with password for their primary domain, may get a separate second factor for your domain depending on configuration, and you control their permissions in your domain.
The core concept here is that Central IT are part of the "not trusted" group in this scenario.
That's handled by making sure nobody in the central IT has control over all the parts, making sure all changes to the identity management are traceable to appropriate requests and approvals, and auditing the state of the identity management. But definitely not by allowing department-specific systems to handle authentication separately.
Or even if you do conclude allowing department-specific systems is a good idea, it should still be a central system for the deparment, so at least an LDAP server, not just letting each service run with its own identity management.
-
-
@Bulb fun fact, you do not need a central identity management for ISO-27001.
Source: two companies that went through and got ISO-27001, including more than one annual re-review, that I’ve worked for managed to pass the audit while not having a properly central auth for anything beyond email, at the time of the audits.
-
@Arantor Yeah, I think we were forced to unify the identity management (back when I started we had two parallel, one for the then-still-Office-364 and one plain old LDAP for the legacy on-prem systems) by that big multi-national customer of ours than by the ISO-27001 … to which we were forced by another customer demanding we do TISAX and it's almost the same, so we did both.
-
Novel attack against virtually all VPN apps neuters their entire purpose
TunnelVision vulnerability has existed since 2002 and may already be known to attackers.
The researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android.
...
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn't implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.
-
@boomzilla said in Hacking News:
Novel attack against virtually all VPN apps neuters their entire purpose
TunnelVision vulnerability has existed since 2002 and may already be known to attackers.
The researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android.
...
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn't implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.
If you control the DHCP server used to hand out addresses to VPN clients, you can compromise traffic sent over the VPN.
NewsFUD at 11!
-
@boomzilla VPN attacks which require connecting to a hostile VPN concentrator? Isn't that an other side of the airtight hatchway problem?
-
@PleegWat the way I read it, it's about controlling the DHCP server on the local network, e.g., the coffee shop wifi.
-
@boomzilla Sorry, RTFA
applies.
-
@PleegWat Making note: CVE-2024-3661. Look up on some internal systems tomorrow.
-
@boomzilla said in Hacking News:
Novel attack against virtually all VPN apps neuters their entire purpose
TunnelVision vulnerability has existed since 2002 and may already be known to attackers.
The researchers believe it affects all VPN applications when they’re connected to a hostile network and that there are no ways to prevent such attacks except when the user's VPN runs on Linux or Android.
...
Interestingly, Android is the only operating system that fully immunizes VPN apps from the attack because it doesn't implement option 121. For all other OSes, there are no complete fixes. When apps run on Linux there’s a setting that minimizes the effects, but even then TunnelVision can be used to exploit a side channel that can be used to de-anonymize destination traffic and perform targeted denial-of-service attacks. Network firewalls can also be configured to deny inbound and outbound traffic to and from the physical interface. This remedy is problematic for two reasons: (1) a VPN user connecting to an untrusted network has no ability to control the firewall and (2) it opens the same side channel present with the Linux mitigation.
The most effective fixes are to run the VPN inside of a virtual machine whose network adapter isn’t in bridged mode or to connect the VPN to the Internet through the Wi-Fi network of a cellular device. The research, from Leviathan Security researchers Lizzie Moratti and Dani Cronce, is available here.
They give little details, but I think I understand what they are doing: they advertise additional route or routes via DHCP (that's what the option 121 is) so that the traffic that should be routed to the virtual network interface created by the VPN software is routed to the physical network anyway.
Except … that should be fairly trivial for the VPN software to prevent. Just instead of simply setting up a default route through the virtual device, read the existing routing table—that was filled by DHCP with the option 121—and create higher priority routes for all ranges except the one IP address of the gateway to which the encapsulated packets are going.
Since the Cisco AnyConnect I use to connect to work breaks routing to the internal 172.16/12 subnet used by WSL2 and virtual machines unless being explicitly told to route it outside itself, I am somewhat confident it already does override the whole routing, making any funny DHCP-defined routes irrelevant.
Of course the attack does not affect VPNs to private networks anyway, because the bypass has no way to get into the target network, so the VPN just breaks, but no traffic can be observed.
And then there is the strange talk about side-channel. If you prevent the bypass by setting up firewall, your connection will simply break instead of being observable, but I don't see how that could create a side-channel, and I don't know what other work-around they mean.
Also, on Linux you can set up the virtual interface in a namespace and attach your session to that namespace, which is equivalent to the VM solution, which doesn't seem to be supposed to open any side-channel.
Anyway, I'd expect any good VPN software to already neutralize this, and if it doesn't, it is extremely simple-minded.
-
… so I read the original article.
- It does mention the namespaces in Linux as a complete fix, linking to pre-existing wireguard documentation describing how to set it up. With the added enhancement that the documentation tells you to actually move the physical devices to a new namespace, leaving all processes in the one that only sees the tunnel.
- It explains the side-channel: if the VPN sets up a firewall to now allow traffic through the physical interface except for the gateway, the DHCP can add routes for only specific ranges and check whether the amount of traffic decreases, concluding it successfully broke some connections to that range.
- It kinda relies on setting very short lease period, adding the routes after the VPN started and relying on the VPN software not monitoring the routing table for changes.
-
-
Speaking of VPNs, I'd be really surprised if they aren't already under surveillance and make no difference at all with regards to privacy from spying state actors. Much like how TOR is completely compromised, and will rather put the spotlight right on top of you instead of protect you. If you don't want your shit traced, set up a jump host in a wall somewhere you can access power and a public wifi, and connect to that thing from a laptop that you use for nothing else, and that never stays where you live. And is powered down by removing the battery. Oh, and do not bring any electronic devices from your regular life anytime you plan on using this computer.
VPNs are for accessing region locked streaming media, nothing else.
-
@Carnage said in Hacking News:
VPNs are for accessing region locked streaming media, nothing else.
Also for accessing my work CIFS mounts from off campus, though that's a different type of VPN...
-
@Carnage Yes, there will be state actors monitoring the VPNs exit side. This concerns the coffee shop wifi you are connecting to, which is an entirely different kind of hacker. Might be as innocent as the coffee shop owner blocking porn sites. Might not be.
-
-
@Zerosquare said in Hacking News:
@Carnage said in Hacking News:
TOR is completely compromised
It is?
Yes. TOR exit nodes are mainly controlled by state actors, and have been for at least about a decade now.
-
@Carnage said in Hacking News:
@Zerosquare said in Hacking News:
@Carnage said in Hacking News:
TOR is completely compromised
It is?
Yes. TOR exit nodes are mainly controlled by state actors, and have been for at least about a decade now.
It's almost like the only people with sufficient financial incentive to run VPN concentrators are people who profit from having traffic come through a VPN concentrator they control
-
@Carnage said in Hacking News:
Yes. TOR exit nodes are mainly controlled by state actors, and have been for at least about a decade now.
Isn't TOR design supposed to be somewhat resistant to the effects of that?
(At least if you're not foolish enough to use unencrypted data)
