CSCvo60450 - Encryption RC4/AES256 & MS AD CVE-2022-38023 patch

[adamscottmaster2013]

According to this bug, it stated:  When user authentication initiates from ISE, ISE will connect and send the encryption types that are supported (RC4, AES128, and AES256). This enhancement is for AD tuning to only send AES 256

This is exactly what I am seeing between my Cisco ISE version 3.1 patch-5 (latest patch) and Microsoft Windows Active Directory (AD).  My Cisco ISE is integrated with AD for user authentication.  In other words, the ISE has to communicate with AD for username and password.  When I capture the traffic on the ISE, I can clearly see the ISE sent RC4 to AD and AD responded back with RC4 with the RPC_Netlogon protocol, as seen below:

Cisco ISE to AD request:

Auth Info: NETLOGON Secure Channel, Packet privacy, AuthContextId(186703)
Auth type: NETLOGON Secure Channel (68)
Auth level: Packet privacy (6)
Auth pad len: 4
Auth Rsrvd: 0
Auth Context ID: 186703
Secure Channel Verifier
Sign algorithm: HMAC-MD5 (0x0077)
Seal algorithm: RC4 (0x007a)
Flags: 0000

This is the response from Active Directory:

Auth Info: NETLOGON Secure Channel, Packet privacy, AuthContextId(186703)
Auth type: NETLOGON Secure Channel (68)
Auth level: Packet privacy (6)
Auth pad len: 0
Auth Rsrvd: 0
Auth Context ID: 186703
Secure Channel Verifier
Sign algorithm: HMAC-MD5 (0x0077)
Seal algorithm: RC4 (0x007a)
Flags: 0000

The problem is that come April 2023, Microsoft will release a patch, AD CVE-2022-38023 patch, to start removing RC4 from Active Directory.  Does it mean the communication between Cisco ISE and Microsoft Active Directory will be broken?  

The Cisco bug ID CSCvo604 listed the following Known Affected Releases Cisco ISE versions:

003.002(000.542)  --> version 3.2

003.001(000.518)  --> version 3.1

003.000(000.458)  --> version 3.0

002.007(000.356)  --> version 2.7

002.006(000.903)  --> version 2.6

... and more versions after this.

The bug ID also does NOT list any known fixes releases.  Does that mean that I will have an outage when RC4 is removed from Active Directory in April with the Microsoft AD CVE-2022-38023 patch ?

TIA

[Arne Bier]

Sounds like a bit of a problem - I was unable to find that bug ID - did you mean CSCvo60450 ?

[adamscottmaster2013]

@Arne Bier:  Yes, CSCvo60450.  Typo on my copy and paste

The bug ID deals with Kerberos function and I think it has to do with Krb5 TGS-REQ/TGS-REP or AS-REQ/AS-REQ:

Cisco ISE to AD request:

etype: 3 items
ENCTYPE: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
ENCTYPE: eTYPE-AES128-CTS-HMAC-SHA1-96 (17)
ENCTYPE: eTYPE-ARCFOUR-HMAC-MD5 (23)

This is the response from Active Directory:

enc-part
etype: eTYPE-AES256-CTS-HMAC-SHA1-96 (18)
kvno: 39
cipher: 3a42d63334b51e466e419d370a67eaeccb07ce3b5c72ebc15fe33b38aed5fcfa8b6908f8…

I thihk this is OK because the ISE sends out both AES along RC4 and Active Directory only response with the highest encryption so I assume that turning OFF RC4 in AD will be OK.  But then there is another packet called RPC_NetLogon (user authentication I think)  where ISE only sent out RC4/MD5 and AD will reply back with RC4 thus turning OFF RC4 in AD will cause things to be broken.

Am I right?  

[Arne Bier]

I am still kind of amazed that we're even talking about RC4 at all - and if your packet analysis was done on ISE 3.1 then it will surely affect all other ISE deployments too. Have you raised a Cisco TAC case?  We should get a reply from the TAC/BU. Well spotted though. In most of my ISE deployments, AD is used. It could be a catastrophe (assuming customers patch their Windows Servers too ..).

[Arne Bier]

Hi @adamscottmaster2013 - I have opened a TAC case as well - they are working on it.

In the meantime, I ran my own Wireshark against ISE 3.1 and Windows Server 2016 and I can see that ISE negotiates a bunch of ciphers including RC4, but the Windows 2016 decides to use AES.  What version of Server did you take your evidence from?

ISE Kerberos Request (ARCFOUR is RC4)

AD Kerberos Response - no mention of RC4

ISE should probably not be offering RC4 in its requests - but it seems plausible that a well behaving Windows Server would just ignore that cipher and use AES instead.

[Greg Gibbs]

I wasn't sure if I was missing something, but I was seeing the same behaviour as @Arne Bier when performing a Test User using the Kerberos authentication type option.

