Audit Blogs

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:

Close all open programs running on my computer (for the cleanest results).

Open Moo0 File Monitor and make sure it’s gathering data.

Clear the Moo0 logs to get a blank slate.

Open the program I want to test (such as Microsoft Word).

Close the program I’m monitoring to see files accessed on program exit.

Click the Stop button in Moo0 File Monitor to stop collecting data.

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:

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.

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:

System files can be accessed or changed.

Program files or program configurations could be modified.

Software that is not approved could be installed, and won’t be maintained.

Malicious code can be installed with unlimited rights.

New, unapproved user accounts could be added to the system.

Password policies could be subverted.

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:

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.

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.

Like many information security practitioners, this week marks the return to the office and reflection after attending the annual RSA Conference in San Francisco. Every year there are interesting speakers, some better than others, crazy parties, and a vendor show the size of a small city. And every year I admit I get a little contemplative at the end of the week and try to reflect a little more on our industry.

This year there was a phrase that I heard that got me thinking, the phrase described the challenges of the “Digital Security Poverty Line.” So it got me thinking, is this a real thing? Is this hype or when we look at organizations today are there really haves and have nots in the world of information assurance?

I think one of the first discussion points has to be a monetary one. Do larger organizations have larger budgets when it comes to information assurance? I think the knee-jerk reaction most of us would have to this is yes. But a better question might be – do larger organizations have a larger percentage of their budget allocated to information assurance? According to a study performed by BAE Systems Applied Intelligence and the Gartner Group there is a wide range of spending that organizations allocate to information assurance. According to their October 2013 study (http://blogs.gartner.com/john-wheeler/it-security-budgets-rise-as-data-breach-fear-spreads/) the majority of organizations allocate between 3-10% of their IT budgets towards information assurance efforts.

But this still begs the question – does that mean if your organization allocates lower than 3% of its IT budget on information assurance, does that mean your organization is in poverty?

For this statement to be true, there would have to be a set of organizations under-allocating resources – which likely is true. But also the industry would have to be lacking in low cost quality tools that could be used to secure information systems. So is that true?

This is where I think the phrase starts to break down. Yes, in my opinion, there are and there always have been low cost tools available to small, midsized, or “poverty stricken” information assurance departments that could be used to secure information assets. While certainly it would be nice if everyone could afford a tool like Tenable’s Security Center, Tenable has always been gracious enough to provide tools like stand-alone Nessus if your organization did not have the funds for the larger solution. And of course this does not even take into account the abundance of free or open source (FOSS) tools that companies could employ – OpenVAS anyone?

I can certainly understand the vendors point about the appearance of a poverty line. And more importantly I think it’s quite generous for companies such as Qualys and Tripwire (nCircle) to release tools for small businesses to help them alleviate the stress. For those of you would did not notice, both of these vendors released free tools at the RSA Conference to help SMBs to secure their information systems based on the recommendations from the Critical Security Controls project.

So free or low cost tools are available to organizations. So if there is a poverty line, then it would have to be related to the personnel resources that an organization allocates to the issue. In the long term automation will help to remove this as a consideration, but as organizations initiate their assurance programs, it will take people to kick things off and create a strategy for organizations. Certainly that’s hard to argue against.

So, is the idea of a digital poverty line real? That’s hard to say. It could be the emergence of a new trendy marketing word. Or on the other hand if one does exist today I would argue that is has to do with the allocation of personnel and not the allocation of capital budgets. So what’s the moral of the story? If a digital security poverty line exists, it is because of their personnel. So if I was an organization today reading about data breaches and theft of intellectual property I would make sure I’m investing in the people that keep my data secure. Am I giving them the training and mentoring necessary to make good decisions for the organization or am I simply throwing my capital after more products. Maybe it’s time we all followed after groups like the State of Colorado and spend fewer resources on software licenses and fancy appliances and more on investing in the people that watch over our organization’s data every day.

Back in December we posted a couple scripts that fellow auditors had pointed out to us that helped auditors dump Microsoft Windows file permissions to a CSV file for easier auditing. As a result of that post we’ve had feedback from a number of people that it would be helpful to see more of these scripts and even some suggestions for PowerShell audit scripts that we might want to share with others.

Two scripts immediately jumped out to us this past month as comprehensive PowerShell audit scripts that might help people who are auditing Microsoft Windows systems. These might inspire you to write your own script or maybe you just want to use these in the course of your audits. So we’ll share them here for you in the hopes that they make your life as an auditor easier.

The first script was posted to the Microsoft Script Center and was written to perform a comprehensive system audit of multiple machines that are detected in an Active Directory environment:

Both of these scripts illustrate the ideas we’ve been trying to teach people of automating your audit efforts. These are both good examples of what we hope you all are creating. If you do have further suggestions, please pass them along. You can email info@auditscripts.com if you have more resources you’d like us to share with the community.

Happy New Year! I hope everyone has had a great holiday season so far and is excited and ready for a new year full of auditing excitement! For the first post of the year I thought we would discuss a topic more for fun and something different in the hopes of inspiring you to spend a little more with PowerShell and scripting.

WARNING: Please do not attempt anything we’re about to discuss without clear permission from everyone and anyone you can think of. If you don’t have permission, don’t do it!! Anyways…

One problem auditors and penetration testers often have when auditing passwords is that most of the tools that are commonly used to extract passwords from a Windows system are viewed as malware by the anti-virus software installed on the system. Or if you have whitelisting software installed, then you are only able to execute the binaries approved in advance by management. But what if you want to rely on native tools and commands to do your assessment and you want to “live off the land”? That’s where Microsoft’s PowerShell comes in handy.

Once you have the local SAM database from a computer the next step would be to examine the databases in your favorite password cracking tool offline, such as Cain from http://oxit.it.

In general those of you who know me know that I’m always a little hesitant to recommend that auditors especially consider password cracking at all. If an auditor chooses to run a script like this there should be a clear business reason for running the script, and should only be done with clearly documented management approval. But a script like this, downloading the SAM database from a local computer can still have quite a few benefits. Some of the controls an auditor might be able to test with this file are:

Are only the appropriate user accounts on each local computer?

Are any local user accounts using blank passwords?

Are any local user accounts using the same password?

Are any local user accounts using passwords that do not match the organization’s password policies?

So what else could we do with this script? From an automation and penetration testing perspective there’s all sorts of creative things we could do next. Just a few creative ideas you might consider:

Automate the script to download the local SAM database

Automate the script to encrypt the SAM and email it to the penetration tester

Automate the script to run against multiple remote computers

There’s just all sorts of fun that a penetration tester or auditor could have with this tool if they really wanted to. Again, I hope this code is useful to you and your security efforts. To a great 2014!

Often times as we talk with auditors or students in our classes audit scripts are brought to our attention that might be useful to people performing audits of various technical systems. Sometimes we write helpful scripts and when we do we’ll post them here for you to review. But sometimes we find the scripts and want to make you aware of them in case they help make your job easier.

This month we found two scripts that we think might help you out and both enable auditors of Microsoft Windows systems to use PowerShell to dump file system permissions to a CSV file so you can parse them in Excel or you favorite spreadsheet program.

The first script was written by John Milner, and he gives a full explanation of its capabilities here:

If you have other favorites that you would like to share with the AuditScripts community, please don’t keep them to yourselves. Email us at info@auditscripts.com if you have other resources that you think would help your fellow auditors in their audit efforts.

Most people in information security have heard of the Critical Security Controls these days. The idea of a community risk assessment project that helps all prioritize our information security efforts is appealing to most of us. The sticking question everyone always comes back to though is “how do I start implementing an information security plan using the controls?”

There are a few different approaches to this question. One of the most common is to simply start at the first priority (#1) and work your way through the list. It’s designed to be simple to use.

Ideally though we would have a translation between business requirements and what technical sensors security analysts need to deploy in order to achieve all the goals defined in the controls. So we took it upon ourselves to answer that exact question. If someone would take every sub control in the Critical Security Controls (version 4.1) and map a corresponding sensor to each of the controls, what controls would be left.

This is the list that we came up with (in priority order):

Hardware Inventory System

Asset Inventory System

Active Device Discovery Tool

Passive Device Discovery Tool

System Imaging & Cataloging System

Authentication System

Public Key Infrastructure (PKI)

802.1x Authentication System (RADIUS / TACACS+ / etc)

Network Access Control (NAC) System

Software Inventory System

Software Whitelisting System

SCAP Compliant Vulnerability Management System

SCAP Compliant Configuration Scanning System

Configuration Policy Enforcement System

Patch Management System

Vulnerability Intelligence Service

File Integrity Assessment System

Anti-Malware / Endpoint Protection System

Email Anti-Malware System

SPF DNS Record

Web Based Anti-Malware System

Web Application Firewall (WAF)

Application Code Review / Vulnerability Scanning System

Database Vulnerability Scanning System

Application Specific Firewalls

Wireless Network Device Management System

Wireless Intrusion Detection System (WIDS)

Backup / Recovery System

Data Encryption System

DHCP Server Logs

Domain Name System (DNS) Monitoring System

Host Based Data Loss Prevention (DLP) System

Host Based Access Control Lists

Host Based Firewalls / Endpoint Protection System

Intrusion / Malware Detection System

Log Management System / SIEM

Network Based Data Loss Prevention (DLP) System

Network Devices that Support VLANs & ACLs

Network Proxy / Firewall / Monitoring System

Password Assessment System

Removable Media Control / Endpoint Protection System

User Account Discovery / Inventory System

It certainly seems like a long list, but I would bet most companies already have many of these controls in place.

It seems to us if an organization would work their way through this list as a part of a gap analysis and then review the controls, they would find that they hand implemented the majority of the sub controls in the list simply by implementing these sensors. Certainly an organization will need to operationalize the controls too. But at least this might help a few organizations to get started in their efforts.

One of the projects that we have been thoroughly engaged on at AuditScripts.com has been to work with the Council on Cybersecurity on the Critical Security Controls project. If you haven’t had a chance to see the project, I would strongly recommend that you take a look. The full text can be most easily found at the SANS Institute at the following link:

One question I get asked a lot is regarding maturity models and the Critical Security Controls. Is there a maturity model that I can use to measure myself against to see how I compare to other organizations implementing the controls? At this point the official answer from the Council is “No, there is no official model.” However that being said, there’s also quite a bit of discussion around what might constitute a solid maturity model.

To answer this question I think the first thing we need to understand is that the controls are not just a list of good things to do. They also compose a mentality and philosophy for securing information systems. Therefore to understand a potential maturity model, we have to understand the guiding principles that the controls teach. The core philosophies of the controls are:

“Offense informs defense: Use knowledge of actual attacks that have compromised systems to provide the foundation to build effective, practical defenses. Include only those controls that can be shown to stop known real-world attacks.

“Prioritization: Invest first in controls that will provide the greatest risk reduction and protection against the most dangerous threat actors, and that can be feasibly implemented in your computing environment.

“Metrics: Establish common metrics to provide a shared language for executives, IT specialists, auditors, and security officials to measure the effectiveness of security measures within an organization so that required adjustments can be identified and implemented quickly.

“Continuous monitoring: Carry out continuous monitoring to test and validate the effectiveness of current security measures.

“Automation: Automate defenses so that organizations can achieve reliable, scalable, and continuous measurements of their adherence to the controls and related metrics.”

That being said, it seems like a good maturity model would need to be composed of more than just “What percentage of the controls have you implemented.” So in anticipation of the various summits held on the controls this year in London and Washington, DC, we created the following maturity model for organizations looking to measure themselves:

Level #0: Project Initiation

Level #1: Some Controls Implemented & Audited

Level #2: All Controls Implemented & Audited

Level #3: All Controls Automated

Level #4: All Controls Reporting to Management

Level #5: Continuous Monitoring & Remediation

This is meant to be a high level statement, not a deep dive or project plan. But I think it could be the start of an interesting discussion. Companies need to do more than simply check boxes that they’ve implemented the right controls. Those controls need to be integrated into business processes, automated, and placed in the hands of knowledgeable business owners. Hopefully this model encourages us to start considering each of these aspects as we judge our maturity.

In some of our training we’ve mentioned to people that we’ve published a number a whitepapers on the Critical Security Controls in conjunction with the SANS Institute and various other vendors. Unfortunately we’ve also discovered that many of these whitepapers can be difficult to locate on the SANS Institute’s website. So we wanted to compile a list of some of the more relevant whitepapers that we think might help people in their efforts implementing the Critical Security Controls.

We hope you find these helpful as you consider utilizing the Critical Security Controls as a part of your information security architectures. If you ever have any questions on the subject, please don’t hesitate to reach out to us at info@auditscripts.com.