Using File Monitoring to Limit Admin Rights

Over the past few weeks we have been posting blogs about the importance of limiting user account rights to only what is necessary for someone to do their job. Users should have all the rights necessary to do their job, but nothing less and certainly not any more. This includes local administrator rights. Only the people that absolutely need those rights should be given those rights. It is also our argument that fewer people actually need those rights that people generally believe. We’ve also posted a few times already on the dangers of giving people too many rights on a system. And remember, this applies to both Windows and Unix systems. Just because you can login as root, it doesn’t mean you should.

A question that comes up a lot though is, “What about software programs that require the user to be a local administrator in order to run the program?” Well, as I argued in a previous post, most programs don’t need the actual local administrator rights, they just need access to an object that the current user doesn’t have access too.

One of the most common objects that users often do not have the rights to are file system objects. Now in a perfect world, software developers would write their programs to only access portions of the file system that are accessible to everyday users. Or at a minimum, developers would document what file system objects they need to access to run their software. Of course reality says developers & documentation rarely go together. So how can a sysadmin figure this out for themselves?

In the old days, we could always use tools like Filemon & Regmon by Sysinternals to figure this out at a granular level. Unfortunately after Sysinternals was purchased by Microsoft, they combined the tools into one giant monitoring tool called Process Monitor. Don’t get me wrong, it’s a great tool and very capable of gathering system information. The trouble is it can be TOO powerful. Sometimes there are so many things happening on a system that it can be difficult to isolate just the file system events. So it would appear we need a different tool that we could use to monitor simply the file system object events to help us isolate where a user may need additional user permissions.

In searching for an app that would do this, I wanted something that would be isolated to file system objects, have the ability to start and stop monitoring on command, have the ability to reset logs, and have the ability to export data to a CSV or similar format so I could manipulate the data in Excel later if I needed to. Oh, and it would be nice if the tool were free. Even better would be if the app were a portable app that I could bring with me in my toolkit without having to install it on a machine. That’s when I found Moo0 File Monitor.

Let’s say I wanted to run Microsoft Word as my test case. I want to make sure I know all the file system objects that Word needs to access in order to run on my machine. To gather my data I would need to:

  1. Close all open programs running on my computer (for the cleanest results).
  2. Open Moo0 File Monitor and make sure it’s gathering data.
  3. Clear the Moo0 logs to get a blank slate.
  4. Open the program I want to test (such as Microsoft Word).
  5. Close the program I’m monitoring to see files accessed on program exit.
  6. Click the Stop button in Moo0 File Monitor to stop collecting data.
  7. Save the Log File for later analysis.

The results of this process should be a list of files that were accessed during my session working with the software program in question. In this case when I tested it with Microsoft Word I received the following results:

moo0

Now we can use this information to examine all the file system object permissions that were listed in the log we created. Granted this can be a tedious process, looking at each set of permissions one at a time. However if you’re patient this can lead to giving people access to the objects they need to run their applications without giving them rights to all the files on the file system (ie. Local administrator). There may be more steps you need to take, such as looking at the registry or user rights as well, but this is often a good place to start and often solves the problem for you.

Hopefully tools like this make it easier for you to give people only the rights they need to do their jobs. If you have other tools that you think will help, send us a note on Twitter at @isaudit. We’d love to hear what’s worked for you as well.

The Danger of Local Windows Administrator Rights

