Released: August 2023 Exchange Server Security Updates

Workaround

# Automatic services
$auto = "MSExchangeADTopology",
"MSExchangeAntispamUpdate",
"MSExchangeDagMgmt",
"MSExchangeDiagnostics",
"MSExchangeEdgeSync",
"MSExchangeFrontEndTransport",
"MSExchangeHM",
"MSExchangeImap4",
"MSExchangeIMAP4BE",
"MSExchangeIS",
"MSExchangeMailboxAssistants",
"MSExchangeMailboxReplication",
"MSExchangeDelivery",
"MSExchangeSubmission",
"MSExchangeRepl",
"MSExchangeRPC",
"MSExchangeFastSearch",
"HostControllerService",
"MSExchangeServiceHost",
"MSExchangeThrottling",
"MSExchangeTransport",
"MSExchangeTransportLogSearch",
"MSExchangeUM",
"MSExchangeUMCR",
"FMS",
"IISADMIN",
"RemoteRegistry",
"SearchExchangeTracing",
"Winmgmt",
"W3SVC"

# Manual services
$man = "MSExchangePop3",
"MSExchangePOP3BE",
"wsbexchange",
"AppIDSvc",
"pla"

# Enable Services
foreach ($service in $auto) {
   Set-Service -Name $service -StartupType Automatic
   Write-Host "Enabling "$service
}
foreach ($service2 in $man) {
   Set-Service -Name $service2 -StartupType Manual
   Write-Host "Enabling "$service2
}

# Start Services
foreach ($service in $auto) {
   Start-Service -Name $service
   Write-Host "Starting "$service 
}

• Save this Script into a .ps1 file and run it as Adminstrator in the Powershell
• When Errors appears, check the Name of the Service and start him manually
• After this my Exchange 2016 and 2019 worked

Source for the Script : https://www.alitajran.com/restart-exchange-services-powershell-script/ 

FloydH80 and stevmorr indeed, you can work on CVE-2023-21709 independently from the August update. No, server reboot is not required, whether you run our script or run manual commands as per the CVE. We listed this step as done AFTER the update installation because we want all customers to update to August SU. It just had to be put into the workflow someplace... but there is no dependency on August update (as the blog post text indicates).

For those who don't want to wait for the revised update from MS: I validated the workaround and wrote these instructions for updating Exchange Server 2016 CU 23 on a Windows Server 2016 with de-de locale.

Microsoft removed the original Exchange2016-KB5029388-x64-de.exe from the Download Center. I reuploaded it because it can be actually used to successfully patch a german Exchange 2016.

If the update already failed and did a rollback, fix Exchange services by following these steps:

- Open Elevated Powershell
- Change to the following directory: \Exchange Server\V15\Bin.
- Enter .\ServiceControl.ps1 AfterPatch, and then press Enter.
- Restart the computer.

To install the update follow these steps:

1) Download standalone update from https://backofficeplusgmbh-my.sharepoint.com/:u:/g/personal/julian_haupt_backoffice_plus/EWf-wAFN4BdDgFAH66GbEhkB0YH7QjeecDX2y-J_S0uW6g?e=4lTXqF
2) Add dummy AD user by running:

New-ADUser -Name "Network Service" -SurName "Network" -GivenName "Service" -DisplayName "Network Service" -Description "Dummy user to work around the Exchange August SU issue" -UserPrincipalName "Network Service@$((Get-ADForest).RootDomain)"

3) If AD is replicated wait up to 15 minutes for replication to propagate
4) Run Exchange2016-KB5029388-x64-de.exe as Administrator

5) Fix registry access to the correct "Network Service" user by running

$acl = Get-Acl -Path "HKLM:\SOFTWARE\Microsoft\MSIPC\Server"
$rule = New-Object System.Security.AccessControl.RegistryAccessRule((New-Object System.Security.Principal.SecurityIdentifier("S-1-5-20")), 983103, 3, 0, 0)
$acl.SetAccessRule($rule)
Set-Acl -Path "HKLM:\SOFTWARE\Microsoft\MSIPC\Server" -AclObject $acl

6) Restart Exchange Server
7) If there a multiple Exchange Servers repeat steps 1 & 4-6 on every server
😎 Remove the dummy AD user by running

Remove-ADUser -Identity "Network Service"

This Exchange SU cannot be installed in our environments (OS and Exchange in de-de). Installer throws Error 1603.

Tested on Exchange Server 2016 CU23 SU8 on Windows Server 2016 as well as Exchange Server 2019 CU13 SU1 on Windows Server 2022.

Property(C): msgINTERIMUPDATEDETECTED = Unable to install because a previous Interim Update for Microsoft Exchange Server 2016 Cumulative Update 23 has been installed. Please use Add/Remove Programs to uninstall the Interim Update before running this setup again.
Property(C): msgRequiresProc = The version of this file is not compatible with the version of Microsoft Exchange Server 2016 Cumulative Update 23 that you're running. Check your computer to see whether you need an x64 (64-bit) or x86 (32-bit) version of this file.

