Aanvallers scannen actief op Exchange-kwetsbaarheid ProxyShell na openbaarmaking

Verschillende beveiligingsbedrijven en overheidsinstellingen waarschuwen voor kwetsbaarheden in Microsoft Exchange. Die staan samen bekend onder de naam ProxyShell en worden actief opgezocht nadat ze op de BlackHat-conferentie publiek werden gemaakt.

De waarschuwingen komen onder andere van het Nederlandse Digital Trust Center en beveiligingsonderzoekers zoals Kevin Beaumont. Met de kwetsbaarheden is het mogelijk om van een afstand code uit te voeren op Exchange-servers, zonder dat authenticatie nodig is.

Het gaat om een aanval die bestaat uit drie verschillende kwetsbaarheden, die samen de naam ProxyShell hebben gekregen. De aanvallen richten zich op de Client Access Service en op PowerShell, waar de naam vandaan komt.

De kwetsbaarheden maken het mogelijk om de access control list in firewalls te omzeilen, en vervolgens via PowerShell een local privilege escalation op te zetten. Met de derde kwetsbaarheid kan vervolgens code worden uitgevoerd.

Kwetsbaarheid	Soort	Gerepareerd
CVE-2021-34473	Remote code execution	KB5001779
CVE-2021-34523	Local privilege escalation	KB5001779
CVE-2021-31207	Omzeilen van access control list	KB5003435

De kwetsbaarheden zijn niet nieuw; ze werden al weken geleden ontdekt tijdens hackerscompetite Pwn2Own. Beveiligingsonderzoeker Orange Tsai van Devcore ontdekte de kwetsbaarheden en won daar 200.000 dollar voor.

Nu heeft Tsai zijn bevindingen publiek gemaakt tijdens beveiligingsconferentie Black Hat, dat vorige week in Las Vegas plaatsvond. ProxyShell heeft veel weg van ProxyLogon, een aanvalsvector die onlangs ook door Tsai naar buiten werd gebracht.

Nu de kwetsbaarheden publiek zijn, zien zowel Tsai als andere beveiligingsonderzoekers dat servers actief worden aangevallen. Microsoft heeft in april en mei al updates uitbracht waarin de bugs werden gerepareerd. Desondanks ziet Tsai dat er van de 400.000 servers op internet zeker 30.000 toegankelijk zijn die de patches nog niet hebben doorgevoerd.

Update: in het stuk stond aanvankelijk dat er 400.000 kwetsbare servers zijn, maar dat is het totale aantal servers. Het aantal kwetsbare ligt op 30.000.

Reacties (83)

De kwetsbaarheden zijn volgens mij niet helemaal goed omschreven met de volgende quote uit het artikel:

De kwetsbaarheden maken het mogelijk om de access control list in firewalls te omzeilen, en vervolgens via PowerShell een local privilege escalation op te zetten. Met de derde kwetsbaarheid kan vervolgens code worden uitgevoerd.

Als ik de slides (vanaf slide 55) en de presentatie die op timestamp 34:30 begint over ProxyShell bekijk is het meer als volgt:

De eerste stap is niet het omzeilen van een ACL in een firewall maar het gebruiken van een fout in een HTTP proxy ("CAS", een asp.net webapp die requests doorstuurt naar de Exchange backend). Wanneer die proxy een request ontvangt dat eindigt op "/autodiscover.json" herschrijft deze de URL op onjuiste wijze waardoor server side request forgery (SSRF) mogelijk is met de credentials van de proxy (zie slide 63 voor de URL). Waarschijnlijk zijn dit de requests waarop gescanned wordt die gemeld worden.

Met deze SSRF wordt via de proxy de "Remote PowerShell Backend" aangeroepen die het mogelijk maakt uiteindelijk gelimiteerde PowerShell uit te voeren (in een Runspace waarin alleen bepaalde commando's beschikbaar zijn). Op slide 65 staat dat deze backend een toegangstoken uit de URL accepteert waardoor je PowerShell kan uitvoeren als een bepaalde gebruiker.

De laatste stap is inderdaad wel het uitvoeren van code maar preciezer is het droppen van een .aspx bestand in de webroot die een remote shell opent wanneer je die aanroept. In het proof of concept wordt de .aspx pagina naar een mailbox gemailed, via de SSRF en een WinRM (SOAP) proxy wordt met een beschikbaar PowerShell commando de mailbox als .pst bestand gexporteerd naar de webroot. De asp.net code moet ge-encode worden zodat deze bij een .pst export weer leesbaar wordt voor asp.net.

Voor zover ik weet heeft de onderzoeker niet zijn hele proof-of-concept ("rce.py" in dit ProxyShell exploit demo filmpje) gepubliceerd, dus niet elke scriptkiddie zal meteen remote shells kunnen droppen naar Exchange servers. Je moet best een goede security researcher zijn om met deze informatie een exploit te kunnen maken.

edit: in het blog Reproducing The ProxyShell Pwn2Own Exploit staat nog meer informatie en de stappen wat uitgebreider uitgelegd, daarmee moeten hackers wel een eind komen.

[Reactie gewijzigd door matthijsln op 10 augustus 2021 00:16]

Desondanks ziet Tsai dat er alsnog zeker 400.000 servers vanaf het internet toegankelijk zijn die de patches nog niet hebben doorgevoerd.

Hoe komen die op die schattingen ? Gaan die nu de hele ipv4 (en wat met ipv6?) space lopen portscannen op exchange poorten en banners van die services parsen of custom check_exploit scripts erop afvuren ?

Ja klopt, de firma secutec heeft een scan lopen die nog een week duurt. Zo simpel is het meestal hoor :-).

Edit : https://www.nieuwsblad.be/cnt/dmf20210809_95022542

[Reactie gewijzigd door Yarisken op 9 augustus 2021 16:53]

