How to address security vulnerability with Cookie Provider redirects?

[Edmund Ashburner]

Apparently, there is a security vulnerability with Cross Domain Single Sign On (Cookie Provider).  With GET based requests at login time or during session update, the browser will redirect to the cookie provider with the SMSESSION recoverable by a hacker from just the request URL.  With SecureURLs=NO, the redirect includes an SMSESSION query parameter that can be replayed through the browser directly.  With SecureURLs=Yes, you will see SMQUERYDATA, but the whole URL can be copied to a browser and replayed to set the session cookie and redirect the user back to the original application.  A second redirect will then recover the Cookie Provider cookie and set one for the application and the hacker is in.  Note that even if the application uses and SSL/TLS (HTTPS) connection, the request URL itself is not encrypted over the internet and can be recovered in plain text and replayed without any need to break the HTTPS encryption.

According to a case opened with CA (01072531: Security Vulnerability with Cookie Provider), there are only a couple of options to close this loophole.  You can try to implement IP address checking for the session (TransientIPCheck=Yes, PersistentIPCheck=Yes).  This will prevent the request from being replayed by someone from a different user source IP address.  It is possible to spoof an originating IP address.  Also, this setting is not always possible as users sometime come from inside client networks that "NAT" the address from a pool.  From SiteMinder's perspective, the user is seen to jump between source IP addresses.  This setting will reject these users.

The second option is to implement a Session Store and use Session Validation to detect the shift of the users device.  According to CA support, there is no other way at present to prevent session hijacking when cross domain single sign on is used.  The use of a session store can be problematic across datacenters.  In addition, all application access is lost if the session store becomes unavailable.  My company has been trying to avoid this component for these reasons.

The documentation should be VERY clear on this point.

Also, redirects between domains should encrypt any sensitive data in the body of a POST request.  This is not how the web agents work today.  I request that CA consider a web agent upgrade to add this capability and a new configuration parameter similar to "PostCPRedirects" which can be used enable/disable it for compatibility and adoption purposes.

[Ujwol]

Hi Edmund,

 

If Ihe hacker could access the SMSESSION cookie from the URL , then it should also be able to access the SMSESSION cookie from the request/response , isn't it ?

 

The best full proof solution till date to avoid session hijack and replay with CA SSO is "Enhanced Session Assurance".

Have you considered implementing this feature ?

 

Regards,

Ujwol

[Edmund Ashburner]

Hi Ujwol,

 

With "SecureURLs=No" then SMSESSION cookie is in the redirect URL as a query parameter in form to be copied directly.  With "SecureURLs=Yes", the redirect uses encrypted SMQUERYDATA.  The hacker can't see the SMSESSION cookie in the redirect, but the whole redirect target can replayed to set the SMSESSION cookie in the hacker's browser.

 

Yes, we have been told that the only way to improve security is to follow the instructions for setting a session store and then using the session validation feature to ensure that the existing session is not being replayed by a hacker.  In addition, with a session store, once the user logs out, all hackers that might have been sharing a hijacked session would also be logged out.  It is a BIG deal to take an environment with many policies across multiple data centers and convert it to use a session store.  That is why I stated above that "The documentation should be VERY clear on this point." when new applications are considering cross domain single sign on to make it sufficiently secure from the start.

[Ujwol Shrestha]

I stil find hard to understand the case where hacker has the access to request URL but does not have access to other request headers ( e.g cookies).

But anyway, if not session assurance have you considered IP checking?

https://docops.ca.com/ca-single-sign-on/12-7/en/configuring/web-agent-configuration/user-protection/verify-ip-addresses#VerifyIPAddresses-CompareIPAddressestoPreventSecurityBreaches

Compare IP Addresses to Prevent Security Breaches

An unauthorized system can monitor packets, steal a cookie, and use that cookie to gain access to another system. To prevent a breach of security by an unauthorized system, you can enable or disable IP checking with persistent and transient cookies.

The IP checking feature requires agent to compare the IP address stored in a cookie from the last request against the IP address contained in the current request. If the IP addresses do not match, the agent rejects the request.

The two parameters that are used to implement IP checking are PersistentIPCheck and TransientIPCheck. Set them as follows:

• If you enabled PersistentCookies, set PersistentIPCheck to yes.
• If you did not enable PersistentCookies, set TransientIPCheck to yes.

CA Single Sign-On identity cookies are unaffected by IP checking.

 

[Edmund Ashburner]

Hi Ujwols,

 

When a user connects their computer to a site using SSL/TLS (HTTPS), the requests of "where" to go are transmitted in plain text over the internet to allow for proper routing.  The content of the requests (cookies, POSTED data, etc.) are encrypted.  Looking at any number of access logs or network traffic monitors can capture the plain text request URL even though the content sent is fully encrypted.

 

For the IP address restriction, please read the original post above....  It is not always possible to restrict a session to an end user's IP address.  For one, IP addresses can be spoofed.  In addition, some real user traffic may present more than one valid address based on their company's outbound proxy (among other things).  

How Network Address Translation Works | HowStuffWorks 

[Ujwol Shrestha]

For clients behind proxy, there is X-Forwarded-For headers which needs to be implemented so the agents always gets the actual client IP.

The idle/max time out values can be set to low value to ensure hacker doese get enough time to spoof IP address.

