Cookies op Tweakers

Tweakers is onderdeel van DPG Media en maakt gebruik van cookies, JavaScript en vergelijkbare technologie om je onder andere een optimale gebruikerservaring te bieden. Ook kan Tweakers hierdoor het gedrag van bezoekers vastleggen en analyseren. Door gebruik te maken van deze website, of door op 'Cookies accepteren' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt? Bekijk dan ons cookiebeleid.

Meer informatie

Microsoft dicht zerodays in Exchange 'die misbruikt zijn door Chinese hackers'

Microsoft heeft vier zeroday-kwetsbaarheden gedicht in Exchange Server. Die zouden misbruikt zijn door Chinese spionnen om data te stelen van Amerikaanse defensie-aannemers, advocatenkantoren en infectiologen.

Microsoft heeft verschillende zeroday-exploits ontdekt in Microsoft Exchange Server die gebruikt zijn in een aantal gerichte aanvallen op Amerikaanse slachtoffers. Dat schrijft Microsoft in een securityblog. De kwetsbaarheden gaven de aanvallers toegang via on-premise Exchange-servers die versies 2013 tot 2019 draaien, en daarmee toegang tot e-mailaccounts, waarna zij malware konden installeren. Microsoft roept gebruikers op zo snel mogelijk een patch te installeren.

Microsoft schrijft de exploits 'met grote zekerheid' toe aan de Chinese hackersgroep Hafnium. Dat is een groep die gelinkt wordt aan de Chinese regering en zich actief richt op het stelen van gegevens van Amerikaanse personen die onder andere werken bij advocatenkantoren, in het hoger onderwijs, bij politieke denktanks en non-profits. Ook richt de groep zich op defensie-aannemers en infectiologen. Hafnium werkt voornamelijk vanaf gehuurde virtual private servers in de VS, zegt Microsoft.

In dit geval werden vier zerodays ontdekt die actief misbruikt zijn. Kwetsbaarheid CVE-2021-26855 gaf aanvallers de mogelijkheid om arbitraire HTTP-requests te versturen en zich voor te doen als Exchange-server. CVE-2021-26857 gaf de aanvallers de mogelijkheid om code te draaien met veel rechten op een Exchange-server, waarbij de hackers volledige admintoegang nodig hadden of door gebruik te maken van de vorige kwetsbaarheid. Met kwetsbaarheden CVE-2021-26858 of CVE-2021-27065, kregen de hackers de mogelijkheid om bestanden te schrijven naar elke plek op de Exchange-server die ze wilden.

De hackers werkten volgens Microsoft in drie stappen. Allereerst kregen ze toegang tot on-premise Exchange-servers door deze kwetsbaarheden te misbruiken of door gestolen wachtwoorden te gebruiken. Vervolgens kon Hafnium web shells op de Exchange-servers opzetten, waarna de hackers op afstand beheer van de server konden overnemen. Vervolgens lukte het de hackers data te stelen en malware te plaatsen. Ook lukte het de hackers om volledige adresboeken te downloaden, waarna zij informatie kregen over organisaties en gebruikers. Microsoft zegt de Amerikaanse overheid van de aanvallen op de hoogte te hebben gebracht.

Beveiligingsbedrijf Volexity ontdekte twee van de kwetsbaarheden in januari, nadat het ontdekte dat een grote hoeveelheid data naar verdachte ip-adressen werd gestuurd. In eerste instantie dacht Volexity dat er gebruik werd gemaakt van een backdoor, maar al snel kwam het bedrijf erachter dat het ging om meerdere zerodays. Voor misbruik van een van de zerodays is geen enkele authenticatie nodig. Een aanvaller hoeft alleen maar te weten welke server Exchange draait en van welk e-mailadres het data wil stelen. In een blog legt het bedrijf uitgebreid uit hoe de kwetsbaarheden misbruikt konden worden.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Door Stephan Vegelien

Redacteur

03-03-2021 • 11:11

97 Linkedin

Submitter: RobinF

Reacties (97)

Wijzig sortering
Het NCSC heeft al een beveiligingswaarschuwing met predicaat hoog/hoog gecommuniceerd: https://www.ncsc.nl/actueel/advisory?id=NCSC-2021-0200

Overigens is ook Exchange 2010 vatbaar, ook hier heeft Microsoft een patch voor uitgebracht; zie https://techcommunity.mic...rity-updates/ba-p/2175901

