If someone was able to gain system-level access to a machine with ZeroTier installed and authorized to a network, would they be able to copy config files to another machine and authorize that machine to the network without access to the controller?
There’s nothing in the install of ZeroTier that allows you to authorize devices on a network. You can only authorize members via the network config web page, or via an API key generated at https://my.zerotier.com. I’m assuming that you’re not keeping your username & password and/or API keys in plain text laying around on the machine in question.
If you’re running your own controller, and the user gains admin level access on the machine running the controller, then yes, they will be able to authorize members along with anything else they wanted to do on the machine in question.
I was more wondering if once a machine was authorized if there were keys stored on that machine could be taken and used on another machine to gain access to the ZeroTier network bypassing authorization potentially.
I suppose it’s possible to steal the node’s identity if the user has Admin access to the machine, but if they have broken in and gotten admin access already, then you have bigger things to worry about. However, if they did try to join the network from another machine with the same identity… Well, ever run into the situation where two machines on a LAN have the same IP or MAC address? It breaks things. The same situation would happen on ZeroTier because IP addresses are tied to the ZeroTier identity, and the zerotier adapter on each machine is a virtual ethernet card. It would behave the exact same way.
Thank you for these responses. I agree that there would definitely be bigger problems if a malicious person has that access to a machine. I need to add de-authorizing nodes into our incident response plan.
I feel like it would be highly unlikely that something like this would happen. My concern is code like dridex for instance goes undetected for a few days and captures the node’s identity. If a user were able to connect an outside machine to the network with no AV, EDR, or monitoring, they would be able to execute code undetected bypassing a few security layers.
We are debating on building an authentication platform requiring a user to auth with 2fa with each Windows login which would reduce this risk. The rhetorical question- is Windows auth enough to allow constant network access? It sure is convenient, but I’m not sure
I can’t tell you anything on Windows auth, unfortunately. Not my area of expertise
On the other hand I would assume most active users of this forum will stay signed in on ZeroTier Dsicussions. Correct me if I’m wrong, but it also gives up full control of your networks.
No. This is a separate site. Just because you stay logged in here doesn’t mean you’ll stay logged in on https://my.zerotier.com.
@zt-grant That’s not what I’m seeing here.
- Sign out of MY.
- Go to Discussions and log in (with google account).
- Open MY in a new browser tab.
I’m now automatically logged in on my.zerotier with discussions account (i.e. the same name).
- Set up 2FA on MY and log out.
- Go to Discussions and try to log in.
It asks me for second factor so it is not separate from MY account.
What I’m doing wrong? I know I can set up a dummy account just for discussions, but it doesn’t solve the fundamental flaw.
Yes, there’s a shared authentication system. Your login sessions time out at different rates. If you come back at a later time, you’ll still be logged on here on the discussion forum, but you’ll have to re-authenticate to access your networks.
I’m also not understanding your “Fundamental Flaw”. Protection of your usernames/passwords/api keys/ is up to you.
OK so let me explain. In general I’m trying to be proactive and apply some network hygiene.
I’m logging in to my Central account only from trusted machine/account that I fully control, because loosing these credentials can have really bad consequences.
But when it comes to less important things - say keeping track of posts on some forum that I like to follow in the mean time - I don’t mind logging in from other machines in the office or at home. They are not worth the trouble.
So entering my important credentials via less trusted machine (and I’m not talking about random PC at hotel reception) is fundamentally wrong for me.
But even if you dismiss everything above let me ask you this.
- You are logged out from Central.
- You log in to Discuss.
- You log out from Discuss.
Would you expect to be logged in to Central at this point?
Turns out some dodgy system automatically authenticated you to Central behind the scenes but never bothered to log you out. That is what I call a security flaw.
It’s no more of a security flaw than logging into your Google account. By having a Google account you have access to Gmail, Calendar, Docs, Groups, etc. You aren’t expected to create brand new accounts with separate logins and passwords for each individual service. Additionally, if you log in at one, you don’t have to log in to all the others.
Same thing here. You have a ZeroTier account that gives you access to Central as well as this forum, and possibly other things in the future. We don’t want, nor do we expect you to have to manage separate login/passwords for each one. You have a ZeroTier account and that grants you access to everything we offer via OIDC or SAML depending on the service. These are authentication and identification systems the entire web runs on. Our web properties are no different and no it is not a security flaw.
I just tested this. Your right, Logging into Discuss does auth you to myzerotier. Zerotier being such a powerful tool I see the concern.
To be honest I’ve never met a system like that. You focus on “log in” part. That’s OK. I don’t like this behavior, but it is fairly common.
I’m talking about “log out” part. I don’t find my Google Calendar authenticated when I log out of Gmail.
You can create separate accounts if needed. Use one account for your production network management and the other for personal stuff and Discuss.
One option would be to host your own controller if these answers are not good enough. For me understanding the behavior is good enough.
Exactly what I’m doing and it works well for me from usability and security point of view.
Still, it’s just a workaround for a broken system. It doesn’t fix the system.
And I’m not trying to force anybody to my way of thinking, it’s more about reporting. I did my part and you can officially ignore it now I love ZeroTier anyways as it solves real problems for me and Discuss is a great add on.
I have done this on few of the PC’s I use. In order to login, You are required to input your “Username, Password & OTP Code”. I have set the OTP code to be generated by Google and Automatically creates a new code every 30 secs.
@jcline back to your initial question about taking over node’s identity.
Attacker only needs a copy of
identity.* files and
networks.d directory. With these tokens he can join your network as authenticated node and do his usual stuff. No surprise here.
I’ve cloned one node into three VMs and didn’t notice anything in the Central console to give me a clue other than changing public IP address. I also didn’t notice any connectivity issues on them but in general it’s not a wise idea to have 4 devices with the same IP address on the network so I manually changed IP address on a rogue node and it still worked fine.
So IP address conflicts is not an issue for attacker as long as you are using default Flow Rules. To prevent this you should consider uncommenting this block:
#drop # not chr ipauth #;
It’s interesting problem you brought up. Anyone has ideas about how to mitigate this situation? At least, compared to traditional networks, ZeroTier makes it very easy to cut this node out once you realize what’s going on.