So far you have rejected all the possible solutions proposed.

What do you think would be the solution that would fit your purpose? 

[Edmund Ashburner]

Hi Ujwols,

 

We have hundreds of clients, each with their own network management infrastructure and staff.  It is not practical to try to get each of them aligned with our internal standards.  We are perhaps just one of many vendors they use.

 

Idle/Max timeout affect the real end user.  Setting Idle timeout to say "1 minute" to limit the amount of time a CA security vulnerability can be exploited requires the end user to be active every minute or they will need to login again...  This is also not a practical approach.

 

The suggestion we made in our support case was for CA to develop a redirect that uses a POST method similar to what is done during "Post Preservation".  As stated above, information POST'ed to a site is fully encrypted and thus can not be extracted or exploited without a full decrypting proxy Man-in-the-Middle attack underway.   (If you have one of those going on, there are more immediate considerations that just session hijacking.)  This was described above in the original entry...  see last paragraph that begins, "Also, redirects between domains should encrypt any sensitive data in the body of a POST request....."  This would require an agent update for both Web Agent and Cookie Provider, but at least it would be secure.

[Ujwol Shrestha]

Thanks. Makes sense. Thanks for clarification.

Please post this request in "idea" section for this to be considered by PM.

[Mark ODonohue]

Hi Edmond

 

1. Just a quick note - this statement is not really correct : 

Note that even if the application uses and SSL/TLS (HTTPS) connection, the request URL itself is not encrypted over the internet and can be recovered in plain text and replayed without any need to break the HTTPS encryption.

 

The URL is sent over the SSL/TLS session and is not visible unless someone has the ssl session keys. 

 

The hostname is visible since a socket connection SSL?TLS  is make to the host name www.example.com  to then negotiate the SSL handshake.  But the contents of the URL :

https://www.example.com/someuRL/?SMSESSION=***&OR=OtherParam  

is sent over the SSL/TLS encrypted channel and is not in visisble in cleartext. 

 

There is a preference for POST data rather than GET parameters since GET parameters like the above are logged in access_logs and the like on the server, whereas POST data or cookies are not (unless you put in specific rules).

 

That is what I think you are probably alluding to. 

 

 

2. Cookie providers domains

 

There is also ACO parameter validtargetdomain where you can restrict the domains where the cookie provider will return to, and there was some internal mechanism in the cookie itself to ensure those were generated for the right target when returned (my experience is with case where request was forward internally and they did not match).  

ValidTargetDomain  Help Prevent Attacks - CA Single Sign-On - 12.52 SP1 - CA Technologies Documentation 
TrackCPSessionDomain  Configure Web Agent Single Sign-On Settings - CA Single Sign-On - 12.8 - CA Technologies Documentation 

 

There is also similar mechanism for different zones and cookies in place.

 

I know this has been gone over quite a few times internally from security perspective - particularly in the latter versions and fixes were added - and that they are fairly confident that the method is safe. 

 

 

3. Cookie validity time 

SSO cookies are valid until idletimeout is reached, (unless you have a session store).   So usually  the cookie is "active" for 10min or so before it becomes stale.   If someone has access to your cleartext stream (including URL for redirects to cookie providers) then they can use the stolen cookie for that idle timeout time.

 

The methods like device DNA, and IP check are meant to be additional guards on the session cookie coming from some other source during that idle timeout period. 

 

 

Having said that that idea of using POST rather than GET QUERY parameters is not unreasonable.   And I'd suggest to raise it as an "Idea" in thie forumn (that is already done for postpreservationdata anyway).    But a 302 redirect is understood by even basic web clients, whereas a generally to do a POST to a different domain you needed to invoke some javascript on the client (there is also recently a 307 redirect web development - Why doesn't HTTP have POST redirect? - Software Engineering Stack Exchange ) .   

 

My suspicion however, is that they will keep the GET for cookie providers and slowly move to a more federated method for doing these cross domain relationships as the preferred approach.

 

But also if you have specific example of vulnerability then it is probably best to raise a case with the penetration test that is used, then we can follow it up with the security team.  

 

 Cheers - Mark

[Edmund Ashburner]

Thanks for the reply Mark,

 

Yes, I agree that the primary concern is with logging of the request in access logs, etc.  There may be several places where this information is logged and recoverable.  Certainly the local browser history on the end user's device, perhaps the client company's internet proxy, perhaps the destination service provider's load balancer (that might un-encrypt and re-encrypt the traffic), the destination web server log, and if any of these logs are forwarded to log monitoring systems, then those too.

 

Track CP Domain just prevents a cookie from being used on a domain for which it was not intended....  but if you set the domain for ".MYCOMPANY.COM" for SSO across the enterprise, then this does very little.

 

Session validity of limited value as it primarily would affect the end user...  how long can they remain idle before they need to re-authenticate.  Set it to 30 minutes, and then any recoverable link can be replayed in that time.

 

The penetration test that cited the vulnerability was pretty general.  They use a full decrypting proxy to inspect traffic and look for vulnerabilities (full Man-in-the-Middle).  The finding that sensitive URL was able to be replayed was based on attempts of using the URLs as if they were recovered from the logs or browser history or a traffic monitoring environment.

 

I'll make an entry as you suggest in the "Idea" forum and see where that goes.

 

Edmund