Our Client’s Head of Security Raises Concerns about Lightning for Outlook (LFO)

We recently worked with a Hedge Fund client, which, like most in the industry, has very high security requirements especially around email. We recognize that financial services companies are not the only organizations that are highly regulated and a key target of hackers and other nefarious individuals on the internet.  

From this experience, we have learned many key elements of how Salesforce’s email integrations work, and we felt it was important to share this information with any Salesforce users who are utilizing the Lightning For Outlook (“LFO”) or other Outlook Integrations with Salesforce. 

The main area of concern for our client was the use of Exchange Web Services (“EWS”) used by Salesforce in order to pass the email contents, and more specifically any email attachments from the Exchange Server to Salesforce. 

Salesforce’s Method for Outlook Integration

Our client’s primary concerns included why Salesforce had to access the Exchange Server rather than just the Outlook client for this information. Our client provided a clever analogy on this matter, explaining that when you have a house you typically don’t place your house right on the street. Most houses are pushed back from the street and have front doors that are closed and locked. He further elaborated on this analogy, noting that the usage of EWS by Salesforce is, in essence, allowing a person to enter the front room of the house, but also providing full access to the rest of the home (even though only specific access is needed). He said Salesforce’s setup of EWS is the equivalent of placing your property directly on the street, thereby providing your house with the flimsiest of locks on the front door, and effectively giving access to your entire home.

Salesforce’s Response

Salesforce’s response included an acknowledgement that our client is correct, that this does open a security concern echoed by other clients. However, Salesforce still believes that its solution is secure. Salesforce asserts that exposing an EWS URL end-point on Exchange is often perceived as risky by customers for many reasons. They note that Exchange Online servers do have a standard EWS URL end-point that is perfectly safe per its out-of-the-box configuration. Salesforce also points out that it is not entirely fair to expect Salesforce to share best practices around Exchange server management (this is really Microsoft’s responsibility), further clarifying that the integration model has been vetted by Microsoft. That is why, according to Salesforce, customers are encouraged and liberally advised to refer to Microsoft for best practices around Exchange management practices, so that they can implement extra measures to mitigate any concerns regarding their specific needs. With all that said, Salesforce did acknowledge that they are continuing to follow up with Microsoft on this as they do deem it to be an issue with the method Microsoft offers to get access to Email Attachments. 

Salesforce recognized that enabling Internet Access to an Email Service like EWS is sensitive.

1. Salesforce did point out that the Authentication does not use the username and password of the Exchange user, so this was one area that provided more comfort to our client, because initial discussions with Salesforce Support did lead us to believe that they were using the user’s email ID and password to access the email. This still may be the case with Lightning Sync, but this is not the case for LFO. 
2. Salesforce clarified that the Outlook Integration uses a JSON Web Tokens (“JWT”) by exchange server hosted on-premise that produces JWT which is requested by the Salesforce add-in through Outlook. They further explained that the Office add-in framework released by Microsoft expects EWS end-points to be available for certain framework functions to be utilized.

This then produces an exchange JWT to send back to Salesforce. Salesforce also noted that the token has a limited time life (5 minutes) and scope (only the email the user has highlighted in his/her inbox), so the token cannot be used to access any other emails, or events from the user’s mailbox. 

Some Mitigation Steps Salesforce Suggested

Salesforce acknowledged that its clients do go to great measures to protect their exchange servers, like hiding them behind firewalls, and they understand how their approach would create issues for many clients’ security teams. In the current environment, they suggested two main considerations to address the current security holes: 

1. IP whitelisting all the IP’s that are owned by Salesforce (this was raised by our client, and Salesforce agreed that this is a large part of the internet, but not an ideal solution).
2. The second option seems to have much more merit, which includes creating a Python script on the firewall that listens to all incoming calls and deconstructs the packets looking at JWT to validate that the session is still open. 

Here are the links Salesforce shared with us after our session with them on this topic.

Information regarding the JWT
Functions that can be used to deconstruct the JWT
Linux Python WSGI that sits between the Firewall and Exchange server

What Salesforce Plans To Do To Address This Issue And What You Can Do To Help

Salesforce noted that this method of accessing emails and attachments is primarily an issue with how Microsoft supports access to attachments. Currently, the only way Microsoft offers this functionality is through an Office add-in from Office JS.  

Salesforce has asked Microsoft to enhance the Office JS library, so Salesforce would not need to access the Exchange Server, but so far Microsoft has not moved on this request. Salesforce did ask for support to get Microsoft to make this change. 

The bottom line appears to be that Outlook Integration from Salesforce is not 100% secure, and it would be wise to implement at least one of Salesforce’s currently proposed safeguards. We also recommend contacting Microsoft and Salesforce to continue pushing them to address this security hole as soon as possible.