Microsoft waarschuwt voor actief misbruikte kwetsbaarheden in Exchange Server

Microsoft waarschuwt voor twee kwetsbaarheden in Exchange Server 2013, 2016 en 2019. Deze worden nu actief door criminelen misbruikt. De twee kwetsbaarheden samen laten hackers op afstand code uitvoeren op systemen.

De eerste kwetsbaarheid, CVE-2022-41040, betreft een Server-Side Request Forgery-kwetsbaarheid. De tweede kwetsbaarheid, CVE-2022-41082, laat gebruikers vervolgens remote code execution uitvoeren mits ze toegang hebben tot PowerShell. Microsoft benadrukt dat geauthenticeerde toegang tot de kwetsbare Exchange Servers vereist is om een aanval uit te kunnen voeren.

Het bedrijf heeft nog geen update uitgebracht voor de kwetsbaarheden, maar zegt dat gebruikers kwetsbare Remote PowerShell-poorten moeten uitschakelen en een blocking rule moeten toevoegen binnen de IIS Manager. Microsoft geeft klanten ook tips over hoe ze aanvallen op basis van deze kwetsbaarheden kunnen opsporen. Microsoft Exchange Online-klanten hoeven geen stappen te ondernemen, stelt het bedrijf. Er wordt volgens Microsoft aan een update gewerkt.

Beveiligingsonderzoekers van GTSC ontdekten de kwetsbaarheden begin augustus. Ze kwamen de kwetsbaarheden op het spoor toen 'kritieke infrastructuur' dankzij de kwetsbaarheden werd aangevallen. Het Vietnamese GTSC zegt meerdere klanten te hebben die met deze kwetsbaarheden zijn aangevallen.

Reacties (70)

[eltweako]

Er is op dit moment nog geen update van microsoft beschikbaar, maar gelukkig wel een eenvoudige mitigatie die je snel live kunt toepassen.

• Ga naar de IIS manager op je Exchange servers en kies onder je default web site de autodiscover.
• Open URL Rewrite
• Klik op Add Rules
• Klik op Request Blocking
• Voer deze string in: “.*autodiscover\.json.*\@.*Powershell.*” (zonder de aanhalingtekens), kies bij Using voor "Regular Expressions" en bevestig met OK
• Klap de nieuwe rule uit met het plusje, en klik op het patern die nu zichtbaar is.
• Kies rechts op edit en wijzig {URL} naar {REQUEST_URI}
• Bevestig met OK

Je bent nu volgens Microsoft beschermd tegen de aanval.
Kleine moeite en beter voor je stressniveau net vlak voor het weekend.

Net al uitgerold op een aantal servers en het heeft geen impact op de beschikbaarheid van de servers. Een reboot van de IIS is niet nodig.

Bron:
https://msrc-blog.microsoft.com/2022/09/29/customer-guidance-for-reported-zero-day-vulnerabilities-in-microsoft-exchange-server/

Met dank aan @Mirano en @robbinkg: mocht je URL Rewrite niet zien:
https://www.iis.net/downl...write#additionalDownloads

[Reactie gewijzigd door eltweako op 23 juli 2024 13:16]

[DVBNL]

Na het doorvoeren een IISreset en je kunt testen of het werkt vanaf een Linux machine:

└─$ curl -X post "https://{EXCHANGE URL}/autodiscover/autodiscover.json?@test.com/%3CExchange-backend-endpoint%3E&Email=autodiscover/[e-mail]" -v |& grep "x-ms-diagnostics:"

test.com is een random entry, maar dit maakt niet uit. Als het goed is returned deze request een error als:

"< x-ms-diagnostics: 2000007;reason="Een potentieel gevaarlijke waarde Request.QueryString is gedetecteerd vanuit de client (="...test.com/<Exchange-backend-en...").";error_category="internal_error"

Dan weet je dat de server niet te exploiten is en dat de block rule binnen IIS werkt.

[SleepingSebbe]

Zou het kunnen dat er toch een fout in de configuratie van de Rule geslopen is?
(en dat elke website dit foutief aan het overnemen is )

Standaard staat de matching method bij een rule op "Wildcard" matching, maar de string lijkt me eerder te suggereren dat het een "Regular Expression" is.

Zie ook https://learn.microsoft.c...rence#rule-pattern-syntax

[Mantis]

In de print screen op de officiële blogpost wordt er inderdaad "Regular Expression" gebruikt.

[Flytezero]

Dit was wildcard, foutje van ze.

[eltweako]