Dat is goed mogelijk (althans voor ipv4) via tools zoals ZMap (https://zmap.io/)

Wow ik wist niet dat ze een hele service en suite van tools rond dat ding hadden gebouwd. Wel wat vreemd. sinds ze in hun paper een serieus stuk toegewijd hebben aan "internet citizenry" en de ethiek rond deze portscans.

Het gaat niet om de mogelijkheid maar of het resultaat waarop het gebaseerd is redelijk is.
Je kan op verschillende manieren tot een conclusie komen, maar dan mag er nog wel verwacht worden dat er aantoonbaar redelijkheid is.
Het voorbeeld wat je geeft scant bijvoorbeeld heel snel, maar is daarmee nog niet zomaar nauwkeurig genoeg. Die nauwkeurigheid gaat niet leen over een te veel aan ontdekte kwetsbare apparatuur. Het aantal kan bijvoorbeeld ook veel hoger liggen terwijl firewalls de aantallen resultaten beinvloeden.

Misschien scant hij 1% van bepaalde reeksen en doet dat keer 100 om een schatting te maken.

Mogelijk een vergelijking van hoe vaak de vorige patch (build) is gedownload ten opzichte van deze patch.

Een bepaalde query runnen op https://www.shodan.io/ ?

Simpel vraagje: als je exchange in je Office 365 abbo zit dan word die automatisch up to date gehouden zeker?

Edit: dank je beide

[Reactie gewijzigd door Damic op 9 augustus 2021 17:30]

Simpel vraagje: als je exchange in je Office 365 abbo zit dan word die automatisch up to date gehouden zeker?

Ja dat is onder controle :-).

https://www.nieuwsblad.be/cnt/dmf20210809_95022542

"Dit nieuwe lek betreft énkel fysieke Exchange-servers. Indien er systeembeheerders meelezen: ga nu uw Exchange-server updaten. Wie de clouddiensten van Microsoft (Office 365) gebruikt, moet zich geen zorgen maken."

[...]

"Dit nieuwe lek betreft énkel fysieke Exchange-servers. Indien er systeembeheerders meelezen: ga nu uw Exchange-server updaten. Wie de clouddiensten van Microsoft (Office 365) gebruikt, moet zich geen zorgen maken."

Beetje dubieuze text van die krant. Zou meer iets noeten zijn van "Als er systeembeheerders meelezen die hun Exchangeserver nog niet hebben gepatcht voor deze lekken: doe dat dan nu en zoek daarna een andere baan". Want de patchrondes van april en mei horen voor zulke kritieke gaten toch wel doorgevoerd te zijn begin augustus.

Doorgaans wel, aannemende dat je de dienst gebruikt die Microsoft voor je host en beheert. Dat maak ik op uit de patch notes voor een van de exchange lekken, in elk geval.

Ik durf het alleen niet met zekerheid te zeggen, omdat Microsoft zo godsgruwelijk veel verschillende Office-pakketten aanbiedt en constant de naam ervan aanpast.

valt toch nog wel mee,

M365 en O365 , bijde in standaard variant (E1 en E3) en in de security variant (E5)

O365 = alleen office
M365 is inc security functionaliteiten.

Als groot bedrijf had je vroeger bijna een persoon nodig die zich de hele tijd met Microsoft licensering moest bezighouden om ervoor te waken dat de BSA geen boete op zou leggen. En als die boetes voor je bedrijf hoger uit kunnen vallen dan een jaarsalaris, dan was dat geld enigzins nuttig besteed.

Microsoft staat erom bekend dat hun licentiemanagement heel veel weg heeft van een "moeras". Vandaar dat veel bedrijven (veel) meer licenties dan nodig afnamen, om maar van dat ge-emmer af te zijn.

Je zou verwachten dat met de opkomst van de cloud, dit zou verbeteren/versimpelen. Microsoft doet dat absoluut niet, zij vullen hun schatkist hiermee tot aan de nokken. En nu niet alleen met grote bedrijven, maar ook met kleine bedrijven en particuliere gebruikers.

Microsoft heeft maar 1 doel, winst maken. Op welke manier dan ook. Ze geven nu meer uit aan PR en positieve berichtgeving dan dat ze vroeger deden. Maar vergis je niet, de aard van het beest is niet veranderd. Als je Microsoft hierin onderschat, dan is dat Microsoft niet aan te rekenen, maar eerder jouw probleem.

Microsoft is niet je vriend, zelfs niet vriendelijk. Blijf dat in je achterhoofd houden en je kan hun produkten op hun aktuele waarde inschatten.

Als MS employee herken ik dat niet echt, sterker nog meestal zijn Enterprise klanten under licensed en doet MS een ratio contract voorstel waardoor het voordeel bij het bedrijf ligt en niet bij MS.

Juist M365 heeft het licentie model zover versimpled dat alles wat je nodig hebt in de licentie zit zeker als je E5 neemt is de complete client voorzien van alle bescherming software en licenties die hij nodig heeft.

Dat zijn de pakketten die nu verkocht worden, maar er zijn een miljoen pakketten die gaandeweg allemaal hernoemd of omgezet zijn naar een vorm van 365.

Neem de laatste naamswijziging: Office 365 Business Premium is Microsoft 365 Business Standard geworden, Microsoft 365 Business is Microsoft 365 Business Premium geworden.

Als je bedrijf ooit een specifieke versie van Business Productivity Online Suite Standard hebt gekocht, wens ik je veel succes met uitzoeken hoe dat nu heet en wat voor voorwaarden daar nu aan hangen. Ik geloof dat je dan nu een M365-licentie hebt, maar dat is alles behalve duidelijk. Google vindt er geen huidige informatie van Microsoft over, in elk geval.

De huidige naamgeving van Microsoft is doorgaans goed te begrijpen, maar iedere laat jaar gooien ze alle namen om bij een nieuwe rebranding. Dat maakt het hele ecosysteem nodeloos verwarrend.

