I need to write up a script to prove this, however my concern (documented here so this isn't just in my head) that: Given (this much we know): - a machine account can select it's own name (samAccountName is writable by SELF) - the machine account name is not constrained to be ending in a $ - the RODC PAC-regeneration is name-based (the incoming PAC is ignored) An attacker, holding a machine account replicated to the RODC can: - rename that account to DC - obtain a Kerberos TGT against the RODC - rename that account to not-DC - present that ticket (as RODC) to the RWDC for upgrade to a real ticket - access services as the DC (eg replicate passwords, obtain the krbtgt). This is partly because of bug 14558 (as otherwise the ticket as DC would not be honored), but even if that is fixed, the machine account can become the RODC, which can still request passwords of and print tickets for any user in the "Allowed RODC password replication group".
To be clear, the upgrade to a real ticket step is because in MS-KILE 3.3.5.6.1 Client Principal Lookup, also roughly implemented in Samba, any incoming ticket with a name BOB also matches an account BOB$. Our C and python testsuites also confirm this.
Correction to the scope here. A (helpdesk) user able to create accounts set as replicated to the RODC could take over the Samba domain. We were concerned about SELF permissions on the machine account's samAccountName, but we can't find any of those on re-examination. Joseph and I are continuing to work on exploits to help ensure our concerns are real, to avoid any unsupported conclusions.
A viable exploit has been written and shown that Samba does indeed have this issue.
The proposed coordinated fix with MS for this and bug 14724 is to always issue a FULL or 'mini' PAC to all clients. The current discussion is if a full PAC should always be issued and delivered to clients (which they can't see except by ticket size) or a mini PAC with the GUID and SID for validation against the name in the ticket. Any mismatch would cause the ticket to be rejected at any point it is decrypted by the KDC. Ideally for Samba (because it would help bug 14556) the full PAC will always be delivered to the target server unless the server has UF_NO_AUTH_DATA_REQUIRED in userAccountControl, but this may break clients that were requesting NO PAC via the AS-REQ to get UDP packets.
*** Bug 14724 has been marked as a duplicate of this bug. ***
This is merged with [SECURITY][EMBARGOED] S4U2Self allows domain takeover by user able to create accounts as the mechanism doesn't matter as much as any name matching in the KDC. Name matching is the norm in RFC-style Kerberos but aliasing in AD and lax user creation permissions make this a problem for: - RODC - S4U2Self - user2user (broken in Heimdal based Samba AD, need to check MIT) (and others) This bug is about the cases where the SID in the PAC can be used to enforce tracking of the account despite the renames.
Moving to be a task under bug 14561 and patches will be marked with CVE-2020-25719 along with the other issues where the KDC or AD DC can be confused about a username.
This bug was referenced in samba v4-15-stable (Release samba-4.15.2): 317b66d00d0dc771a2a724aa11d7c26f7bd117fd b69f1a758b24125c2de9aaa789ee37c0edf5811e 421edd0e14ff58698abebe8b48a814fc4f327d89 7cd1e133b675df3ebe8b5b6b2e11f0bafba44b57 947c922c6845a205b2e77c3d8dbfb54ecec2352d 63ea53393607a94db094ddb4443090bd331c0cd2 d0228a228cc4e04623288156fae45cc896a2e808
This bug was referenced in samba v4-14-stable (Release samba-4.14.10): 4b012b23eb4ca87302729d9818266be62de3e485 02e371103544428cee502bb2432feb799cd8b6a8 62de092e86f6db8d3a7767a7674ac19e29abd349 faba235a343fa3bc287cb44db7fc1e9d808f5c4a 289a526bfd883f9fe097b1f6cacc60006f348ec3 d68a530c66cf1200db112607d6c6bd91ad828232 50e11804fadf9f3e55192487126c6aa86b17353b
This bug was referenced in samba v4-14-test: 4b012b23eb4ca87302729d9818266be62de3e485 02e371103544428cee502bb2432feb799cd8b6a8 62de092e86f6db8d3a7767a7674ac19e29abd349 faba235a343fa3bc287cb44db7fc1e9d808f5c4a 289a526bfd883f9fe097b1f6cacc60006f348ec3 d68a530c66cf1200db112607d6c6bd91ad828232 50e11804fadf9f3e55192487126c6aa86b17353b
This bug was referenced in samba v4-13-test: 17a08609b20389a7cdf50065292d4ef0dd4f530f 66d2176a706272f5f25255ecf7f654a2532218bb 6b82704c2f723ac41f3e775d313c8e17805a000c f839cc40af6115ea84bcac5c7fa84d616b181d83 4d92c401a9906933a78cb67ac80afc1d82ccfa3f 8d94ec0d3f7d3271aa9499e6a9c535ba2efc8f57 864623d873fe93fe4167e562800d7b2cb0ca9a68
This bug was referenced in samba v4-13-stable (Release samba-4.13.14): 17a08609b20389a7cdf50065292d4ef0dd4f530f 66d2176a706272f5f25255ecf7f654a2532218bb 6b82704c2f723ac41f3e775d313c8e17805a000c f839cc40af6115ea84bcac5c7fa84d616b181d83 4d92c401a9906933a78cb67ac80afc1d82ccfa3f 8d94ec0d3f7d3271aa9499e6a9c535ba2efc8f57 864623d873fe93fe4167e562800d7b2cb0ca9a68
This bug was referenced in samba v4-15-test: 317b66d00d0dc771a2a724aa11d7c26f7bd117fd b69f1a758b24125c2de9aaa789ee37c0edf5811e 421edd0e14ff58698abebe8b48a814fc4f327d89 7cd1e133b675df3ebe8b5b6b2e11f0bafba44b57 947c922c6845a205b2e77c3d8dbfb54ecec2352d 63ea53393607a94db094ddb4443090bd331c0cd2 d0228a228cc4e04623288156fae45cc896a2e808
This bug was referenced in samba master: 4a792ad92d6f7319f3272b38e32e281b55d76f70 dbedf5b6e26cd6ed7ba18a96797f9bd610161a49 48e5154de645daa168c6b79467abfd977f72277e 7f7476b08cb3eb8ec3d9c1c5b6903a2d6e79b6a8 bacb51d0d3acd529de4e3315ed2f04eeac4829d5 05898cfb139ae0674c8251acc9d64c4c3d4c8376 756934f14cc87dc1adfd9315672ae5d49cb24d95
The patches addressing this issue have been pushed to master and security releases made.
Removing embargo