Ik denk dat je gelijk hebt.Net getest, je hebt gelijk.
Scherp opgemerkt, als ik het screenshot bekijk bij Microsoft staat deze ook op regular expression, maar de handleiding rept daar geen woord over.
Ik pas mijn comment aan, bedankt!

[Reactie gewijzigd door eltweako op 23 juli 2024 13:16]

[Flytezero]

Die fout hebben ze later aangepast, wel slecht dit. Wij hadden het gelukkig door dat wildcard fout is. Veel systeembeheerders die het zonder na te denken hebben overgenomen zijn nu misschien niet beschermd.

[johoces536]

De string moet zijn “.*autodiscover\.json.*Powershell.*”
De string die MS adviseert is te bypassen!

https://www.gteltsc.vn/bl...xchange-server-12715.html

https://twitter.com/GossiTheDog/status/1576852912877101057

[Reactie gewijzigd door johoces536 op 23 juli 2024 13:16]

[Mirano]

Ik zie alleen geen URL-Rewrite onder "Autodiscover"

[robbinkg]

https://www.iis.net/downl...write#additionalDownloads Downloaden en uitvoeren, IIS opnieuw openen en het staat er.

[RedShift]

Belangrijk om te weten, tijdens de installatie wordt IIS gestopt en weer gestart.

[Mirano]

Ah deze zie ik later dan ik het zelf al had opgemerkt! dank

[AMS76]

Je moet wel de URL rewrite module geïnstalleerd hebben (is ook best practice op Exchange front-end servers). Eventueel nu nog toe te voegen, is een onderdeel van de IIS installatie.

[Mirano]

Als je URL Rewrite niet ziet:

http://www.iis.net/downlo...write#additionalDownloads

[Mirano]

LET OP

Gebruik wel Wildcard. Anders werkt de autodiscovery niet na het opnieuw opstarten van Outlook binnen de organisaties.

@eltweako Kan jij dit verifieren?

[Reactie gewijzigd door Mirano op 23 juli 2024 13:16]

[kipjr]

Let op! De regex is weer gewijzigd:

(?=.*autodiscover)(?=.*powershell)

bron: https://msrc-blog.microso...icrosoft-exchange-server/

[Williams123]

Ik zag het bericht ook gisteravond. vanmorgen meteen de tijdelijk workaround uitgevoerd op alle exchange servers.

er is ook nog een powershell link commando om te testen of je niet al besmet bent

Get-ChildItem -Recurse -Path <Path_IIS_Logs> -Filter "*.log" | Select-String -Pattern 'powershell.*autodiscover\.json.*\@.*200'

[Urk]

Ik ben een beetje verbaasd. Ik log zojuist in op een Exchange 2019 omgeving die ik beheer en hoewel ik 100% zeker weet dat ik daar nog niks had aangepast stond er onder de Autodiscover virtual dir in IIS al de regel:
Condition input: {REQUEST_URI}
Check if input string: Matches the pattern
Pattern: .*autodiscover\.json.*\@.*Powershell.*

Vreemd toch?! Hoe kan dit...? Heeft MIcrosoft via de Exchange Emergency Mitigation (EM) service gepushed naar servers?

@HellBeast: goed dat je dit benoemd, ik heb hem aangepast

Edit: De naam van de regel is trouwens EEMS M1.1 PowerShell - inbound dus die moet zeker door de Exchange Emergency Mitigation Service zijn ingesteld automatisch

Edit2: Ik heb nu voor de zekerheid de rule iets uitgebreid nav de post van @HellBeast, als volgt:
Condition: Match Any

{REQUEST_URI} - Matches the pattern - .*autodiscover\.json.*\@.*Powershell.*
{REQUEST_URI} - Matches the pattern - .*autodiscover\.json.*Powershell.*
Ignore case AAN

Meer info over EEMS.

[Reactie gewijzigd door Urk op 23 juli 2024 13:16]

[Piemol]

Niet direct in paniek raken...

It should be noted that authenticated access to the vulnerable Exchange Server is necessary to successfully exploit either of the two vulnerabilities.

Dus er moet al wat aan de hand zijn als een kwaadwillende toegang heeft.

[robertlinke]

er hoeft maar 1 iemand te reageren op een 2FA spam attack en je heb je credentials.
als je in een grote organisatie werkt met een paar 100 man, en ze suten die 2FA messages en mass naar iedereen is er vaak wel 1 zo stom om er op te klikken

[GoeiedagEem]