Ik denk dat je even moet kijken naar de feature tables,

dat is het ebige wt belangrijk voor je zou moeten zijn daar zie je in 1 oogopslag alle feature en licentie vormen in 1 single table,

je kijkt welke features je nodig hebt en dan weet je dus welke licentie je nodig hebt,

Dit kan ook een van de redenen zijn om juist in de cloud te zitten

Toch jammer dat er zoveel bedrijven minstens drie maanden achterlopen qua security patches. Ik ben het doorgaans eens met de 90 dagen richtlijn die de meeste beveiligingsonderzoekers aanhouden, maar er zij nu zoveel exploits die zo kritiek zijn en waar zoveel gedoe mee is, dat het toch echt tijd is hier wat aan te doen.

Ik zou het jammer vinden als beveiligingsonderzoekers hun onderzoek moeten verbergen omdat systeembeheerders rond de hele wereld niet in staat zijn hun servers bij te werken, maar aan de andere kant kun je ook niet niks doen met 400.000 servers die kwetsbaar aan het internet hangen.

Als het zo doorgaat, forceert Microsoft met Windows 11 server hun updates op dezelfde manier als ze bij consumenten op Windows 10 doen. Als je een server aan het internet hangt, is het je taak om die veilig te houden, en als je niet aan die taak kunt voldoen, krijg je bedrijven als Microsoft en overheden als de Amerikaanse die rare sprongen gaan doen. Als je daadwerkelijk de beveiligingsupdates van mei nog niet hebt toegepast, heeft je bedrijf naar mijn mening eerlijk gezegd niks te zoeken in de hostingwereld (of dat nou door technische of organisatorische beperkingen komt).

Ik wou dat ik een oplossing had, maar hier is geen simpele oplossing voor ben ik bang.

Het onderhouden van een Exchange omgeving is ook een complexe actie die vaak buiten het normale Windows Update beheer valt. Cumulatieve Updates (CU) zijn als een volledige herinstallatie van Exchange en de normale beveiligingsupdates durft men meestal niet ‘zomaar’ te installeren. Maar goed, als je nu nog onpremise Exchange draait dan weet men toch niet heel erg goed waarmee men bezig is. Er is geen business case voor te maken…

Ik kan de business case wel bedenken, maar als je het complexe onderhoud van zo'n systeem meeneemt zul je denk ik snel uitkomen op een ander mailsysteem, danwel iets als goede oude Zimbra, danwel iets als hosted Microsoft mail.

Heb je een volledig beheerd Microsoft-kantoor met informatie die de EU niet mag verlaten (en je geeft er wat om, privacy shield is dood maar iedereen laat zijn spul bij MS staan...) en heb je de expertise in huis om een Exchange-systeem te onderhouden, dan kan een on-premise Exchange-setup best een logische keuze zijn. Ik denk niet dat de FTE's die je aan Exchange kwijt bent opweegt tegen de kosten van alle andere alternatieven, maar het scenario is te bedenken.

Driekwart van de bedrijven die Exchange draaien kunnen waarschijnlijk beter gewoon over op een ander platform. Het zou me weinig verbazen als de manier waarop je licenties voor zulke servers krijgt steeds minder toegankelijk worden voor een MKB omdat Microsoft ook wel doorheeft dat dit niet de bedoeling is.. .

Ik denk niet dat de FTE's die je aan Exchange kwijt bent opweegt tegen de kosten van alle andere alternatieven, maar het scenario is te bedenken.
Medewerkers zijn altijd de hoogste kosten en helemaal als die arme man s’ nachts Exchange servers moet updaten. Microsoft is er in ieder geval erg duidelijk over: als je minder dan 50000 clients hebt, dan ben je een Exchange online klant, geen onpremise.

De onpremise licenties gaan ook over naar een user based abonnement dus dat product is toch EOL.

Dus Exchange wordt geen role/product meer op een lokale Windows Server ?
Wow ...

Jawel maar dan met abonnement.
https://searchwindowsserv...-subscription-requirement

En je kunt wel nagaan hoe dat geprijsd wordt t.o.v. Exchange online

[Reactie gewijzigd door dycell op 9 augustus 2021 23:07]

Ik grapte enkele jaren terug dat met Windows 10, Office 365 en Azure Microsoft de weg was ingeslaan om alle system administratie van iedereen over te nemen. Dit doet me daar toch terug voor vrezen.

Ik heb al twee weddenschappen verloren gezien ik zeker wist dat Exchange 2016 de laatste on premise exchange versie zou zijn.
Ik dacht dat Microsoft gewoon bedrijven zou forceren naar cloud oplossingen.

MS is van de lange adem. Ze proberen het in ieder geval wel.

Die business case is er wel degelijk in het midden bedrijf. Niet voor iedereen is het voordelig om per maand per user te betalen voor iets als email. En ik ken ook een paar groot bedrijven die weer hard teruggekomen zijn op Office 365 in verband met kosten en issues.

Vergeet ook niet de legacy binnen heel veel bedrijven, anderen willen niets van de cloud weten en dat is hun goed recht denk ik.

Het valt of staat met goed beheer, en ja een CU op exchange is natuurlijk wat anders als een patch op windows 10 via windows update, maar momenteel nog altijd makkelijker als de initial exchange installatie.

3 maanden is redelijk lang, er is extreem veel over gepubliceerd zelfs het journaal had het erover. Ik denk dat je dan ook beter kunt stellen dat als je On prem exchange hebt en niet bekent bent met deze patch dat je niet heel erg goed weet waar je mee bezig bent.