Het advies is om deze patches per direct te installeren al dan niet om de HTTP/HTTPS (OWA, ECA, etc) diensten van Exchange (tijdelijk) te blokkeren totdat de patches zijn geïnstalleerd.
Het advies is om deze patches per direct te installeren al dan niet om de HTTP/HTTPS (OWA, ECA, etc) diensten van Exchange (tijdelijk) te blokkeren totdat de patches zijn geïnstalleerd.
Dan werkt ActiveSync ook niet meer.

Dat gaat zeer waarschijnlijk nergens goedgekeurd worden dat alle mobiele telefoons geen mail meer hebben in een mkb organisatie.

[Reactie gewijzigd door Dennisb1 op 3 maart 2021 12:43]

Want dat bedrijfsgegevens potentieel gestolen worden is natuurlijk meer acceptabel 8)7...
Dat is de afweging die elke organisatie voor zichzelf moet nemen. Hoe groot is daadwerkelijk het risico vs impact.

[Reactie gewijzigd door Dennisb1 op 3 maart 2021 13:01]

Dit lijkt me toch een no brainer? Of wou je op voorhand alvast je document voor de AP klaarmaken als je gegevens uitlekken?
Het niet uitrollen van een update dat actief misbruikt wordt, is wachten op dat het op de black market e.d. te vinden is. Dan is het simpel een shogan.io dump te gebruiken en snel alle servers infecteren die te traag zijn met updates, en daar zit meestal iedereen die een server host bij. Een beetje virus zal zich dan ook verspreiden door elke server die geinfecteerd is weer te gebruiken om nieuwe servers te zoeken.
Gegeven het feit dat er reeds honderdduizenden organisaties getroffen zijn zou ik zeggen dat het risico zeer hoog is. De exploit is bekend en gewoon uitvoerbaar. Hoeveel groter kan het risico nog zijn?
Je kunt de OWA webpagina wel prima onklaar maken zonder Active Sync functionaliteit te verliezen hoor. Voor een klant die dit expliciet vroeg hebben we een aanpassing gemaakt in de reverse proxy waardoor je de website niet meer kunt benaderen maar nog wel mail kunt ophalen via een telefoon. (Dit is geen mooie security oplossing wat we ook de klant hebben gemeld, maar die wilde dit toch.)
Ik vermoed dat ze de EWS ook kunnen aanvallen, dus enkel OWA onklaar maken is misschien niet genoeg. En EWS onklaar maken is vragen om grote problemen met het beheer.

[Reactie gewijzigd door GoBieN-Be op 3 maart 2021 16:10]

Ik vraag me af of het probleem zich beperkt tot on-premise exchange servers, aangezien je EWS ook bij office365 kan gebruiken.
In de notice die Microsoft heeft uitgestuurd wordt beschreven dat het bij Exchange Online (Microsoft 365) niet van toepassing is.
Maar die patched MS natuurlijk gewoon zelf, zo snel als ze kunnen bij dit soort incidenten. Kans is groot dat het probleem in o365 al was opgelost nog voor het nieuws bekend werd gemaakt.
Dan denk ik niet dat je doorhebt wat het verschil is tussen Exchange met Outlook en Protonmail. Of wat bedrijven allemaal doen met hun Exchange en Outlook. Het is zoveel meer dan gewoon wat mailtjes versturen.
Dit gaat over Exchange on premise. Niet over O365.
En waarom zou het minder erg zijn als de gegevens naar Zwitserland gaan?!
Goede vraag. (Ik heb werkelijk geen idee waarom je -1 gemod wordt. Dit is geen agressie vraag, niet opruiend of aanstootgevend.)

Mijn vermoeden is dat Zwitserland EU regels voor persoonsgegeven aanhoudt en daarom meer privacy vriendelijk is. Bovendien is Proton.mail een betrouwbare en onafhankelijke partij.
Ik denk dat je Microsoft ook als een betrouwbare partij kunt zien. Althans als je naar het klanten bestand kijkt dan hebben een hoop AEX/NASDAQ bedrijven er vertrouwen in en plaatsen ze steeds meer data in Azure & Office365.

Gaan er dingen fout zeker, de vraag is hoe snel kun je mitigeren als bedrijf. Ik heb er meer verrouwen in dat een bedrijf als MSFT snel maatregelen kan nemen dan een kleinere club. Wist je dat MSFT 1 miljard per jaar investeerd in security?

