Hello everyone! Last time I was busy on other stuff and haven’t enough time to continue the topic. Today I want to talk about SRP rule ordering and how rule conflicts are resolved.

When you define SRP rules, you may have 2 or more conflicting rules. For example, you have a rule that allows to run any software signed by a certain certificate. For some reasons you decided to block one or more specified applications that are signed by the allowed certificate. Or you have two path rules that points to the same file, but have opposite security levels. It is important to understand how SRP processes rules and decides resulting action (allowed or blocked).

Multiple policies

The first thing we should learn is how multiple policies are applied. As you already know (at least, I assume that you know, because you have to know this), in a domain environments you can define multiple policies at various levels. Normally, such policies are applied by following the following sequence: LSDOU (local, site, domain and GPO linked to an OU). The latest policy object applied becomes effective. However this is not true for SRP. When you look at RSOP (Resultant Set Of Policies) for other settings (for example, account lockout settings), you can see which policy wins:

when you explore SRP node, you won’t see this information:

This is because elements in Additional Rules and Designated File Types are not replaced by the latest applied policy, instead, they are merged. As the result, all rules are dumped to a single list. To understand this, consider the following scenario:

You defined 2 GPOs with SRP settings:

1. allows everything, but system and program folders (C:\Windows and C:\Program Files)
2. allows only certain applications by hash

the first policy is linked to a domain level, and the second GPO is applied to an OU (say, OU named Accounting) level. As the results, users in a domain will be able to run everything from system and program folders only. However, logging to a computer that resides in Accounting OU, users will be able to run anything from system and program folders and additional programs allowed by hash in second policy.

The same thing occurs when you define SRP in both, user and computer configurations. In this case, all rules are merged to a single list.

only items in Additional Rules and Designated File Types are merged. Other elements (Security Levels, Enforcement and Trusted Publishers) are replaced by the latest policy. That is, if you define two GPOs with different security levels at domain and site level, the security level defined in the site policy is set to active.

Rule processing rules

In previous post I gave a little intro to SRP rules in prioritized order. As we already know, rules are processed as follows:

• Certificate rules;
• Hash rules;
• Network zone rules;
• Path rules.

Since, we are using SRP as a whitelisting, then the following process occurs when user attempts to run a file:

1. If the file is digitally signed and signing certificate (at least, one of them) is explicitly disallowed, the file is blocked;
2. If the file is digitally signed and signing certificate is explicitly allowed (at least one of them), the file is executed.
3. If the file hash is explicitly disallowed, the file is blocked.
4. If the file hash is explicitly allowed (Unrestricted), the file is executed.
5. If the MSI package is launched from explicitly disallowed network zone, the installation is blocked.
6. If the MSI package is launched from explicitly allowed network zone, the installation is executed.
7. Path rules are processed.

Authenticode signature supports multiple signers. Therefore, it is possible that the policy may have two signing certificates with opposite security levels (Disallowed and Unrestricted). However, if any of the certificates is explicitly disallowed, the file is blocked.

So far everything is very simple. If certain condition returns True, the action is taken and no other steps are processed. That is, if you explicitly allow application by digital certificate (certificate rule), it is not possible to block it via restricted hash rule, because only first step is processed and hash rules are not processed. And if you allowed file by hash, it is not possible to block it by using network zone rules (MSI only) or path rules.

Here is a little diagram that describes this process:

I didn’t included path rules details, because they are processed in a specific manner. While, it is impossible to have 2 different hashes (using the same digest algorithm) for the file, it is possible to have two or more path rules for the same file. For example, we can create the following path rules for wmplayer.exe file:

• C:\
• C:\Program Files
• C:\Program Files\Windows Media Player
• C:\Program Files\Windows Media Player\wmplayer.*
• C:\Program Files\Windows Media Player\wmplayer.exe

and so on. These rules may have conflicting security levels. which one wins? The answer is the following (or very close): the closest and the most specific path has higher precedence. In the example above, the latest rule will be used to determine file execution status: allowed or not. Absolute path to a file (without shortcuts and wildcards) is the higher rule. By using this behavior, it is possible to disallow entire folder by a rule that points to a folder and allow specific files by adding rules that points to a specific file (or files).

SRP do not support path rules to mapped drives (technically you can create them but they won’t work). Instead, you have to provide an UNC path (for example, \\servername\sharename\filename.ext).

End of story

Today we explored the mechanism of how SRP rules are ordered and processed. It is important to understand this subject, so you can avoid unexpected results when you define SRP in 2 or more policies (or even 2 or more conflicting rules within the single policy) and make more reliable and working SRP.

As I said, SRP is not the answer to all questions and moreover, there are a lot of common ways to overcome SRP restrictions. Therefore, in next topic I’ll show the most common ways and how to eliminate these “vulnerabilities”.