Reviving Old CVEs - Reflected XSS in CA SiteMinder / SSO

Recently, I've been on a number of engagements where I've run into Computer Associate's (CA) SiteMinder product.  So, what is SiteMinder?  SiteMinder is an enterprise infrastructure product that enables centralized web access management system that enables user authentication and single sign-on, policy-based authorization, identity federation, and auditing of access to Web applications and portals.  SiteMinder pages usually have an extension of "fcc" but I've seen them wrapped in a number of different environments with various extensions.  A typical login.fcc page usually leverages a custom template but the default one looks like this:

When I first ran into the product, I Googled around and discovered two old vulnerabilities, CVE-2005-2204 and CVE-2007-5923.  Both of these were reflected cross-site-scripting (XSS) vulnerabilities so I figured it was worth exploring how these were fixed and if I could uncover a workaround or a vector they didn't see.  While researching how they fixed it, I discovered they implemented some configuration parameters for bad cross-site scripting characters (BadCSSChars) and bad URL characters (BadUrlChars).  A list of agent configuration parameters revealed what the default values were for these parameters and offered a brief description of all of them.  Here are the two relevant ones:

Parameter Name	Default	Usage
BadCSSChars	<,',>	A comma-separated list of characters to block due to use in XSS attacks.
BadUrlChars	//,./,/.,/*, *.,~,\,-%1f,%7f	A comma-separated list of character sequences to block from use in URL requests to prevent exploitation by malicious web clients.

Right away, the BadCSSChars parameter seemed lacking, with obvious omissions of backslash and double quotes.  I did see backslash in the default list of BadUrlChars so I started digging further into the documentation for how this filter was applied.  The documentation stated that the Web Agent will refuse URL requests that contain any of the characters or strings of characters that you include in this list. However, that checking is done on the URL before the "?" character.  That meant the backslash was in play for GET parameters.

With all of this in mind, it was time to start poking around various pages to see what parameters I could control that were reflected somewhere in the page. preferably somewhere in JavaScript, since I could use both double quotes and backslashes without issue.  The page mentioned in CVE-2007-5923 seemed like a good place to start.  Sure enough, just a few minutes of poking around revealed the "USERNAME" GET parameter is reflected in a JavaScript block.

https://www.example.com/siteminderagent/forms/smpwservices.fcc?USERNAME=[XSS PAYLOAD]&SMAUTHREASON=7

Both the USERNAME and SMAUTHREASON parameters are reflected in a JavaScript block and both are important for different reasons.  SMAUTHREASON dictates control flow within the JavaScript block.  This is important to get our code to execute, especially if there is a WAF in front of the application blocking double quotes and our ability to escape a string assignment and control flow ourselves.  Leveraging just a valid SMAUTHREASON and backslashes it's possible control the flow of execution and get XSS.  For example, the source code of the example URL above will contain JavaScript similar to this:

...[SNIP]...
//Auth Reason 7 - Account disabled
else if (7 == 7)
{
document.write("<TR>");
document.write("<TD NOWRAP WIDTH='100%' BGCOLOR='' height='26'>");
document.write("<font face='Arial, Helvetica'><B>[XSS PAYLOAD]</B> you cannot access your account at this time.</font>");
document.write(" </TD>");
document.write("</TR>");
} //Auth Reason - 7
...[SNIP]...

When this JavaScript executes in the victim's browser, it writes the following to the document object model (DOM):

<TR>
<TD NOWRAP='' WIDTH='100%' BGCOLOR='' height='26'>
<font face='Arial, Helvetica'><b>[XSS PAYLOAD]</b> you cannot access your account at this time.</font>
</TD>
</TR>

This is pretty basic to exploit.  Even with a slightly limited character space, we can leverage backslash and numbers to encode our payload and have use the functionality of the page to write it to the DOM.

For example:

https://www.example.com/siteminderagent/forms/smpwservices.fcc?USERNAME=\u003cimg\u0020src\u003dx\u0020onerror\u003d\u0022confirm(document.domain)\u0022\u003e&SMAUTHREASON=7

Would result in the following being written to the DOM:

<TR>
<TD NOWRAP='' WIDTH='100%' BGCOLOR='' height='26'>
<font face='Arial, Helvetica'><b><img src=x onerror="confirm(document.domain)"></b> you cannot access your account at this time.</font>
</TD>
</TR>

Simple XSS for the win!  Worst of all, it bypasses all browser XSS protections.

I found some different WAFs required some different encoding, sometimes "\u" or different key words, like "alert" or "script" would trigger them, but many could be bypassed with all the characters available to us, as long as backslash was accepted.  One of my favorite methods is using octal encoding instead of unicode since it's just a backslash followed by a number.

I found these endpoints were vulnerable consistently:

• smpwservices.fcc
• smaceauth.fcc

While many others were randomly vulnerable based on changes the individual developers made to various templates.

I reported this issue to Broadcom on July 12th, 2019.  Receipt was acknowledged but requests for updates have provided very little information.  Since there are a large number of vulnerable sites out there and many issue cookies to the parent domain (it's SSO, after all) I feel like it's important to make this known.  My recommendation for resolving this issue is to edit your "BadCSSChars" configuration parameter to block all of the following: ",\,',<,>,+