Hoe zie je dat voor je? Die push notification fatigue attacks gaan er vanuit dat gebruikersnaam en wachtwoord bekend zijn, zonder die twee kunnen ze de MFA spam niet opzetten.

Info: https://portswigger.net/d...oad-of-push-notifications

Dus hoe zouden ze je gebruikersnaam en wachtwoord dan achterhalen met zo'n attack?

[robertlinke]

ok ik heb het niet goed verwoord, dat klopt duidelijk wel.
de credentials moet je al hebben, en dan kun je de authorization krijgen.
probleem is dat het krijgen van credentials meestal niet moeilijk is.

[e-mail] is vaak de standaard voor username
en dan is het gewoon vaak gebruikte passwords proberen totdat je de 2fa gestuurd krijgt.
en daarna is het spammen tot iemand erop reageerd.

[Blokker_1999]

Veel inbrekers maken gebruik van een keten van kwetsbaarheden. Een account zonder rechten buit maken en dan software vinden die exploiteerbaar is waardoor uiteindelijk privilege escalation mogelijk wordt en je zo weer verder door in het netwerk kunt.

Ja, het feit dat je reeds credentials moet hebben zorgt ervoor dat het niet zomaar misbruikt kan worden door elk script kiddy, maar dat wil niet zeggen dat je het tot met Kerst kunt laten liggen.

[Piemol]

Uiteraard, maar ik postte dit meer als tegenhanger van de eerste paar reacties in de trend van "moord en brand" en "zeg alle afspraken dit weekend maar af".

[DigitalExorcist]

Probeer jij maar eens te garanderen dat niet ergens een account van één van de gebruikers van je mailserver ontvreemd is en dat er dus al mensen zijn die die toegang gewoon al hebben.....

Ik zou die afspraken toch maar even cancellen.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 13:16]

[AMS76]

Voor 5 minuten werk om de URL rewrite in te stellen in je front-end IIS zou ik toch echt niet het hele weekeinde vrij nemen...

[DigitalExorcist]

Als je alleen de IT van je eigen organisatie doet valt het mee, als je 100 klanten hebt die allemaal hun Exchange servers hebben wordt het 500 minuten.

[AMS76]

Dan hoop ik toch dat je dat niet alleen hoeft te doen maar ja, dan wordt het wel anders ja.

[Verwijderd]

100 klanten met Exchange Servers aanpassen ... Automation ? We zijn toch 2010 al voorbij hé ?
Kan gerust met Powershell gedaan worden:

$site = "iis:\sites\Default Web Site\Autodiscover"
$filterRoot = "system.webServer/rewrite/rules/rule[@name='BlockPS1']"
Add-WebConfigurationProperty -pspath $site -filter "system.webServer/rewrite/rules" -name "." -value @{name='BlockPS1' + $_ ;patternSyntax='Regular Expressions';stopProcessing='True'}
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/match" -name "url" -value ".*"
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/conditions" -name "logicalGrouping" -value "MatchAny"
Add-WebConfigurationProperty -pspath $site -filter "$filterRoot/conditions" -name "." -value @{input="{REQUEST_URI}";matchtype="Pattern";pattern=".*autodiscover\.json.*\@.*Powershell.*"}
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/action" -name "Type" -value "CustomResponse"
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/action" -name "statusCode" -value 403
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/action" -name "SubstatusCode" -value 0
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/action" -name "statusReason" -value "Forbidden: Access is Denied"
Set-WebConfigurationProperty -pspath $site -filter "$filterRoot/action" -name "statusDescription" -value "GTFO: You do not have permission to view this directory or page using the credentials that you supplied."

[Reactie gewijzigd door Verwijderd op 23 juli 2024 13:16]

[Blokker_1999]

En dan hoop ik vooral de je de nodige automatisatie voorziet om het te doen.

[Piemol]

Dat kan geen enkele IT'er garanderen

[DigitalExorcist]

Als MS nou eens met een tool zou komen om ingestelde wachtwoorden te matchen tegen databases met gelekte wachtwoorden.....

Het is net als met een voetbalwedstrijd. Je gaat niet ál je vertrouwen aan de keeper geven dat die de bal wel tegen zal houden. Als de tegenstander schiet en de keeper houdt 'm, good for him, maar dan heb je alle reden om in elk geval de middenvelders en de verdedigers op hun falie te geven.

Oftewel.. je kunt ook wachten tot MS Defender een alarmpje triggert (en dat doet ie). Maar vóórdat Defender in actie moet komen heb je al genoeg verdedigingslinies die op orde hadden moeten zijn.

