DavidBerner (Customer) asked a question.

Has anyone ran into issues with the latest patch to address CVE-2024-3596.? Citrix has came back saying NetScalers don't support the message authenticator attribute. Looking for any feedback how your upgrades went.

  • johnneset (Customer)

    [user reply edited by admin for breach of community guidelines]

     

    "For the message authenticate attribute (Message Authenticator) needs to be enabled on both sides the client and server side, and it only needs to be enabled if you're using it in your radius client."

    • DavidBerner (Customer)

      Ha so it's not just me where support has not been helpful or provided incorrect information. I asked for a list of potentially impacted vendors and was told they don't have a master list which I find hard to believe issues aren't being tracked. Very frustrating.

      • We empathize you. We would love to have a such a list, but vendors do not want to advertise being vulnerable. For third-party product concerns, please contact your vendor directly.

  • @DavidBerner (Customer)​ ,

     

    I am shamelessly plagiarizing this from @jay.guillette (RSA SecurID)​ , with a few tweaks:

     

    Authentication Manager 8.7 SP2 patch 3 includes a mitigation for CVE-2024-3596, a.k.a. the Blast RADIUS vulnerability.

     

    RADIUS allows certain Access-Request messages to have no integrity or authentication checks. Therefore, a man-in-the-middle (MitM) attack could change an Access-Denied response form the server to an Access Accept; thereby, allowing an attacker to force an authentication with whatever authorization they wanted. This would be possible by using the cryptographically broken MD5 hash for a chosen prefix attack so that the modified RADIUS response passes all the integrity checks for the original response.

     

    Per The Hacker News, "[f]or the attack to succeed, the adversary has to be able to modify RADIUS packets in transit between the client and server. This also means that organizations that send packets over the internet are at risk of the flaw." See RADIUS Protocol Vulnerability Exposes Networks to MitM Attacks for more information.

     

    Mitigation for this flaw includes migration to TLS RadSec and the use of the Message-Authenticator attribute, which is sent by via FreeRADIUS, beginning with Authentication Manager 8.7 SP2 patch 3.

     

    There are two new unrelated RADIUS features in Authentication Manager 8.7 SP2 patch 3:

    • First, the added option of "FreeRADIUS-ClientRequire-MA = no" causes the RADIUS server to require that the RADIUS client include the message-authenticator attribute. By default, this is set to No and is a separate RADIUS enhancement.
    • Second, RADIUS vendors implemented the following to address the CVE-2024-3596 vulnerability: “For Access-Accept or Access-Reject responses, the Message-Authenticator should be included as the first attribute. Patches implementing this mitigation have been implemented by all RADIUS implementations of which we are aware. This guidance is being put into an upcoming RADIUS RFC " See https://www.blastradius.fail/ for more.

     

    There are reports that some Authentication Manager customers have difficulties with RADIUS authentication after updating to Authentication Manager 8.7 SP2 patch 3. According to the RADIUS RFC2865 (circa 2000), the RADIUS client may ignore unknown attributes, which causes authentication failures.

     

    There should be a way for any RADIUS client (such as a VPN) to ignore the Message-Authenticator attribute in the Access-Accept or Access-Reject response or to properly acknowledge it. It is a security feature and there is no known or supported way to turn off sending the Message-Authenticator attribute in Authentication Manager RADIUS responses.

     

    There are two important notes on page 6 of the Authentication Manager 8.7 SP2 patch 3 readme: related to the Message-Authenticator attribute:

     

    • RSA recommends enabling the message authenticator attribute flag in the RADIUS server to enforce the use of Message-Authenticator attribute in all RADIUS authentication requests.
    • Note: Before enabling the message authenticator attribute flag, ensure your RADIUS client software version supports sending the message authenticator attribute in each RADIUS authentication request.

     

    Please work with the vendor of your RADIUS client devices to ensure that they are properly handling the Message-Authenticator attribute.

    Expand Post
    • DavidBerner (Customer)

      Thanks Erica this is helpful. So can we upgrade > enable the parameter from the OPS console > if something fails can we just disable the parameter in the ops console instead of reverting to a snapshot??

      • johnneset (Customer)

        Was curious if that was your thinking-patching/going to RSA Authentication Manager 8.7 SP2 Patch 3 certainly doesn't turn this setting on. It's purely a post-patching ad-hock thing left for us to find buried away in release notes to crumble & be pinned in the middle of vendors on....

        We have 2 completely different MSPs hosting our ADCs & they both kicked out once we attempted this feat. Didn't even think of trying to reauth to our VPN!

        Maybe you have premium Citrix support & can get some actual answers from them, but we certainly don't have that benefit & my usual reachouts are answered w/ complete ludacris from them.

        They recently went as far as telling me that HA failover are very normal to disconnect the session...

        Expand Post
      • DavidBerner (Customer)

        Yes exactly! Apply the patch and then enable. The question I have if something fails can we just disable the setting? @EricaChalfin (RSA)​ 

         

        @johnneset (Customer)​ Citrix support pretty much told me that it's all on the RADIUS server and nothing to change from their standpoint!

      • johnneset (Customer)

        Yeah, seemingly overlooked that fact being in your subject line!

        We've done this feat 2x as the 1st time it was like whatttt even happened there!

        Just ensure you save out current config to notepad++, but it's extremely light to apply, test ADCs, VPNs, etc, & then revert.

        From how I'm recalling this, reverting just the 1st &FreeRADIUS-Client-Require-MA = no was even enough to revive ADC RADIUS auth, for both ADCs.

         

        A 1% caveat is we couldn't even access the Radius Servers page. I've wondered about this caveat over the years, but it suddenly became priority that I actually access this segment.

        If you somehow fall into this scenario-don't panic & think something got corrupt! Just ensure you eventually get fw port 7082 bidirectional open between all AM servers.

        Article Detail (rsa.com)

        Expand Post
      • @DavidBerner (Customer)​ ,

         

        Sending the Message-Authenticator attribute (attribute 80) is included in Authentication Manager 8.7 SP2 patch 3 as a way to mitigate CVE-2024-3596.

         

        You can edit the parameter in the Operations Console as documented in the Authentication Manager 8.7 SP2 patch 3 readme to change FreeRADIUS-ClientRequire-MA = no to FreeRADIUS-ClientRequire-MA = yes and revert back, if needed.

         

        When it is set to yes, Authentication Manager will ignore/fail auth attempts from RADIUS clients if the CLIENT does not include the message-authenticator attribute (in its RADIUS request to the AM server).

         

        Authentication Manager 8.7 SP2 patch 3 makes it so Authentication Manager includes the Message-Authenticator attribute in responses back to RADIUS clients. This part of the update is NOT configurable.

         

        The information on making sure that your RADIUS clients support the Message-Authenticator attribute is in the readme, as mentioned and also in the advisory announcing critical security upgrades for RSA ID Plus components, RSA Authentication Manager and RSA identity routers:

         

        Before you apply the patch/hotfix, ensure that the vendor RADIUS clients support the message authenticator attribute in response. The configuration added in RSA ID Plus products can ignore message authenticator attribute in request.

         

        The ability to ignore unknown RADIUS attributes has been allowed since the RFC in 2000 (and likely earlier unofficially). Again, it is on the RADIUS vendors to process those requests properly.

         

        Per RADIUS RFC 2865 (Section 2.5, page 22:

        In general, it is best for a RADIUS client to err on the side of caution. On receiving an Access-Accept including an attribute of known Type for an unimplemented service, a RADIUS client MUST treat it as an Access-Reject, as directed in RFC2865 (Section 1.1). On receiving an Access-Accept including an attribute of unknown Type, a RADIUS client SHOULD assume that it is a potential service definition and treat it as an Access-Reject.

         

        According to RFC2865 (Section 5), circa 2000, the RADIUS client may ignore unknown attributes. If this is not configured, the RADIUS client likely will interpret an Access-Accept response as Access-Reject.

         

        It is the onus of the RADIUS client to ignore the Message-Authenticator attribute in the Access-Accept or Access-Reject responses or to acknowledge it. It is a security feature and there is no known or supported way to turn off sending the Message-Authenticator attribute in Authentication Manager RADIUS responses.

        Expand Post
      • DavidBerner (Customer)

        Can you confirm there is now a known way to turn this off with a work around in 8.7 SP 2 P4?

10 of 11