Environment
NetIQ Access Manager 4.2
NetIQ Access Manager 4.1
Access Manager Identity Server
unsigned SAML2 AuthnRequest generated by untrusted Provider
CVE-2016-5752
NetIQ Access Manager 4.1
Access Manager Identity Server
unsigned SAML2 AuthnRequest generated by untrusted Provider
CVE-2016-5752
Situation
An Access Manager Identity Server (IDP) may receive an unsigned SAML2 authentication request that contains an explicit Assertion Consumer Service URL. With an unsigned request, the IDP server simply sends a response to the ACS URL ie. the IDP fails to check whether the supplied URL is matches or is even listed in the metadata for the SP.
Aside from it being a security hole, this is in direct contravention of the SAML2 standard. From saml-core-2.0-os.pdf, lines 2061-2067:
AssertionConsumerServiceURL [Optional]
Specifies by value the location to which the <Response> message MUST be returned to the requester. The responder MUST ensure by some means that the value specified is in fact associated with the requester. [SAMLMeta] provides one possible mechanism; signing the enclosing <AuthnRequest> message is another.
Similar to the target parameter with AG protected resources, we need some sort of whitelist to prevent the assertion being sent to a rogue site.
Aside from it being a security hole, this is in direct contravention of the SAML2 standard. From saml-core-2.0-os.pdf, lines 2061-2067:
AssertionConsumerServiceURL [Optional]
Specifies by value the location to which the <Response> message MUST be returned to the requester. The responder MUST ensure by some means that the value specified is in fact associated with the requester. [SAMLMeta] provides one possible mechanism; signing the enclosing <AuthnRequest> message is another.
Similar to the target parameter with AG protected resources, we need some sort of whitelist to prevent the assertion being sent to a rogue site.
Resolution
Fixed in 4.2.2 (for NAM 4.2 platform), or NAM 4.1.2 HF1 for NAM 4.1 platform. With these patches installed, the IDP provides an option for validation of the AssertionConsumerServiceURL in a SAML authentication request. By default this is disabled, and can be enabled using SAML 2.0 options in the Administration Console, on a per provider level.
There are two sources of validation, one is the metadata of the SP, and the other is a configurable whitelist of domains.
Steps to configure:
1. In the Administration Console, navigate to <IdP Cluster> --> SAML2 --> Service Providers. Select the concerned service provider and go to Options from the top pane.
2. Click New on the Options screen, and select 'OTHER' from the pop up menu.
3. If you simply want to validate the ACS URL against that provided in the SP metadata, specify 'Property Name' as 'SAML2_ACS_URL_RESTRICT' and 'Property Value' as 'true'.
4. If you want to validate additionally against a whitelist, repeat Step 2. Then specify 'Property Name' as 'SAML2_ACS_DOMAIN_WHITELIST'. The 'Property Value' here would be the whitelist. Format of the whitelist must be a ';' separated string of domain names. Each domain is basically a host name (RFC 2396 and RFC 2732 of the IETF). All whitespaces are ignored.
To workaround the issue on previous NAM builds, make sure that the SP signs the SAML AuthnRequests.
There are two sources of validation, one is the metadata of the SP, and the other is a configurable whitelist of domains.
Steps to configure:
1. In the Administration Console, navigate to <IdP Cluster> --> SAML2 --> Service Providers. Select the concerned service provider and go to Options from the top pane.
2. Click New on the Options screen, and select 'OTHER' from the pop up menu.
3. If you simply want to validate the ACS URL against that provided in the SP metadata, specify 'Property Name' as 'SAML2_ACS_URL_RESTRICT' and 'Property Value' as 'true'.
4. If you want to validate additionally against a whitelist, repeat Step 2. Then specify 'Property Name' as 'SAML2_ACS_DOMAIN_WHITELIST'. The 'Property Value' here would be the whitelist. Format of the whitelist must be a ';' separated string of domain names. Each domain is basically a host name (RFC 2396 and RFC 2732 of the IETF). All whitespaces are ignored.
To workaround the issue on previous NAM builds, make sure that the SP signs the SAML AuthnRequests.
Cause
Incomplete validation of incoming SAML request.