https://www.cybersecurity...r-year-on-cyber-security/
Ik ben nu 16 Exchange servers, 2010 2013 en 2016 aan het updaten, en dit tweakers artikel en jouw comment voor 2010 zijn enorm behulpzaam. gaat grotendeels goed tot nu toe. bedankt!

SP 1 naar SP 3 upgraden lukt niet goed.
Een server 2010 SP 1 naar 3 gekregen, maar patch failed unexpectedly.
Een andere 2010 SP1 ging helemaal kapot tijdens SP1 naar SP3. Met veel moeite weer werkend gekregen.
Maar toch ook een 1 of 2 SP1 naar RU32 gekregen.

[Reactie gewijzigd door Yontekh op 5 maart 2021 08:22]

Microsoft heeft ook een Webcast gehouden over dit onderwerp. De sheets zijn hier te vinden. Hier staat ook in waar naar gekeken moet worden om te zien of er misbruik van gemaakt is van het lek.
Ik probeer de IOC's te checken;

MS geeft het onderstaande powershell commando aan op: https://www.microsoft.com...rgeting-exchange-servers/

Dit commando lijkt niet direct bij mij te werken, de loglocatie is wel hetzelfde. Iemand een idee wat er mis is met onderstaande powershell commando?
Import-Csv -Path (Get-ChildItem -Recurse -Path “$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy” -Filter ‘*.log’).FullName | Where-Object { $_.AuthenticatedUser -eq ” -and $_.AnchorMailbox -like ‘ServerInfo~*/*’ } | select DateTime, AnchorMailbox
BRON: https://techcommunity.mic...rity-updates/ba-p/2175901

The following article contains instructions for detecting whether CVE-2021-26855 exploitation has taken place

Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName | Where-Object { $_.AuthenticatedUser -eq " -and $_.AnchorMailbox -like 'ServerInfo~*/*' } | select DateTime, AnchorMailbox
https://www.microsoft.com...rgeting-exchange-servers/

The command is broken (it will never execute and generates a PowerShell continuation prompt (>>). This can be fixed by changing the double quote after $_.AuthenticatedUser -eq " to two single quotes '' - please update the article ASAP!

Import-Csv -Path (Get-ChildItem -Recurse -Path "$env:PROGRAMFILES\Microsoft\Exchange Server\V15\Logging\HttpProxy" -Filter '*.log').FullName | Where-Object { $_.AuthenticatedUser -eq '' -and $_.AnchorMailbox -like 'ServerInfo~*/*' } | select DateTime, AnchorMailbox
Wat nou als de powershell daadwerkelijk iets vind?
Ik ben al een tijdje naar de juiste zoekopdrachten aan het zoeken, maar we hebben bijvoorbeeld 4 hits met bovenstaande powershell: meestal naar: /ecp/y.js en vanaf: 86.105.18.116.
Dit zien we op meerdere exchange servers. Maar verder zien we niet de bestanden etc, die ze in het Microsoft document aangeven..

Is het dan goed? en kunnen we rustig slapen?
Ik zit met exact hetzelfde vraagstuk, vanaf hetzelfde IP adres.
Ik kom het IP tegen in meerdere logs maar kan niet goed bepalen of er actief misbruik is gemaakt.
ben je hier al achter gekomen? Ik kom schrikbarend weinig info tegen hierover.
Laat antwoord.. (zelfde probleem hier pas vanmorgen een voor mij afdoende uitleg gevonden)

deze site legt uit wat de hack met /ecp/y.js CVE-2021-26855 doet.
https://www.volexity.com/...zero-day-vulnerabilities/

in het kort.. mail downloaden van je server waarvoor de hacker slechts een e-mail adres op je server goed moet gokken.
in mijn geval had ik 12 log lines, welke alle in de ResponseBytes kolom rond de 362 bytes download aangaven..

In 362 bytes past misschien net de SAOP envelope.. voor de inhoud van een e-mail of een lijst van de berichten in een inbox is dat te klein.

Indien je loglines heb die veel grotere responses geven, dan heb je waarschijnlijk een probleem..
Indien je net als ik een aantal van die kleine responses heb, ben je waarschijnlijk slechts gescanned als potentieel toekomstig target.

[Reactie gewijzigd door MvGroenigen op 5 maart 2021 10:50]

Thanks,

Ik had zelf ook al de conclusie getrokken dat het waarschijnlijk alleen een scan was, gezien de tijdstippen op meerdere exchange servers gelijk lagen.

Uiteindelijk hebben we ook niet meer in de http logs kunnen vinden dan alleen deze scan poging.
Idem. Na de patch krijgt-ie een 500 HTTP status code.
Gezien deze opmerking:

In the case where a single server is being used to provide the Exchange service, Volexity believes the attacker must know the targeted user’s domain security identifier (SID) in order to access their mailbox. This is a static value and is not considered something secret. However, it is not something that is trivially obtained by someone without access to systems within a specific organization.

In a multiple server configuration, where the servers are configured in a Database Availability Group (DAG), Volexity has proven an attacker does not need to acquire a user’s domain SID to access their mailbox. The only information required is the e-mail address of the user they wish to target.

Ben ik aardig gerust gesteld, wij hebben niet veel klanten met multiple exchange servers.
Hier wel DAGs helaas.
Je bent geweldig! The power of Tweakers :). Had er al naar gezocht maar kon nergens feedback op het artikel vinden.
Microsoft heeft ondertussen een "All in One" script op github gezet om je servers te scannen

https://github.com/microsoft/CSS-Exchange/tree/main/Security

Ze werken het redelijk actief bij.. dus kan geen kwaad om dagenlijks te checken of er updates zijn en eventueel nieuwe versies opnieuw te draaien
Let goed op dat je patch als admin uitvoerd!!!
Waarom? Iets meer info was interessant geweest ;-)
When you try to manually install this security update by double-clicking the update file (.msp) to run it in normal mode (that is, not as an administrator), some files are not correctly updated.

