It rather required being on the other side of this airtight hatchway: Knowing the domain administrator password
A security vulnerability report arrived that went roughly something like this.
If a system’s built-in local administrator account is not a domain administrator, but the local administrator account’s password matches that of the built-in domain administrator account, then that local administrator can connect to a domain controller, and it will grant the user domain administrator privileges, even though that user is not actually a domain administrator.
What’s happening here is that when you connect to another system on the same domain, Windows will use your userid and password to connect to that system, on the theory that the other system will honor your userid and password, seeing as it’s part of the same domain.
The finder argued that this shows that the attacker can gain domain administrator access without knowing the domain administrator password. All they have to do is match their userid and password to those of a domain administrator.
But wait. If the attacker can match the userid and password to those of domain administrator, then this contradicts the claim that the attacker doesn’t know the domain administrator password. You need to know the domain administrator password in order to match it! The local account is just a decoy. The attacker doesn’t need it. They can just log into the domain controller directly with the userid and password they already know.
This is like saying, “I can open the victim’s luggage combination lock without having the code. All I have to do is change the combination lock on my luggage to match the victim’s. Now I can use my luggage lock code to unlock the victim’s luggage!” Well yeah, but the “change the combination lock on my luggage to match the victim’s” step implies that you do know the victim’s luggage code. Otherwise, how did you manage to match it?
In this particular case, the userid is “Administrator”. The Best Practices for Security Active Directory recommends restricting the built-in administrator account to physical access, so that it cannot be used remotely at all.
Now, if the attacker is someone who was able to take over the account of a local administrator by exploiting some other vulnerability, then it’s true that the attacker could use the local administrator account as a stepping-stone to the domain administrator account, but only if the domain administrator is stupid and not only left the domain administrator password enabled for remote access, but also reused their domain administrator password as their local administrator password.
Mind you, even if the passwords didn’t match, the attacker might still be able to gain domain administrator access if the local administrator had saved the domain administrator’s password in their credential cache. Or the attacker can just sit and wait for the local administrator to enter the domain administrator password in order to do some domain administrative thing, and then take over the session. Once the local administrator account has been breached, the attacker can do anything the local administrator account can do. If you set up the local administrator account so it also has domain administrator access, then you opened a hatchway from one ship to another ship, and you shouldn’t be surprised that people who get onto the first ship can use that hatchway to get to the second.
Light
Dark
5 comments
Let’s say that the domain administrator didn’t follow the best practices, so that it was indeed possible for the scenario mentioned in the report to happen.
Further, let’s say that the domain administrator and the local administrator are both the sort of people whose luggage combination is 12345, whose ATM PIN is 1234, and whose password is Pa$$word1. (It would be password, but complexity requirements, you know.)
Now you have a collision that didn’t require either of the people involved to know the other’s password, or really even to know much beyond how to keep breathing.
It’s highly improbable that such a password collision could occur randomly if passwords were actually random, but is it impossible?
The same logic can be applied to password guessing. No need for domains or account collision here. Even with truly random passwords, it’s still possible to guess them by chance. What saves us from that is precisely that it is highly improbable.
The difference is one of intent. If you’re trying to guess passwords, you know you’re trying to guess passwords. If you accidentally end up logged in as a domain admin because you connected to the wrong machine, you might not know you’ve even done so until you’ve ended up somewhere you shouldn’t have and caused irreparable damage.
“What saves us from that is precisely that it is highly improbable.”
That reminds me of something from quantum mechanics – namely, the fact that an electron needs to get all of the energy required to move it to a higher energy state from a single photon.
From what I’ve read, there is theoretically nothing preventing an electron from absorbing energy from multiple photons. However, the probability of it being hit by even one photon is already quite low, and the chances of it getting hit by another photon before dropping back to a lower energy state are so small that it’s considered essentially impossible.
(Once again, this is just my understanding – happy to be corrected if I’m wrong!)
This somehow doesn’t feel quite as black and white as the other examples in this category.
After all, preventing this is kind of the reason we need both username and password and systems preventing duplicate usernames even if passwords wouldn’t match since passwords can indeed coincidentally match.
The issue is that in this case the system assumes that Administrator@machine1 is the same username as Administrator@machine2.. I have always found it strange that I open RDP connection and log in to the remote machine using LOCAL\username – not having to write REMOTE\username