notes/docs/lectures/security/08_windows_security.md

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 SIDs 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 SIDs (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