When this issue occurs, you don’t receive an error message or any indication that the security update was not correctly installed. However, Outlook on the web and the Exchange Control Panel (ECP) might stop working.

This issue occurs on servers that are using User Account Control (UAC). The issue occurs because the security update doesn’t correctly stop certain Exchange-related services.
Daar hadden ze wel een betere check in kunnen bouwen. Wat een gepruts...
Klopt, dit is een weetje als beheerder op het moment dat je .MSP handmatig gaat installeren. Als je het via windows updates doet dan is dit uiteraard niet nodig.

Gewoon even powershell of CMD uitvoeren als admin -> msp uitvoeren.
Ter info: dit is altijd een lastig probleem dat voorkomt bij het handmatig installeren van iedere Exchange security update.

Je moet hier dus rekening mee houden als je de patch handmatig download en installeert. Wanneer je de update installeert via Windows Update of SCCM dan hoef je hier geen rekening mee te houden.
When you try to manually install this security update by double-clicking the update file (.msp) to run it in normal mode (that is, not as an administrator), some files are not correctly updated.

When this issue occurs, you don’t receive an error message or any indication that the security update was not correctly installed. However, Outlook on the web and the Exchange Control Panel (ECP) might stop working.

This issue occurs on servers that are using User Account Control (UAC). The issue occurs because the security update doesn’t correctly stop certain Exchange-related services.

To avoid this issue, follow these steps to manually install this security update.

Note: This issue does not occur if you install the update through Microsoft Update.

Select Start, and type cmd.

In the results, right-click Command Prompt, and then select Run as administrator.

If the User Account Control dialog box appears, verify that the default action is the action that you want, and then select Continue.

Type the full path of the .msp file, and then press Enter.
https://support.microsoft...21-4ee7-b9da-fa85b3e1d23b
Hadden ze niet even een check in kunnen bouwen zodat je niet toevallig tegen dit probleem aan loopt omdat je met 100 dingen tegelijk bezig bent?
Wellicht moet je niet 100 andere dingen doen als je zerodays handmatig aan het patchen bent?
jup... en eerst de handleiding lezen voordat je begint O-)
Wie voert er patches op een server niet als admin uit? Voor degenen die geen handleidingen lezen zou dat standaardpraktijk moeten zijn, in plaats van andersom.

[Reactie gewijzigd door mae-t.net op 3 maart 2021 13:00]

Kan je vinden, blijft een feit dat als de patch aangeeft succesvol te zijn geinstalleerd je geen zorgen hoeft te maken over bestanden die wel of niet zijn geupdate.
Known issues in this update
When you try to manually install this security update by double-clicking the update file (.msp) to run it in normal mode (that is, not as an administrator), some files are not correctly updated.

When this issue occurs, you don’t receive an error message or any indication that the security update was not correctly installed. However, Outlook on the web and the Exchange Control Panel (ECP) might stop working.