[Reactie gewijzigd door DigitalExorcist op 23 juli 2024 13:16]

[Williams123]

Als je de AD login gebruik voor Exchange ook kan je dat makkelijk met powershell testen.

$pwnfile = "C:\Powershell\pwned-ntlm-hash-v8.txt"
$DC = "domein.nl"
$Domain = "DC=domein,DC=nl"
Get-ADReplAccount -All -Server $DC -NamingContext $Domain | Test-PasswordQuality -WeakPasswordHashesSortedFile $pwnfile

download de file https://haveibeenpwned.com/Passwords
je zien dan of gebruikers een wachtwoord gebruiken die in de txt file staat.

[Reactie gewijzigd door Williams123 op 23 juli 2024 13:16]

[DigitalExorcist]

Ja, je kan het reactief wel scripten, maar bij het instellen van je password zou het ook wel handig zijn. Hoewel, MS wil natuurlijk van wachtwoorden af (terecht ook).. en met MFA leg je er nog een extra hindernis bovenop.. dus of het écht nut heeft..? Maar het zou wel prettig zijn.

[Williams123]

Het zou leuk zijn als iets in Windows zat ja. Dit is beter dan helemaal niet controleren.

[Mantis]

Dit bestaat en is best eenvoudig te implementeren: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-operations

[Verwijderd]

De meeste 3rd party MFA leveranciers bieden zulke tools of services aan. MS zelf (nog) niet ... maar de vraag daarnaar is vrij groot.

[DigitalExorcist]

Yep. En ik weet wel hoor, MS wil af van wachtwoorden, maar zo ver zijn we helaas nog niet.

[_Dune_]

Klopt, als men dit kan uitvoeren is men in principe al binnen jouw netwerk en geautentiseerd en dan heb je al een ander veel groter probleem.

Snel mitigeren: https://msrc-blog.microso...icrosoft-exchange-server/

edit: typo

[Reactie gewijzigd door _Dune_ op 23 juli 2024 13:16]

[SuperDre]

Juist, en als ze daar al toegang tot hebben dan geb je denk ik wel meer zorgen te maken dan alleen deze kwetsbaarheid in Exchange (die natuurlijk ook zo snel mogelijk opgelost wordt). Maar dat soort informatie staat vaak puur 'tussen neus en lippen door' in artikels.

[robertlinke]

voor dit soort dingen is office365 geen slecht idee.
ik ben nu zelf voor de AZ-801 bezig, en de hoeveelheid security en compliance je kan inzetten in azure is best indrukwekkend, zeker als je niet zo bekend bent met security/infosec.

[iFap]

Nou, veel organisaties hebben al Exchange Online draaien maar meestal in een hybride setup. Dan ben je alsnog kwetsbaar. En zolang je Active Directory gebruikt kom je voorlopig ook niet af van de hybrid Exchange server.

[Yodocus]

Inmiddels wel.

[robertlinke]

AZ-800 nerd moment incoming:
je kan de Azure AD tenant gebruiken om via password writeback users the autoriseren via de cloud AD, zolang je een on-premise ADDS of ADFS omgeving heb. heb je dus geen lokale database van user credentials nodig, maar nog wel een AD. en je kan in theorie je MX omgeving geheel liften de cloud in, en dan langzaam je features migraten naar O365.

[segil]

Maar dan moet je nog steeds je mail objecten beheren via je lokale AD. Zolang je ADDS gebruikt als source of authority ontkom je daar niet aan. Gelukkig heeft MS een klein half jaar geleden een PS module uitgebracht, die kan dienen als management oplossing van mail objecten, ter vervanging van Exchange. Alhoewel je nog wel een Exchange org nodig hebt, kunnen de Exchange servers uitgezet worden.

[nehal3m]

Round and round we go. Voor MKB'ers is het hopen dat hun IT service providers goede update procedures op orde hebben, anders wens ik de sysadmins werkzaam aldaar sterkte voor het weekend.

[Calamor]

Als ze al iemand of een bedrijf in dienst hebben voor zulke taken.
Er zullen wel bedrijven zijn die dat niet hebben en niet op de kanalen zitten dat ze info krijgen dat dit speelt.

Als ze er niet direct van merken. Als het voor hun werkt zo als het zou moeten werken.

[DigitalExorcist]

Er valt alleen nog niks te updaten.

[Verwijderd]

Zijn er nog veel MKB's die een Exchange-server draaien? Voor de meesten komt het goedkoper om gewoon een Office365 abbo te nemen.

