I would like to raise a concern from a security perspective regarding the Desktop Edge Client, both on macOS and Windows (primarily Windows).
As I understand it, once the Ziti Desktop Edge Client is installed on a machine, the user has access to the GUI and can enroll a JWT directly from the client. This does not appear to require local administrator privileges.
My concern is the following scenario: what prevents a malicious user from enrolling a JWT for a Ziti environment they control? Once enrolled, they could potentially bind services and tunnel arbitrary traffic through the client. In practice, this could allow them to route traffic through the workstation and effectively gain broad network access.
From a security standpoint, it would seem safer if enrolling a JWT required elevated privileges (such as local administrator rights) or some other form of restriction. Otherwise, a standard user on a workstation could enroll into an external NetFoundry/OpenZiti environment and establish network connectivity without administrative approval.
Has this risk been considered, and are there recommended mitigations or configuration options to restrict this behavior?
The only answer here I can think of is the "standard security practice" of "don't leave your machine unattended and unlocked". (which not only blocks this particular attack but all the other ones that come along with leaving a workstation unlocked). That's really it at this time that I can think of. This was a deliberate choice. We need people who aren't administrators to be able to add identities because many enterprise users aren't administrators to their own machine and it's effort on that IT staff to automate this process. It's conceivable that some day we might add an option to 'lock' identity addition, but it isn't something we've seen a demand for from our NetFoundry customers to date that I know of so far.
Yes that risk has been covered and considered before. Along with the risk of a rogue network administrator "binding" services from your devices. Our ziti-edge-tunnel has a "run-host" mode (where all it can do is offload traffic, not intercept) but we haven't implemented "intercept-only" mode because it's a fair bit of effort to make it work the way we want it to work. (that particular request has surfaced here a couple of times here on discourse as well as internally)
The issue can seem like a sticky one when looked at in isolation, but the issue is that if that particular action was blocked, a malicious user could use any number of VPNs, directly or browser based to do the exact same thing. So while it is a risk, the real risk of malicious users exfiltrating data or using it as a jump point to attack internal networks is not truly mitigated by blocking it.
If it is a risk you need to mitigate for business reasons, there are methods like whitelisting (not that I like it, I said it’s an option) and monitoring traffic flows and behaviors (UEBA, etc.). Stopping exfiltration and intrusion by a determined malicious user is something that takes a significant amount of effort and friction.