Die business case is er wel degelijk in het midden bedrijf. Niet voor iedereen is het voordelig om per maand per user te betalen voor iets als email.
Klopt, als je veel ploegendiensten draait dan zou device based licensing goedkoper kunnen zijn. Maar de laatste jaren verhoogd MS de onpremise licenties steeds verder en uiteraard vooral de device client licenties. Ik heb het een paar jaar geleden uitgerekend voor 5000 gebruikers en kon het toen al niet meer verantwoorden.

En ik ken ook een paar groot bedrijven die weer hard teruggekomen zijn op Office 365 in verband met kosten en issues.
Zeer waarschijnlijk was dit dan de schuld van de partner. Office 365 goed implementeren is heel veel mensen werk, workflow begeleiding en training. Iets dat vaak niet wordt gedaan waardoor het project faalt. Als mensen denken dat cloud zomaar iets is wat net zo werkt als vroeger dan kun je maar beter direct stoppen. Voorbeeld: bedrijf gaat over naar Office 365 en schaft voor iedereen E3 aan. Terwijl ze bergen geld kunnen besparen door gebruikers de licenties te geven die ze echt nodig hebben. Veel medewerkers kunnen bijvoorbeeld gewoon E1 gebruiken. Maar goed, dan moet je dus wel gaan kijken wat mensen doen.

anderen willen niets van de cloud weten en dat is hun goed recht denk ik.
Zeker, ik ben ook groot voorstander van onpremise. Maar in dit geval is het niet echt relevant want we praten hier over e-mail. Iets dat niet bestaat zonder ‘cloud’.

anderen willen niets van de cloud weten en dat is hun goed recht denk ik.
Zeker, ik ben ook groot voorstander van onpremise. Maar in dit geval is het niet echt relevant want we praten hier over e-mail. Iets dat niet bestaat zonder ‘cloud’.

Het bijhouden van een mail server is hoofdpijn. Heb zelf een (Linux) mailserver on-prem draaien. Het hoofdpijn deel is te wijten aan anti-spam organisaties die hele IP clusters aanmerken als spammer, terwijl er maar 1 IP adres daadwerkelijk een probleem heeft.

De vrijheden die een on-prem mailserver (of eentje die op een VPS draait) wegen nog altijd zwaarder dan de hoofdpijn. Exchange alleen gebruiken voor mail, dat zie ik meer als weggegooid geld. Zo goed is Exchange als mail server niet. Maar als je met Outlook als client werkt, dan vormen de extra functies van Exchange een makkelijkere intergratie.

En dat is zo'n beetje het bestaansrecht van Exchange. Maar alleen als de gebruikerspoel groot genoeg is, want de Exchange server hardware kost een boel in aanschaf en onderhoud, heeft een "stevige" Windows licentie nodig, waar dan ook nog de Exchange licentie en softwarematig beheer bij komen.

Als alleen mail de bedoeling is, dan is Exchange veel te duur en een grote rompslomp. Vind het daarom niet vreemd dat je denkt dat een Exchange omgeving maar beter door Microsoft kan laten beheren in hun cloud oplossing.

Maar om dan gelijk alle vormen van mail server omgevingen over 1 kam te halen, dat is dan weer overdreven.

