• CVE-2024-3596:
• Configure the RADIUS server to require the presence of a Message-Authenticator attribute in all Access-Request packets from RADIUS client devices that support it
• Restrict access to the networks where RADIUS messages are exchanged (e.g., send RADIUS traffic via management network or a dedicated VLAN)

Please follow the General Security Recommendations.

As a general security measure, Siemens strongly recommends to protect network access to devices with appropriate mechanisms. In order to operate the devices in a protected IT environment, Siemens recommends to configure the environment according to Siemens' operational guidelines for Industrial Security (Download: https://www.siemens.com/cert/operational-guidelines-industrial-security), and to follow the recommendations in the product manuals. Additional information on Industrial Security by Siemens can be found at: https://www.siemens.com/industrialsecurity

This chapter describes all vulnerabilities (CVE-IDs) addressed in this security advisory. Wherever applicable, it also documents the product-specific impact of the individual vulnerabilities.

Description

The vulnerability could allow on-path attackers, located between a Network Access Server (the RADIUS client, e.g., SCALANCE or RUGGEDCOM devices) and a RADIUS server (e.g., SINEC INS), to forge Access-Request packets in a way that enables them to modify the corresponding server response packet at will, e.g., turning an "Access-Reject" message into an "Access-Accept". This would cause the Network Access Server to grant the attackers access to the network with the attackers desired authorization (and without the need of knowing or guessing legitimate access credentials).

Successful attacks are demonstrated against RADIUS/UDP (IETF RFC 2865), similar attacks are considered possible against RADIUS/TCP (IETF RFC 6613). RADIUS/TLS (IETF RFC 6614) and RADIUS/DTLS (IETF RFC 7360) are not vulnerable.

Impact to SCALANCE and RUGGEDCOM Products, Countermeasures

SCALANCE and RUGGEDCOM devices use RADIUS/UDP and are therefore considered vulnerable, except for the IEEE 802.1X port security feature.

To fix the issue, specific countermeasures are required on both RADIUS client and RADIUS server side. In typical deployments, SCALANCE and RUGGEDCOM devices as well as RUGGEDCOM CROSSBOW are configured as RADIUS clients. SINEC INS as well as other 3rd party products are RADIUS servers.

RADIUS clients need to:

• C1. Ensure that all Access-Request packets they send to the server contain a Message-Authenticator attribute.
• C2. Implement a per-server configuration flag which requires that all Access-accept, Access-Reject, and Access-Challenge packets coming from a server must contain a Message-Authenticator attribute.

RADIUS servers need to:

• S1. Ensure that all replies to Access-Request packets contain a Message-Authenticator attribute as the first attribute in the packet.
• S2. Implement a per-client configuration flag which requires that all Access-Request packets coming from a client must contain a Message-Authenticator attribute.
• S3. If the server is also configured as a proxy (i.e., forwards certain client Access-Requests to another RADIUS server): Ensure that all proxied Access-Request packets contain a Message-Authenticator attribute.

The issue is fully mitigated only, if all recommendations are enforced in all RADIUS clients and servers. However, every individual recommendation decreases the likelihood of a successful attack.

Status

• SCALANCE devices, except X-300 family (incl. X408 and SIPLUS NET variants): C1 is implemented in current firmware versions; C2 is planned to be implemented in a future version.
• SCALANCE X-300 family (incl. X408 and SIPLUS NET variants): C1 is implemented in the latest firmware version (V4.1.8); C2 is planned to be implemented in a future version.
• RUGGEDCOM (ROX and ROS based) devices: C1 and C2 are not supported in current firmware versions; both are planned to be implemented in a future version.
• RUGGEDCOM CROSSBOW: C1 is implemented in current firmware versions; C2 is planned to be implemented in a future version.
• SINEC INS, when RADIUS Server feature is enabled: S1 is implemented in current versions for all clients that support C1; S2 is implemented in current versions.
• SINEC INS, when the Relay feature is configured: S3 is not implemented, all packets are forwarded unchanged.

Specific Countermeasures

• SCALANCE devices, except X-300 family (incl. X408 and SIPLUS NET variants): Update all devices to the latest available firmware version; ensure that the RADIUS server(s) in your deployment implement S1-S3; ensure that S2 is enabled for all SCALANCE devices; as soon as a new firmware version is available that supports C2: update all devices.
• SCALANCE X-300 family (incl. X408 and SIPLUS NET variants): Update all devices to V4.1.8 or later version; ensure that the RADIUS server(s) in your deployment implement S1-S3; ensure that S2 is enabled for all SCALANCE devices; as soon as a new firmware version is available that supports C2: update all devices.
• RUGGEDCOM (ROX and ROS based) devices: Ensure that the RADIUS server(s) in your deployment implement S1-S3, but keep S2 disabled for RUGGEDCOM devices; as soon as a new firmware version is available that supports C1 and C2: update all devices and enable S2 on the server.
• RUGGEDCOM CROSSBOW: Update to the latest available version; ensure that the RADIUS server(s) in your deployment implement S1-S3; ensure that S2 is enabled for RUGGEDCOM CROSSBOW; as soon as a new version is available that supports C2: update RUGGEDCOM CROSSBOW. Alternatively, consider to use a different supported method for authentication: AD, RSA or a combination of both.
• SINEC INS, when RADIUS Server feature is enabled: Configure S2 for all clients that support C1
• SINEC INS, when the Relay feature is configured: Ensure that the connections between SINEC INS and the configured RADIUS server groups are secured and access-restricted (e.g. via IPSec or VPN)

More Information

• CERT Coordination Center - "RADIUS protocol susceptible to forgery attacks": https://kb.cert.org/vuls/id/456537
• Research paper and related information - "RADIUS/UDP Considered Harmful": https://www.blastradius.fail/
• IETF Internet-Draft - "Deprecating Insecure Practices in RADIUS": https://datatracker.ietf.org/doc/draft-ietf-radext-deprecating-radius/