This issue occurs on servers that are using User Account Control (UAC). The issue occurs because the security update doesn’t correctly stop certain Exchange-related services.

To avoid this issue, follow these steps to manually install this security update.
Het zou vreemd zijn als je patches voor services als gewone gebruiker kan uitvoeren terwijl het nodig is om admin te zijn. Dan mag verwacht worden dat je een melding krijgt dat je de verkeerde rechten hebt en de pach dus niet werkt. Het heeft weinig zin om patches uit te laten voeren met een vals gevoel van veiligheid.

[Reactie gewijzigd door kodak op 3 maart 2021 11:39]

Het punt is dat je bij het uitvoeren van de patch wel de UAC krijgt, maar dat is niet hetzelfde als run as admin helaas.
Dat het niet hetzelfde is weet Microsoft, ze hebben het zelf zo ontworpen. Het punt is dus meer of microsoft rekening heeft gehouden dat het niet hetzelfde is en waarom niet als het nu (weer) een probleem is en miljoenen klanten daardoor extra risico lopen.
of je leest eerst de handleiding die bij de patch hoort....
Er verschijnen per keer heel veel patches van diverse leveranciers. Ondertussen zijn de leveranciers overgegaan op het zo makkelijk mogelijk maken van de patch uitrollen met lezen en klikken. Dan kan je niet verwachten dat veel klanten steeds maar alle handleidingen gaan lezen op zoek naar mogelijke uitzonderingen die de patches al jaren afvangen.

Natuurlijk is het verstandig dat je als klant weet wat de risicos bij een patch zijn, maar miljoenen klanten met dat uitzoekwerk opzadelen (en dus vele werkjaren per patch laten investeren in het opknappen van de fouten van de leverancier) is niet redelijk. Niet voor niets betalen al die klanten veel geld voor veilige software en veilige updates.
en toch moet je dat wel doen, omdat er genoeg patches zijn die behoorlijk ingrijpend kunnen zijn voor de werking van software. Als het goed is test je eerst de patches in een OTA omgeving en daarna in Productie.
Mocht je daar allemaal geen tijd voor hebben, dan wordt het waarschijnlijk toch voor extra mankracht.
Het is zó makkelijk praten als je er niet zelf in zit. ik ben het heel erg eens met Kodak, er staat al genoeg druk op ICT organisaties, er is een schreeuwend tekort aan mensen die weten wat ze doen en dit is simpel genoeg af te vangen met een check.. Hell, ik bouw het in elk powershell script in (waarbij het nodig is), omdat het zo simpel te implementeren is.
Als admin installeren is toch nog altijd standaardpraktijk als je de handleiding niet leest. Je komt dan alleen in de problemen bij patches die juist niet als admin geinstalleerd moeten worden (zijn die er?).

Wel mee eens dat het een beetje slordig is dat MS vergeten is hoe UAC ook alweer werkt.
Kennelijk niet perse standaard als ik de reacties zo lees. En dat is ook niet zo vreemd als je updates krijgt die het je zo makkelijk mogelijk maken om de juiste rechten te eisen voordat het daardoor mis gaat. Wat ik alleen nog niet lees is of deze verwijzing naar de juiste rechten echt nodig is of microsoft het er slechts extra bij zet zodat je vooraf kan lezen wat nodig is.
Wat is het verschil dan?
goede tip, staat ook in de MS documentatie.
Wel grappig om dan weer de Chinezen in het verhaal te betrekken, om de aandacht van het echte probleem af te leiden.

De bugs zaten toch echt en de Software van Microsoft.
Het is in de context van het artikel toch relevant om te laten weten dat de kwetsbaarheid actief wordt misbruikt en door wie? Meestal staat in dit soort artikelen dat men vermoedt dat de gevonden kwetsbaarheden (nog) niet uitgebuit worden, maar nu dat wel zo is lijkt het me relevant voor beheerders om te weten vanuit welke hoek ze potentieel een aanval kunnen verwachten.

