A serious design issue, tracked as CVE-2023-4154, was discovered in Samba's implementation of the DirSync control. This flaw exposes sensitive passwords and secrets stored in Microsoft Active Directory (AD) to accounts and systems that should never have this level of access. Because Samba is widely used to provide Windows-compatible file and print services on Unix systems—and often handles AD roles—this vulnerability has significant implications for organizations using Samba as domain controllers (DCs) or read-only domain controllers (RODCs).
In simple terms, CVE-2023-4154 lets certain users and RODCs view all directory secrets, including privileged passwords and the krbtgt account, which is critical for Kerberos authentication. This breaks the security model that is supposed to protect these secrets and limits replication.
What is DirSync Control?
DirSync is a special LDAP control that allows clients to request changes in AD objects. It's used by certain services (like RODCs) to synchronize directory data efficiently. Normally, synchronization is limited by permissions and filter rules, so RODCs only get "safe" attributes (like user logons for their region), but *not* high-privilege secrets.
What Went Wrong?
Samba's implementation of DirSync contained a design flaw:
The DirSync control did not correctly limit which attributes could be returned.
- Privileged users and RODCs with the right to use DirSync (typically those with the GET_CHANGES right) could request *and get* all attributes.
The krbtgt account (crucial for forging Kerberos tickets)
> Critical Issue: In normal Microsoft Active Directory, RODCs can only replicate subset of user credentials. But due to this flaw, any RODC DC account with DirSync, or any user with GET_CHANGES permission, can grab ALL directory secrets—including the master krbtgt key.
Even Worse: "Fail Open" Condition
When Samba faces certain failure scenarios (like running out of RAM or hitting unexpected errors), it can "fail open":
Warning: This is for educational purposes only. Unauthorized access is illegal.
Below is a code snippet that shows how you can request *all* attributes—including secrets—from a vulnerable Samba AD server using LDAP and the DirSync control:
import ldap3
server = ldap3.Server('ldap://samba-ad.example.com')
conn = ldap3.Connection(server, 'rodc_account@example.com', 'Password123', auto_bind=True)
# Request DirSync control with highest privilege
dirsync_control = ldap3.DirSync(sync_all=True)
conn.search(
search_base='dc=example,dc=com',
search_filter='(objectClass=*)',
search_scope=ldap3.SUBTREE,
attributes=['*'], # Get all attributes
controls=[dirsync_control]
)
for entry in conn.entries:
if 'unicodePwd' in entry:
print("Password Hash:", entry['unicodePwd'])
if 'msDS-KeyVersionNumber' in entry:
print("krbtgt Secret:", entry['msDS-KeyVersionNumber'])
With minimal modification, a real attacker could harvest *all* active passwords and secret key material.
Why This Is So Dangerous
- Exposure of ALL secrets: Usually, secrets like krbtgt are tightly controlled. Once you have it, *you can create valid Kerberos tickets* (pass-the-ticket, Golden Ticket attacks).
- RODC accounts are now as powerful as full DCs: This flaw removes the boundary—RODCs should not have these privileges.
- Privilege escalation: Attackers with GET_CHANGES rights, or those who can exploit "fail open," can escalate to domain dominance.
- Persistence: Compromised secrets can be used to maintain access, even after incident response cleans up normal accounts.
References & Official Resources
- Samba Security Advisory (CVE-2023-4154)
- NIST CVE Detail
- Samba Release Notes
Restrict DirSync Usage:
Audit who has DirSync / GET_CHANGES rights. Remove from accounts that don't need it.
Conclusion
CVE-2023-4154 is a devastating flaw for organizations using Samba as their AD backend. The clear takeaway? Until patched, even "safe" roles like RODCs (and certain privileged users) can read *every secret in your directory*. In the wrong hands, this gives attackers total control.
Stay safe: PATCH and rotate your keys!
*This post is exclusive. Please share and credit for awareness. For further details, see the links above.*
Timeline
Published on: 11/07/2023 20:15:08 UTC
Last modified on: 12/29/2023 05:15:08 UTC