A quick blog on security updates for Exchange Server 2016 and Exchange Server 2019 released September 8th. These fixes address the following vulnerability:
CVE-2020-16875: Exchange Memory Corruption Vulnerability A remote code execution vulnerability exists in Microsoft Exchange server due to improper validation of cmdlet arguments. An attacker who successfully exploited the vulnerability could run arbitrary code in the context of the System user. Exploitation of the vulnerability requires an authenticated user in a certain Exchange role to be compromised. The security update addresses the vulnerability by correcting how Microsoft Exchange handles cmdlet arguments.
The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.
Be advised that these security updates are Cumulative Update level specific. You cannot apply the update for Exchange 2016 CU17 to Exchange 2016 CU16. Also, the security update download has the same name for different Cumulative Updates, and I would suggest tagging the file name with the CU level, e.g. Exchange2016-CU17-KB4577352-x64-en.msp.
Also, run the Security Update from an elevated command prompt, to prevent issues during installation. And on a final note, as with any patch or update, I’d recommend to apply this in a acceptance environment first, prior to implementing it in production.
Not too long ago, the Exchange product group enabled Modern Authentication (or OAuth2) support for IMAP and SMTP in Exchange Online, and shortly after for POP3 as well. This support was much needed with the imminent deactivation of Basic Authentication. With Modern Authentication available, vendors, developers as well as organizations running custom scripts are given time to adopt Modern Authentication where applicable.
By delaying the original end date of Basic Authentication from October 13, 2020 to Q3’ish 2021 due to the Corona situation, the adoption period is increased significantly. That does not mean however developers and organizations can sit back and relax: Act sooner rather than later, the end of Basic Authentication is nigh.
The benefits of Modern Authentication are of course that it is a more secure model (e.g. resistant to password spray attacks), as well that it can leverage Microsoft 365 functionality like Conditional Access to limit protocols to certain locations.
That said, in this article I will show you how to approve usage of a popular 3rd party e-mail application Thunderbird, using IMAP protocol in conjunction with the Modern Authentication scheme. The procedures below have been run against Thunderbird 78.0b4 on Windows as well as Ubuntu.
Third Party Applications Before we move on to Thunderbird, we first make sure the organization settings allow for third party applications to access your mailbox Exchange Online. This process has been blogged about for common popular applications, such as the native iOS Mail app or the Gmail app on Android. So, how to go ahead if your organization restricts access to third party applications, and they only want to allow specific applications, which is of course good practice.
The easiest way to add Thunderbird to the allowed applications and grant consent to the organization, is by constructing an admin consent URL. To construct the consent URL, take the following URL:
Replace <TenantID> with your Tenant ID. This piece of information can be found under the Azure Active Directory blade in the Azure portal.
Replace <AppID> with the Application ID (sometimes also referred to as Client ID) of the application you want to provide consent for. As we can see in the table below, the ID of Thunderbird is 08162f7c-0fd2-4200-a84a-f25a4db0b584.
Application
ID
Thunderbird
08162f7c-0fd2-4200-a84a-f25a4db0b584
Gmail app
2cee05de-2b8f-45a2-8289-2a06ca32c4c8
iOS Accounts (Apple Mail app)
f8d98a96-0999-43f5-8af3-69971c7bb423
Open your browser, and visit this URL as an administrator. You will be greeted with a consent form, in which you will be asked to accept for your organization. Because the redirect_uri is empty here, you will likely be send to a non-existing location after giving consent, but that’s OK.
When you look at the Enterprise Applications blade in the Azure Portal, you will notice the Thunderbird app has been added. Here you can further customize it, like any enterprise application supporting Modern Authentication, e.g.
Restrict access to specific users or groups.
Use Conditional Access to restrict access to certain locations.
Another thing to note is that permissions for Thunderbird app will have been translated to the following Graph permissions:
API
Permission
Type
Microsoft Graph
Read and write access to mailboxes via IMAP.
Delegated
Microsoft Graph
Read and write access to mailboxes via POP.
Delegated
Microsoft Graph
Read and write access to mailboxes via SMTP AUTH.
Delegated
Microsoft Graph
Sign in and read user profile.
Delegated
We should now be ready on the back-end.
Thunderbird Now as an end user, start Thunderbird. Do not start configuring the account yet, as we first need to modify a Thunderbird setting to allow for successful Modern Authentication through a browser popup. Click the ‘hamburger’ menu to open the Options window. Scroll all the way down, and open the Config Editor. Click ‘I Accept the risk’. In the settings overview, set General.UserAgent.CompatMode.Firefox setting to True:
Preference Name
Status
Type
Value
general.useragent.compatMode.firefox
modified
boolean
True
Close the Config Editor and Preferences tab. We can now set up our account in Thunderbird.
Select Add Mail Account, and enter your name and e-mail address. You can leave the password empty, as we will be using an Oauth token which we will retrieve later on. Press Continue to have Thunderbird figure out where your mailbox is hosted. When it properly discovers the mailbox location, it will set the configuration as follows:
If Thunderbird can’t figure out your settings (for some reason the Windows build could, but the Ubuntu build couldn’t), configure them as indicated above. We can’t select OAuth2 for authentication here, so leave Authentication as is; we will correct this right after we click Done.
Note: Configure manually would be the place you expect to set authentication to OAuth2 straight away, but with the build we used, the OAuth2 option is not available from the manual account setup dialog. Therefore, we need to set up the account and correct settings afterwards.
In the Server Settings window related to your account, select OAuth2 authentication:
In the Outgoing Server (SMTP) settings, select Offic365 (Microsoft) – smtp.office365.com, click Edit and set authentication for outbound SMTP to OAuth2 as well. Note: The Thunderbird build running on Ubuntu doesn’t provide the OAuth2 authentication option for SMTP.
When finished, click ‘Get Messages’. The familiar Microsoft 365 authentication browser dialog should show up. After signing in, the next question will be to grant consent to the Thunderbird application to it can access your mailbox data and send e-mail:
Note that this dialog can not be suppressed, as currently only interactive applications are supported. If you are working on an app or script which needs unattended access, please use Graph API.
After the user provides consent, Thunderbird is ready and will start fetching your default folders and mail items. If you want to view additional folders, you need to subscribe to them by right-clicking the account and picking Subscribe. Only folders with mail-items are supported, despite you can select every folder in your mailbox including Calendar or Contacts.
Logging If you have people in your organization requiring some form of proof that Modern Authentication is being used, you can use the Enterprise Applications / Sign-Ins view from the Azure Active Directory portal.
Alternatively, you can use Thunderbird’s built-in logging capabilities. To accomplish the latter, set the following environment variables before starting Thunderbird:
A quick blog on recently published security updates for Exchange Server 2013 up to Exchange Server 2019 and Exchange Server 2010 as well. These fixes address the following vulnerabilities:
CVE-2020-0692: Microsoft Exchange Server Elevation of Privilege Vulnerability
An elevation of privilege vulnerability exists in Microsoft Exchange Server. An attacker who successfully exploited this vulnerability could gain the same rights as any other user of the Exchange server. This could allow the attacker to perform activities such as accessing the mailboxes of other users. Exploitation of this vulnerability requires Exchange Web Services (EWS) to be enabled and in use in an affected environment. To exploit the vulnerability, an attacker would need to change parameters in the Security Access Token and forward it to a Microsoft Exchange Server, thereby allowing impersonation of another Exchange user. To address this vulnerability, Microsoft has changed the way EWS handles these tokens. This vulnerability does not apply to Exchange 2010.
CVE-2020-0688: Microsoft Exchange Memory Corruption Vulnerability
A remote code execution vulnerability exists in Microsoft Exchange Server when the server fails to properly create unique keys at install time. Knowledge of a the validation key allows an authenticated user with a mailbox to pass arbitrary objects to be deserialized by the web application, which runs as SYSTEM. The security update addresses the vulnerability by correcting how Microsoft Exchange creates the keys during install.
The CVE documents contain more details on the vulnerabilities. In addition, KB4536989 (Rollup 30) for Exchange 2010 and KB4536988 for Exchange 2013 also fixes the following issue:
KB4540267 MSExchangeDelivery.exe or EdgeTransport.exe crashes in Exchange Server 2013 and Exchange Server 2010
The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.
Be advised that the Security Updates for Exchange 2013-2019 are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CUs, and you cannot apply the update for Exchange 2016 CU15 to Exchange 2016 CU14. I would suggest tagging the Cumulative Update in the file name used, e.g. Exchange2016-CU15-KB4536987-x64-en.msp.
Also, run the Security Update from an elevated command prompt, to prevent issues during installation. And on a final note, as with any patch or update, I’d recommend to apply this in a acceptance environment first, prior to implementing it in production.
A quick blog on recently published security updates for Exchange Server 2013 up to Exchange Server 2019. These fixes address the following vulnerabilities:
CVE-2019-1373: Microsoft Exchange Remote Code Execution Vulnerability
The CVE documents contain more details on the vulnerabilities. The exploits can be fixed by single security update, which you can find in the table below per current Exchange version.
Be advised that the Security Updates for Exchange 2013-2019 are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CUs, and you cannot apply the update for Exchange 2016 CU14 to Exchange 2016 CU13. I would suggest tagging the Cumulative Update in the file name when you store it, e.g. Exchange2016-CU14-KB4523171-x64-en.msp.
As with any patch or update, I’d recommend to apply this in a acceptance environment first, prior to implementing it in production.
Note: KB4515832 supersedes KB4509409 and KB4509408.
Be advised that these Security Updates are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CU’s, and you cannot apply the same update for Exchange 2016 CU13 to Exchange 2016 CU12. I would suggest tagging the Cumulative Update in the file name when you store it, e.g. Exchange2016-KB4515832-x64-en_CU11.msp.
As with any patch or update, I’d recommend to apply this in a
acceptance environment first, prior to implementing it in production.
A quick blog that rather silently, Microsoft published hotfixes for a number of products few days ago, including Exchange Server 2010 up to Exchange Server 2019. These fixes address the following vulnerabilities:
CVE-2019-1084: Microsoft Exchange Information Disclosure Vulnerability, allowing non-printable characters to be added to Display Names.
CVE-2019-1136: Microsoft Exchange Server Elevation of Privilege Vulnerability, allowing NTLM MITM elevation permissions or impersonation through Exchange Web Services. This sounds like a variation on the NTLM MITM exploit which was fixed earlier this year with the February update cycle.
CVE-2019-1137: Microsoft Exchange Server Spoofing Vulnerability, allowing for cross-site scripting (XSS).
The CVE documents contain more details on the vulnerabilities. These exploits can be fixed by single security updates; you can download them here:
Be advised that the Security Updates for Exchange 2013-2019 are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CU’s, and you cannot apply the update for Exchange 2016 CU12 to Exchange 2016 CU11. I would suggest tagging the Cumulative Update in the file name when you store it, e.g. Exchange2016-KB4503027-x64-en_CU11.msp.
As with any patch or update, I’d recommend to apply this in a
acceptance environment first, prior to implementing it in production.
A quick note that an update was released for current Exchange versions as well as Exchange 2010 related to the following advisory:
ADV190018 Microsoft Exchange Server Defense in Depth Update
Unfortunately – or perhaps understandably – the advisory doesn’t present any more details than, ‘”Microsoft has released an update for Microsoft Exchange Server that provides enhanced security as a defense in depth measure.”.
Be advised that the Security Updates for Exchange 2013-2019 are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CU’s, and you cannot apply the update for Exchange 2016 CU12 to Exchange 2016 CU11. I would suggest tagging the Cumulative Update in the file name when you store it, e.g. Exchange2016-KB4503027-x64-en_CU11.msp.
As with any patch or update, I’d recommend to apply this in a acceptance environment first, prior to implementing it in production.
Yesterday, an article was published on ZDNet, where the author claims “Russian Cyberspies” are exploiting a backdoor in Exchange. The article is based on a report of Slovakian-based ESET Research, which is no stranger on the anti-virus/malware market. The report, titled “Turla LightNeuron, One email away from remote code execution”, claims the group – Turla – leverages LightNeuron to exploit Exchange Server for malicious usage, using instructions hidden in image attachments delivered through e-mail to control the backdoor. The news was quickly picked up by other media, and it didn’t take long for customers to start asking questions on the topic. Time for some fact checking.
Exchange Backdoor The article claims the group using ‘one of the most complex backdoors’ ever spotted on an email server. While complexity is relative, it could very well be that this backdoor was indeed discovered on some improperly managed Exchange Servers in the wild.
However, the exploit leverages an installed malicious MTA (Message Transfer Agent, or Transport Agents in Exchange). An MTA is software handling incoming and outgoing e-mail messages using the Simple Mail Transfer Protocol (SMTP). A lot of legitimate 3rd party MTAs exist for Exchange Server, for example to add disclaimers to messages or for message hygiene purposes.
This LightNeuron is the actual backdoor, so there is no backdoor in Exchange. A totally different conclusion than one could read from the article’s title, and a totally different attack vector:
How did this Transport Agent get installed on Exchange server in the first place?
How was it possible to store the DLLs required by the Transport Agents, and which are likely to get caught by AV products, on Exchange Server?
How was it possible to perform these tasks using administrative access, which is required to install such components in the first place?
The ESET report mentions this requirement; the ZDNET article and all other media simply omit this. Note that developing your own Transport Agent isn’t rocket science; Microsoft provides instructions on how to write your own custom Transport Agent for Exchange Server on-premises.
Hidden Instructions Sending instructions hidden in images isn’t new. Steganography became famous to public in the last decade, where Osama Bin Laden was claimed to be embedding instructions for his followers in images posted on the internet. Little messages can also easily be embedded in the structure of an image file format, with places to store custom data or instructions.
Remote Control As the installed malicious MTA runs under administrative permissions, it is no surprise that whoever (remotely) controls the MTA, in principle controls the Exchange Server as it runs in the context of the Exchange Trusted Subsystem.
Remote Controlled malicious code is not new; it is what drives zombie computers, and it is what made some prank tools popular in the mid-90’s, when you could prank your coworkers by opening their CD trays (anyone remember those?).
Impact ESET claims that Turla has been leveraging LightNeuron for nearly 5 years, “which shows the tool’s advanced capabilities, being able to avoid detection for so many years”. In my opinion, this shows how many organizations have more bigger issues, such as an improperly managed mail environment.
SendMail The report also mentions LightNeuron being ported to *NIX as well, e.g. SendMail. This shows perfectly that any communications system, when compromised, can be used for man-in-the-middle attacks. However, mentioning leaks in SendMail might not drive traffic as much as mentioning ‘Backdoor in Exchange’ for media, which is a driver when you depend on advertisements.
Detection The article claims the hidden messages make LightNeuron hard to detect. Of course, this depends. The backdoor requires installation and presence of two malicious DLL files. Any respectable AV product should catch those. Windows Server 2016+ comes with Windows Defender, which according to its encyclopaedia should be able to detect Turla variants.
Removal Finally, the article claims that, “removing this backdoor is quite problematic”. This is utter nonsense, as any weathered Exchange administrator should be able to install or uninstall Transport Agents as part of their skill set.
Conclusion In summary and concluding:
This is not a backdoor in Exchange Server.
The backdoor is a malicious Transport Agent which needs to be installed on the Exchange Server
Installing this backdoor requires administrative permissions.
Well-managed Exchange environments should be OK.
Removal is simple, and a task any Exchange admin should be able to perform.
Windows Defender detects Turla variants.
And last but not least:
Media should do proper fact-checking as opposed to blindly copying articles.
Media should use titles which reflect the contents, and refrain from click-bait titles.
ESET is a vendor selling e-mail hygiene and security-related products, which always is a potential red flag when these kinds of reports are published.
A short notice on the zero-day vulnerability in the Exchange ecosystem as reported by researcher Mollema last week. Through a man-in-the-middle setup, one can exploit the permissions Exchange has with regards to Active Directory in conjunction with NTLM as well as Exchange Web Services (EWS). This 3-stage missile allows one to elevate their privileges in Active Directory, and thus to grant themselves administrative access.
The issue was already logged at 13 november in the Microsoft Security Response Center (MSRC) as CVE-2018-8581, Microsoft Exchange Server Elevation of Privilege Vulnerability. An uptake on the public attention for the issue was generated after the Mollema article, and media like The Register started publishing about it. Meanwhile Exchange fellow Tony Redmond also wrote a short note on the issue as well.
At this moment, Microsoft is fully aware of the issue, and is actively working on resolving the issue as soon as possible. Meanwhile, the mitigation mentioned in CVE-2018-8581 can be considered, which is to remove the DisableLoopbackCheck key from HKLM:\SYSTEM\CurrentControlSet\Control\Lsa. The effect of removing this key is that it’s no longer possible to make NTLM connections on the loopback adapter (localhost), which should be OK for Kerberos authenticated sessions as they are name-based. Again, test this as for example platforms like SharePoint will break when setting this key, but nobody runs SharePoint on the same box, so for Exchange this is a valid mitigation.
Organizations are advised not to blindly implement mitigations mentioned in Mollema’s article or elsewhere in the field, as they might not be applicable to every deployment out there, or have unforseen side-effects. Then again, organizations might already have things deployed SMB signing, in which case the exploit does not apply.
Update (Feb6): Meanwhile, Microsoft Security Response Center published an advisory (ADV190007) containing guidance on how to deal with the issue at this moment. MSRC takes the EWS Throttling Policy route to block EWS Subscriptions at the original level, which of course breaks Outlook for Mac functionality (e.g. new mail notifications as the client can no longer subscribe to receive updates), or other applications which rely on this mechanism (e.g. meeting room systems). This can be mitigated by explicitly allowing EWS subscriptions for trusted users and applications.
Update (Feb13): Today the quarterly cumulative updates for Exchange 2019/2016/2013 were released, which will remove the DisableLoopbackCheck key (when present).
A quick heads-up as during my vacation Microsoft released security updates for supported releases of Exchange Server 2013, 2016 as well as Exchange Server 2019. In addition, a new Rollup was released for Exchange 2010 as well, containing one of the security updates.
The security updates patch issues as reported in the following Microsoft Common Vulnerabilities and Exposures:
CVE-2019-0586: Microsoft Exchange Memory Corruption Vulnerability
CVE-2019-0588: Microsoft Exchange Information Disclosure Vulnerability
KB4471389 supersedes KB4468741 and KB4459266; KB4468742 supersedes KB4458321.
Be advised that the Security Updates for Exchange 2013 and 2016 are Cumulative Update level specific. Unfortunately, the security update carries the same name for different CU’s, and you cannot apply the update for Exchange 2016 CU10 to Exchange 2016 CU11. I would suggest tagging the Cumulative Update in the file name when you archive it, e.g. Exchange2016-KB4471389-x64-en-CU10.msp.
As with any patch or update, I’d recommend to thoroughly test this in a test and acceptance environment first, prior to implementing it in production.
![clip_image001[14]](https://eightwone.files.wordpress.com/2020/07/clip_image00114.png "clip_image001[14]")
![clip_image001[18]](https://eightwone.files.wordpress.com/2020/07/clip_image00118.png "clip_image001[18]")
Yesterday, an article was published on ZDNet, where the author claims “Russian Cyberspies” are exploiting a backdoor in Exchange. The article is based on a report of Slovakian-based ESET Research, which is no stranger on the anti-virus/malware market. The report, titled “Turla LightNeuron, One email away from remote code execution”, claims the group – Turla – leverages LightNeuron to exploit Exchange Server for malicious usage, using instructions hidden in image attachments delivered through e-mail to control the backdoor. The news was quickly picked up by other media, and it didn’t take long for customers to start asking questions on the topic. Time for some fact checking.