Klopt, ik praat hier ook enkel over Exchange servers. Andere mailservers heb ik te weinig ervaring mee en ken hun licentie structuur niet. Uiteraard heeft Exchange veel meer mogelijkheden dan enkel e-mail maar als je echt kijkt is het voornamelijk e-mail. De agenda (waar de afspraken gewoon opgeslagen worden als losse (e-mail) items is nummer 2 maar lang niet iedereen gebruikt dat. Notities is nummer 3 maar dat is weer echt amper in gebruik. Ook is dit in Office 365 weer vervangen net als To-Do.

Als je echt inzoomt op het gebruik dan vragen de meeste mensen zich af waarom ze zoveel betalen.

Kun je uitleggen wat precies het probleem is ,

Als je MS PLA draait met je exchange kun je gewoon overdag gedurende de dag patchen zonder enige impact op je users ,

Probleem doet zich meestal voor als men Niet PLA compliant is en daardoor een afwijkend iets gebouwd heeft.

Hee niet werken in de avond uurtjes he, scriptkiddie :-P

De meeste onpremise Exchange gebruikers draaien online (zoals met VDI). Online, via een load balancer, zorgt altijd voor verstoringen bij failovers. Ook al is het maar een minuut, dat wordt in veel omgevingen zoals ziekenhuizen niet gewaardeerd. En dat is helemaal PLA compliant.

juist en dan doe je dus savonds of overdag wanneer je wilt je bleed op je LB en als die cas droog is zet j ehem in maintenance.

Of je doet het in een keer in de avond rond een uur of 6 kost je 5 min, dan kan de de dag erna gewoon patchen en weer enablen zonder dat users er last van hebben. Reenable merkt helemaal nietmand en kan overdag,

Het is de reconnect met de cas die ze kunnen merken, maar als je Mapi RPC met Metacache draait zal ook daar bijna niemand er iets van merken

En nu komen we op het probleem: wie gaat dat allemaal doen en wanneer? Dit zijn dure mensen. Mijn punt is dat deze zaken niet meer houdbaar zijn qua kosten. Laat staan dat beheerders er wel klaar mee zijn. De bezetting is meestal laag en IT medewerkers hebben meerdere verantwoordelijkheden. Dat betekend meestal dat ander werk dus blijft liggen. Tevens kun je het niet zo ‘soft’ doen als er een incident is zoals laatst. Even een paar dagen doen over security patches installeren is soms geen optie.

Al met al is voor on-premise Exchange het vrijwel geen business case te maken. Microsoft is hier ook heel duidelijk over: als je minder dan 50.000 mailboxen hebt dan ben je geen Exchange klant maar een Exchange online klant. Daar zorgen ze met hun licenties natuurlijk ook voor.

ow maar dat zeker, als MS employee kunnen we zelfs als exchange CE alleen maar de cloud aan raden in verband met goedkopere kosten en betere uptime en bescherming ,

maar dat is buiten de patch discussie procedures voor onprem en het excuus dat je er geen tijd voor hebt. Als je geen tijd hebt om onprem te hosten moet je gewoon naar de cloud.

Limiet ligt overigens iets lager, wij zeggen altijd >5000 is M365 daar boven kun je onprem hosten maar het zal zeker niet goedkoper zijn.

Limiet ligt overigens iets lager, wij zeggen altijd >5000 is M365 daar boven kun je onprem hosten maar het zal zeker niet goedkoper zijn.

Persoonlijk vind ik dat nummer een beetje laag. Zeker als we ‘preferred design’ in beschouwing nemen. Fysieke dozen met support zijn weer erg kostbaar en dat gooit de business case weer in de war. Daarnaast ben ik wel een beetje klaar met al die on-premise servers, dan liever Exchange online. Jammer genoeg snappen velen ook weer niet dat dat ook gewoon onderhouden moet worden maar alle security ellende zijn we dan wel voor.

PA praat over 900 users per server ,

Minimaal advised DAG is 4 servers, daar komt dat afgeronde getal van 5000 vandaan

Check, interessant als duimwaarde.
Ik gebruik zelf altijd de Exchange Server Capacity Calculator

Nogmaal ik ben een MS employee in the area of exchange onprem.

Excalc 10.5 is leuk maar heeft issues atm, hiervoor staan ook changes open bij de PG, in 10.3 zitten alle changes die ik er in heb laten bouwen door de PG om de calc binnen het supported model te houden.

excalc voor 2019 kun je gebruiken als je de issues weet van elke versie, huidige kun je bijvoorbeeld alleen op autocalc gebruiken anders wordt het aantal users verkeerd berekend.

Als je goed rekend kom je bijna niet boven de 900 users per server uit tenzij je userbase bijna geen email stuurd. Calculator laat nl ook niet al je andere issues zien waar je rekening mee moet houden afhankelijk van je topology.

Deze patch was al in Mei uit , Als je deze update nu nog niet op je server heb dan ben je werkelijk waar je beroep als beheerder niet waard.

Patches uitrollen is meestal van wel meer afhankelijk dan een persoon. Die persoon die het uiteindelijk kan doen is bijvoorbeeld afhankelijk van tijd, geld en prioriteiten waar anderen over gaan.
Ik ben het met je eens dat een beheerder dan ook eisen moet stellen of anders duidelijk moet maken dat zo lang wachten onacceptabel is, maar dat maakt nog niet dat je alleen daar de verantwoordelijkheid kan leggen of de belangrijkste is om de schuld te leggen.

Ok, laten we eens kijken:

Geld: Gratis patch, geen issue dus.

Tijd: Voor een zeroday maak je tijd, als je dat niet over tafel kan krijgen bij je manager ga je naar zijn baas. En zeker bij een zo breed in de media uitgemeten variant kun je inderdaad beter een andere baan zoeken.

Prioriteiten: Zie tijd, geen argument in deze. De downtime die je om je oren krijgt als je een ransomware binnen krijgt is inmiddels wel helder bij de heren managers en je bent als beheerder toch slim genoeg om even een "outage" te creeeren?

De beheerders handelen hier fout door niets te doen.

Je bent onredelijk aan het bagatelliseren door tal van zaken weg te laten. Je laat daarbij niet blijken te begrijpen hoe organisaties werken en het niet simpel weg een kwestie is van beheerders om te kunnen of mogen patchen.

Geld zit niet alleen in de kosten van de patch zelf. Dat kon je al beseffen door je af te vragen waar de kosten in kunnen zitten. De beheerders kosten geld, het plannen en testen van patches kost geld, het in stand houden van services levert geld op (waar een bedrijf niet zomaar op wil inleveren omdat de beheerder iets nodig wil). Patchen is dus niet gratis. Net doen alsof is niet redelijk.

Tijd: Jij bent van mening dat een beheerder maar tijd moet maken. Dat is niet zomaar iets waar een beheerder over gaat. Bijvoorbeeld omdat er te weinig beheerders zijn en een beheerder niet zomaar gaat over de prioritenten. Daarbij is de stelling dat downtime vanuit risico voor criminelen het (enige) uitgangspunt is niet zomaar redelijk. Er staat tegenover dat in het voorbereiden, uitvoeren en mogelijk zelf moeten herstellen een keuze is die ten kosten gaat van andere zaken die een bedrijf ook wil. Bijvoorbeeld andere software prioriteit geven omdat er te weinig beheerders in dienst zijn genomen.

Prioriteiten: de situatie was dat er nog geen publieke exploit was. De onderzoeker heeft er vervolgens voor gekozen om dat te veranderen, waardoor ze bewust het risico namen dat voor honderdduizen bedrijven en mogelijk miljoenen afhankelijke personen die eerst nog moesten aanpassen. Terwijl die dat niet zomaar kunnen, ook al vind jij dat het zou moeten. En dat jij een mening hebt maakt nog niet dat daarmee de verantwoordelijkheid bij de beheerder ligt om de prioriteit te stellen (of kunnen stellen).

Het is dus eerder fout dat jij de schuld bij de beheerder legt zonder rekening te willen houden met omstandigheden. Daarmee los je ook geen problemen op door zo makkelijk mening te vormen zonder ook maar een beetje besef te tonen hoe organisaties of onderzoekers te werk gaan.

Ik weet niet waarom, maar de issues die je hier noemt ben ik echt nog nooit tegengekomen. En ik heb in allerlei bedrijven gewerkt tot aan Amerikaanse banken toe.

Zodra er iets als dit aan de hand is wordt er in mijn ervaring naar de beheerders geluisterd. Misschien heb ik mazzel gehad met mijn directe managers, maar gezien dit 100% van mijn 17 jaar ervaring betreft lijkt me het eerder andersom.

Als je als beheerder niet uit kan leggen waarom iets als dit belangrijk is kom je echt tekort in deze job en is de kans groot dat je eruit vliegt als het wel mis gaat.

Het lijkt me geen mazzel.
Het gaat kennelijk 'maar' om 400.000 bedrijven op een totaal van honderden miljoenen bedrijven wereldwijd. Dat is maar een miniem aantal, waar men om heel veel verschillende redenen hele andere prioriteiten kan hebben dan het belang van op tijd patchen.

Daarbij lees ik je geen uitleg geven waarom je de indruk had dat er altijd geluisterd werd. Zoals je zelf ook stelt, de manager namen de beslissing. Maar in grotere bedrijven is het niet realistisch om net te doen alsof daar niet ook andere belangen gelden. Aangezien je niet toont hoe die belangen dan aandacht krijgen (bijvoorbeeld door wel op tijd genoeg beheerders in dienst te hebben, geld te hebben om overwerken te betalen, anderen/hogeren in de organisatie teleur te stellen hun prioriteiten niet belangrijk genoeg zijn) kan er dus niet zomaar de situatie bestaan dat er naar de beheerders werd geluisterd.
Waar je overigens een prima reden voor geeft als het ondanks luisteren toch mis ging: je kan als verantwoordelijke de beheerder de schuld.

En ik denk dat je waarschijnlijk keuzes maakt voor welke organisaties je niet wilde (blijven) werken om er echt last van te hebben dat er andere keuzes konden bestaan. Waarschijnlijk kom je die paar bedrijven die hier andere prioriteiten lijken te hebben dan niet eens tegen omdat die mogelijk niet op zoek zijn naar beheerders die menen dat er naar ze geluisterd moet worden?

[Reactie gewijzigd door kodak op 9 augustus 2021 21:23]

Fijne vent, die Orange Tsai. Hij weet dat er ondanks de patch van MS nog steeds honderdduizenden servers kwetsbaar zijn maar gaat toch gewoon zijn hack openbaren op Black Hat met alle gevolgen van dien. Zulk kinderachtig, onverantwoordelijk gedrag. Hou gewoon je mond erover ipv dat je kwaadwillende hackers de gelegenheid geeft om ellende te veroorzaken. Straks lezen we weer over allerlei bedrijven die met cryptolockervirussen zijn gekaapt. Wat mij betreft pakken ze die 200.000 dollar weer van Tsai af om de schade die hij berokkent heeft af te betalen.

Volgens mij heb je iets gemist, want de kwetsbaarheden zijn reeds gepatched:

Microsoft heeft in april en mei al updates uitbracht waarin de bugs werden gerepareerd. Desondanks ziet Tsai dat er alsnog zeker 400.000 servers vanaf het internet toegankelijk zijn die de patches nog niet hebben doorgevoerd.

Er is geen enkele reden om security patches geen absolute prioriteit te geven in je patching-ritueel gezien het risicovolle klimaat vandaag de dag.

[Reactie gewijzigd door Insectiside op 9 augustus 2021 16:47]

Maar ja dat houdt niet in dat beheerders de update hebben doorgevoerd..

Maar hoe lang zou meneer Tsai dan moeten wachten? Voor hetzelfde geld zijn de patches over 1 jaar nóg niet doorgevoerd, moet 'ie dan wachten tot Sint-Juttemis?

Ja. Ik geloof niet in het motto "Dikke bult, eigen schuld, dan had je je server maar op tijd moeten patchen."

Je WEET gewoon dat niet elk bedrijf de security van al zijn servers op orde heeft, je WEET dat na het openbaren van een kritieke kwetsbaarheid hackers aan de slag gaan om die kwetsbaarheid uit te buiten, je WEET dat er bedrijven zullen zijn die door een geslaagde hack of crypto-aanval gigantische schade zullen lijden. Waarom zou je willens en wetens dan die informatie op straat gooien? Vanwege de egoboost? Vanwege het leedvermaak?

Ik vind dat de potentiële schade van de openbaring van een veiligheidslek niet opweegt tegen de ellende van bedrijven die om wat voor reden dan ook die updates (nog) niet hebben geïnstalleerd. Meld de kwetsbaarheid bij MS/Google/Apple/etc, verheug je over je vindersloon en houd daarna gewoon je mond. Als je mond opent, zijn er daarna alleen verliezers.

Diezelfde bedrijven zijn wel altijd op tijd met de BTW aangifte: de fiscus kent ook geen genade. Ik zie niet in waarom dat bij beheer niet lukt.

Waarschijnlijk omdat de beheerder van die enkele server bij een winkel enkel kijkt bij de updates die het OS voorschotelt. Deze netjes uitvoert en verwacht dat alles uptodate is. Iets dat je ook zou verwachten bij een MS product op een MS OS. Maar MS heeft in alle wijsheid besloten dat de exchangeupdates met het handje moeten. ZONDER waarschuwingen tijden, na het installeren of bij het updaten van het OS.

Je noemt niet op wanneer bedrijven daaraan voldoen: als het wettelijk vast ligt als plicht. En dan nog zijn er landen waar zelfs die verplichting niet van toepassing is en bedrijven het met verplichting ook niet allemaal netjes doen.
Het is dus geen kwestie van dat kan wel, maar wat een bedrijf belangrijk genoeg lijkt te vinden.

Los van de wisselende regels per land sla je de spijker op zijn kop met "wat een bedrijf belangrijk genoeg lijkt te vinden".

Waarom moet hij überhaupt de kwetsbaarheden publiek maken? Ik lees er geen enkele afweging in. Het leek dus belangrijker voor hem te zijn om bij honderdduizenden anderen (als het niet miljoenen afhankelijken zijn) risico te vergroten om er zelf mee te pronken wat was ontdekt?

Het is zeker een redelijke vraag wat dan redelijk was. Aangezien het ontdekken en aankaarten gaat om het beperken van gevolgen, terwijl de onderzoeker weet dat hij mede verantwoordelijk is dat de details van bekendmaken veel slachtoffers kan maken, kan het antwoord dus niet zijn dat de onderzoeker hier genoeg gedaan heeft om risico te beperken.

Waarom moet hij het überhaupt openbaar maken ?

Security issues moeten openbaar zijn. Ze verborgen houden leidt tot niets, want de bad guys vinden ze toch wel. Als je als bedrijf zijnde meer dan drie maanden wacht met het toepassen van security fixes, heb je kennelijk de kans ingecalculeerd dat je gehackt wordt

Maar ze zijn niet verborgen gehouden, ze werden gedeeld met de fabrikant, die een patch heeft gemaakt.

Ze openbaar maken voor het grote publiek heeft absoluut geen meerwaarde, dan enkel kunnen pronken met je verwezenlijking.
Als het zo makkelijk was om exploits te vinden, deed iedereen het.

Ik heb me niet ingelezen in welke versie van exchange kwetsbaar is, maar ik neem aan dat dus ook bv windows server essentials kwetsbaar zijn en dat zijn toch echt vaak installaties zonder exchange admin / support.

[Reactie gewijzigd door klakkie.57th op 9 augustus 2021 19:12]

Je argument klopt niet. Dat anderen de kwetsbaarheid ook kunnen vinden was dus al een risico. De exploit voor iedereen bekend maken vergroot dat risico. Het doel van kwetsbaarheden verhelpen is om risico te beperken, niet vergroten.

Daarbij is bekend maken terwijl je weet dat er honderdduizenden systemen zijn die nog niet gepatched zijn extra risico nemen. Dan weet je als onderzoeker dat die bedrijven met jou code slachtoffer kunnen worden, en dat neem je dan kennelijk voor lief. Dat klinkt niet als risico echt willen beperken, meer als niet malen dat je acties slachtoffers maakt om andere zaken belangrijker te vinden.

[Reactie gewijzigd door kodak op 9 augustus 2021 22:22]

2 redenen die je veel hoort om toch te openbaren zijn:
1) De eer claimen
2) Cultuur verandering.
Om op dat laatste in te gaan: zolang bedrijven weg kunnen komen met software publiceren met lekken en deze oplossen als een security onderzoeker deze meld zonder verder te openbaren dat dit gebeurde blijft het probleem bestaan. In een grijs verleden heeft MS zijn hele ontwikkelafdeling op een security training gestuurd nadat het maand na maand mis was met de security problemen en er een imago probleem ontstond.