The only time I was seeing the RC4 cipher used was when I did a Test User using the MS-RPC authentication type option which, unless I'm mistaken, is not what ISE uses when performing lookups against the domain. My setup uses Windows Server 2019 (with the latest patches and and ISE 3.1p5.

[adamscottmaster2013]

Hi @Greg Gibbs:  Apparently Cisco ISE must be using MS-RPC to lookup users against the domain in Active Directory because I am seeing a lot of this in Active Directory everytime users are loggingg in and out of ISE.  Wouldn't that be a problem?

My setup is also Windows Server 2019 and ISE 3.1 with patch 5.

Also if you refer to the bulletin release by microsoft regarding MS AD CVE-2022-38023, it specifically stated about the NetLogon protocol and not Kerberos:  https://support.microsoft.com/en-us/topic/kb5021130-how-to-manage-the-netlogon-protocol-changes-related-to-cve-2022-38023-46ea3067-3989-4d40-963c-680fd9e8ee25

Therefore, we're talking about two different things, or least that's how I understand it.

[adamscottmaster2013]

Hi @Arne Bier:  I tested this on both Windows 2016 and 2019 and I am seeing the same issue. What you showed above the the Kerberos packets and that is normal because ISE sent out both AES-256/128 and also RC4 requests but Active Directory (AD) only replied with AES-256 which is normal.  That's what I said in my previous replies. What you are referring to is the AS-REQ, AS-REQ, TGS-REQ and TGS-REP which is Kerberos.

The packet that I am referring to is the RPC_Netlogon that you could clearly see the RC4/MD5 in the seal algorithm like what I described in the original thread.  Looks for SMB packet in the wireshark capture with NetrLogonSamLogonEx and you will find RC4/MD5.

Thank you.

[Arne Bier]

Hi @adamscottmaster2013 and @Greg Gibbs 

I get it now - it's when a user logs in that you will see the SMB2 Netlogon. I didn't realise this subtlety.

This is from the lab 3.1p4 against a patched Windows Server 2016 

It looks like ISE is not even offering the AES encryption anymore ...

[adamscottmaster2013]

Hi @Arne Bier:  thank you very much for confirming.  That's exactly what I am also seeing as well.  I am using ISE 3.1 patch-5 but I am also seeing this in ISE 3.0 patch-4 and Windows 2019 Active Directory with the latest patch. 

I also find it very interesting that when I enforce RC4 on Active Directory for NetLogon by adding the "RequireSeal" set to 2 in the AD registry, I still see ISE send RC4 request to AD and that AD still responds back with RC4.  In other words, everything is till working as nothing has changed.  Not sure what to make of it.

Another this about the Microsoft article, it stated:  Windows updates address weaknesses in the Netlogon protocol when RPC signing is used instead of RPC sealing. More information can be found in CVE-2022-38023.

If you look in the capture, in the secure channel verifier, it has "sign algorithm" as HMAC-MD5 while "Seal algorithm" is RC4.  How is that related to the Microsoft Article?  signing and sealing? 

[Greg Gibbs]

@adamscottmaster2013 and @Arne Bier 

So, I read through the CVE-2022-38023 again, and it just states:
"Enforcement mode. All clients are required to use RPC Seal, unless they are added to the "Domain Controller: Allow vulnerable Netlogon secure channel connections” group policy object (GPO)."

There is nothing in that CVE about an issue with using the RC4 cipher for the Seal algorithm, just that the client must use RPC Seal (rather than just RPC Sign). Since the pcap shows that both RPC Seal and RPC Sign algorithms are present, this should meet the enforcement being applied by MS.

I also set the Enforcement registry setting on my 2019 server and I can still do MS-RPC lookups from ISE.

That would make sense as to why the communication with AD would still be working when you change the RequireSeal registry setting to 2 (Enforcement mode).

[Arne Bier]

In general crypto lingo, hashing is about confirming that you’re communicating with the party you expect (integrity) - so that means verifying the signature. In this case MD5 is used for the hashing. Better would be SHA2. 
Other piece of the crypto is the confidentiality of the message. The sealing of the message. Done with the symmetric cipher. In this case the olde world RC4 is the cipher. Better would have been AES. 

let’s see if Cisco can weigh in on the conversation 

[Surendra]

This is picked up and being worked on. Please keep an eye on this bug's notifications.

[zac ragoonath]

Is there any update on this?

[navtom]

I have received this uncertain reply from TAC:

---

From Cisco side, enhancement request has been opened:
CSCvo60450 - Enhancement for encryption to only send AES256 for MS-RPC calls
https://bst.cisco.com/bugsearch/bug/CSCvo60450
However, there are no workarounds as there should not be any impact, ISE will still be able to negotiate other ciphers with AD.

---

But because I can not work with "should" I am wondering if anybody managed to test Netlogon with enforcement enabled domain controller.