How to watch SDDL and not break your eyes on semicolons

My journey to information security began with an amazing discovery: “secure ≠ encrypted”. Now this statement looks simple and obvious, and in the first year the awareness of this fact had an effect comparable to the mental atomic bomb. Information security attacked by expanding the boundaries of the subject area: it turned out that cryptography is only one line of defense, and there are still legal, organizational, and just physical, in the end. One of the theoretical aspects was “All information security issues are described by subjects' access to objects”. I memorized, painted the mandate and discretionary access patterns, told, passed and forgotten.

I specialize in security analysis of Windows applications. Quite often, the study of precisely the various access rights takes a substantial part of the study. To automate the process of finding strange or incorrect access rights, we had to understand the SDDL (Security Descriptor Definition Language). Who cares to learn to read rights in the form of SDDL (for example, something like this O: SYG: SYD: (A ;; CCLCSWLOCRRC ;; IU) (A ;; CCLCSWLOCRRC ;;; SU) (A ;; CCLCSWRPWPDTLOCRRC ;;; SY) (A ;; CCDCLCSWRPWPDTLOCRSDRCWDWO ;;; BA) ) and to get acquainted with my utility for working with descriptors in this format, welcome under cat.

SDDL format

SDDL is a string with descriptions of access rights in text form. Most often consists of 3 parts: owner, group and DACL access rights. Sometimes another part of the SACL is added - the auditing part (if actions with an object fit the SACL rules, then a system event will be created that is easily monitored by various systems). The descriptor looks like this:
')
O: <owner> G: <group> D: <DACL access rules> S: <SACL audit rules>



Thus, the example above can be expanded as follows:

• O: SY
• G: SY
• D: (A ;; CCLCSWLOCRRC ;;; IU) (A ;; CCLCSWLOCRRC ;;; SU) (A ;; CCLCSWRPWPDTLOCRRC ;;; SY) (A ;; CCDCLCSWRPWPDTLOCRSDRCWDWO ;;; BA)

The owner and group can be specified as the SID of the user or OS group, or as special abbreviations. For example, in this case, the owner and the SY group are the Local System Account (NT AUTHORITY \ SYSTEM). The list of abbreviations (unfortunately, not exhaustive) can be viewed at the link .

Access rules consist of enumerating DACL flags and ACE (Access Control Entries) strings. Detailed analysis of the ACE presented on the link , we consider the most important. Each ACE line is enclosed in parentheses, in which data is separated by a semicolon.
Of greatest interest are the first, third and last groups. This is the type of access (allowed "A", prohibited "D"), a list of actions and the name of the subject of access. The first rule of DACL from the example above: (A ;; CCLCSWLOCRRC ;;; IU), we will consider in detail.

• "A" - the rule allows the action of the subject;
• “CC”, “LC”, “SW”, “LO”, “CR”, “RC” - list of allowed actions;
• "IU" - this abbreviation means the group Interactive Logged-on Users.

It remains to understand what exactly is allowed. What do these mysterious "CC", "LC", "SW", "LO", "CR", "RC" mean?

Here we are waiting for another reef - not always to reduce, you can accurately specify the action. They are, so to speak, contextualized. For example, if we are talking about the rights to work with services, then WP is “service stop”, if about files, then “execution”, and if about folders, then “traverse” (access to files in a folder by name, in the absence of list content). Some descriptions are here , some here , with the world on a thread.

Automation

The Sysinternals utilities help me a lot, namely the Process Monitor and Access Check (also known as procmon and accesschk). The first allows you to look at file and registry accesses in real time, and the second is to collect information from the OS on security descriptors.

By the way, in the OS itself, the window with the rights looks like this if someone has not seen:



Unfortunately, accesschk output cannot be filtered by narrowing the request for rights to specific actions. Process Monitor shows only the actual calls at a particular moment and it turns out too accurate request, which is not directly affected. In addition, I would like to have a memo on what kind of user group is NO or NS , and what actions are hidden behind CC and RC.

This is how a simple utility was born for viewing and filtering SDDL records.

How to use

It is easy to work with the utility, just three steps:

1. Get SDDL records.
2. Define rule filters.
3. View report.

Read more about each stage.

Getting SDDL. To obtain SDDL records, you can use the functions built into the utility (buttons 1, 2, 3, or 4), or download the previously received list (button 5). Please note that the request for access rights is made on behalf of the user who launched the SDDL Viewer, so in some situations it is worth running the program not only as a regular user, but also as an administrator. Well, in general, the field itself with SDDL strings is editable — you can at least manually rewrite it.

Filtering occurs by two parameters: user groups and access rights. The list of groups and users is based on all the users mentioned in the SDDL. Pay attention to the checkbox Translate SIDs (6) - if it is set, then the SIDs of users and groups will, if possible, be translated into names relative to the current computer. The list of rights is a little more clever - you need to select a category of rights (if the SDDL is filled with the utility itself, then the desired category is automatically selected). Moreover, the rights that are present in the SDDL are highlighted more clearly in the list of rights.

The report is simply the result of decoding SDDL and filter mapping. For more information on each line, you can find out if you select it in the list (yes, it was with this function that I came up with a plug, which gave rise to a little research on .NET internals ).

Results

Source code is available on github . Binary files are there in the Release section.

My plans for the utility:

1. To add a search to the input fields of the SDDL - yet only filtering is not enough.
2. Add launch parameters that would allow building reports without a visual part.
3. Perhaps it is worth adding SDDL padding from processes, shared folders and printers?

I will be glad to hear the wishes in the comments.