Je argument klopt niet. Dat anderen de kwetsbaarheid ook kunnen vinden was dus al een risico.

Je begrijpt kennelijk niet dat du moment microsoft een patch publiceert, de bad guys aan het werk gaan met diff's en decompilers. Binnen een dag is er dan een werkende exploit.
Er is helemaal niets om geheim te houden: de bad guys hebben de exploit code al lang en zij weten ook al lang dat er zo'n half miljoen kwetsbare targets zijn. De enigen die een gebrek aan informatie hebben, zijn de exchange beheerders die niet patchen. Zij schatten hun kansen verkeerd in. Publicatie zou dan kunnen helpen om hen alsnog tot patchen te doen besluiten. En anders leren ze het maar the hard way

Net doen alsof er geen verschil is tussen aan miljarden mensen de werkende exploit kant en klaar aanleveren of bepaalde criminelen die tijd en moeite moeten stoppen om eerst een patch om te zetten naar een exploit lijkt me niet redelijk. Dan ben je alles over een kam aan het scheren.

Zet in elk geval flink vaart achter het patchen door admins, ze moeten nu wel.

Microsoft heeft een patch uitgebracht het is dan de verantwoordelijkheid van het desbetreffende bedrijf of beheerders.

Er zijn patches beschikbaar. Dat is duidelijk iets heel anders dan de mensen die slachtoffer kunnen worden zijn dus voldoende beschermd als een onderzoeker zijn ontdekking publiek wil maken.

