A Tale of Breaking SAP's SuccessFactors's XSS Filter

TL;DR: 

'-confirm(1)-' was enough to break SAP's SuccessFactors's XSS filter and were able to make hundreds of web applications vulnerable ... 

Earlier this year, SAP invited me for a talk in their SAP Product Security Expert Summit (March 19th & 20th, 2015) held at Walldorf, Germany. It was an invite only conference and security team members of SAP around the world were there. As soon as I got the invitation for a talk, I started thinking that it would be great if I will be able to break something that belongs to SAP in front of their security and research team members. 

I started browsing SAP's main web application and ends up on their Talent Community site. The URL that catches my attention at that time is given below:

https://jobs.sap.com/talentcommunity/login/?returnurl=   

The first thing I injected as a value of returnurl GET parameter was a harmless probe string i.e., "xxxxxxxx'yyyyy</img. The URL looks like ...

https://jobs.sap.com/talentcommunity/login/?returnurl="xxxxxxxx'yyyyy</img

The probe string reflected back on the page 11 times (one time as a part of action attribute of the <form> tag while 10 times inside the script block). The following screen-shot shows the reflection of harmless probe string inside the script block. 

The reflection shows that our probe string ends up as a part of if condition and a variable loginfromReturnurl inside the script block. In all these cases/sinks (i.e., variable declaration and if condition) inside script block, developers were using single quote and reflection shows single quote that're part of a probe string not filtered or encoded or escaped while </ was also there in hardcoded form. The game is over here because developers were not controlling ' as well as </. The attacker may use ...

1. </script><script>alert(1)</script> 
2. '-confirm(1)-' 

Lets start with the first choice. The URL will looks like ...

https://jobs.sap.com/talentcommunity/login/?returnurl=</script><script>alert(1)</script>

I was expecting that the payload will work in a neat and clean manner but it was not. The reason can be seen in the following screen-shot. 

I will come to the bypass later (I think most of you can easily figure out at this point) but now lets see how this filter works. I was curious to see how hard it is and how it works because after all it is SAP's SuccessFactors's XSS filter.  The next payload I tested was a commonly used XSS vector <img src=x onerror=alert(1)>. In the following screen-shot, you can see the filter output.

One can observe that the part of above payload i.e., onerror=alert(1) becomes XSS-VIOLATIONXSS-VIOLATION while <img src=x was unfiltered. The next thing, I tested was again the above payload except I changed alert(1) to confirm(1) and now see the output below. This time you will see only one time XSS-VIOLATION and confirm(1) was there in the reflected output. It shows that they're doing black-listing of hard-coded keywords e.g., alert(1) was filtered while confirm(1) was not.

Lets continue to figure out what they're filtering and what they had missed. It was fun playing around. The next payload was <a href=javascript:confirm(1)>click</a>. The screen-shot shows that the keyword javascript was filtered.

Lets see the filter behavior by encoding the letter a of the keyword javascript. I used decimal encoded form of the letter a i.e., &#97. As I mentioned earlier, that we're dealing with GET parameter so the URL encoded form will be %26%2397 and once the payload will land in the DOM it will looks like: <a href=j&#97vascript:confirm(1)>click</a>. This is a valid XSS vector and works in all browsers. The XSS filter missed it and the working payload reflects back. In short, the keyword javascript was filtered but encoded form was not (though I only encoded the letter a of keyword javascript).  In short, the following payloads were not filtered.

• <p onmouseover=prompt(1)>IamParagraph</p>
• <details ontoggle=confirm(1)> (see https://twitter.com/soaj1664ashar/status/589672390076006400)
• <input type=search onsearch=confirm(1)> (see https://twitter.com/soaj1664ashar/status/589815633258381313)
• and many more 

All these payloads were able to bypass the filter or have the potential to bypass the filter but under the current situation (by keeping in mind the input reflection) where injected closing script block i.e., </script> becomes XSS-VIOLATIONS (as described earlier and can be seen in one the earlier screen-shot), payloads did not work because once I will be able to close the script block prematurely then I can make use of any of the above mentioned payloads. The problem was that </script> becomes XSS-VIOLATIONS. I tried other valid tricks for closing the script block like ...

/* I have at least 2 examples from very popular sites where the following variations of closing script block works while simple </script> does not */

• </script%0a> 
• </script -_->
• </script anythinggoeshere>    

but failed. But who needs < and > signs/characters when input reflects back in the script block inside the sandbox of single (') or double quotes (") and at the same time single (') or double quotes (") were not filtered or encoded or escaped. Now lets go back and see the reflection of probe string again in the following screen shot.

The developers were using single quote (') as a part of if condition and inside the if condition our probe string reflects back and single quote (') (i.e., part of probe string "xxxxxxxx'yyyyy</img) was there in its hard-coded form. The final attack payload looks like ...

'-confirm(1)-'

The first ' of the payload will break the context and then minus operator followed by a function call followed by a minus operator and payload ends on '. Inside the if condition, it is evaluated as an expression and during expression evaluation a function call (i.e., confirm(1)) is made. In JavaScript you can subtract anything from anything and it won't care. You can also use other operators like +, *, || and ^ etc. So here is an XSS in SAP's web application.

SAP is third largest software maker and if it is SAP's product or SAP is using it then definitely it may be found on other sites. I realized during email conversations with the SAP security team that this XSS filter belongs to SuccessFactors. SuccessFactors is a leader in providing cloud based human resource solutions, according to their website. As per information from the customers and about sections of their web application, they have around 4000 customers. 

I wanted to identify other sites that're using this particular XSS filter and for this purpose I used Google's inurl operator and NerdyData (a source code search engine). In my opinion (you may disagree), Google's inurl operator and NerdyData are a lethal combination for the identification of other vulnerable sites. For example, I queried the following by keeping in mind SAP's URL structure at that time and by looking at the other URL points in the XSS filter client-side JavaScript code. 

• inurl:talentcommunity/login/?returnurl=
• inurl:talentcommunity/subscribe/

The above two queries via Google's inurl operator almost gives back more than 200 unique results (the number may vary). At the same time, on NerdyData I queried the following string that was part of the filter code ...

//TODO: CSRF Token -- Removed from ajaxSetup headers parameter

It resulted in almost 179 entries. After spending sometime on the results of Google's iunrl and NerdyData, I compiled a list of almost 100 popular and unique sites that're using this XSS filter. The list is available here (in case you guys will find something in this XSS filter...). For proof of concept, I prepared a screen-shot that shows XSS in 39 sites. It includes big names like KPMG, CISCO, VISA, Sprint, SunTrust, Ericsson, Johnson & Johnson, Weather, Booz Allen Hamilton, Royal Mail Group and Singtel etc.  The screen-shot is given below.

SAP took almost three months in order to fix it and SAP acknowledged my name as a part of their July 2015 acknowledgement announcement. Once they had informed me about the fix, I thought lets look at the fix and this time found redirect (but it requires user-interaction) in the same returnurl GET parameter. The URL at the time of redirect looks like ...

https://jobs.sap.com/talentcommunity/login/?returnurl=//google.com

SAP now had fixed this redirect case. I also found number of bugs in SAP Enterprise Portal and I will later write about it once SAP will fixed them. I will conclude on a saying (pretty much summarizes the state of cloud) by keeping in mind that SuccessFactors provides cloud based solutions ...

"First one bug to rule them all and then one fix to cover them all ..."