Recently I was having a discussion with some folks about Web Security and amongst some of the items discussed was Single Sign-On. It reminded me of SiteMinder and some things that bothered me about how some organizations utilize the solution. Especially the blind reliance upon the vendor to have written a secure solution rather than verifying if this technology is being employed correctly.
Sometimes its not the software created it is the folks that configure it that cause the headache. Sometimes the biggest flaw is inherent because of the very nature for which the software was intended to be used in the first place. When you configure this incorrectly AND you do it at the Single Sign-On server level it can literally be an "epic fail". In a large organization it can potentially leave hundreds or even thousands of sites open for compromise.
So I first noticed the odd configuration and therefore the potentially insecure nature of SiteMinder approximately 1 year or so ago (can't remember, could have been longer). I thought I would share some of details with you the reader to give a better idea of where some of the pitfalls might exist and maybe this helps someone who is charged with installing/configuring the SiteMinder solution in the future. I really don't believe this could be ONLY a SiteMinder specific issue. My personal belief is this can hold true for any Single Sign-On solution if improperly managed.
Now keep in mind I am not a full-time researcher. That being said, this is simply what I've observed. Also, I encourage anyone reading this to invest some time playing around with the technology. Don't just take my word for it. I will not detail the EXACT steps for correct configuration but more of a broader approach to where things I've seen things go wrong and some proactive steps to take.
First lets talk about the benefits of SiteMinder SSO:
1) Can be used as a means of verifying and/or restricting the user before ever viewing the application. As an attacker I may not need to be logged in to cause damage. So having anonymous access to the unprotected portion of your site could still be used as a launch platform for another attack such as XSS, SQLi, abuse of account registration, password recovery, default content discovery.... etc, etc.
2) Can be configured to require two factor authentication.
3) Has the ability to provide either two-factor authentication (Common Access Cards) OR if your users do not have access to CAC equipment this allows for form based authentication as well. So it is convenient.
4) A bit more difficult to brute force login credentials AND can enforce account lock-out while mitigating other security concerns like registration, etc. However, this is a very general statement and in many cases isn't implemented correctly.
5) Simple account management. This doesn't requires a user to remember, or jot down on a sticky pad ;-), their user-name and password to a large number of applications.
Lets detail some of the drawbacks:
1) The solution is not infallible but in the cases I've come across is treated as such.
2) If one site fails at any number of things other sites can become targets of attack and possibly victims of a compromise.
3) The user privacy issue. ESPECIALLY when employing CAC / PKI authentication. The data held on a user's Common Access Card can be logged on the web application they are using and in some cases most certainly is (for troubleshooting purposes?).
The data within their CAC can hold valuable information about the individual that certainly wouldn't allow anyone to view, so why would a web app developer need this information to the purposes of troubleshooting the SiteMinder solution? This basically boils down to trust I suppose and I'm sure can be argued in length about.
Details of the SiteMinder authentication (what I've observed):
1) A user requests target URL https://example.bigcorp.com
2) User is then redirected to https://ssoserver.bigcorp.com
3) The user submits a request with https://ssoserver.bigcorp.com/SmMakeCookie=xxxxxx
4) The ssoserver site is checking to see if we already have a valid session.
5) The normal response is to set a HTTP 302 method with a redirection to https://example.bigcorp.com with a parameter SMSESSION=NO. This basically tells the applications that this user does not have a valid SiteMinder session and must authenticate.
6) At this point https://example.bigcorp.com provides a HTTP 401 (authorization required) message and sets the browser's cookie as SMCHALLENGE=YES.
Now keep in mind, these are two different sites so the SSL stream is broken by default and because of this it will work even if one application does not employ SSL. This is important when dealing with sites that have “Forceful Browsing” vulnerabilities or simply not using SSL.
7) So now the user's browser sends a request to https://example.bigcorp.com with basic authorization and a cookie - SMCHALLENGE=YES.
8) The response from https://example.bigcorp.com is a redirection (HTTP 302) to https://ssoserver.bigcorp.com with the session value in the query. For example, https://ssoserver.bigcorp.com/smmakecookie.ccc?SMSESSION=SM-ABC123&PERSIST=No&Target=https://example.bigcorp.com
NOTE: This is bad. This value is sent in the header of the request and is now stored in three separate locations. 1) Proxy logs 2) Server side logs 3)In the users browser. Additionally, this value is your “Master Key” AND in may cases is not set to expire for some time for user friendly purposes.
9) Simultaneous with Step 8, https://example.bigcorp.com is now performing a
set-cookie= SMSESSION-ABC123 ; path=/; secure
and this is within the 302 redirection response. So take note that the secure flag is set and the path is for the example.bigcorp.com BUT no HttpOnly flag. This means that client side Javascript can interact with the cookie.
10) So as stated previously in step 8 we are sending a GET request to https://ssoserver.bigcorp.com/SMSESSION=ABC123&PERSIST=No&Target=https://example.bigcorp.com
NOTE: The target value has special characters URL encoded.
11) The response from https://ssoserver.bigcorp.com is a redirection (HTTP 302) to https://example.bigcorp.com with a set-cookie= SMSESSION-ABC123; path=/; domain=bigcorp.com; secure
12) The user's browser sends a request to https://example.bigcorp.com/login.aspx
The referrer is set as example.bigcorp.com and now two SMSESSION cookie values are provided/set. In this initial request both SMSESSION values (cookie) are set as SMSESSION-ABC123 and passed to the application in the subsequent request.
13) Now the user is redirected via a HTTP 302 to https://example.bigcorp.com/protected/default.aspx and the new SMSESSION value set following the first request is XYZ123. Remember the user will always pass two SMSESSION values. One of those values is the “Master Key” SMSESSION-ABC123 and SMSESSION-XYZ. For all subsequent requests to resources on example.bigcorp.com the SMSESSION value will be checked. If you have this value then you are allowed into the site with the caveat being that your ssoserver account must have permissions to view this application.
Security Concerns:
1) XSS will allow anything bigcorp.com to be taken, which of course includes the “Master Key” SMSESSION value which is stored as a bigcorp.com cookie value. CAVEAT: XSS must be performed on a bigcorp.com site; otherwise the domain mismatch will not allow the cookie value to be stolen. An attacker can replay this cookie/query value to gain access to a list of *.bigcorp.com sites (details - Number 6)
2) The SMSESSION value is stored in the browser cache due to the fact that a GET request was sent with the value in the header.
3) Usually this value does not expire for quite some time.
4) If the application does not enforce SSL this value will be shown in clear-text across the wire.
5) Due to the fact the HttpOnly flag is NOT set, Javascript can interact with the cookies.
6) Any application the user has access to can become a potential target. The applications which employ the SiteMinder agent will check to see if the user already has a valid SiteMinder session. If the Master Key (SMSESSION-ABC123) is employed, the ssoserver.bigcorp.com will recognize this as a valid SMSESSION when the attacker’s browser is redirected to the ssoserver for an active session validation. Once the ssoserver determines the cookie value provided by the attacker is a valid session value the attacker is given the necessary SMSESSION cookie for accessing the target web application.
7) The SMSESSION value, in all of the instances for which I’ve observed, are not salted by IP nor limited by session. This means simultaneously a user in Egypt can access an application utilizing the same SMSESSION value a user in Canada is currently using.
No comments:
Post a Comment