In software zitten nu eenmaal bugs. Deze keer is het Microsoft, de volgende keer de Linux kernel en daarna weer een ander veel gebruikt stuk software. Dat het dit keer Microsoft betreft staat duidelijk in de titel van het artikel, dus het is niet alsof er wordt geprobeerd om dat onder de mat te vegen.
Het maakt toch niet uit wie de exploits gebruikt.
Velen exploids worden gebruikt door net zoveel overheden, en over westerse overheden horen we nooit iets?
Het maakt toch niet uit wie de exploits gebruikt.
Daar verschillen we dan over van mening.
Velen exploids worden gebruikt door net zoveel overheden, en over westerse overheden horen we nooit iets?
Onzin. Toen het hele debacle rondom Stuxnet aan het licht kwam is er uitgebreid in de media gerapporteerd over hoe deze malware is gemaakt en de wereld in is geholpen door de VS en Israël. En zo zijn er vast nog andere voorbeelden te vinden.

De grootste reden dat we hier in het westen weinig horen over cyberaanvallen vanuit het westen op doelen in bijvoorbeeld Rusland, China of het Midden Oosten is omdat er hier sowieso weinig van wat er in deze regio's gebeurd in het nieuws komt. Blijkbaar zijn we in onze westerse maatschappij niet heel erg geïnteresseerd in wat er in deze delen van de wereld speelt, behalve als zij iets doen dat direct impact heeft op ons.
Het is zeker belangrijk om te weten wie dit misbruikt. Dit maakt deel uit van security overwegingen wat betreft risico. Als het Chinese staats hackers zijn is dat een andere overweging dan dat criminele bendes dit doen, natuurlijk geheel afhankelijk van in wat voor organisatie je werkt. Het is natuurlijk niet fijn dat het gebeurt en het moet worden opgelost. Het zou me niets verbazen als sommige (type) organisaties direct hun Exchange server uitzetten of er direct de netwerkstekker uittrekken.
Het is Babi Pangang, en dat is een Indonesisch gerecht, geen Chinees.
Ik zou zeggen lees het artikel, staat gewoon in beschreven dat het op basis van doelwitten, gebruikte methodiek enz logisch lijkt dat het een bepaalde afkomst heeft.
Daar zegt Microsoft zelf ook dat het niets meer dan waarschijnlijk is, geen feit maar wel aannemelijk op basis van hoe ze te werk gaan.
Is nogal logisch omdat vanuit daar de zero day's massaal gebruikt worden om in instellingen in America te komen.
Apart, ik zie toch echt dat MS ook genoemd wordt.

Voor beheerders is het allebei nuttige informatie. Je moet weten wie het lek in handen heeft zodat je kunt inschatten hoe groot het acute risico voor jou is, en je moet weten in welke software het lek zit zodat je het kunt patchen.

Aan beide voorwaarden is prima voldaan.

Ter context: het noemen van China ligt wat gevoelig, omdat het geen onderscheid maakt tussen het regime en de mensen - een onderscheid dat door het regime ook actief ontkend en bestreden wordt, dus daar moet je niet intrappen. Je kunt er gevoegelijk van uitgaan dat bij dit soort berichten altijd het regime bedoeld wordt, en niet de bevolking, een of meerdere van de rassen of het land in geografische zin. Dat regime (de CCP) doet nou eenmaal zulke dingen, en om daar een keer een einde aan te breien zal dat gewoon benoemd moeten worden. Nog los van bovenstaande reden dat je bij een hack gewoon altijd noemt waar die van afkomstig is.

[Reactie gewijzigd door mae-t.net op 3 maart 2021 13:10]

Waarom noem je mogelijke daders aanwijzen afleiden van het probleem? Je bent vooringenomen waarom een bedrijf extra informatie geeft?

Microsoft stelt namelijk niet dat hun software geen probleem geeft, ze geven het zelfs heel duidelijk aan. Er is alleen een extra probleem bij: een ander weet er ook van en gebruikt het tegen de gebruiker. Het uitleggen dat het niet alleen om een probleem in de software gaat maar ook dat anderen dat probleem kennen en gebruiken zorgt er voor dat duidelijker is dat je het zo snel mogelijk moet oplossen in plaats van dat uit te stellen. Dat er problemen in software worden gevonden zet niet zomaar aan tot snel updaten. Hoe meer risico hoe meer belang om te updaten.
Als een medetweaker suggereert dat een bedrijf iets zou doen ter afleiding van hun eigen probleem, zonder die beschuldiging te onderbouwen, kan je de vraag verwachten of het uit vooringenomenheid over het bedrijf komt. Suggerend beschuldigen dat een bedrijf fout bezig zou zijn is nogal wat. Suggeren dat het afleiden is heeft niet zomaar te maken met wat anderen doen, eerder wat de medetweaker negatief lijkt te denken over een bedrijf dat patches uitgeeft.
Ik vind het opvallend dat er in het artikel nogal duidelijk gemaakt wordt dat het om on-premise omgevingen gaat, maar O365 draait ook gewoon Exchange (iets aangepast en 1SP nieuwer) en ik vind het opvallend dat er niks over de O365 omgeving gezegd wordt.
Staat overduidelijk in Exchange team publicatie, "
The vulnerabilities affect Microsoft Exchange Server. Exchange Online is not affected."
Dat gezegd hebbende: Hybride Exchange Online implementaties zijn dus wel impacted omdat deze ook nog een lokale Exchange configuratie draaien.

