Blocking Office365 Attacks (CVE-2017-11774) with MFA
US Cyber command has recently published a security alert on Twitter regarding abuse of an Outlook vulnerability [https://twitter.com/CNMF_VirusAlert/status/1146130046127681536].
This vulnerability was originally found and reported by SensePost back in 2017 – see here: https://sensepost.com/blog/2017/outlook-home-page-another-ruler-vector/ A patch has been available since then, but the vulnerability is still being actively abused.
How does it Work?
It is an interesting attack vector, allowing remote code execution (RCE) given compromised Office 365 credentials: The exploit takes advantage of a feature of Outlook’s Home Page, which can open a web page each time a folder is opened in Outlook. Why would you want to do this? One example floating online is to have a quick link to SharePoint from inside the Outlook application. The is a legacy feature, which Microsoft’s security fix removed. This is an example of why legacy features are dangerous to keep in your software – a topic for a different blog. The home page URL is stored inside of the folder settings. Where are the folder settings defined? If the server is synced from an on-premises Exchange server, then on that server. If this folder is synced from Outlook 365, then from there. This attack vector exploits the sync from the Office 365 server to the actual computer.
How does this translate into a remote code execution attack?
Until now we have described how to open a webpage given access to the user’s Office 365 account. But how does this translate into a remote code execution attack? Given that the webpage is loaded by an Internet Explorer frame, the first course of action is to look at loading ActiveX controls. Although there are restrictions on which ActiveX controls can be loaded, the hackers found a way to work around these restrictions. There is an Outlook ActiveX control that is whitelisted to run in the sandbox. This is an object that represents the container running the current code, i.e., the Outlook application. This object has a function called “createObject”, which allows creation of any arbitrary object, including the “Shell” object. This final object allows execution of any application and thus enables escaping from the sandbox. This serves as a reminder that sandboxes are not bullet proof.
There are two key recommendations: First of all, be sure to patch all you users’ systems. A patch for this vulnerability was released way back in October 2017. There is no reason to leave any systems unpatched. In addition, we highly recommend enforcing MFA to block this and similar attacks: Enforcing MFA for users’ access to Office 365 accounts will stop this attack chain at its root as attackers won’t be able to authenticate with the 2nd factor and as a result, they won’t be able to access the Office 365 account. Even given the vulnerabilities in the Outlook application, access to Office365 is necessary to exploit the vulnerability and enable a remote code execution scenario.