Pentesting SAML

Here you can see user agent (mostly user’s browser) request to the service provider for access of resource (lets say a web portal). Service provider detects that user has to authenticate via Identity Provider then only access can be granted. Service provider redirects user to Identity provider with some parameter’s for identification.

After that user try to authenticate identity provider via credentials. Once the authentication is done, identity provider sends a XHTML form to user which has multiple parameters including a base 64 encoded parameter which contains entire SAML data.

User Agent takes the request and forwards it to Service Provider with all the values and access to the resource is granted based on authorization of the user.

Vulnerabilities? Let’s discuss

1. XXE Attack – As SAML is XML based it is highly recommended to check for all sort of attacks related to XML External Entity injections like LFI, RCE etc.
2. Message Expiration Time – Most of the time SAML is mis-configured to support long expiry time. In the below example you can see that there is a time difference of 1 hour which is not at all required. Suggested time difference between the “Created” and “Expires” should be of 2-4 minutes because it won’t take long for identity provider to authenticate and redirect the user to service provider, its a matter of seconds.

   <wsu:Created+xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2019-02-03T05:33:21.118Z
   <wsu:Expires+xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2019-02-03T06:33:21.118Z

3. Forged Message Expiry – Try to forge the expiry of date and time and see if service provider accepts it. Below is the code to look in SAML.

   <wsu:Expires+xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2019-02-03T06:33:21.118Z

4. Different Valid User – Check if server accepts same assertion with different valid user id. Below is the line of code in which AttributeValue “SecureLoopholes” needs to be modified with some other valid user id which exists in identity provider

   <saml:Attribute+AttributeName="UPN"+AttributeNamespace="http://schemas.xmlsoap.org/claims">
   SecureLoopholes
   

5. Different Invalid User – Check if server accepts assertion with different invalid user id. Below is the line of code in which AttributeValue “SecureLoopholes” needs to be modified with some invalid user id which doesn’t exists in identity provider

   <saml:Attribute+AttributeName="UPN"+AttributeNamespace="http://schemas.xmlsoap.org/claims">
   SecureLoopholes
   

6. No Signatures? – Messages should always be signed with signatures. SAML authentication which lacks “signature” block is vulnerable to exploitation. Below is the signature tag one should look in SAML. If there is signature implemented in the message try removing it and sending the request. Check if it is accepted by the service provider.

   Long Random data

7. Signature CA – Signatures should be signed by a valid CA. If the signature is generated by a self signed certificate then there is a high risk. Attacker can clone the certificate OR generate a new self signed certificate. Try to generate a new signature with the help of SAML Raider tool and send the request to service provider with forged signature.
8. Different Origin – Signature designed for one service provider should not be accepted by any other service providers. Try capturing the request of one service provider login, copy the signature and replicate the same signature with other service provider. check if it passes.
9. Signature Wrapping – There is lot of signature wrapping test-cases which can be executed with the help of SAML Raider tools. In SAML Raider there are different methods to perform signature wrapping attack ranging from XSW1 to XSW8, try it out.