In hoeverre dat hetzelfde risico heeft is geheel afhankelijk of de HTTP/HTTPS onderdelen van de On-Premise Exchange omgeving via het internet te raadplegen valt.
dat klopt, en dat staat ook in de documentatie
In hoeverre dat hetzelfde risico heeft is geheel afhankelijk of de HTTP/HTTPS onderdelen van de On-Premise Exchange omgeving via het internet te raadplegen valt.
Dat geeft alleen maar de prioriteit aan die je moet hanteren m.b.t. patchen. Microsoft heeft zelf aangegeven dat alle Exchange deployments gepatcht moeten worden, ook die niet direct aan het internet hangen.
De uitleg hiervoor is hier te vinden: https://msrc-blog.microso...ased-for-exchange-server/

These vulnerabilities are used as part of an attack chain. The initial attack requires the ability to make an untrusted connection to Exchange server port 443. This can be protected against by restricting untrusted connections, or by setting up a VPN to separate the Exchange server from external access. Using this mitigation will only protect against the initial portion of the attack; other portions of the chain can be triggered if an attacker already has access or can convince an administrator to run a malicious file.

Het lijkt erop dat als je een reverse https proxy tussen het internet en je exchange server hebt hangen dat er dan geen probleem is.
Dat wordt er wel, namelijk:
The vulnerabilities affect Microsoft Exchange Server. Exchange Online is not affected.
https://techcommunity.mic...rity-updates/ba-p/2175901
-

[Reactie gewijzigd door Carlos0_0 op 3 maart 2021 11:59]

Exchange 2010 SP3 is ook getroffen door dit security issue: CVE-2021-26857:

https://msrc.microsoft.co...nerability/CVE-2021-26857

De reactie hierover vanuit Microsoft: We are releasing updates for Exchange Server 2010 for defense-in-depth purposes.

Hier hoeven we geen actie te ondernemen omdat we volledig draaien op Exchange Online. Paar jaar geleden alle on-premises Exchange servers uitgefaseerd :)

[Reactie gewijzigd door nextware op 3 maart 2021 11:34]

Wat je heel vaak nog wel ziet is dat een organisatie alle mailboxen en mailflow op Online heeft zitten, maar dat er toch nog steeds een hybrid omgeving is. Juist voor een on-premises management server, een provisioning server omdat je identity management omgeving niet mee veranderd is, of voor wat lokale services die wel Exchange services nodig hebben, maar niet met Online zijn mee gegroeid.

Als je echt helemaal op cloud-only over bent is dat geweldig, ik verwacht wel dat er nog behoorlijk wat organisaties zijn die deze week druk aan de slag gaan (lang leve spoed changes :) )
Wanneer deze update (KB5000871) wordt geïnstalleerd op een Exchange 2013 omgeving is dan een herstart van de server nodig? Haal dit (zo snel) niet uit de release notes
Bij Exchange 2016 CU19 was dat wel zo.
Zojuist uitgevoerd en op deze (enkele) Exchange 2013 CU23 server geen reboot nodig geweest.
Wel worden alle services gestopt dus ik zou sowieso een reboot voor en na de installatie uitvoeren (preventief)
Bedankt voor deze reactie, bij Exchange 2013 (helaas) niet anders, gisterenavond de patch geladen op de door ons gebruikte omgeving
Every time someone writes "on-premise", the supreme being kills a kitten.
wat ik me dan nu afvraag heh: zijn deze 0days gevonden omdat de sources van exchange via de solarwinds supplychain hack gelekt zijn naar China?

Op dit item kan niet meer gereageerd worden.


Apple iPhone 12 Microsoft Xbox Series X LG CX Google Pixel 5 Sony XH90 / XH92 Samsung Galaxy S21 5G Sony PlayStation 5 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2021 Hosting door True