[nehal3m]

Dat klopt, maar de migratie brengt vaak ook kosten en/of downtime met zich mee. Nu valt dat in de praktijk vaak wel mee, maar het zijn toch weer kosten en gedoe waar de meeste MKB'ers niet op zitten te wachten. De laatste keer dat ik bij een managed service provider werkte waren er nog een paar tientallen die on premise Exchange draaiden.

[Polderviking]

Nou succes hier maar weer mee zo even voor het weekend...
Zo blij dat ik al jaren geleden afscheid heb genomen van on premise email.

[Reactie gewijzigd door Polderviking op 23 juli 2024 13:16]

[AMS76]

Ach, de URL rewrite regel was in 5 minuten gedaan, en de remote powershell poorten stonden bij ons sowieso al dicht. Dus, zoveel werk was het niet

[DrPoncho]

Wellicht dat zijn bericht dan niet op jou sloeg, maar je bent vast niet de enige Exchange manager hier

[jaenster]

Hoewel ik best snap dat je dingen zelf wil hosten, zou mail toch wel iets zijn wat ik zou uitbesteden. De lijst met kwestbaarheden is zo groot, elke mail die je verstuurd word gezien als spam, want het komt niet van een grote partij.

[Polderdijk]

Nou dat elke uitgaande mail als spam wordt gezien valt wel mee. Alleen weten heel veel IT-ers niet goed (genoeg) hoe je een mailomgeving moet opzetten. Succes valt of staat met genoeg kennis. Als je alles goed opzet heb je amper last van uitgaande spam markeringen.

Heel vroeger nog wel eens last met Hotmail of KPN mail, maar dat lag dan weer aan hun en kon je idd weinig aan doen. Gelukkig allemaal tijdelijke problemen die ze relatief snel hadden opgelost.

[Verwijderd]

Zelf jarenlang mail-admin geweest voor grote bedrijven, en ook eigen mail-server beheerd voor mezelf. Uiteindelijk heb ik het opgegeven. Zelfs als je alles juist instelt van SPF tot DMARC, als je IP niet de juiste reputation-score heeft, blijft de kans groot dat grote providers je als spammer beschouwen. En die score kan je alleen verhogen door grote hoeveelheden "goede" emails te versturen of te betalen (of een combinatie van beide).

Op een bepaald moment was het sop de kolen niet waard Zelfs de meeste grote bedrijven (inc. multinationals) waar ik voor gewerkt heb zijn ondertussen overgegaan op een hosted alternatief (meestal Office365 of Google Mail). De kosten van infrastructuur en personeel om e-mail omgeving te houden werden gewoon te hoog, en kosten/baten kwam een hosted alternatief beter uit. De resources die hierdoor vrijkwamen konden beter benut worden.

[smurfjeffrey]

ik heb zelf in een VPS exchange server willen opzetten maar is inderdaad erg compleg met omzetten en inrichten als je niet de juiste kennis hebt en dan moet het ook nog onderhouden worden en dan krijg je dit soort dingen ook nog

[Blokker_1999]

Maar voor persoonlijk gebruik zou ik nooit naar Exchange kijken. Daarvoor is het product te groot en te complex. Er bestan veel eenvoudigere oplossingen.

[MischaBoender]

Zoals @jaenster ook al aangeeft, dat ligt vooral aan de configuratie van de omgeving. Belangrijk zijn vooral SPF, DKIM, DMARC en TLS voor SMTP (en bij voorkeur ook MTA-STS). Maar als je de rest van je security niet goed op orde hebt en iemand is in staat misbruik te maken van jouw mail omgeving dan kom je snel op een deny-list te staan.

[Keypunchie]

Mee eens dat als MKB je er niet zelf aan moet beginnen. De voordelen zijn erg laag, terwijl je voor competitieve prijzen terecht kunt bij service providers.

[Verwijderd]

Exchange Online klanten hoeven dan geen actie te ondernemen. Maar draait dat in basis ook niet gewoon op Exchange?
MS zal dan wel het e.a. mitigeren voor O365 klanten, maar lijkt mij dat ook daar de cve's van toepassing zijn (geweest)?

[Amendeon]

Volgens de Microsoft berichtgeving is Exchange Online inderdaad ook kwetsbaar, maar hebben ze zelf de mitigatie maatregelen doorgevoerd.

[G_Dragon]

Dat is geen leuk bericht voor alle MKB'ers zo voor het weekend, hopelijk hebben ze alles goed op orde!