Ik hoop dat de patchbereidheid in Nederland hoger is dan bij eerdere lekken (zoals in Citrix gateways en Pulse Secure VPN servers).

Waarschuwing, te vinden in de KB artikelen voor de specifieke Exchange versie, zo te zien geldt dit voor alle versies

Door Erik van Straten: Mijn vragen uit https://security.nl/posting/645957 (aldaar met toelichting), maar die gaan in die thread waarschijnlijk niet meer beantwoord worden en hopelijk hier wel:

Weet iemand:
1) Of ook de laatste versies van OWA / EWS na clean install "SHA1" en/of "3DES" nog voorkomen in web.config?
2) En of dit na de patch van februari veranderd is?
3) Of je, tijdens patchen, ervoor gewaarschuwd wordt dat je op servers in een farm identieke keys en algoritmes moet configureren in web.config? En zo ja, hoe je dergelijke keys veilig genereert?

Door Anoniem:
Clean install Exchange Server 2019 (laatste versie) is dit standaard:

TLS 1.2 is the only version that's enabled by default: Exchange Server 2019 includes important changes to improve the security of client and server connections. The default configuration for encryption will enable TLS 1.2 only and disable support for older algorithms (namely, DES, 3DES, RC2, RC4 and MD5). It will also configure elliptic curve key exchange algorithms with priority over non-elliptic curve algorithms

Bron : https://docs.microsoft.com/en-us/Exchange/new-features/new-features?view=exchserver-2019

Door Erik van Straten: Dank voor jouw reactie, maar wat je schrijft heeft betrekking op de communicatie met clients en andere mailservers via TLS-gebaseerde protocollen als ESMTP, IMAP en de https verbinding met een OWA/EWS server.

Niet duidelijk is of dit ook geldt voor wat in web.config staat voor de server-side signing en/of encryption van de ASP.NET "ViewState", informatie die de server (via een https verbinding die hier los van staat) na elke gebruikershandeling op de server naar de browser stuurt (ik wist hier niet zoveel van maar heb me er ondertussen verder in verdiept). Door die ViewState telkens naar de browser te sturen, hoeft de server niet te onthouden wat de gebruiker aan het doen is, zoals reeds ingevulde velden op een webformulier (het is een soort uitgebreide cookie). Die ViewState bevat instructies die de server uitvoert zodra deze die ViewState terugontvangt van de browser.

Nb. door de browser te laten onthouden waar de gebruiker precies was, kan deze door een serverfarm worden bediend en kan er, halverwege de sessie, probleemloos van server worden gewisseld (mits elke server daarin de ViewState kan decrypen en/of de signature checken - waar naast dezelfde sleutels, natuurlijk ook identieke algoritmes voor moeten worden gebruikt).

Probleem: als je zo'n door de browser ontvangen ViewState kunt wijzigen en de server deze toch accepteert en de opdrachten daarin (server-side) uitvoert, is dat een kwetsbaarheid. Want kennelijk kun je in die ViewState bijvoorbeeld een opdracht opnemen om een willekeurige file op de server te (over-) schrijven, zoals "C:\Vuln_Server.txt" (zie https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys).

Soroush Dalili beschrijft verschillende soorten kwetsbaaarheden m.b.t. die ASP.NET ViewState in https://soroush.secproject.com/blog/2019/04/exploiting-deserialisation-in-asp-net-via-viewstate/.

De kwetsbaarheid hier (CVE-2020-0688) was dat alle Exchange servers by default identieke "geheime" sleutels gebruiken voor encryption en/of signing voor de ViewState van het "Exchange Control Panel" (de ViewState die de browser ontvangt nadat iemand met succes daarop is ingelogd).

In het kader van deze kwetsbaarheid ben ik geïnteresseerd wat er na een clean install in web.config staat m.b.t. die ViewState parameters (die niets met TLS te maken hebben). Uit figure 1 in https://www.thezdi.com/blog/2020/2/24/cve-2020-0688-remote-code-execution-on-microsoft-exchange-server-through-fixed-cryptographic-keys blijkt wat ik bedoel (met name 3DES).