CloudSOC CASB Gateway

Overview
Recently, Elastica Cloud Threat Labs discovered a security issue in one of the subdomains of Salesforce used for blogging purposes. This vulnerability in “admin.salesforce.com” could have been exploited by attackers to hijack Salesforce accounts or to distribute malicious code to the users. This subdomain was vulnerable to a reflected Cross-site Scripting (XSS) vulnerability where a specific function in the deployed application failed to sanitize and filter the arbitrary input passed by the remote user as a part of an HTTP request. As a result, the attacker could have executed JavaScript in the context of the application, thereby impacting the privacy and security of Salesforce users. Furthermore, all Salesforce accounts for different applications (including cloud) were at risk because Salesforce uses Single Sign On (SSO) for managing multiple accounts.

Vulnerability Exploitation Cases

• The attacker could have  executed JavaScript to steal cookies and session identifiers, which could lead to a potential Salesforce account takeover depending on Same Origin Policy (SOP).
• The attacker could have forced Salesforce users to visit phishing sites to potentially extract credentials via social engineering tricks. The attacker could have also also injected pop-up windows to facilitate Phishing attacks, which we are going to demonstrate in this blog post.
• The attacker could have  forced the users to download malicious code on their machines by executing unauthorized scripts in the context of the browser running a vulnerable application.

Vulnerability Validation

We validated the vulnerability using a step-by-step process. In-depth validation allows us to understand the risk and impact of the vulnerability. 
Step 1: At first, we supplied the arbitrary input to the vulnerable component. As expected, the application reflected back the content as shown in Figure 1.

Figure 1: A Simple HTML Content is Reflected Back by the Server

Step 2: Since the application is reflecting the HTML content, the next step is to test for potential Document Object Model (DOM) injections, a variant of XSS to see if we can extract the cookie using JavaScript. The idea is to validate whether the scripts can be executed from the same domain hosting the vulnerable application. Figure 2 shows the successful output of the “document.cookie”.

Figure 2 : Successful Execution of DOM Injection to Extract Cookie with Session Identifiers

It was also possible to inject JavaScripts from third-party domains, which get executed in the vulnerable application.

Exploitation Use Case—Phishing Attack Demo

To show the impact of this vulnerability, we created an effective Proof-of-Concept in which we highlighted how easy it would have been  for attackers to conduct Phishing attacks using this vulnerability. To be clear, all the PoCs for this vulnerability were reported to Salesforce as a part of the responsible disclosure process.

Step 1: We authored a well-designed pop-up that is almost similar to the login prompt provided by Salesforce when a user wants to log in to “hxxp://login.salesforce.com”. Figure 3 shows the layout of the pop-up that we designed for this assessment. You can still perceive the differences between the test and original pop-up. However, this pop-up is substantially similar to the original one.

                       Figure 3: A Custom Generated Salesforce Login Prompt for Demo Purposes

Step 2: Since we are able to inject JavaScripts from a remote location, it becomes quite easy to inject a pop-up in the primary webpage of the vulnerable application. We hosted the JavaScript on a third-party domain and passed it as a part of an injected JavaScript. Figure 4 shows the JavaScript rendering properly and triggering the pop-up.

Figure 4: Injected JavaScript Executed Pop-up in the Vulnerable Application

Step 3: In this step, we submit the demo credentials in the injected pop-up as shown in Figure 5. This is a demo test so we simply pass the credentials in the HTTP GET request, which in fact is an insecure way of passing credentials. For demo purposes, it works as expected.

Figure 5: Demo Credentials are Passed to Analyze the Phishing Test

Step 4: Once the credentials are submitted, they are passed onto the Web server, which distributes the notification email as shown in Figure 6. Attackers commonly mail or store credentials when exploiting new users during a Phishing attack.

Figure 6: Notification Email Showing Successful Delivery of Credentials

Disclosure

The vulnerability was disclosed to Salesforce more than a month ago. Salesforce considered it less severe because this vulnerability is not present in the main “salesforce.com” website. Rather, it is in a subdomain. According to Salesforce, the impact is low because only selected users can be targeted. However, we believe that this vulnerability has the potential to be exploited in the wild as shown in the earlier PoC, which could lead to potential account takeover since the primary domain is “salesforce.com”. We sent another email to Salesforce before releasing the details so the vulnerability could be mitigated accordingly. As a result, Salesforce addressed the issue and the vulnerability has been patched.

Conclusion

This XSS vulnerability could be dangerous if exploited. In this case study, the vulnerability was not present in “login.salesforce.com” but in another subdomain of Salesforce. However, since the primary domain is “salesforce.com”, this trust can be exploited through phishing attacks by tricking users into providing their legitimate credentials. With SSO accounts, the threat extends to all the accounts including accounts used for cloud applications.