Microsoft Office Add-ins, Reason for Concern?

This question came into Compass IT Compliance from a client the other day: “How risky are 3rd party plugins? Should I be concerned about them?”. I had to stop and think about this for a while. In my years of working on vulnerability and penetration testing projects for Compass IT Compliance, I had never run across any threats related to 3rd party Microsoft Office add-ins. Naturally, I headed over to my trusty Google Search Engine and started researching information about these objects. Not surprisingly, I didn’t find a lot of documented risks. Delving a little deeper into Google, I found this Microsoft documentation regarding security and privacy of Office add-ins.

Reviewing this document revealed that Office add-ins run in a mostly isolated sandbox-type runtime environment. Access to the UI (user interface), CPU (central processing unit), memory, and network resources are limited and/or governed by this runtime environment. Access to modal functions (e.g. JavaScript calls such as alert, confirm, prompt) are not allowed. This limits the add-in’s ability to interface with the OS (operating system), other applications, or the user. These are all good ideas and can make exploiting the OS very difficult through the use of add-ins.

However, I was able to uncover an existing phishing exploit that utilizes a malicious add-in to compromise a user’s Outlook account. In this scenario, the attacker sends a traditional phishing email that contains a link to a SharePoint or OneDrive document using social engineering to tempt the recipient into clicking on the document. Recently, I have personally received several of these types of messages. Clicking on the link brings the user to a legitimate Office sign-in page (if not logged in already). After logging in, the user is presented with the following (or similar) permissions dialog:

A quick review of the requested permissions should send any security professional into a coma. Granting these permissions gives the application full rights to your Office account. Even worse, those rights are maintained even if the user changes their password (first step in most account compromise situations).

You may ask, how this is possible considering the runtime environment designed for add-ins? The attack takes advantage of two basic flaws in the add-in installation process. The first is the Microsoft feature that allows any user to install any add-in by default. The second is essentially a user vulnerability as the attacker is counting on the user to simply accept the app permissions.

By default, all users can install any Office add-ins from any source. Most add-ins are simply a web object that a user can click on and install. This installation process is known as sideloading. Since all users can install add-ins, sideloading the add-ins works within the user’s security scope. The only security check is typically the request permissions dialog. Once the user grants access to the requested permissions, the only way to make changes is to uninstall the add-in completely. Microsoft reviews add-ins provided through their AppSource stores (Exchange, Outlook, Office, SharePoint), but since there are no restrictions placed on the installations by default, malicious add-ins can be installed from any source, even ones controlled by the attackers. The good news is that the default installation settings can be changed and access can be limited to trusted add-in catalogs. There are several places that these settings must be changed and they can be distributed through Group Policy Objects. (See https://docs.microsoft.com/en-us/office/dev/add-ins/concepts/privacy-and-security for more information.)

The second weakness exploited in this attack is the end-user. Requested permissions dialogs are very common on mobile devices. However, in most cases, the user simply accepts the requested permissions without actually reading and understanding the access that the application is going to use. A good information security awareness training program should cover these situations. If yours does not include app permission education, I suggest including it in the next course. Better yet, create a quick module and share it with your users today. The more frequently end-users receive security awareness training, the better prepared they will be to make the right decisions when they arise.

Microsoft Office add-ins themselves have limited capabilities to cause harm to the operating systems and applications running on a device due to the add-in runtime environment. However, the permissions granted to an add-in could allow unwanted access to resources and documents. I recommend limiting add-in installations from trusted sources only. If possible, do not allow add-ins to be installed except by administrators and only after a review of the permissions and functionality is conducted. I also recommend adding application permission request education to your end-user information security awareness training material.

Contact us today to learn more about this topic and to discuss our Security Awareness Training and Office 365 Security Assessment solutions!