164 lines
5.3 KiB
Markdown
164 lines
5.3 KiB
Markdown
# Windows Security
|
||
|
||
Windows Architecture
|
||
|
||
|
||
|
||
Note: Windows has `kernel mode drivers` and `user mode drivers`
|
||
|
||
### Security Subsystem
|
||
|
||
- Runs in user mode
|
||
- `Logon` processes (`winlogon`, `LogonUI`)
|
||
- Local security authority (`LSA`)
|
||
- Checks users’ accounts
|
||
- Provides access token
|
||
- Responsible for auditing
|
||
- Security Account manager (`SAM`)
|
||
- Maintains user account database used by `LSA`
|
||
- Encrypts / hashes passwords
|
||
- Windows predominantly uses **Access Control Lists**, and has done since Windows NT
|
||
- Extends the usual read, write and execute with:
|
||
- Take ownership
|
||
- Change permissions
|
||
- Delete
|
||
- This allows finer control over files for example a user will be able to read a file but not delete it
|
||
- 32-bit access masks (unlike Unix’s 9 bits)
|
||
- A higher degree of control, with the associated complexity increase
|
||
|
||
### Access Control Matrix
|
||
|
||
- Access rights are defined individually for each combination of subject and object
|
||
- Quite an abstract concept, but would allow for very fine-grained control
|
||
- Not practical, think of the memory required in scaling it up
|
||
|
||
|
||
|
||
##### Capabilities
|
||
|
||
- A list of capabilities defined per user, equivalent to a row in the access control matrix
|
||
|
||
|
||
|
||
Windows doesn’t do this, it does the opposite storing columns called the **Access Control List**
|
||
|
||
##### Access Control List
|
||
|
||
- Stored with an object itself, corresponding to a column of an ACM
|
||
|
||
|
||
|
||
The access control list can be found by right clicking on a file -> properties -> security.
|
||
|
||
### Access Control
|
||
|
||
- Access control in Windows treats more than just files, also:
|
||
- Registry keys
|
||
- Active directory objects
|
||
- Groups
|
||
- Inheritance is implemented
|
||
- File can inherit ACLs from parent directories
|
||
|
||
#### Principals
|
||
|
||
- Principals are more broadly defined as well:
|
||
- Local users
|
||
- Domain users
|
||
- Groups
|
||
- Machines
|
||
|
||
Each principal has a human-readable name and security ID (`SID`)
|
||
|
||
```
|
||
S-1-5-21-2475811070-2421845406-3333283485-1005
|
||
S-1-5-21-1664130791-3153540899-3044996548-279530
|
||
```
|
||
|
||
These are examples of `SID` from Windows, but why are they so long?
|
||
|
||
This is a form of future proofing. Imagine company A buys company B, you can merge the users onto one active directory without two `SID`s clashing. (also 96 bits of memory isn’t a lot in the grand scheme of things)
|
||
|
||
##### Local / Domain Principals
|
||
|
||
- LSA creates local principals
|
||
- principal = `MACHINE\principal`
|
||
- Domain principals administered on DC by domain admins
|
||
- principal@domain = DOMAIN\principal
|
||
- net user /domain
|
||
- net group /domain
|
||
- net localgroup /domain
|
||
|
||
#### Groups
|
||
|
||
- Groups are collections of `SID`s (object-orientated)
|
||
- Group can itself be an `SID`
|
||
- Groups can thus be nested
|
||
- Groups are not nest-able on local machines
|
||
- Managed by a domain controller within Active Directory
|
||
|
||
#### Objects
|
||
|
||
- Objects are passive entities in access operations
|
||
- In Windows:
|
||
- Executive objects (processes, threads, etc)
|
||
- Private objects (files, directories)
|
||
- Securable objects have a security descriptor
|
||
- Built-in securable objects managed by the OS
|
||
- Private objects managed by the application software
|
||
|
||
### Access Tokens
|
||
|
||
- Instead of passing a number as in Linux, we pass an access token
|
||
- It is the security credentials for a login session stored in the **access token**
|
||
- Identifies the user, the user’s groups, and the user’s privileges
|
||
|
||
#### Subjects
|
||
|
||
- Windows subjects: Processes and threads
|
||
- New processes get a **copy** of the parent access token, possibly modified
|
||
- Individual access tokens are immutable and can live beyond policy changes
|
||
- The access token checked is the one given at login, not the current access token
|
||
- This is a TOCTTOU issue (Time-of-check to Time-of-use)
|
||
- Admins can force a user to log off to update their access token
|
||
|
||
### User Account Control
|
||
|
||
- After Vista, administrator users do not use an administrative access token by default
|
||
- Users have two tokens, one heavily restricted and used by default
|
||
- A prompt allows a user to spawn a process with the administrative token, or switch a process’ token.
|
||
- Similar to `sudo`
|
||
- Can be swapped mid-execution
|
||
|
||
#### Domains
|
||
|
||
- Single sign-on for network resources
|
||
- Centralised security administration
|
||
- Domain controller (DC)
|
||
- Handles user accounts and access control
|
||
- Trusted 3rd party for authentication
|
||
- Multiple DCs allow for decentralisation by design
|
||
|
||
#### Interactive Logon
|
||
|
||
- The Windows interactive logon allows a user to authenticate
|
||
- Windows logon begins with the Secure Attention Sequence `Ctrl+Alt+Del`
|
||
- Can prevent spoofing - is tied directly to `winlogon`
|
||
- The logon process differs slightly for local and domain authentication
|
||
|
||
##### Local Logon
|
||
|
||
1. `Ctrl+Alt+Del` initiates a login prompt using `GINA`
|
||
2. These collect credentials which are passed to the `LSA`
|
||
3. The `LSA` uses `NTLM` to check the credentials against the `SAM` database
|
||
4. Successful login produces an access token, which is used to spawn a shell (explorer.exe)
|
||
|
||
|
||
|
||
##### Domain Logon
|
||
|
||
- Replaces `NTLM` with `Kerberos`
|
||
- Replaces `SAM` with an Active Directory Domain Controller
|
||
- Checks of a user are now performed on the remote `LSA`
|
||
|
||
|