A couple weeks ago I wrote a blog post about limiting local Windows administrator rights – the importance of it and some of the things organizations can do to allow end users to work without having those rights (http://bit.ly/1hpyllB). One of the questions that has come up, and it always does, is the question – how bad is it if users have local administrator rights?

Obviously the easiest answer is BAD, REALLY BAD! It’s like you buy a house or a car and then decide that you don’t need locks on any of the doors. The reason we have file permissions, registry permissions, user right assignments, and the like in Windows is to limit ourselves to only having the rights we need on a system that are necessary in order for us to do our jobs. We shouldn’t have any more or any less rights than are necessary. But when we give our end users administrator rights, it is like we’ve just taken all the locks off the doors and given those users the ability to go into any room of the house without our permission.

Ok, so beyond the simple answer, what else could happen on a machine if we allow users to be local administrators of their machines? Here are just a few of the things that could happen:

  1. System files can be accessed or changed.
  2. Program files or program configurations could be modified.
  3. Software that is not approved could be installed, and won’t be maintained.
  4. Malicious code can be installed with unlimited rights.
  5. New, unapproved user accounts could be added to the system.
  6. Password policies could be subverted.
  7. Security controls such as anti-malware, firewalls, removable media controls, could be disabled.

And as you can imagine, the list goes on and on…

One other fun issue to consider is the issue of passwords. Many people have heard of the pass the hash attack where an attacker steals the local password hash from a machine and then replays it into the system’s memory whenever they want to authenticate as that user. This attack is certainly possible when users have local administrator rights. But wouldn’t it be easier if the user could just steal passwords out of memory in clear text instead? Well it turns out that’s possible too. Enter Mimikatz.

For a nice long, technical explanation of how Mimikatz works, there are plenty of nice tutorials (although to be fair many of them are in French). But here’s the bottom line, if your users are local administrators on their Windows machine, then they will by default have the user right assignment of “Debug Programs” (or they can assign themselves this right if it is taken away by a security policy). Once they have this right they have the ability to interact with sensitive portions of memory, such as those where authentication credentials are stored. With that information they are able to read authentication credentials out of memory as seen in the following screen capture:

mimikatz

Not only are we able to read the NTLM password hash out of memory – which could be taken offline and cracked or used in a pass the hash attach, but we are given the passwords for every logged in user in plain text. Even in the above example where the user is utilizing upper case, lower case, numbers, and special characters and a long password, there is no need for the time or computing resources to crack the password because it is there in clear text.

Many people might wonder at this point, is this only in older versions of Windows? Unfortunately the answer is no. Version 1.0 of Mimikatz works all the way through Windows 8 systems (although Windows 8.1 does appear to be safe). Version 2.0 of Mimikatz works even with Windows 8.1 systems to manipulate this type of information. And if you were wondering, yes, there is integration between Mimikatz and the Metasploit framework to make your penetration testing efforts easier. And, just because, there is also a plugin for Mimikatz for Volatility if you’d like to play with this tool with offline forensic memory dumps.

So once again, let’s restate the issue. How bad is it if end users have local administrator rights on their Windows machines? It’s BAD, REALLY BAD!! Both the Australians DSD in their Top 35 Mitigation Strategies document and the Council on CyberSecurity in their Critical Security Controls document list this issue as a serious concern. Hopefully we can all make sure to keep this issue in mind as we defend our systems.

Limiting Windows Local Administrator Rights

One of the common issues we run into during security assessments and incident response cases is the issue of users being assigned too many permissions on their local computer. For the sake of convenience and expediency, end users often demand that they be assigned local administrator rights. These users, often in an agitated and exaggerated manner, explain to their bosses that they simply cannot do their job unless they are given these rights on their work computer. This begs the question, do end users normally need these rights or is there a better more secure approach to take. Or using an analogy, should we stop locking the doors to our home or vehicles because one day we might forget our keys and be inconvenienced in the process?

First of all, let’s start with the basic business principle – end users should be assigned the rights and permissions that they need on their computer in order to do their job. They should not be assigned any more rights or permissions than this, and they should not be given any fewer rights than this. Of course it can be tough to strike a balance between the two, but it’s certainly the ideal we should be striving for.

But what’s the big deal? Why not just assign everyone local administrator rights on their workstation and call it a day? We even saw one company take it so far as to add the local “Everyone” group to the local administrators group on all their machines to limit the helpdesk requests that would come in. Is this really so bad? The answer is YES!

If end users are assigned local administrator rights and they don’t need those rights and permissions it opens the door for a number of abuses. Malicious actors wanting to cause harm to the users can arbitrarily run code on their systems with full permissions if they can convince the user to click on a malicious link or open malicious email content. End users could turn off the security controls we use to protect our systems like whitelisting software, password controls, anti-malware software, and similar tools. Unapproved software could be installed on an end user’s machine, breaking business critical applications, thus requiring troubleshooting from desktop support. And the list goes on…

Basically if you give end users local administrator rights to their workstations, in effect the organization has disabled all the locks on the system put in place to protect the end user and the organization’s data.

But the common complaint still exists. Will users be able to do their work if they are not local administrators? The answer of course is yes. But we still need to be able to assign the correct rights and permissions on the system to enable the user to work. One of the most common complaints we hear is that certain pieces of software simply will not function unless the end user is granted local administrator rights on their computer. How do we address that?

Whenever we encounter a software application on a Microsoft Windows system that believes it needs to have local administrator rights in order to function, there are a series of checks that we try first. In most every case when a developer states that they need local administrator rights, it is because they haven’t taken the time to try to figure out specifically what rights are necessary in order for the program to function properly or they are trying to access an operating system object that they should not be trying to access. So what are those checks, what do we do when we are troubleshooting to see why a program will not run unless you are an administrator?

Generally when an application developer says that their software requires local administrator rights, it is because their software is trying to access a protected operating system object. So to troubleshoot, the trick is to determine which object they are trying to access. When we’re troubleshooting this issue, it is always one of the following objects:

  • File system object permissions
  • Registry hive object permissions
  • User right assignments of the user
  • Mandatory Integrity Control (MIC) levels on an object

Nine times out of ten the issue is simply a file system issue. But don’t forget the other issues as well, they all can play a part.

If you don’t want to take the time to figure it all out on your own, there are of course software vendors that will make this process easier for you. Companies like Cyber-Ark, Computer Associates, BeyondTrust, and Cloakware all sell software designed to make this process easier for you. But as with anything else, trying the simple steps first often times will solve the issue for you.

In future posts we will look into each of the operating system objects above to see if we can better understand how to examine the necessary rights for each. But for now hopefully by examining those objects you will be able to determine what the specific, necessary rights are for your organization’s applications to function properly and only with the rights they need.