It rather involved being on the other side of this airtight hatchway: Administrator attacking a domain account on the local system
A security vulnerability report came in that said that a local administrator can attack the system and sign in on the local system as a domain account without knowing the account’s password.
So far, no security boundary has been crossed. The attacker is a local administrator, and a local administrator already has full control over the local system.
While it’s true that the administrator has compromised a domain user account, this ability to act as the user does not extend outside the local computer. You have control over the domain user account on the local system, but other computer systems will recognize you for the fraud that you are.
In other words, the attacker has gained nothing. They started as a local administrator, which gives them full control over the local system. They then attacked a domain account, which gives them all the powers of that domain user on the local system. But this is a subset of the powers they had as an administrator! Nothing was gained.
This compromise of the domain account on the local system does not extend to other systems, so the attacker gained no privileges on other systems.
The finder even acknowledged in their report that the compromised account is not recognized by other computers on the network. I’m not quite sure what vulnerability they were reporting. I mean, maybe they’re just saying that they found something interesting, but “interesting” doesn’t mean that you have a security vulnerability. Really, all they did was find a way to do something the hard way. The easy way is to just use your existing administrator powers.
Light
Dark
10 comments
That is true, but it open the door to installing something which then is able to do its thing once the user logs in and does have network access. Of course, the local machine is already compromised – but this makes finding the cause a lot harder. But an admin which isn’t truly an administrator would not be able to be an administrator.
If you are willing to wait until the user logs in, then you can accomplish this without a complex attack. Just drop a rogue program in the global Startup folder. The rest are just style points.
Isn’t “identity theft” also a vulnerability? It allows the attacker to cover their tracks for example when doing things as the user is enough to cause trouble. Someone else gets the blame because of the vulnerability. Sure the admin can create an exe that is run by the user. But the exe has metadata that the admin created it. The exe might delete itself, but the audit trail might still be there (defender lets you track those, I think). Anything (in theory) the admin does is/should be auditable, unless it’s a bug. The vulnerability might be in avoiding the audit trail.
Administrators have the power to tamper with anything in the system. After all, they are administrators. They can install a driver that falsifies the audit trail if they want. If you don’t trust a person not to do that, then don’t make them an administrator!
Installing such a driver should (I don’t know if it does) also leave an audit trail, raise an alert and get reverted. Everything an admin does, whether trusted or not should be auditable. You may trust the admin, but the users and customers not so much – they don’t even know the guy. Especially with high security projects (medical, gov…) auditing is a legal requirement and the possibility of going around it is a problem.
There are specialized systems with strict requirements like that. But for the most part, it’s not usually built into a general-purpose operating system, because on a single user system, pervasive audit logging is (or could plausibly become) a privacy violation. Windows, like other systems, does not force you to use audit logging if you do not wish to do so.
In cases where auditing is useful, it is usually done at a much higher layer of abstraction than the operating system on each individual machine. Auditing often requires identifying the provenance and sensitivity of data (e.g. “Is this real customer PII, or is it fake test data?”), which an OS is poorly equipped to handle. More generally, useful audit logs typically have a much coarser and more application-specific granularity than what the OS can meaningfully provide – we want to know that employee A accessed user B’s data, and the ticket associated with this access, but the OS can at most tell us which files were opened and what offsets were read at a given time. Correlating all of that low-level file data and relating it back to the original business logic is nontrivial, and good audit logs should not require us to do that. The OS-level audit logs are obviously better than nothing, and may be useful in contexts where we are concerned that an individual machine could have been compromised, but nobody pretends that they are a complete, out of the box solution to the auditing problem, because that’s a really hard problem to solve.
Obviously, it is desirable to prevent a single human from having unilateral administrator privileges over a given machine, to protect against all kinds of insider risk (not just audit violations). However, this is usually accomplished with authentication (or impersonation) barriers rather than authorization barriers (i.e. rather than prohibiting the administrator from doing things, we prohibit humans from assuming the mantle of “administrator” in the first place). It is not unheard of, for example, to have systems that require two people to concurrently exercise administrator privileges on an action-by-action basis.
Easy to say, not so easy to do.
May I ask a question please. A process created by System user can`t get clipboard data which format CF_HDROP.
It’s not clear to me from the writeup, although I presume the answer to be “No” – could they use this approach to sign in with a domain account that is a domain administrator? Because then it seems to me that they could rid themselves of any inconvenient group policies set by domain admins, which does seem like a vulnerability. But I’m not very clear on all this stuff so I welcome any correction.
I should emphasise here that while I am in this situation, as a local admin on my work machine but constrained by various group policies (sometimes in annoying ways), as a responsible user I do not wish to and will not attempt to get around them. In addition, trying to do so would of course be a fireable offense.
If you’re a local admin you can already get change any inconvenient group policies and then afterwards change the sync time to ensure they’re not synced with the AD.