Het gaat hier niet alleen om tienduizenden systemen die kennelijk nog niet gepatched zijn, maar ook vele mogelijke gebruikers (zoals medewerkers, klanten, leveranciers enz) die per systeem afhankelijk zijn van de gevolgen van het publiek maken.

Dat een onderzoeker dus een ontdekking doet en een softwaremaker patches uitbrengt is dus slechts een onderdeel van het veilig maken. En als je dan als onderzoeker vervolgens wel weet hoeveel systemen er nog risico lopen en bewust mag zijn hoeveel mensen je dus zelf risico laat lopen door al je code publiek te maken, dan lijkt me dat de onderzoeker hier niet perse bezig was om schade te voorkomen. Wat uiteraard niet zegt dat die medewerkers, klanten en leveranciers geen verantwoordelijkheid hebben om bij de bedrijven die nog steeds niet gepatched hebben te klanten, maar de onderzoeker weet welke dat zijn en kan er wel wat aan doen om erger te voorkomen. Dat leek hier geen prioriteit te hebben?

Dat is in mijn ogen de omgekeerde wereld. Bedrijven zijn laks in het bijhouden van hun veiligheid, brengen daarmee de gegevens van al hun klanten in gevaar en stellen hun servers beschikbaar aan botfarms, en degene die daarover rapporteert moet daarvoor boeten?

De kwetsbaarheden die gelinkt zijn, zijn al minstens twee maanden opgelost. Op dit punt is het de incompetentie van de bedrijven die hier de echte schade doet, niet het publiceren van de informatie.

Vergeet niet dat iedereen met een decompiler in staat is een diff te doen tussen de binaries met en zonder patch. Het niet rapporten van details maakt de exploits langzamer, maar tijdig patchen is de enige oplossing. Zolang ransomware populair en winstgevend blijft, kun je met het afdwingen van stilte je servers niet beveiligen.

