It rather involved being on the other side of this airtight hatchway: Account vulnerable to Active Directory administrator

A security vulnerability report came in that went something like this:

Disclosure of arbitrary data from any user

An attacker can obtain arbitrary data from any user by means of the following steps:

  1. Obtain administrative access on the domain controller.
  2. Stop the XYZZY service.
  3. Edit the XYZZY.DAT file in a hex editor and changes the bytes starting at offset 0x4242 as follows:
  4. ...

There's no point continuing, because the first step assumes that you are on the other side of the airtight hatchway. If you have compromised the domain controller, then you control the domain. From there, all the remaining steps are just piling on style points and cranking up the degree of difficulty.

A much less roundabout attack is as follows:

  1. Obtain administrative access on the domain controller.
  2. Deploy a logon script to all users that does whatever you want.
  3. Wait for the user to log in next, and your script will DO ANYTHING YOU WANT.

No, wait, I can make it even easier.

  1. Obtain administrative access on the domain controller.
  2. Change the victim's password.
  3. Log on as that user and DO ANYTHING YOU WANT.

You are the domain administrator. You already pwn the domain. That you can pwn a domain that you pwn is really not much of a surprise.

This is why it is important to choose your domain administrators carefully.

Comments (45)
  1. Entegy says:

    Man, they didn't even pretend this time around. Step one was essentially "pick run as admin from context menu".

  2. Joshua says:

    I've seen stuff like this come up due to the Stupidity of the S-Ox law. The reset password is detected very quickly which is good enough but the direct attacks won't be.

    As late as XP we had a solution: remove Domain Administrators from the Administrators group. Vista puts it back.

  3. henke37 says:

    Admins being able to do whatever they want? Shocking!

  4. Kirillenseer says:

    I'd really like to know who's stupid enough to pull that off.

  5. alegr1 says:

    There is a subtle difference.

    Resetting the password will have the user noticing that. This may also cause loss of access to encrypted files.

    Having a local administrator access to the computer will not get you access to the user's encrypted files, if the recovery certificate is removed from the computer.

    But if you run a script in the login context of the user, you can get all their encrypted files, and the user will not notice that. Ed Snowden likes that.

    [Doesn't matter, because the domain administrator will set up the domain controller as the recovery agent. The intended purpose is so that if you lose your encryption key, you can ask the domain controller for a backup copy. But it also means that the domain administrator can decrypt all your stuff. "This is why it is important to choose your domain administrators carefully." -Raymond]
  6. Freddie says:

    Looks like time for a follow-on to the venerable MS07-052:

    MS14-052:  Administrator privileges result in administrator privileges.

  7. Entegy says:

    Is there something special about MS07-052? Or was that just a random number and it happens to map to a legit vulnerability?

  8. IanBoyd says:

    @Entegy I believe he is trying to imply that allowing Domain Admins to create logon scripts is a "Remote Code Execution vulnerability". I believe he is confusing "remote code execution vulnerability" with "not remote code execution vulnerability".

  9. Hildar says:

    Better report this security bug now! If an attacker can get physical access to a (writeable) Domain Controller, they can, through a convoluted method, set everyone's desktop to cat pictures!

  10. Brad says:

    I appreciate and enjoy these "airtight hatchway" posts. But I think they show the disconnect that software designers have with ordinary people. Ordinary people don't expect that domain administrators can read everyone's documents.

    I actually think a lot of security problems come down to the fact that the design of the security policies in Operating Systems doesn't account for user psychology very well at all (i.e. programmers are crappy psychologists).

    There certainly are other ways it could work that would prevent this sort of thing (e.g. shared secrets, etc.).

  11. @Brad: There are, but it's not easy to keep the balance between security strength vs usability.  It ultimately has to do with the fact that it's really hard to share secrets and keep them secret.  The more the secret is shared, the less of a secret it is/may be.  You can make the secret harder to understand, but that intrinsically makes communication more difficult.  The same parallels are seen in computer science as well.

    Then you have the whole "this should be secret even though you don't really know that" thing, like what UAC is supposed to help with.  The problem is that ultimately for most people computers are appliances that are used to fulfill tasks, not objects of value that need to be protected (at least, not software-wise).  Making users understand that requires them to completely rethink what computers are, which isn't practical.  This is why the major OS companies lock down application functionality very tightly for consumer-based devices: if the user doesn't understand the value, then the OS needs to protect the user.

    It kind of sucks for power users and administrators who enjoy the flexibility of running arbitrary programs and scripts, but then again, that's what rooting and Windows Desktop is for.

  12. You can't really use technical solutions to fix non-technical problems.  If you don't trust someone with administrative rights then don't make them an administrator.  That's really the only solution you have to the "problem" of "administrators can do anything they want".

  13. @Joshua: removing Domain Administrators from the Administrators group doesn't achieve much anyway.  Group policy would be the easiest way for a rogue administrator to bypass it, though there are plenty of other methods, even without resetting passwords.  (For one thing, a domain administrator has access to the Kerberos master secret, so could construct forged access tokens.)

  14. Joshua says:

    @Harry Johnson: With that removed we can block GPO updates permanently then audit the existing policy. Forging the kerberos ticket doesn't do anything with the server service disabled. Resetting the password works, but that's intentional and noisy.

    [If you distrust the domain so much, then why did you join the domain? -Raymond]
  15. cheong00 says:

    Some people prefer TrueCrypt over BitLocker because of this – it's not controlled by GP so if the domain controller got compromised, the attackers don't have immediate access to your documents.

  16. meh says:

    I usually remember to encrypt all my truly confidential files with my own private key, which I store in C:miscpins_and_keys.txt in case I forget it.

  17. @Joshua: well … maybe.  A rogue domain admin could change the password and then change it back again straight away (tricky, but not impossible) or subvert the password verification process.  But if the machine isn't accessible over the network anyway, and assuming that the attacker doesn't have physical access, I don't suppose that would matter.

    I think you'd be better off not joining the machine(s) to the domain in the first place, though.  I'm not convinced that "security by hacking" is a sound approach.

  18. Joshua says:

    [If you distrust the domain so much, then why did you join the domain? -Raymond]

    To use single sign-on to access domain resources.

    [Then you have a social problem, not a technology problem. The domain administrator said, "All computers which access domain resources must adhere to the following policies…" You don't want to adhere to those policies. You need to talk to your domain administrator and work out some sort of agreement, say, to exempt your computer from some of the domain policies. -Raymond]
  19. Joshua says:

    @Brad: So, you think you can design an OS for which the administrator cannot arrange to read other people's documents. Did you consider the administrator enabling the kernel debugger to change the kernel behavior against your design? Did you think about the administrator replacing the OS on disk with a modified version that does some checks differently? Did you think about how to apply updates at all?

    The necessary constraint to make this even *possible* is the authoritative code signing and hardware enforcement rejected by the marketplace.

  20. Harry Johnston says:

    @Joshua: Sounds like a lot of trouble just to avoid people having to re-enter their password occasionally, but YMMV.

    (I think there are third-party SSO solutions, FWIW, but I don't know how well they work.)

    Rather than removing Domain Admins from the Administrators group (since that doesn't work post-XP) couldn't you assign "deny access to this computer from the network", et. al., to the Domain Admins group?  I think it would have the same effect.

  21. Steve says:

    We've just had external security consultants in and they've come back with a whole host of these 'faults'.

    Having insisted on being provided with a domain account, and a username/password pair set up with full admin access to one of our systems, they then had the bare-faced cheek to submit the fact that they could amend data as a high level risk. The trouble is that the eventual report gets read by organisational high-level, but non-technical, people, who see the flag for the high level risk and go into full blame and panic mode; it's then up to us to try to convince them that the pen testers were already on the other side of the metaphorical hatch-way. But the consultants must be right, because we paid them lots of money.

    At least they didn't submit the fault the same bunch flagged as a high level risk three years ago; that all of our web servers were exposing port 80. Man, that was a fun one to make go away …

  22. Lev says:

    @Steve Well you shouldn't have given them admin access.

    Also, how about intentionally creating vulnerabilities in order to check whether the consultants find them?

  23. DosFreak says:

    What's this with not being able to remove Domain Admins? IIRC, the group is added on connecting a computer to the domain but not added afterwords. A GPP push to administer the local administrators group takes care of the initial problem and by default runs every 90 minutes anyway. Obviously this doesn't prevent a Domain Admin from doing anything they want but it is an extra layer of security.

  24. Joshua says:

    Steve understands the actual driving force.

    [ ] Only accountants have access to machines with accounting records.

    [ ] Use of single signon to disable accounts of people leaving.

  25. Eddie says:

    I love these non-vulnerability articles.  The categories box should now read like the following:



    It Rather Involved


    Other (Computer)


    All tags

  26. Joe says:

    At a few companies where I've worked, the problem wasn't finding Domain Administrators who could be trusted with secrets, but rather finding Domain Administrators who weren't completely incompetent.

  27. alegr1 says:


    If I were the security consultant, I would have written your org up for giving domain admin credentials to a third party (me).

  28. ex-DonH says:

    I cannot begin to tell you how many times this was reported during AD development.  The fundamental solution to guarding against the guy who has complete control over your computer must be based on things that are not part of your computer, such as a security camera aimed at the administrative console and/or a guard with a gun.

  29. Andre says:

    Ironically enough, today a Linux "vulnerability" named "Grinch" makes the news that is exactly the same thing.

    Users in the "wheel" group (when configured to give sudo rights) can use sudo to become root. So the linux version of "an admin has admin rights".

  30. rwww says:

    @ex-DonH: A guard is unlikely to have the knowledge and experience to understand what the admin is doing. A security camera might be helpful in post-incident forensics – or if there's another (competent) admin watching the feed with her/his finger on the "big red button" to kill the console session if needed.

    One company I used to work for, admin access to certain sensitive servers was limited to text consoles connected via serial port – with a hardened box between each server and the serial terminals. In the box was a simple processor (program run from ROM) that (a) logged everything and (b) required 2 admins at terminals in separate rooms with one entering commands and the other confirming the commands. The 2 could discuss, via intercom (recorded), what needed to be done. In order to minimize the possibility of collusion, admins were randomly paired at the start and middle of each work shift. Also, members of a pair were not allowed to take a break at same time (except lunch, because new pairings would be done when they returned to work).

    (At some point, monitors to display graphics were added, but all actual interaction remained via the serial text consoles.)

    I'm not sure how effective this really was, but, eventually, the CFO pursuaded the CIO it was too expensive, so a third of the admins were laid off and they rely solely on the logging. (Or did. I don't know what they do now.)

  31. cheong00 says:

    @Andre: Wheel group member uses "sudo" to switch to root all the time they need "real" administrative access. Kind of the point like why UAC is created on Windows (with slightly different context). Is this even a "news"?

    I think people who assigned to do Linux vulnerability check should have known better.

  32. cheong00 says:

    @Harry Johnston: I now read the report too. What is say is like what Raymond set in the past: If you put your home user to "Power Users" group, there's little difference on putting it to "Administrators" group.

    (The report involves someone able to install packages that requires "root" access to set the an executable file with "setguid" bit with "pkcon", and claims if attacks can get package with vulnerability with your update repository, you can be pwned.)

  33. @Andre: reading the vulnerability report, it seems to me that the point is that there are supposed to be restrictions on sudo, and they've found a way to bypass them.  For example, in the default configuration you're supposed to have to put your password in (in case it isn't really you issuing the command) and this issue means that you don't need to after all.

    Also, it is common enough to configure the system to allow certain non-admin users to issue specific commands (and *only* those commands) via sudo, and it sounds as though they've bypassed that as well.

    All in all, sounds like a legitimate issue to me.

  34. Engywuck says:

    I'd rather expect the same people claiming "Administrators should never be able to read my files" are the same that come with "why can't you recover the files of coworker X why got fired recently?" when this could (would) be implemented. There simply *has* to be a way for at least file recovery.

    Which leads me to another group which should be selected carefully: Backup Administrators (and in some cases Operators). Sure, there *may* exist some systems which only save hardware-encrypted data with a non-removable (non-copyable) hardware token and require multi-person authentication before recovery, but most systems I know allow the Backup Admin to restore any file to anywhere. Which means that even restore of the SID won't help too much against rogue Backup Admins. Especially if they are the same as the Domain Admins, as in many smallish organisations.

  35. Joshua says:

    [Then you have a social problem, not a technology problem.]

    No, we have a Congress problem. Engywuck posted in detail deranged manner of mind that leads to wanting this set of technical behaviors. If we replace "Administrators should never be able to read my files" with "Administrators should never be able to read my files without being caught" we have something close enough to doable that we can fool the auditors we did it and so make it appear to the judge we complied with the law for which there can be no compliance.

  36. ex-DonH says:

    @rwww, the guard is there to shoot the admin if he touches the camera.

    I kid on the mechanism, but I think we agree on the fundamentals: you cannot use a system to monitor or control the actions of someone who has complete control over that very same system.  Use an external system whose details depend on your level of paranoia.

  37. Erik F says:

    @Joshua: Given that an admin can basically do anything, it's not very surprising that they can mess with audit trails too; some trust in the admin is required, or else they shouldn't be an admin! If you absolutely need to prevent unauthorized admin logins, the only thing I can think of is only give out admin accounts that require RSA tokens or something similar (which you can then lock away.)

    Also, pretty well anyone can read your data without getting caught if they have physical access to the computer; all they need is a spare hard drive and a disk duplicator.

  38. Harry Johnston says:

    @cheong00: not quite the same, IMO.  Power Users was *always* equivalent to Administrators, from day one, in any configuration, and by design.  Wheel only became equivalent to root when the new authorization system was introduced, and it was unintentional.  (Disclaimer: I'm simply assuming the report is factually correct as far as that goes; I don't have any personal knowledge on the subject.)

    @Joshua: half tongue-in-cheek, but what if you made your domain administrators obtain whatever certification the accountants have?

  39. cheong00 says:

    @Harry Johnston: Actually "wheel" group exist a lot longer than that. It's introduced around the time when "sudo" is invented as a way to persuade administrators not to use "root" for their everyday use anymore.

    By definition, if you don't want someone to have "root" access to your system, you should never put him/her into wheel group.

    Also, one of the goals of "PackageKit" is to reduce the number of "security prompt" user encountered (Like the fine-tuned UAC behavior in Win7 when comparing with Vista).

    So the fact that you can install programs without re-entering password is not intentional. It's by design too.

  40. cheong00 says:

    @Harry Johnston: Actually, you edit /etc/sudoers to allow non-wheel users to run root-access required commands, with or without passwords.…/Sudoers (note that in this documentation, the admin group is wheel group in other Linux systems)

  41. Harry Johnston says:

    @cheong00: ah, my mistake then.  Thanks for clearing that up.  I see the latest news on "grinch" is that it is pretty much exactly as you originally claimed: a non-issue.

  42. Harry Johnston says:

    @cheong00: as I understand it, you *have* to put someone in the wheel group if you want them to be able to sudo.  Is that not true?  Of necessity, in some scenarios, that includes people who shouldn't have unrestricted root access, but need to be able to run certain specific commands as root – to pick an example from my workplace at random, starting and stopping a web server.  That's documented functionality; you can configure sudo to only allow certain users to issue specific commands.  If it's true that a bug means they can run arbitrary commands, instead of just the ones they're supposed to be able to, then that's a security vulnerability by any reasonable definition.

    By way of analogy, I have a system service installed on some of my Windows machines that is configured so that any user can start and stop it.  If Windows had a bug that meant those users could start and stop *any* service, rather than just the one that is configured to allow it, that would be a security vulnerability.  Surely in that case you wouldn't say, "if you don't want someone to be able to start and stop any service, don't give them permission to start and stop your service"?  How is being able to run an arbitrary sudo command instead of a specific one any different?

  43. Anon says:


    No such legislation exists. It is a gross misreading.

    But I work with accountants, and I've come to expect them to generally not understand the law.

  44. Skyborne says:

    @Harry Johnston: sudo access is restricted by the intersection of PAM and sudoers configurations, and the defaults set by popular distros grant wide permissions to use sudo to "all members of the wheel group".  Generally they can run any command; frequently as any user (and not just root, which is basically equivalent, thanks to `sudo su – otheruser`); and in certain cases like Amazon EC2 instances, maybe even *passwordless* rights.

    So while yes, the default answer is "sudo doesn't work unless you're wheel," that's also completely configurable.

Comments are closed.

Skip to main content