• Home
  • Topics
    • Office 365
    • Teams
    • SharePoint Online
    • Exchange 2019
    • Exchange 2016
    • Exchange 2013
    • Hybrid
    • Certificates
    • PowerShell
    • Migration
    • Security
    • Azure
  • Blog
  • Podcast
  • Webinars
  • Books
  • About
  • Videos
    • Interview Videos
    • How To Guide Videos
  • Subscribe
    • Facebook
    • Twitter
    • RSS
    • YouTube

Practical 365

You are here: Home / Exchange Server / Why Exchange admins should be very worried

Why Exchange admins should be very worried

March 2, 2020 by Steve Goodman 46 Comments

Why Exchange admins should be very worried

Update March 2021: This post relates to issues found in March 2020. A new, more serious set of security issues have been found in March 2021. See Tony Redmond’s post on the topic for more information and watch on-demand our live panel discussion on protecting Exchange Server from #HAFNIUM attacks from March 12.

If you haven’t already done so, this week you should be applying patches to your Exchange Servers. A reasonably easy to exploit vulnerability has been disclosed by Microsoft as CVE-2020-0688.

Sigi and I talked about this in this week’s episode of The Practical 365 podcast, but this is important enough to write about separately in case you missed the show.

The TL:DR version of this is – anyone with the username and password for a mailbox on your Exchange Server and access to the /ecp directory can execute code as the SYSTEM account on the server itself.

The proof-of-concept exploits show this can be achieved by sending it an easily crafted URL using freely obtained open source tools.

This vulnerability is due to Microsoft using the same set of cryptographic keys on every Exchange Server installation. The keys being stored in plain text in a web.config file on every server.

The bad news is that although it has taken nearly ten years for this to be noticed, now it has, would be attackers are acting quickly. Security researchers are already seeing scans for public-facing Exchange servers to obtain build version information. If you publish OWA and ECP externally the next step by these malicious people will be to attempt to gain a set of working credentials to access Exchange. There are already tools available to use social networks like LinkedIn to harvest email addresses and of course tools to automate login attempts.

Make no mistake – if you publish Exchange externally and don’t patch, it’s only a matter of time until this is exploited.

Even if you don’t publish Exchange externally, you should consider this a threat. Not all staff follow the rules and it’s possible an insider within your organization may use this opportunity to take advantage of the rights an Exchange computer account has. The amount of damage someone could do easily shouldn’t be understated.

Simon Zuckerbraun, of the Zero Day Initiative, has produced a comprehensive write-up on their blog that provides a vast amount of detail about the vulnerability including a walk-through on how to exploit it. It makes for worrying reading – all an attacker needs is a compiled version of ysoserial.net, the validation key from either his article – or any Exchange Server– and then by crafting a URL GET request to /ecp/default.aspx they can do as they wish. If that hasn’t worried you yet, read the article now.

Getting patches for Exchange

Patches are available for all support versions of Exchange Server – from 2010 through to 2019 and all are affected.

The update comes in the form of an Update Rollup, UR30, for Exchange 2010, and security updates for the latest Cumulative Updates for Exchange 2013, 2016 and 2019. If you aren’t running the latest CUs for Exchange 2013 or higher, then you will need to get current as well as subsequently applying the patch.

You can find links to the patches on the Microsoft Security Response Center page for CVE-2020-0688.

Exchange Server

About Steve Goodman

Chief Editor for Audio and Video Content and Technology Writer for Practical 365, focused on Microsoft 365. A nine-time Microsoft MVP, author of several Exchange Server books and regular conference speaker, including at Microsoft conferences including Ignite, TechEd and Future Decoded.

Steve has worked with Microsoft technology for over 20 years beginning and has been writing about Exchange and the earliest iterations of Office 365 since its inception. Steve helps customers plan their digital transformation journey and gets hands on with Microsoft Teams, Exchange and Identity projects.