MSI (c) (54:10) [22:15:58:033]: Product: Microsoft Exchange Server - Update 'Security Update for Exchange Server 2016 Cumulative Update 23 (KB5029388) 15.1.2507.31' could not be installed. Error code 1603. Additional information is available in the log file C:\Program Files\Microsoft\Exchange Server\V15\Logging\Update\msi\ExchangeUpdate_2023-08-08-195915.log.

MSI (c) (54:10) [22:15:58:034]: Windows Installer installed an update. Product Name: Microsoft Exchange Server. Product Version: 15.1.2507.6. Product Language: 1033. Manufacturer: Microsoft Corporation. Update Name: Security Update for Exchange Server 2016 Cumulative Update 23 (KB5029388) 15.1.2507.31. Installation success or error status: 1603.

Do I really have to uninstall the previous SU first?

The Patch even leaves the server in a non-working state with all Exchange services deactivated which have to be reset to automactic startup!

Microsoft released a workaround for this issue: 

https://support.microsoft.com/de-de/topic/exchange-server-2019-and-2016-august-2023-security-update-installation-fails-on-non-english-operating-systems-ef38d805-f645-4511-8cc5-cf967e5d5c75

It seems that the "Network Service" account is hard coded in the update. I think they need to change the code to lookup the localized version of this account.

I haven't tried the workaround yet.

Nino_Bilic 

I see that the company with the 2.4 trillion USD market cap still cannot test their updates properly and as usual this blog post will degenerate into hundreds of comments with people asking for clarification on things that should have already been answered in the post.

re "Clearly, there was a case that was missed"  Non-EN installations is a major case and not some obscure bit of functionality in the product.  I suspect that like the tablecloth that is too small for the table, in the future other languages will get tested thoroughly while some other area will not and we can all meet again in the comments section of this blog.

Correct me if i am wrong, but the main issue with the TokenCacheModule is probably a hash-collision attack (3. ISS-Authentication Bypass) as described here: https://devco.re/blog/2022/08/18/lets-dance-in-the-cache-destabilizing-hash-table-on-microsoft-iis/

essentially giving you unlimited chances to guess user credentials / brute force credentials..
The version fixed in 2022 probably fixes that username/password is compared instead of two times the username, so its much more unlikely to get a cache hit, but essentially there is no rate limit for that, so an attacker could just run brute-force / wordlist attacks against known usernames in order to try to get an collision with an existing session.

The main purpose of the TokenCacheModule is probably to not perform authentication for each and every request but instead do it once and if the hash matches re-use the cached token..

The correct fix here would be to fix the TokenCacheModule to use a better hash function / use a larger hash to make collisions highly unlikely and rate-limited the number of requests for cache-misses, so it can´t be abused by brute-forcing credentials to hit a valid cache entry...

I guess the Exchange team isn´t able to patch this, as it´s part of IIS, so they choose to recomment to just disable the Module via the CVE Mitigation script.
However this leads to potential performance issues, as know each and every request to the Exchange has to be authenticated instead of using cached token, that´s probably why BastiMS experiences performance issues / hanging Outlook clients..

From an Exchange team perspective: Is the IIS Team working on a fix of the TokenCacheModule which we can expect in the foreseable future?

We have a similar problem like Lothar_Lindinger . The Exchange SU cannot complete in our environments (Exchange 2019 and 2016), also on an very clean test environment. The OS and the Exchange are in de-de.

Property(C): msgINTERIMUPDATEDETECTED = Unable to install because a previous Interim Update for Microsoft Exchange Server 2019 Cumulative Update 13 has been installed. Please use Add/Remove Programs to uninstall the Interim Update before running this setup again.
Property(C): msgRequiresProc = The version of this file is not compatible with the version of Microsoft Exchange Server 2019 Cumulative Update 13 that you're running. Check your computer to see whether you need an x64 (64-bit) or x86 (32-bit) version of this file.

MSI (c) (BC:74) [21:17:48:953]: Product: Microsoft Exchange Server - Update 'Security Update for Exchange Server 2019 Cumulative Update 13 (KB5029388) 15.2.1258.23' could not be installed. Error code 1603. Additional information is available in the log file D:\Exchange Server\Logging\Update\msi\ExchangeUpdate_2023-08-08-190917.log.

After the patch the servers are in a non-working state. We have services which do not start because of dependencies and even crashing transport services ("1067, Prozess wurde unerwartet beendet").

The_Exchange_Team Please remove this update from WSUS Distribution at the earliest!

Same on my end, tried on two different Exchange 2019 CU13 de-de servers. After failing, I fixed all services and it seems to run fine without the SU.

Please provide a working patch soon, as POCs for the RCEs will be coming up in the next few hours...