Cross-site scripting vulnerability uncovered in Salesforce cloud

Cross-Site Scripting (XSS) vulnerability within a Salesforce subdomain now patched

Millions of Salesforce users targeted by Dyre malware
Millions of Salesforce users targeted by Dyre malware

Researchers at cloud application security vendor Elastica have published details  of a Cross-Site Scripting (XSS) vulnerability within a Salesforce subdomain providing the potential for attackers to use a trusted Salesforce application as a platform for end-user credential gathering attacks.

Disclosed in early July, Salesforce finally patched the vulnerability on Monday just two days before Elastica went public with the disclosure. Admittedly, XSS vulnerabilities are not the most exciting of attack vectors, but that doesn't mean they are not dangerous. Nor does it mean that organisations shouldn't know better when it comes to detecting them.

Heck, the Salesforce developer pages themselves even have a section dedicated to preventing XSS attacks  which states "Most applications that display dynamic Web pages without properly validating the data are likely to be vulnerable. Attacks against the website are especially easy if input from one user is intended to be displayed to another user. Some obvious possibilities include bulletin board or user comment-style websites, news, or email archives."

Oh the irony. XSS is becoming both more frequent and more dangerous as an attack vector year on year. Frequent because XSS vulnerabilities are pretty easy to spot (oh the irony again) and dangerous as they are also easy to exploit, and exploit with similar outcomes to SQL injection attacks for example. The bad guys would rather take the easiest route on offer, and for many that appears to be XSS right now.

In the case of this particular XSS vulnerability, because it existed in a real Salesforce subdomain 'admin.salesforce.com' the chances are pretty high that any end user on the receiving end of a phishing email from that URL would not identify it as malicious, nor would  it have been detected by anti-phishing filters as being bogus. Dr  Aditya K. Sood, lead architect of Elastica Cloud Threat Labs, speaking to SCMagazineUK.com explained:  "XSS vulnerabilities in cloud service providers' websites can be exploited by attackers to steal end-user SSO credentials, which further results in account hijacking."

So, does that make this particular vulnerability particularly dangerous? "In this case the vulnerability persists in a subdomain of Salesforce and, due to the presence of Same Origin Policy (SOP), cookie stealing attacks are not possible because SOP treats “login.salesforce.com” and “admin.salesforce.com” as separate hosts" Dr Sood says, adding: "However, the vulnerability is severe because it allows the attacker to inject any arbitrary script from a third-party domain to execute on “admin.salesforce.com” as reflective content."

So, for example, Elastica Cloud Threat Labs created a Salesforce login popup and injected it through a control point. With a proper socially-engineered phishing attack, users could be directed to open the URL embedded in the phishing email, which then executes the attacker-injected script and triggers a Salesforce login popup, causing unsuspecting users to fall for this attack. "One important thing that must be addressed" Dr Sood concluded "is that the vulnerability is exploited in the application hosted on the Salesforce subdomain by injecting JavaScript and users are redirected to the same application and not to any custom application hosted by the attackers." It becomes a matter of trust, and the trust between users and Salesforce can be pretty easily exploited by the attackers in such a scenario.

Because the vulnerability existed in a subdomain, versus the primary Salesforce website, Salesforce considered it a low-impact threat. Hence the relatively lengthy period of time between disclosure and fix. The admin.salesforce.com subdomain was actually used by Salesforce for blogging purposes. It was susceptible to a reflected Cross-site Scripting (XSS) vulnerability, whereby a specific function in the deployed application failed to filter the arbitrary input passed by the remote user as part of an HTTP request. Salesforce itself uses Single Sign On (SSO) so enabling users to easily access a variety of integrated applications through that central login; a login that could provide access to a variety of services were a phishing attack successful, and potentially multiplying the effects of any breach.

We asked Richard Kennedy, head of cloud computing at Cloud Simplified, whether the fact that the XSS vulnerability was found in a cloud-based service actually made any difference to the threat posed? "An XSS vulnerability exists within the code of an application that a remote attacker exploits and leverages, (makes it) possible to obtain personal, commercial or financial information" Kennedy explained, adding "As the vulnerability exists at a software level, the platform is irrelevant because the same risks exist regardless of the platform whether it shares hosting, traditional dedicated or cloud based hosting."

And how can organisations best defend against the exploitation of such cloud-based XSS vulnerabilities? "Companies can help to mitigate risk by performing regular vulnerability and penetration scans to help detect flaws, allowing the developers to take pro-active action to ensure that their data, systems and customers information is secue" says Kennedy.

Iin an email to SC TK Keanini, CTO at Lancope added: “This is top notch research and responsible disclosure. The only concern I had was the statement from Saleforce.com whereby it is not a high priority because it only effected a small set of users?  I hope this is someone who just misspoke because for those users, it is a priority.  And priority over what else?  Meaning the statement makes it sound like there are even more critical weaknesses than this one occupying resources and that is not an accurate inference I'm sure – or lets hope."