Comments

  1. Robert Atanovich says

    March 10, 2021 at 11:20 am

    Does applying updatecas.ps1 deprecate the KB5000871 exchange security update?

    Reply
  2. Chris B. says

    March 4, 2021 at 10:37 pm

    We installed Exchange CU 23 yesterday. A few notes from our experiences:

    1. Make sure you install .Net 4.8 prior to the install
    2. As others have mentioned, the install needs to be run as an admin

    In our case, the CU failed updating the mailbox database service. Luckily, our server is still running but we are getting odd errors related IIS crashing and have to periodically reboot the server. We have a call in to Microsoft but it has been a full 24 hours at this point and we have not gotten a response.

    Reply
    • steve hovey says

      March 6, 2021 at 10:59 am

      mine crashed on a system account with insufficient creds (no oabgen).. it broke search.. I fixed the system account, reran, and it straightened out.. so if you haven’t approached it that way it might be an option.

      Reply
    • Neil A says

      March 9, 2021 at 1:14 pm

      We installed our’s last week as well, issues encountered is that the OWA/ECP broke in our environment.
      We followed instructions on KB article but did not mention of the .NET 4.8 being installed first before the security update.

      I’m wondering if that’s causing our OWA issue in our case.

      We followed the KB suggested by Microsoft about OWA/ECP being broken after CU security update but issue still persists:
      https://docs.microsoft.com/en-us/exchange/troubleshoot/client-connectivity/owa-stops-working-after-update

      I’ll install 4.8 and re-apply the CU23 security update tonight I’ll see if this resolves our issues.

      Were you able to hear a word from Microsoft, I’m curious to know how they responded to your issue.

      Also, I noticed that there’s a new release for the Security Update but only applied to 2016/2019 Exchange servers. Wondering if Microsoft discovered bugs on the initial release.

      Reply
      • Steve Goodman says

        March 9, 2021 at 2:44 pm

        I’d suggest dropping into Tony’s post on the topic here – remember this post is about the security issues from a year ago (2020!). There are new releases today, to cover older CUs and make things less painful for those updating.

        https://practical365.com/blog/microsoft-issues-critical-security-updates-for-exchange-server/

        Reply
  3. Remi says

    March 20, 2020 at 4:23 pm

    Hi Steve,

    a Customer have an atypical configuration with two Exchange 2013 with Cu23 installed. One with Client Access role, the second with Mailbox role.

    I wonder if i should installed KB4536988 on both servers like any other Cu (Mailbox first, CAS after) or simply on CAS.

    Thank you in advance for your reply

    Reply
    • steve hovey says

      March 6, 2021 at 11:00 am

      we did cas first since its the first box they’d hit to crack at

      Reply
  4. Andrew says

    March 19, 2020 at 9:21 am

    Ah great… we are still on exchange 2007…

    Reply
  5. B. Smith says

    March 14, 2020 at 5:36 am

    I like your blog and getting spun up on Exchange as this will be a full-time job for me. Appreciate the feedback from everyone. I’ll save this blog as a favorite.

    Reply
  6. Ralph says

    March 12, 2020 at 7:45 pm

    Hi guys
    After logging with Microsoft, the issue was this:
    “https://support.microsoft.com/en-us/help/3032024/outlook-web-app-and-ecp-redirect-to-the-fba-page-in-exchange-server-20”
    Interesting to note: the public cert worked fine before the patch, and then the restriction of no support for “CSP=Microsoft Storage Key Provider” kicked in and the cert did not comply.
    Also, the certificate CSP conversion process (explained in the Tech Article) failed on the existing cert, so a re-issue (with the Provider = Microsoft RSA SChannel Cryptographic Provider in the new request) was requested from Digicert, installed with services, and OWA & ECP started working correctly.
    Hope this helps someone with this issue…

    Reply
  7. Jeff Johnson says

    March 7, 2020 at 6:10 am

    Hey guys,
    I just installed on Exchange 2013 CU23 and everything went fine with the installation itself, but I noticed that i could not search in Outlook. I checked the Content IndexState of my databases and they were all failed.

    It looks like it set the Microsoft Exchange Search Host Controller to Disabled. I changed this to Automatic and started it and restarted the Microsoft Exchange Search and everything was showing Healthy in about 5 minutes.

    We use Zerto for DR replication and I performed a test failover to prior to the patch and it was set to automatic confirming that after the patch it was Disabled.

    I can’t speak for other Exchange versions, but this is something for people to keep an eye on while applying this patch

    Reply
    • Donnie Lee says

      March 25, 2020 at 3:28 am

      I ran into this same issue. The security patch must be ran from an elevated CMD. I didn’t see that on the fine print initially and it led to a corrupted OWA and ECP virtual directory.

      It still installed without showing an error but we started getting calls about users getting a 400 error when trying to access via OWA.

      Reply
      • Richard says

        March 30, 2020 at 10:52 pm

        Hi, did you have a resolution to this issue?

        Reply
      • steve hovey says

        March 6, 2021 at 11:02 am

        this.. plus you cant right click, run as admin, on the cu install.. you have to invoke it from the command line of an elevated cmd window

        Reply
  8. Virsingh Rathore says

    March 5, 2020 at 1:42 am

    Hi Steve, I have just applied Exchange 2016 CU15 yesterday. DO i need to still install this patch or it would be inbuilt as this Patch is available since Feb.

    I am a bit afraid hearing about ECP/OWA break issues.

    Please suggest.

    Reply
    • Michael says

      March 5, 2020 at 5:45 am

      Virsingh,

      This security patch is NOT built into any CU for any version of Exchange. It is a separate installation that can only be installed once the Exchange system is upgraded to the latest CU.

      Reply
    • Steve Goodman says

      March 5, 2020 at 6:10 am

      As above – you need to install the security update *in addition* to the CU.

      Reply
  9. Rob Barclay says

    March 4, 2020 at 8:48 pm

    If your environment doesn’t expose exchange urls externally then locking down the internal ECP virtual directories with the IIS IP Address and Domain restrictions feature is likely a decent temporary option until patching can be done. Can lock down ECP to subnets or IP’s only your admin staff have access to.

    Reply
    • Dan says

      March 12, 2020 at 12:44 am

      Hello and yes, that is what I did. We do not publish OWA externally at all, in fact, all of our desktops use OWA internally instead of using a full Outlook client. It is just a cleaner, leaner solution that works for us. Hence, the IP based restriction for the ECP default web site (in IIS) worked very well. Set it to 127.0.0.1 as the only address that can access the ECP, so you must be physically at the server to have access, etc. Thanks for the suggestion!

      Reply
  10. Chris Colden says

    March 4, 2020 at 5:32 pm

    Great write up Steve. Couple of things to add. Make sure you run this patch from an elevated command prompt else it may not install all files.

    There has also been some people having issues with it on Exchange 2013 where it breaks OWA/ECP. The fix is a bit two fold, I have a link for all the details but didnt want to share it without asking first.

    We personally haven’t had any issues with any of our customers but worth others being aware.

    Reply
    • Michael says

      March 4, 2020 at 11:30 pm

      I’m interested in the post-patch OWA/ECP fix if you’d care to share?

      Reply
      • gregor says

        April 2, 2020 at 10:31 pm

        I managed to fix OWA with updatecas.ps1 script, ocated in Exchange scripts folder.
        Sorry, cant paste link, reported as spam???

        Reply
    • Ralph says

      March 6, 2020 at 10:33 pm

      Hi Chris/Paul
      I have a client who has just run this update Exch 2013, CU23 (but NOT from an elevated prompt …!), and now neither ECP or OWA are functional.
      The Login page for both appears, but after entering password, the screen simply keeps requesting a password.
      I have tried a number of tasks to resolve, but none have been successful.
      I will attempt to run the patch again this evening (with elevated prompt !), but would be eager to try any other fixes in the meantime…
      I’m also interested in the possible post-patch fixes.
      Ralph

      Reply
      • Nate says

        April 10, 2020 at 6:14 am

        Ralph,

        Did that work? I installed CU23 and the patch. A couple weeks later OWA/ECP are broke. Waiting on a call from MS but, they are taking forever.

        Reply
    • Satyam Gupta says

      October 1, 2020 at 11:27 pm

      Hi Chris,

      Could you please the solution/fix of ecp/owa break? I installed the cu23 with this security patch and things are not good after that.

      Reply
  11. DuyAnh says

    March 4, 2020 at 9:30 am

    My server’s running 2013 sp1 (CU4),if i install CU23, my server works well? Please help me to update CU23.

    Reply
    • Excadmin says

      March 4, 2020 at 5:05 pm

      Even though every Cu is a new exchange install, the prerequisites are different, for example, your .net version would need to be updated etc. I would advise you to read the prerequisite first before jumping to the latest CU especially since you are so far out on updates.

      Reply
  12. Excadmin says

    March 4, 2020 at 5:27 am

    I have updated my Exchange 2016 Cu14 with the Cu14 patch however my ecp does not work any longer, OWA works,I get error HTTP Error 500.19 – Internal Server Error only when trying ecp.

    Reply
    • Steve Goodman says

      March 4, 2020 at 5:39 am

      I’ve not personally seen the same thing with this patch, but would check:

      – You’ve rebooted the server
      – When you ran the patch you did so from an elevated command prompt – I don’t know if it’s safe to run the patch again if you didn’t do so from an elevated command prompt but would personally consider doing so.

      If either of those don’t help – then until someone else reproduces it and can solve it then a first point of call would be to raise a SR with Microsoft, as poking around is likely to make it worse.

      Reply
      • mike says

        March 5, 2020 at 3:20 am

        This is a known / published issue with exchange updates, when not run from an elevetad prompt

        Reply
    • Trevleno says

      March 4, 2020 at 6:15 am

      Update to my own comment, I noticed that the ecp web.config file was blank, restored it from backup, did an iisreset and ecp back up and running!

      Reply
      • Steve Goodman says

        March 4, 2020 at 6:33 am

        Thank you! That might well help someone else reading this

        Reply
    • Revino says

      March 4, 2020 at 2:45 pm

      I would assume exchange online users are safe

      Reply
  13. Jeff Stevens says

    March 4, 2020 at 1:10 am

    There is no more recent CU for 2013 than CU23, which is from July 2019. So apparently there is no patch for 2013.

    Reply
    • Steve Goodman says

      March 4, 2020 at 1:45 am

      Hi Jeff,

      The link to the security update for Exchange 2013 is broken in the Microsoft article.

      The KB (https://support.microsoft.com/en-us/help/4536988/description-of-the-security-update-for-microsoft-exchange-server-2013) does link to it though.

      It is a patch – a security update to apply *to* CU23, rather than a new CU. The release date of the CU is Feb 2020.

      https://www.microsoft.com/en-us/download/details.aspx?id=100909

      Steve

      Reply
      • Robert Atanovich says

        March 10, 2021 at 11:21 am

        Does applying updatecas.ps1 deprecate the KB5000871 exchange security update?

        Reply
    • Mario Sapag says

      March 4, 2020 at 4:41 am

      There is, if you have the CU23 installed, all you need is this patch. I just finished installing CU23 and this patch after without any issues.

      Reply
  14. Navishkar Sadheo says

    March 3, 2020 at 9:00 pm

    Hi Steve

    What happens if you still running Exchange 2010 SP3 on Server 2008 R2? I believe RU30 for Exchange 2010 SP3 is not available for Server 2008 R2, unless I am mistaken.

    We are currently in processing of deploying Exchange 2016 within our organization.

    Appreciate any advice.

    Reply
    • Rafael Silva says

      March 4, 2020 at 12:06 am

      No problem Exch 2010 SP3 and Server 2008 R2
      I alredy do it on a client.

      Reply
    • Steve Goodman says

      March 4, 2020 at 1:43 am

      I agree with Rafael, RU30 should apply like any existing update rollup for Exchange Server 2010 SP3.

      Steve

      Reply
    • Levi says

      March 5, 2020 at 12:09 am

      Exchange 2010 stops at 2008 R2 so it will be available.

      https://docs.microsoft.com/en-us/previous-versions/exchange-server/exchange-140/aa996719(v=exchg.140)?redirectedfrom=MSDN

      Reply
  15. renders says

    March 3, 2020 at 3:42 am

    Practical365 is my go to resource reading for Exchange, so wanted to share my “scary CU stories to tell in the dark”.

    An environment I was brought on to work last week were still on 2016 CU4 (version December 13, 2016). I needed to get them up to CU15, then apply the related patch that is only compatible on the newest and one version back per Microsoft’s SOP.

    It was…a long weekend, but overall came out of the tunnel successful. Going that far in CU’s is always scary, so many changes, improvements, items that can fall over – but wanted to take this latest exploit as serious as it really is for the clients health. Plenty examples are now published of how to leverage it, there are strong hints of scanning afoot of bad folks attempting to locate exploitable company servers.

    Best advice for other Exchange admins: if you have a history of holding on to a CU, choose today to correct that situation, don’t be an easy target.

    Reply
    • Steve Goodman says

      March 4, 2020 at 1:47 am

      Well done on what was likely a tough weekend. Moving forward that far, plus applying security updates is not a small undertaking.

      My immediate actions with my clients that I am mid-project with has been to mitigate against the risk urgently before getting patches installed. For those mid-migration patching is difficult as well, especially long migration jobs that can’t just be halted.

      I agree – keep up to date and it makes not only applying the patches easier but also makes sure there is less fear of applying CUs and patches.

      Reply
      • Dan says

        March 12, 2020 at 12:51 am

        Hello, would you mind fleshing out a bit more the phrase “mitigate against the risk urgently” since, from the context of your comments, I assume this means these clients are mid-project and you cannot immediately update versions / apply patches, etc. Thanks!

        Reply
  16. keen says

    March 2, 2020 at 11:59 pm

    If you can’t update or patch your environment right away, you can stop the ECP application pool in IIS as a temporary security measure.

    If it’s not possible to update your platform, you can manually change the Machine Key for your ECP applications in IIS. Although this is not a supported solutions, it seems to work.. but you should really update. 🙂

    Reply
    • Steve Goodman says

      March 4, 2020 at 1:49 am

      Yes, I would agree that that should be fine on the face of things, though Microsoft aren’t suggesting it as a workaround. The issue often with disabling ECP is it is the options page in OWA, so it can have unintended effects. However as a temporary measure, doing as above, or stopping publishing that specific path externally (no solution for insider threats, but..) can work until the patch window.

      Reply

Leave a Reply Cancel reply

You have to agree to the comment policy.

Recent Articles

  • Three Steps to Securing Microsoft Teams
  • Turn On MFA: Real-World Example of Fraud, Domain Stealing, and the Nearly Lost House Deposit
  • Changes in Microsoft 365 Apps Channels and Why You Should Care
  • A New Tool to Manage Exchange-related Attributes Without Exchange Server
  • Microsoft Launches Group Ownership Governance Policy

Copyright © 2022 Quadrotech Solutions AG · Disclosure · Privacy Policy
Alpenstrasse 15, 6304 Zug, Switzerland