Forum Discussion
THE_BLUE
Cirrostratus
CirrostratusCVE-2024-21410
does F5 has mitigation for CVE-2024-21410 ?
based on microsoft document we must disble ssl offloding with load balancer , as below
SSL Offloading scenarios
Extended Protection isn't supported in environments that use SSL Offloading. SSL termination during SSL Offloading causes Extended Protection to fail. To enable Extended Protection in your Exchange environment, you must not be using SSL offloading with your Load Balancers.
so does this mean disable https between WAF and Server (pool) and only https will be exist from Client to WAF
- Daniel_Wolf
MVP
Hi THE_BLUE,
to my knowledge F5 does not provide an Attack Signature or a Threat Campaign that protects from CVE-2024-21410.
Extended Protection is supported in environments that use SSL Bridging under certain conditions. That should solve your issue.
IMHO the days of SSL offloading are anyhow over, also internal networks cannot be considered as secure any longer. Therefore, go for SSL Bridging.KR
Daniel
THE_BLUEThank you for your clarification.
How to enable ssl bridging ? what i should configure in WAF ? , if i enabled https (port 443) from client to WAF with client ssl and enable http (port 80) from WAF to server (pool) and no server ssl profile. Does this achieve ssl bridging ?
Juergen_MangF5 does not support Extended Protection in SSL Bridging Mode. There is an RFE to support this, but it is rather unlikely that it is implemted for BIGIP Classic.
(Bug alias 758880) [RFE] [NTLM V2 SSO] Support MS IIS option "Extended protection" with value "required" during authentication
- Daniel_Wolf
Good to know, Juergen. Looking at the linked Microsoft article it says:
"Extended Protection is supported in environments that use SSL Bridging under certain conditions. To enable Extended Protection in your Exchange environment using SSL Bridging, you must use the same SSL certificate on Exchange and your Load Balancers. Using different certificates cause Extended Protection Channel Binding Token check to fail and as a result, prevent clients from connecting to the Exchange server."That seems feasible, to have the same cert on both ends. That should at least do for satisfying the requirements for the Channel Binding Token to work.
Do you have any insights why it is not supported? Cannot find the RFE here: https://my.f5.com/manage/s/bug-tracker.
Neither by ID 758880 nor by searching for the term "extended protection".Thx in advance.
- Juergen_Mang
I have tried using the same certificate on both ends and it has not worked. I opened a ticket and the support gave me the mentioned bug id and RFE. It seems these are only F5 internally accessible.
I had unfortunately no time to debug into this issue further. My customer decided to move forward to modern authentication, disabling NTLM completely and do not invest time and money in legacy authentication mechanisms.
Unfortunately I have no access to Exchange LAB environment. Digging into this issue deeper would be very interesting!
Edit:
This is interesting: https://www.synacktiv.com/en/publications/dissecting-ntlm-epa-with-love-building-a-mitm-proxy.html
With enough time it should be feasible with an iRule.
- lnxgeek
During a brainstorming we came up with a simple solution for protecting against NTLM relay attacks, when using SSO with APM, you simply either block or remove the authorization header on the clientside. All NTLM should only be present between APM and Exchange.
This will give you inside into who is compromised as you can log when you see any clientside NTLM headers. It will also stop any NTLM negotiation attempts from the client browser as that can be considered unwanted information disclosure.
If you are not deploying APM SSO you could make a semi proteted solution by picking up the first NTLM hash you see from the client and store it in a table. If you encounter a different hash later in the session you know it is bad and can either block it or start alarming. It is not bulletproof, but it is better than nothing.
The word on the street is that EPA is expected to be supported in NEXT, late this year.
- P_Kueppers
Since there are at least 3 threads for this...
If you are only using OWA - or ActiveSync - You can use form-based or basic-auth SSO with EAP and this will work.
- Daniel_Wolf
Valid point...
LiefZimmerman - can threads be merged?
- LiefZimmerman
Admin
Daniel_Wolf I can do some moderation/management to the other posts and close further comments > point them to the right/best post.
To keep this thread clean - I'll send a group DM to you and P_Kueppers requesting the URLs for the other posts so I can try.
