The Importance of Updating the Exchange Online Remote PowerShell Module

A recent episode of the popular Risky Business infosec podcast titled “Good Microsoft, Bad Microsoft” discusses a security vulnerability in a PowerShell tool used to manage Exchange Online. I have listened to the podcast twice (once the first time, and then a second time to make some notes for this article) and it seems they’re referring to the Exchange Online Remote PowerShell module, aka EXOPS.

The security issue is basically a lack of proper certificate validation that leaves EXOPS vulnerable to man-in-the-middle (MITM) attacks. An attacker could hijack an authentication token from the session, which would be valid for up to 10 minutes, and perform administration tasks with all the privileges of the authenticated user.

There’s a bit of a story in the podcast about the difficulties that the individual who found the bug encountered while trying to get Microsoft Security to acknowledge that it was a legitimate issue. We all understand MITM risks are a serious problem, no matter how slim the chances of exploit under different scenarios may be. And when the vulnerability is caused by something as fundamental as certificate validation, it should obviously be fixed. Which it eventually was, after Patrick Gray (the Risky Biz podcast host) helped the individual escalate their report through some different channels. Although the vulnerability has been patched and an updated released, there is no public security notice for the issue.

That said, the point of this article is not to debate Microsoft’s response to the vulnerability report. Instead I want to focus on the implications for customers who use the Exchange Online Remote PowerShell Module.

The first PowerShell-based administration for Exchange Online in Office 365 involved connecting to EXO using PowerShell remoting. This process worked fine from an administrative perspective, but lacked support for security measures like multi-factor authentication. Microsoft resolved that by releasing an Exchange Online Remote PowerShell module that supports modern authentication.

The EXOPS module is available today either by going to the preview URL (which still works, and downloads the installer), or by launching the installer from within the Exchange Online admin center in the Hybrid section.

The EXOPS installer connects to a Microsoft URL and downloads the bits to install the module on your local computer. A desktop icon is created as well so that you can launch the EXOPS module in a PowerShell session.

One of the first things that admins do is look for a way to import the module into their own scripts to avoid using the desktop shortcut. If you know exactly where the DLL file is, you can import it easily with Import-Module. If you don’t know the exact path, there are many tips available via a Google search with easy solutions such as this one:

PS C:\> Import-Module $((Get-ChildItem -Path $($env:LOCALAPPDATA+"\Apps\2.0\") -Filter Microsoft.Exchange.Management.ExoPowershellModule.dll -Recurse ).FullName|?{$_ -notmatch "_none_"}|select -First 1)

Although that solves the problem of importing the module into custom scripts, it introduces a new problem that is particularly relevant in light of the security vulnerability mentioned earlier.

When you launch EXOPS from the desktop shortcut, it automatically checks for updates.

By accepting the updates you’ll receive the latest bits that include the fix for the security vulnerability. Of course, you don’t know how important it is to accept the update, because there’s no security notice published and nothing in the update dialog to indicate the severity of any vulnerability that the update fixes. If you’re in a hurry to complete a task, skipping the update would be a natural reaction.

But when you import the module directly into scripts, no automatic update check is performed. You will continue using out of date and potentially insecure bits when running the Exchange Online Remote PowerShell module. On one of my computers I found three separate DLL files with two different version numbers; 16.00.1559.000 and 16.0.1773.000.

After updating the EXOPS module on the computer the version number 16.00.1935.000 was shown for the DLL file instead. Unfortunately one of the older DLL files remained on the system, which leaves the risk that an Import-Module command might be pointed at the older DLL file. Given that I updated after listening to the podcast, which is after the security vulnerability was patched without notice, we can assume that version 16.00.1935.000 is the minimum version number that you should be using to be protected from MITM attacks when using EXOPS (as low a probability as that may be for your particular situation).

The Exchange Online Remote PowerShell Module is generally available, it’s no longer a preview release. Yes, the preview URL still works as a convenient way to download the module, but the information page on TechNet was recently updated to remove the note about EXOPS being in preview (apparently it has been out of preview for longer, but the page was only updated recently). So this is supported, production-ready code that is widely used and needs to be kept up to date.

During preview it was understandable that the EXOPS module would use its own special installation and update method. But now, as a generally available release, it remains in this unique state instead of being shipped as an installable and updatable module from the PowerShell Gallery using Install-Module (as we’re able to use for the AzureAD V2 module and many others). That means it’s up to you to maintain awareness of the EXOPS DLLs installed on your management workstations and servers, and routinely update them in case of future security vulnerabilities like this one.