mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-25 06:00:40 +00:00
GitBook: [master] 370 pages and 4 assets modified
This commit is contained in:
CPol
gitbook-bot
parent
0d14187b51
commit
978bb001f5
9 changed files with 282 additions and 108 deletions
BIN
.gitbook/assets/aceinheritance.jpg
Normal file
BIN
.gitbook/assets/aceinheritance.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 128 KiB |
BIN
.gitbook/assets/audit-tab.jpg
Normal file
BIN
.gitbook/assets/audit-tab.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 63 KiB |
BIN
.gitbook/assets/classicsectab.jpg
Normal file
BIN
.gitbook/assets/classicsectab.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 83 KiB |
BIN
.gitbook/assets/editseprincipalpointers1.jpg
Normal file
BIN
.gitbook/assets/editseprincipalpointers1.jpg
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 122 KiB |
22
SUMMARY.md
22
SUMMARY.md
|
|
@ -41,20 +41,22 @@
|
|||
|
||||
* [Checklist - Local Windows Privilege Escalation](windows/checklist-windows-privilege-escalation.md)
|
||||
* [Windows Local Privilege Escalation](windows/windows-local-privilege-escalation/README.md)
|
||||
* [Privilege Escalation Abusing Tokens](windows/windows-local-privilege-escalation/privilege-escalation-abusing-tokens.md)
|
||||
* [Privilege Escalation with Autoruns](windows/windows-local-privilege-escalation/privilege-escalation-with-autorun-binaries.md)
|
||||
* [ACLs - DACLs/SACLs/ACEs](windows/windows-local-privilege-escalation/acls-dacls-sacls-aces.md)
|
||||
* [Dll Hijacking](windows/windows-local-privilege-escalation/dll-hijacking.md)
|
||||
* [From High Integrity to SYSTEM with Name Pipes](windows/windows-local-privilege-escalation/from-high-integrity-to-system-with-name-pipes.md)
|
||||
* [Named Pipe Client Impersonation](windows/windows-local-privilege-escalation/named-pipe-client-impersonation.md)
|
||||
* [Leaked Handle Exploitation](windows/windows-local-privilege-escalation/leaked-handle-exploitation.md)
|
||||
* [SeDebug + SeImpersonate copy token](windows/windows-local-privilege-escalation/sedebug-+-seimpersonate-copy-token.md)
|
||||
* [MSI Wrapper](windows/windows-local-privilege-escalation/msi-wrapper.md)
|
||||
* [JuicyPotato](windows/windows-local-privilege-escalation/juicypotato.md)
|
||||
* [Windows C Payloads](windows/windows-local-privilege-escalation/windows-c-payloads.md)
|
||||
* [PowerUp](windows/windows-local-privilege-escalation/powerup.md)
|
||||
* [Integrity Levels](windows/windows-local-privilege-escalation/integrity-levels.md)
|
||||
* [JAWS](windows/windows-local-privilege-escalation/jaws.md)
|
||||
* [Seatbelt](windows/windows-local-privilege-escalation/seatbelt.md)
|
||||
* [JuicyPotato](windows/windows-local-privilege-escalation/juicypotato.md)
|
||||
* [Leaked Handle Exploitation](windows/windows-local-privilege-escalation/leaked-handle-exploitation.md)
|
||||
* [MSI Wrapper](windows/windows-local-privilege-escalation/msi-wrapper.md)
|
||||
* [Named Pipe Client Impersonation](windows/windows-local-privilege-escalation/named-pipe-client-impersonation.md)
|
||||
* [PowerUp](windows/windows-local-privilege-escalation/powerup.md)
|
||||
* [Privilege Escalation Abusing Tokens](windows/windows-local-privilege-escalation/privilege-escalation-abusing-tokens.md)
|
||||
* [Privilege Escalation with Autoruns](windows/windows-local-privilege-escalation/privilege-escalation-with-autorun-binaries.md)
|
||||
* [RottenPotato](windows/windows-local-privilege-escalation/rottenpotato.md)
|
||||
* [Seatbelt](windows/windows-local-privilege-escalation/seatbelt.md)
|
||||
* [SeDebug + SeImpersonate copy token](windows/windows-local-privilege-escalation/sedebug-+-seimpersonate-copy-token.md)
|
||||
* [Windows C Payloads](windows/windows-local-privilege-escalation/windows-c-payloads.md)
|
||||
* [Active Directory Methodology](windows/active-directory-methodology/README.md)
|
||||
* [Abusing Active Directory ACLs/ACEs](windows/active-directory-methodology/acl-persistence-abuse.md)
|
||||
* [AD information in printers](windows/active-directory-methodology/ad-information-in-printers.md)
|
||||
|
|
|
|||
|
|
@ -45,8 +45,9 @@ nbtscan -r 192.168.0.1/24
|
|||
### SMB server version
|
||||
|
||||
To look for possible exploits to the SMB version it important to know which version is being used. If this information does not appear in other used tools, you can:
|
||||
- Use the **MSF** auxiliary module _**auxiliary/scanner/smb/smb\_version**
|
||||
- ****_Or **this script**:
|
||||
|
||||
* Use the **MSF** auxiliary module \_**auxiliary/scanner/smb/smb\_version**
|
||||
* **\*\*\_Or** this script\*\*:
|
||||
|
||||
```bash
|
||||
#!/bin/sh
|
||||
|
|
@ -191,7 +192,7 @@ smbmap -u "username" -p "<NT>:<LM>" [-r/-R] [Folder] -H <IP> [-P <PORT>] #Pass-t
|
|||
|
||||
### **Manually enumerate windows shares and connect to them**
|
||||
|
||||
It may be possible that you are restricted to display any shares of the host machine and when you try to list them it appears as if there aren't any shares to connect to. Thus it might be worth a short to try to manually connect to a share. To enumerate the shares manually you might want to look for responses like NT_STATUS_ACCESS_DENIED and NT_STATUS_BAD_NETWORK_NAME, when using a valid session \(e.g. null session or valid credentials\). These may indicate whether the share exists and you do not have access to it or the share does not exist at all.
|
||||
It may be possible that you are restricted to display any shares of the host machine and when you try to list them it appears as if there aren't any shares to connect to. Thus it might be worth a short to try to manually connect to a share. To enumerate the shares manually you might want to look for responses like NT\_STATUS\_ACCESS\_DENIED and NT\_STATUS\_BAD\_NETWORK\_NAME, when using a valid session \(e.g. null session or valid credentials\). These may indicate whether the share exists and you do not have access to it or the share does not exist at all.
|
||||
|
||||
Common share names for windows targets are
|
||||
|
||||
|
|
@ -212,6 +213,7 @@ You can try to connect to them by using the following command
|
|||
smbclient -U '%' -N \\\\<IP>\\<SHARE> # null session to connect to a windows share
|
||||
smbclient -U '<USER>' \\\\<IP>\\<SHARE> # authenticated session to connect to a windows share (you will be prompted for a password)
|
||||
```
|
||||
|
||||
or this script \(using a null session\)
|
||||
|
||||
```bash
|
||||
|
|
@ -229,7 +231,6 @@ for share in ${shares[*]}; do
|
|||
echo $output # echo error message (e.g. NT_STATUS_ACCESS_DENIED or NT_STATUS_BAD_NETWORK_NAME)
|
||||
fi
|
||||
done
|
||||
|
||||
```
|
||||
|
||||
examples
|
||||
|
|
@ -238,6 +239,7 @@ examples
|
|||
smbclient -U '%' -N \\\\192.168.0.24\\im_clearly_not_here # returns NT_STATUS_BAD_NETWORK_NAME
|
||||
smbclient -U '%' -N \\\\192.168.0.24\\ADMIN$ # returns NT_STATUS_ACCESS_DENIED or even gives you a session
|
||||
```
|
||||
|
||||
### Mount a shared folder
|
||||
|
||||
```bash
|
||||
|
|
@ -371,5 +373,3 @@ Which are used by some browsers and tools \(like Skype\)
|
|||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -6,100 +6,17 @@ If you want to **know** about my **latest modifications**/**additions**, **join
|
|||
If you want to **share some tricks with the community** you can also submit **pull requests** to ****[**https://github.com/carlospolop/hacktricks**](https://github.com/carlospolop/hacktricks) ****that will be reflected in this book.
|
||||
Don't forget to **give ⭐ on the github** to motivate me to continue developing this book.
|
||||
|
||||
## ACLs - DACLs/SACLs/ACEs
|
||||
|
||||
**If you don't know what is any of the acronyms used in the heading of this section, read the following page before continuing**:
|
||||
|
||||
{% page-ref page="acls-dacls-sacls-aces.md" %}
|
||||
|
||||
## Integrity Levels
|
||||
|
||||
From Windows Vista, all **protected objects are labeled with an integrity level**. Most user and system files and registry keys on the system have a default label of “medium” integrity. The primary exception is a set of specific folders and files writeable by Internet Explorer 7 at Low integrity. **Most processes** run by **standard users** are labeled with **medium integrity** \(even the ones started by a user inside the administrators group\), and most **services** are labeled with **System integrity**. The root directory is protected by a high-integrity label.
|
||||
Note that **a process with a lower integrity level can’t write to an object with a higher integrity level.**
|
||||
There are several levels of integrity:
|
||||
**If you don't know what are integrity levels in Windows you should read the following page before continuing:**
|
||||
|
||||
* **Untrusted** – processes that are logged on anonymously are automatically designated as Untrusted. _Example: Chrome_
|
||||
* **Low** – The Low integrity level is the level used by default for interaction with the Internet. As long as Internet Explorer is run in its default state, Protected Mode, all files and processes associated with it are assigned the Low integrity level. Some folders, such as the **Temporary Internet Folder**, are also assigned the **Low integrity** level by default. However, note that a **low integrity process** is very **restricted**, it **cannot** write to the **registry** and it’s limited from writing to **most locations** in the current user’s profile. _Example: Internet Explorer or Microsoft Edge_
|
||||
* **Medium** – Medium is the context that **most objects will run in**. Standard users receive the Medium integrity level, and any object not explicitly designated with a lower or higher integrity level is Medium by default. Not that a user inside the Administrators group by default will use medium integrity levels.
|
||||
* **High** – **Administrators** are granted the High integrity level. This ensures that Administrators are capable of interacting with and modifying objects assigned Medium or Low integrity levels, but can also act on other objects with a High integrity level, which standard users can not do. _Example: "Run as Administrator"_
|
||||
* **System** – As the name implies, the System integrity level is reserved for the system. The Windows kernel and core services are granted the System integrity level. Being even higher than the High integrity level of Administrators protects these core functions from being affected or compromised even by Administrators. Example: Services
|
||||
* **Installer** – The Installer integrity level is a special case and is the highest of all integrity levels. By virtue of being equal to or higher than all other WIC integrity levels, objects assigned the Installer integrity level are also able to uninstall all other objects.
|
||||
|
||||
You can get the integrity level of a process using **Process Explorer** from **Sysinternals**, accessing the **properties** of the process and viewing the "**Security**" tab:
|
||||
|
||||
|
||||
|
||||
You can also get your **current integrity level** using `whoami /groups`
|
||||
|
||||
|
||||
|
||||
### Integrity Levels in File-system
|
||||
|
||||
A object inside the file-system may need an **minimum integrity level requirement** and if a process doesn't have this integrity process it won't be able to interact with it.
|
||||
For example, lets **create a regular from a regular user console file and check the permissions**:
|
||||
|
||||
```text
|
||||
echo asd >asd.txt
|
||||
icacls asd.txt
|
||||
asd.txt BUILTIN\Administrators:(I)(F)
|
||||
DESKTOP-IDJHTKP\user:(I)(F)
|
||||
NT AUTHORITY\SYSTEM:(I)(F)
|
||||
NT AUTHORITY\INTERACTIVE:(I)(M,DC)
|
||||
NT AUTHORITY\SERVICE:(I)(M,DC)
|
||||
NT AUTHORITY\BATCH:(I)(M,DC)
|
||||
```
|
||||
|
||||
Now, lets assign a minimum integrity level of **High** to the file. This **must be done from a console** running as **administrator** as a **regular console** will be running in Medium Integrity level and **won't be allowed** to assign High Integrity level to an object:
|
||||
|
||||
```text
|
||||
icacls asd.txt /setintegritylevel(oi)(ci) High
|
||||
processed file: asd.txt
|
||||
Successfully processed 1 files; Failed processing 0 files
|
||||
|
||||
C:\Users\Public>icacls asd.txt
|
||||
asd.txt BUILTIN\Administrators:(I)(F)
|
||||
DESKTOP-IDJHTKP\user:(I)(F)
|
||||
NT AUTHORITY\SYSTEM:(I)(F)
|
||||
NT AUTHORITY\INTERACTIVE:(I)(M,DC)
|
||||
NT AUTHORITY\SERVICE:(I)(M,DC)
|
||||
NT AUTHORITY\BATCH:(I)(M,DC)
|
||||
Mandatory Label\High Mandatory Level:(NW)
|
||||
```
|
||||
|
||||
This is where things get interesting. You can see that the user `DESKTOP-IDJHTKP\user` has **FULL privileges** over the file \(indeed this was the user that created the file\), however, due to the minimum integrity level implemented he won't be able to modify the file anymore unless he is running inside a High Integrity Level \(note that he will be able to read it\):
|
||||
|
||||
```text
|
||||
echo 1234 > asd.txt
|
||||
Access is denied.
|
||||
|
||||
del asd.txt
|
||||
C:\Users\Public\asd.txt
|
||||
Access is denied.
|
||||
```
|
||||
|
||||
{% hint style="info" %}
|
||||
**Therefore, when a file has a minimum integrity level, in order to modify it you need to be running at least in that integrity level.**
|
||||
{% endhint %}
|
||||
|
||||
### Integrity Levels in Binaries
|
||||
|
||||
I made a copy of `cmd.exe` in `C:\Windows\System32\cmd-low.exe` and set it an **integrity level of low from an administrator console:**
|
||||
|
||||
```text
|
||||
icacls C:\Windows\System32\cmd-low.exe
|
||||
C:\Windows\System32\cmd-low.exe NT AUTHORITY\SYSTEM:(I)(F)
|
||||
BUILTIN\Administrators:(I)(F)
|
||||
BUILTIN\Users:(I)(RX)
|
||||
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
|
||||
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APP PACKAGES:(I)(RX)
|
||||
Mandatory Label\Low Mandatory Level:(NW)
|
||||
```
|
||||
|
||||
Now, when I run `cmd-low.exe` it will **run under a low-integrity level** instead of a medium one:
|
||||
|
||||
|
||||
|
||||
For curious people, if you assign high integrity level to a binary \(`icacls C:\Windows\System32\cmd-high.exe /setintegritylevel high`\) it won't run with high integrity level automatically \(if you invoke it from a medium integrity level --by default-- it will run under a medium integrity level\).
|
||||
|
||||
### Integrity Levels in Processes
|
||||
|
||||
Not all files and folders have a minimum integrity level, **but all processes are running under an integrity level**. And similar to what happened with the file-system, **if a process wants to write inside another process it must have at least the same integrity level**. This means that a process with low integrity level can’t open a handle with full access to a process with medium integrity level.
|
||||
|
||||
Due to the restrictions commented in this and the previous section, from a security point of view, it's always **recommended to run a process in the lower level of integrity possible**.
|
||||
{% page-ref page="integrity-levels.md" %}
|
||||
|
||||
## System Info
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,158 @@
|
|||
# ACLs - DACLs/SACLs/ACEs
|
||||
|
||||
## **Access Control List \(ACL\)**
|
||||
|
||||
An **ACL is an ordered list of ACEs** that define the protections that apply to an object and its properties. Each ACE identifies a security principal and specifies a set of access rights that are allowed, denied, or audited for that security principal.
|
||||
|
||||
An object’s security descriptor can contain **two ACLs**:
|
||||
|
||||
1. A **DACL** that **identifies** the **users** and **groups** that are **allowed** or **denied** access
|
||||
2. A **SACL** that controls **how** access is **audited**
|
||||
|
||||
When a user tries to access a file, the Windows system runs an AccessCheck and compares the security descriptor with the users access token and evaluates if the user is granted access and what kind of access depending on the ACEs set.
|
||||
|
||||
### **Discretionary Access Control List \(DACL\)**
|
||||
|
||||
A DACL \(often mentioned as the ACL\) identify the users and groups that are assigned or denied access permissions on an object. It contains a list of paired ACEs \(Account + Access Right\) to the securable object.
|
||||
|
||||
### **System Access Control List \(SACL\)**
|
||||
|
||||
SACLs makes it possible to monitor access to secured objects. ACEs in a SACL determine **what types of access is logged in the Security Event Log**. With monitoring tools this could raise an alarm to the right people if malicious users tries to access the secured object, and in an incident scenario we can use the logs to trace the steps back in time. And last, you can enable logging for troubleshoot access issues.
|
||||
|
||||
## How the System Uses ACLs
|
||||
|
||||
Each **user logged** onto the system **holds an access token with security information** for that logon session. The system creates an access token when the user logs on. **Every process executed** on behalf of the user **has a copy of the access token**. The token identifies the user, the user's groups, and the user's privileges. A token also contains a logon SID \(Security Identifier\) that identifies the current logon session.
|
||||
|
||||
When a thread tries to access a securable object, the LSASS \(Local Security Authority\) either grants or denies access. To do this, the **LSASS searches the DACL** \(Discretionary Access Control List\) in the SDS data stream, looking for ACEs that apply to the thread.
|
||||
|
||||
**Each ACE in the object's DACL** specifies the access rights that are allowed or denied for a security principal or logon session. If the object's owner has not created any ACEs in the DACL for that object, the system grants access right away.
|
||||
|
||||
If the LSASS finds ACEs, it compares the trustee SID in each ACE to the trustee SIDs that are identified in the thread's access token.
|
||||
|
||||
The system examines each ACE in sequence until one of the following events occurs:
|
||||
|
||||
* **An access-denied ACE explicitly denies** any of the requested access rights to one of the trustees listed in the thread's access token.
|
||||
* **One or more access-allowed ACEs** for trustees listed in the thread's access token explicitly grant all the requested access rights.
|
||||
* All ACEs have been checked and there is still at least **one requested access** right that has **not been explicitly allowed**, in which case, access is implicitly **denied**.
|
||||
|
||||
### Order of ACEs
|
||||
|
||||
Because the **system stops checking ACEs when the requested access is explicitly granted or denied**, the order of ACEs in a DACL is important.
|
||||
|
||||
The preferred order of ACEs in a DACL is called the "canonical" order. For Windows 2000 and Windows Server 2003, the canonical order is the following:
|
||||
|
||||
1. All **explicit** ACEs are placed in a group **before** any **inherited** ACEs.
|
||||
2. Within the group of **explicit** ACEs, **access-denied** ACEs are placed **before access-allowed** ACEs.
|
||||
3. Within the **inherited** group, ACEs that are inherited from the **child object's parent come first**, and **then** ACEs inherited from the **grandparent**, **and so** on up the tree of objects. After that, **access-denied** ACEs are placed **before access-allowed** ACEs.
|
||||
|
||||
The following figure shows the canonical order of ACEs:
|
||||
|
||||
### Canonical order of ACEs
|
||||
|
||||
|
||||
|
||||
The canonical order ensures that the following takes place:
|
||||
|
||||
* An explicit **access-denied ACE is enforced regardless of any explicit access-allowed ACE**. This means that the object's owner can define permissions that allow access to a group of users and deny access to a subset of that group.
|
||||
* All **explicit ACEs are processed before any inherited ACE**. This is consistent with the concept of discretionary access control: access to a child object \(for example a file\) is at the discretion of the child's owner, not the owner of the parent object \(for example a folder\). The owner of a child object can define permissions directly on the child. The result is that the effects of inherited permissions are modified.
|
||||
|
||||
### GUI Example
|
||||
|
||||
This is the classic security tab of a folder showing the ACL, DACL and ACEs:
|
||||
|
||||
|
||||
|
||||
If we click the **Advanced button** we will get more options like inheritance:
|
||||
|
||||
|
||||
|
||||
And if you add or edit a Security Principal:
|
||||
|
||||
|
||||
|
||||
And last we have the SACL in the Auditing tab:
|
||||
|
||||
|
||||
|
||||
### Example: Explicit access-denied to a group
|
||||
|
||||
In this example, the access-allowed group is Everyone and the access-denied group is Marketing, a subset of Everyone.
|
||||
|
||||
You want to deny the Marketing group access to a Cost folder. If the Cost folder's ACEs are in canonical order, the ACE that denies Marketing comes before the ACE that allows Everyone.
|
||||
|
||||
During an access check, the operating system steps through the ACEs in the order in which they appear in the object's DACL, so that the deny ACE is processed before the allow ACE. As a result, users who are members of the Marketing group are denied access. Everyone else is allowed access to the object.
|
||||
|
||||
### Example: Explicit before inherited
|
||||
|
||||
In this example, the Cost folder has an inheritable ACE that denies access to Marketing \(the parent object\). In other words, all users who are members \(or children\) of the Marketing group are denied access by inheritance.
|
||||
|
||||
You want to allow access to Bob, who is the Marketing director. As a member of the Marketing group, Bob is denied access to the Cost folder by inheritance. The owner of the child object \(user Bob\) defines an explicit ACE that allows access to the Cost folder. If the child object's ACEs are in canonical order, the explicit ACE that allows Bob access comes before any inherited ACE, including the inherited ACE that denies access to the Marketing group.
|
||||
|
||||
During an access check, the operating system reaches the ACE that allows Bob access before it gets to the ACE that denies access to the Marketing group. As a result, Bob is allowed access to the object even though he is a member of the Marketing group. Other members of the Marketing group are denied access.
|
||||
|
||||
### Access Control Entries
|
||||
|
||||
As stated previously, an ACL \(Access Control List\) is an ordered list of ACEs \(Access Control Entries\). Each ACE contains the following:
|
||||
|
||||
* A SID \(Security Identifier\) that identifies a particular user or group.
|
||||
* An access mask that specifies access rights.
|
||||
* A set of bit flags that determine whether or not child objects can inherit the ACE.
|
||||
* A flag that indicates the type of ACE.
|
||||
|
||||
ACEs are fundamentally alike. What sets them apart is the degree of control they offer over inheritance and object access. There are two types of ACE:
|
||||
|
||||
* Generic type that are attached to all securable objects.
|
||||
* Object-specific type that can occur only in ACLs for Active Directory objects.
|
||||
|
||||
### Generic ACE
|
||||
|
||||
A generic ACE offers limited control over the kinds of child objects that can inherit them. Essentially, they can distinguish only between containers and noncontainers.
|
||||
|
||||
For example, the DACL \(Discretionary Access Control List\) on a Folder object in NTFS can include a generic ACE that allows a group of users to list the folder's contents. Because listing a folder's contents is an operation that can be performed only on a Container object, the ACE that allows the operation can be flagged as a CONTAINER\_INHERIT\_ACE. Only Container objects in the folder \(that is, only other Folder objects\) inherit the ACE. Noncontainer objects \(that is, File objects\) do not inherit the ACE of the parent object.
|
||||
|
||||
A generic ACE applies to an entire object. If a generic ACE gives a particular user Read access, the user can read all the information that is associated with the object — both data and properties. This is not a serious limitation for most object types. File objects, for example, have few properties, which are all used for describing characteristics of the object rather than for storing information. Most of the information in a File object is stored as object data; therefore, there is little need for separate controls on a file's properties.
|
||||
|
||||
### Object-specific ACE
|
||||
|
||||
An object-specific ACE offers a greater degree of control over the types of child objects that can inherit them.
|
||||
|
||||
For example, an OU \(Organizational Unit\) object's ACL can have an object-specific ACE that is marked for inheritance only by User objects. Other types of objects, such as Computer objects, will not inherit the ACE.
|
||||
|
||||
This capability is why object-specific ACEs are called object-specific. Their inheritance can be limited to specific types of child objects.
|
||||
|
||||
There are similar differences in how the two categories of ACE types control access to objects.
|
||||
|
||||
An object-specific ACE can apply to any individual property of an object or to a set of properties for that object. This type of ACE is used only in an ACL for Active Directory objects, which, unlike other object types, store most of their information in properties. It is often desirable to place independent controls on each property of an Active Directory object, and object-specific ACEs make that possible.
|
||||
|
||||
For example, when you define permissions for a User object, you can use one object-specific ACE to allow Principal Self \(that is, the user\) Write access to the Phone-Home-Primary \(homePhone\) property, and you can use other object-specific ACEs to deny Principal Self access to the Logon-Hours \(logonHours\) property and other properties that set restrictions on the user account.
|
||||
|
||||
The table below shows the layout of each ACE.
|
||||
|
||||
### Access Control Entry Layout
|
||||
|
||||
| ACE Field | Description |
|
||||
| :--- | :--- |
|
||||
| Type | Flag that indicates the type of ACE. Windows 2000 and Windows Server 2003 support six types of ACE: Three generic ACE types that are attached to all securable objects. Three object-specific ACE types that can occur for Active Directory objects. |
|
||||
| Flags | Set of bit flags that control inheritance and auditing. |
|
||||
| Size | Number of bytes of memory that are allocated for the ACE. |
|
||||
| Access mask | 32-bit value whose bits correspond to access rights for the object. Bits can be set either on or off, but the setting's meaning depends on the ACE type. For example, if the bit that corresponds to the right to read permissions is turned on, and the ACE type is Deny, the ACE denies the right to read the object's permissions. If the same bit is set on but the ACE type is Allow, the ACE grants the right to read the object's permissions. More details of the Access mask appear in the next table. |
|
||||
| SID | Identifies a user or group whose access is controlled or monitored by this ACE. |
|
||||
|
||||
### Access Mask Layout
|
||||
|
||||
| Bit \(Range\) | Meaning | Description/Example |
|
||||
| :--- | :--- | :--- |
|
||||
| 0 - 15 | Object Specific Access Rights | Read data, Execute, Append data |
|
||||
| 16 - 22 | Standard Access Rights | Delete, Write ACL, Write Owner |
|
||||
| 23 | Can access security ACL | |
|
||||
| 24 - 27 | Reserved | |
|
||||
| 28 | Generic ALL \(Read, Write, Execute\) | Everything below |
|
||||
| 29 | Generic Execute | All things necessary to execute a program |
|
||||
| 30 | Generic Write | All things necessary to write to a file |
|
||||
| 31 | Generic Read | All things necessary to read a file |
|
||||
|
||||
## References
|
||||
|
||||
* [https://www.ntfs.com/ntfs-permissions-acl-use.htm](https://www.ntfs.com/ntfs-permissions-acl-use.htm)
|
||||
* [https://secureidentity.se/acl-dacl-sacl-and-the-ace/](https://secureidentity.se/acl-dacl-sacl-and-the-ace/)
|
||||
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
# Integrity Levels
|
||||
|
||||
## Integrity Levels
|
||||
|
||||
From Windows Vista, all **protected objects are labeled with an integrity level**. Most user and system files and registry keys on the system have a default label of “medium” integrity. The primary exception is a set of specific folders and files writeable by Internet Explorer 7 at Low integrity. **Most processes** run by **standard users** are labeled with **medium integrity** \(even the ones started by a user inside the administrators group\), and most **services** are labeled with **System integrity**. The root directory is protected by a high-integrity label.
|
||||
Note that **a process with a lower integrity level can’t write to an object with a higher integrity level.**
|
||||
There are several levels of integrity:
|
||||
|
||||
* **Untrusted** – processes that are logged on anonymously are automatically designated as Untrusted. _Example: Chrome_
|
||||
* **Low** – The Low integrity level is the level used by default for interaction with the Internet. As long as Internet Explorer is run in its default state, Protected Mode, all files and processes associated with it are assigned the Low integrity level. Some folders, such as the **Temporary Internet Folder**, are also assigned the **Low integrity** level by default. However, note that a **low integrity process** is very **restricted**, it **cannot** write to the **registry** and it’s limited from writing to **most locations** in the current user’s profile. _Example: Internet Explorer or Microsoft Edge_
|
||||
* **Medium** – Medium is the context that **most objects will run in**. Standard users receive the Medium integrity level, and any object not explicitly designated with a lower or higher integrity level is Medium by default. Not that a user inside the Administrators group by default will use medium integrity levels.
|
||||
* **High** – **Administrators** are granted the High integrity level. This ensures that Administrators are capable of interacting with and modifying objects assigned Medium or Low integrity levels, but can also act on other objects with a High integrity level, which standard users can not do. _Example: "Run as Administrator"_
|
||||
* **System** – As the name implies, the System integrity level is reserved for the system. The Windows kernel and core services are granted the System integrity level. Being even higher than the High integrity level of Administrators protects these core functions from being affected or compromised even by Administrators. Example: Services
|
||||
* **Installer** – The Installer integrity level is a special case and is the highest of all integrity levels. By virtue of being equal to or higher than all other WIC integrity levels, objects assigned the Installer integrity level are also able to uninstall all other objects.
|
||||
|
||||
You can get the integrity level of a process using **Process Explorer** from **Sysinternals**, accessing the **properties** of the process and viewing the "**Security**" tab:
|
||||
|
||||
|
||||
|
||||
You can also get your **current integrity level** using `whoami /groups`
|
||||
|
||||
|
||||
|
||||
### Integrity Levels in File-system
|
||||
|
||||
A object inside the file-system may need an **minimum integrity level requirement** and if a process doesn't have this integrity process it won't be able to interact with it.
|
||||
For example, lets **create a regular from a regular user console file and check the permissions**:
|
||||
|
||||
```text
|
||||
echo asd >asd.txt
|
||||
icacls asd.txt
|
||||
asd.txt BUILTIN\Administrators:(I)(F)
|
||||
DESKTOP-IDJHTKP\user:(I)(F)
|
||||
NT AUTHORITY\SYSTEM:(I)(F)
|
||||
NT AUTHORITY\INTERACTIVE:(I)(M,DC)
|
||||
NT AUTHORITY\SERVICE:(I)(M,DC)
|
||||
NT AUTHORITY\BATCH:(I)(M,DC)
|
||||
```
|
||||
|
||||
Now, lets assign a minimum integrity level of **High** to the file. This **must be done from a console** running as **administrator** as a **regular console** will be running in Medium Integrity level and **won't be allowed** to assign High Integrity level to an object:
|
||||
|
||||
```text
|
||||
icacls asd.txt /setintegritylevel(oi)(ci) High
|
||||
processed file: asd.txt
|
||||
Successfully processed 1 files; Failed processing 0 files
|
||||
|
||||
C:\Users\Public>icacls asd.txt
|
||||
asd.txt BUILTIN\Administrators:(I)(F)
|
||||
DESKTOP-IDJHTKP\user:(I)(F)
|
||||
NT AUTHORITY\SYSTEM:(I)(F)
|
||||
NT AUTHORITY\INTERACTIVE:(I)(M,DC)
|
||||
NT AUTHORITY\SERVICE:(I)(M,DC)
|
||||
NT AUTHORITY\BATCH:(I)(M,DC)
|
||||
Mandatory Label\High Mandatory Level:(NW)
|
||||
```
|
||||
|
||||
This is where things get interesting. You can see that the user `DESKTOP-IDJHTKP\user` has **FULL privileges** over the file \(indeed this was the user that created the file\), however, due to the minimum integrity level implemented he won't be able to modify the file anymore unless he is running inside a High Integrity Level \(note that he will be able to read it\):
|
||||
|
||||
```text
|
||||
echo 1234 > asd.txt
|
||||
Access is denied.
|
||||
|
||||
del asd.txt
|
||||
C:\Users\Public\asd.txt
|
||||
Access is denied.
|
||||
```
|
||||
|
||||
{% hint style="info" %}
|
||||
**Therefore, when a file has a minimum integrity level, in order to modify it you need to be running at least in that integrity level.**
|
||||
{% endhint %}
|
||||
|
||||
### Integrity Levels in Binaries
|
||||
|
||||
I made a copy of `cmd.exe` in `C:\Windows\System32\cmd-low.exe` and set it an **integrity level of low from an administrator console:**
|
||||
|
||||
```text
|
||||
icacls C:\Windows\System32\cmd-low.exe
|
||||
C:\Windows\System32\cmd-low.exe NT AUTHORITY\SYSTEM:(I)(F)
|
||||
BUILTIN\Administrators:(I)(F)
|
||||
BUILTIN\Users:(I)(RX)
|
||||
APPLICATION PACKAGE AUTHORITY\ALL APPLICATION PACKAGES:(I)(RX)
|
||||
APPLICATION PACKAGE AUTHORITY\ALL RESTRICTED APP PACKAGES:(I)(RX)
|
||||
Mandatory Label\Low Mandatory Level:(NW)
|
||||
```
|
||||
|
||||
Now, when I run `cmd-low.exe` it will **run under a low-integrity level** instead of a medium one:
|
||||
|
||||
|
||||
|
||||
For curious people, if you assign high integrity level to a binary \(`icacls C:\Windows\System32\cmd-high.exe /setintegritylevel high`\) it won't run with high integrity level automatically \(if you invoke it from a medium integrity level --by default-- it will run under a medium integrity level\).
|
||||
|
||||
### Integrity Levels in Processes
|
||||
|
||||
Not all files and folders have a minimum integrity level, **but all processes are running under an integrity level**. And similar to what happened with the file-system, **if a process wants to write inside another process it must have at least the same integrity level**. This means that a process with low integrity level can’t open a handle with full access to a process with medium integrity level.
|
||||
|
||||
Due to the restrictions commented in this and the previous section, from a security point of view, it's always **recommended to run a process in the lower level of integrity possible**.
|
||||
|
||||
Loading…
Reference in a new issue