Dat gezegd hebbende had de exploit wellicht in minder details gepubliceerd kunnen worden, juist doordat bedrijven met Exchange-servers zo incompetent lijken te zijn als het op het volgen van een goed securitybeleid aankomt.

[Reactie gewijzigd door GertMenkel op 9 augustus 2021 16:49]

Het is natuurlijk geen “boeten” maar “rekening houden met”. Dat is toch echt iets anders. Kun je nog steeds een andere afweging maken, maar het is niet dat de rapporteur daar schade door lijdt.

Tja wat is onverantwoordelijk. Hij heeft het in april gevonden en komt nu 4 maanden later naar buiten ermee.

Iedere beheerder moet zich toch echt schamen als je je (Mail)servers die aan internet hangen niet regelmatig patched (lees: al 4 maanden niet gepatched hebt!).

De laatste patch is 3 maanden oud, maar je punt blijft wel staan.
Met 1 van de patches werkt de aanval niet meer.

[Reactie gewijzigd door blissard op 9 augustus 2021 17:36]

De laatste patch is 3 maanden oud, maar je punt blijft wel staan.
Met 1 van de patches werkt de aanval niet meer.

Elke maand komen er tegenwoordig ook SU’s uit. Zie https://docs.microsoft.co...ates?view=exchserver-2019
De laatste patch is in juli uitgekomen (voor zowel CU9 als CU10 overigens)

[Reactie gewijzigd door Tomba op 9 augustus 2021 18:17]

let op MS support is ook N-1 dus 3-6 maanden is de max supported state,

As je dan op 4 maanden patch achterstand zit zit je op de rand van supportability zeker als je in hybrid zit.

Publiceren is juist een manier om de beheerders van deze servers zich bewust te maken van deze kwetsbaarheden. Ja, je helpt er ook aanvallers mee. Maar uiteindelijk kun je kwetsbaarheden beter niet te lang geheim houden.

Zodra patches gepubliceerd zijn is het niet alleen mogelijk dat aanvallers potentieel al dezelfde kwetsbaarheid gevonden hebben. Maar ook zijn er groepen die patches van Microsoft analyseren om zo terug te komen op de kwetsbaarheid. Door de kwetsbaarheid te publiceren geef je meer bekendheid aan de kwetsbaarheid zelf, waardoor meer beheerders hem dus wel gaan patchen.

Ook help je met publicatie pentesters die deze kwetsbaarheden testen op hun klanten, en hun klanten erop attenderen als ze kwetsbaar zijn.

Nu is dit altijd een afweging, het is niet zo dat zo snel mogelijk publiceren altijd een goed idee is. Daarom is ook in dit geval gewacht tot er patches goed beschikbaar waren. En dan nog kan je te vroeg zijn, en misschien is dat in dat geval ook zo geweest. Wel is het zeer waarschijnlijk dat Microsoft weet dat hij deze kwetsbaarheid ging publiceren. Dat is hoe dergelijke programma's vrijwel altijd in elkaar steken.

Dát is het verschil tussen black hat en white hat

Wat had hij dan moeten doen? Net zolang wachten tot het ruime meerendeel gepatched is? Soms kan enkel door zuks te openbaren, en zodoende de kans op een aanval te vergroten, mensen die security met iets te veel korrels zout nemen (vaak genoeg niet de beheerders in kwestie maar de mensen die hen tijd en middelen beheren) overtuigd worden dat het écht nodig kan zijn.

De patches zijn al ruim 3mnd beschikbaar, houd dat vooral in het achterhoofd.

[Reactie gewijzigd door Annihlator op 9 augustus 2021 18:08]

Wat dacht je er van dat iemand die het erg wil vinden dat anderen de patches niet toepassen dan ook eerst moeite doet om dat te verhelpen voordat ze slachtoffer worden, in plaats van ze maar slachtoffer te laten worden door je exploit liever eerst publiek te maken?

Als die onderzoeker het werkelijk zo erg vind dat er slachtoffers vallen maar wel opzoekt hoeveel dat er dan zullen zijn dan mag er wel redelijke argumentatie gegeven worden wat liever het risico vergroten dan bijdraagt en verantwoord is.

Hoe dan? "Even" de beheerders van die 400.000 servers mailen? De problemen zijn al 3mnd te verhelpen middels patches.

Daar zijn heel veel verschillende manieren voor. Het punt is dat je deze vraag dus maar beter kan stellen voor het publiek maken van exploit code. Dat lijkt weer niet gedaan.

Die kwetsbaarheden werden op de dag van de patch al misbruikt. Als je nu in augustus je server nog niet hebt bijgewerkt met patches uit april... ?? Ik zal niet zeggen dat je er om vraagt... maar je reactiesnelheid is dan niet echt heel goed te noemen...

Hoop gezeik gehad (2 klanten met Exchange 2013 op Windows 2012r2) na de updates dat de webinterface OWA en ECP niet meer wilden starten. Kwam een foutmelding:
HMACProvider.GetCertificates:protectionCertificates.Length<1”:

Via deze sites het kunnen fixen, zat wel een wachttijd op van ruim 2 uur:
https://micoolpaul.com/20...tioncertificates-length1/

https://www.steijvers.com...ctioncertificates-length/

Voor november 2023 mag je dan ook naar een andere versie van exchange, ook windows 2012 is zo buiten support. Beter je tijd in de upgrades stoppen.

Klopt, dit zijn de laatste 2 klanten die nog naar Office365 gemigreerd gaan worden :-)

Ik snap alleen niet goed waarom KB5001779 apart wordt aangedragen aangezien KB5003435 de KB5001779 supersedes. Dus alleen KB5003435 installeren zou alle problemen moeten fixen.