S3 Ep102.5: "ProxyNotShell" Exchange-bugs - een expert spreekt [Audio + Tekst]

Klik en sleep op de onderstaande geluidsgolven om naar een willekeurig punt te gaan. Je kan ook luister direct op Soundcloud.

[MUZIEK MODEM]

---

EEND.  Hallo iedereen.

Welkom bij weer een speciale mini-aflevering van de Naked Security-podcast.

Ik ben Paul Ducklin, opnieuw vergezeld door mijn vriend en collega Chester Wisniewski.

Hallo, Chet.

---

CHET.  [NEP AUSSIE ACCENT] Dag, Duck.

---

EEND.  Nou, Chet, ik weet zeker dat iedereen luistert. als ze luisteren kort nadat de podcast uitkwam, weet dan waar we het over gaan hebben!

En het moet deze dubbele loop zijn Zero-day van Microsoft Exchange die op de laatste dag van september 2022 in de was is uitgekomen:

Onze verkoopvrienden zeggen: "Oh, het is einde van de maand, het is einde van het kwartaal, het is een hectische tijd ... maar morgen krijgt iedereen een reset naar $ 0."

Zo zal het dit weekend niet zijn voor Sysadmins en IT-managers!

---

CHET.  Duck, denk ik, in de onsterfelijke woorden van de dierbare overleden Douglas Adams, "GEEN PANIEK" misschien in orde zijn.

Veel organisaties hosten hun eigen e-mail niet langer on-premise op Exchange-servers, dus een groot deel van de mensen kan dit weekend diep ademhalen en wat tijd voorbij laten gaan, zonder er al te gestrest over te raken.

Maar als u Exchange on-premise gebruikt...

… als ik het was, zou ik misschien wat overuren maken om een ​​paar maatregelen te treffen, om er zeker van te zijn dat ik niet voor een onaangename verrassing sta op maandag of dinsdag wanneer dit naar alle waarschijnlijkheid zal uitgroeien tot iets meer dramatisch.

---

EEND.  Dus het is CVE-2022-41040 en CVE-2022-41042… dat is nogal een mondvol.

Ik heb gezien dat er op Twitter naar wordt verwezen als ProxyNiet Shell, omdat het enige overeenkomsten heeft met de ProxyShell kwetsbaarheid die iets meer dan een jaar geleden het grote verhaal was,

Maar hoewel het die overeenkomsten heeft, is het een volledig nieuw paar exploits die aan elkaar worden gekoppeld, waardoor mogelijk externe code kan worden uitgevoerd - klopt dat?

---

CHET.  Zo klinkt het.

Die kwetsbaarheden werden ontdekt tijdens een actieve aanval op een slachtoffer, en een Vietnamese organisatie genaamd GTSC ontrafelde deze twee nieuwe kwetsbaarheden waardoor de tegenstanders toegang kregen tot sommige van hun klanten.

Het klinkt alsof ze op verantwoorde wijze hebben bekendgemaakt die kwetsbaarheden aan het Zero Day Initiative [ZDI] dat wordt beheerd door Trend Micro voor het verantwoord rapporteren van zero-day-kwetsbaarheden.

En natuurlijk deelde ZDI op zijn beurt al die informatie met Microsoft, iets meer dan drie weken geleden.

En de reden dat het vandaag uitkomt, is dat ik denk dat de Vietnamese groep...

... het klinkt alsof ze een beetje ongeduldig en bezorgd worden dat het drie weken geleden is en dat er geen waarschuwingen of advies zijn uitgegaan om mensen te helpen beschermen tegen deze vermeende natiestaatactoren.

Dus besloten ze alarm te slaan en iedereen te laten weten dat ze iets moesten doen om zichzelf te beschermen.

---

EEND.  En om eerlijk te zijn, zeiden ze voorzichtig: "We gaan niet precies onthullen hoe we deze kwetsbaarheden kunnen misbruiken, maar we gaan je oplossingen geven die we effectief hebben gevonden."

Het klinkt alsof beide exploits op zich niet bijzonder gevaarlijk zijn...

... maar aan elkaar geketend, betekent dit dat iemand buiten de organisatie die de mogelijkheid heeft om e-mail van uw server te lezen, de eerste bug kan gebruiken om de deur te openen, en de tweede bug om in wezen malware op uw Exchange-server te implanteren.

---

CHET.  En dat is een heel belangrijk punt om te maken, Duck, dat je zei, "Iemand die e-mail op uw server kan lezen."

Dit is geen *niet-geverifieerde* aanval, dus de aanvallers moeten enige informatie over uw organisatie hebben om deze aanvallen met succes uit te voeren.

---

EEND.  Nu weten we niet precies wat voor soort inloggegevens ze nodig hebben, want op het moment dat we dit opnemen [2022-09-30T23:00:00Z], is alles nog grotendeels geheim.

Maar van wat ik heb gelezen (van mensen die ik geneigd ben te geloven), lijkt het erop dat sessiecookies of authenticatietokens niet goed genoeg zijn en dat je eigenlijk een gebruikerswachtwoord nodig hebt.

Na het wachtwoord te hebben verstrekt, maar als er twee-factor-authenticatie [2FA] was, wordt de eerste bug (degene die de deur opent) geactiveerd *tussen het punt waarop het wachtwoord wordt verstrekt en het punt waarop 2FA-codes zouden worden aangevraagd*.

Je hebt dus het wachtwoord nodig, maar de 2FA-code niet...

---

CHET.  Het klinkt alsof het een 'mid-authentication kwetsbaarheid' is, als je het zo wilt noemen.

Dat is een gemengde zegen.

Het betekent wel dat een geautomatiseerd Python-script niet zomaar het hele internet kan scannen en mogelijk binnen enkele minuten of uren elke Exchange-server ter wereld kan exploiteren, zoals we zagen gebeuren met ProxyLogon en ProxyShell in 2021.

We zagen de terugkeer van wormen in de afgelopen 18 maanden, ten nadele van veel organisaties.

---

EEND.  "wormen"?

---

CHET.  Wormage, ja! [LACHT]

---

EEND.  Is dat een woord?

Nou, als het niet zo is, is het nu!

Dat vind ik leuk... Ik zou het kunnen lenen, Chester. [LACHT]

---

CHET.  Ik denk dat dit licht ontwormbaar is, toch?

U hebt een wachtwoord nodig, maar het vinden van een geldige combinatie van e-mailadres en wachtwoord op een willekeurige Exchange-server is waarschijnlijk niet zo moeilijk, helaas.

Als je het hebt over honderden of duizenden gebruikers... in veel organisaties hebben een of twee van hen waarschijnlijk slechte wachtwoorden.

En misschien ben je tot nu toe nog niet uitgebuit, want om succesvol in te loggen op Outlook Web Access [OWA] heb je hun FIDO-token nodig, of hun authenticator, of welke tweede factor je ook gebruikt.

Maar deze aanval vereist die tweede factor niet.

Dus het verkrijgen van een combinatie van gebruikersnaam en wachtwoord is een vrij lage drempel...

---

EEND.  Er is hier nog een andere complexiteit, nietwaar?

Namelijk dat hoewel Richtlijn van Microsoft officieel zegt dat Microsoft Exchange Online-klanten zich kunnen terugtrekken uit Blue Alert, het is alleen gevaarlijk als je Exchange op locatie hebt...

… er verrassend veel mensen zijn die, mogelijk enkele jaren geleden, zijn overgestapt op de cloud, die tijdens de omschakeling zowel hun on-premises als hun cloudservice tegelijkertijd draaiden, die er nooit aan toe kwamen om de on-premises uit te schakelen Exchange-server.

---

CHET.  Precies!

We zagen dit teruggaan naar ProxyLogin en ProxyShell.

In veel gevallen kwamen de criminelen in hun netwerk via Exchange-servers waarvan ze dachten dat ze die niet hadden.

Iemand heeft bijvoorbeeld de lijst met VM's die op hun VMware-server draaien niet gecontroleerd om op te merken dat hun migrerende Exchange-servers die hen hielpen tijdens het heftrucktransport van de gegevens tussen hun lokale netwerk en het cloudnetwerk...

… waren in feite nog steeds ingeschakeld en ingeschakeld en blootgesteld aan internet.

En erger nog, als niet bekend is dat ze er zijn, is de kans nog kleiner dat ze zijn gepatcht.

Ik bedoel, organisaties die Exchange op zijn minst hebben, doen waarschijnlijk hun best om er regelmatig onderhoud aan te plannen.

Maar als je niet weet dat je iets op je netwerk hebt "omdat je het vergeten bent", wat heel gemakkelijk is met VM's, zit je in een nog slechtere situatie, omdat je waarschijnlijk geen Windows-updates of Exchange-updates hebt toegepast.

---

EEND.  En de wet van Murphy zegt dat als je echt op die server vertrouwt en je er niet goed voor zorgt, hij crasht net de dag voordat je hem echt nodig hebt.

Maar als je niet weet dat het er is en het voor slecht kan worden gebruikt, is de kans dat het jaren en jaren en jaren zonder enige problemen zal draaien waarschijnlijk behoorlijk groot. [LACHT]

---

CHET.  Ja, helaas, dat is zeker mijn ervaring!

Het klinkt gek, maar het scannen van je eigen netwerk om erachter te komen wat je hebt, is iets dat we je sowieso aanraden om regelmatig te doen.

Maar als je hoort over een bulletin als dit en het is een product waarvan je weet dat je het in het verleden hebt gebruikt, zoals Microsoft Exchange, dan is het zeker een goed moment om dat interne Nmap-scan...

…en misschien zelfs inloggen op shodan.io en controleer uw externe services, om er zeker van te zijn dat al die dingen zijn uitgeschakeld.

---

EEND.  We weten nu uit de eigen reactie van Microsoft dat ze als een dolle bezig zijn om patches uit te brengen.

Als die patches verschijnen, kun je ze maar beter heel snel aanbrengen, nietwaar?

Want als een patch ooit het doelwit zal zijn van reverse engineering om de exploit te achterhalen, zal het iets van dit soort zijn.

---

CHET.  Ja, absoluut, Eend!

Zelfs als je eenmaal hebt gepatcht, zal er een tijdvenster zijn, toch?

Ik bedoel, typisch Microsoft, voor Patch Tuesdays toch, brengen hun patches om 10.00 uur Pacific time uit.

Op dit moment zijn we in Daylight Time, dus dat is UTC-7... dus rond 17 uur UTC is typisch wanneer Microsoft patches uitbrengt, zodat de meeste van hun medewerkers de hele dag hebben om vervolgens te reageren op binnenkomende vragen in Seattle. [Het hoofdkantoor van Microsoft bevindt zich in Bellevue, Seattle, WA.]

De sleutel hier is dat er een soort "race" van uren, misschien minuten is, afhankelijk van hoe gemakkelijk dit te exploiteren is, voordat het begint te gebeuren.

En nogmaals, als we teruggaan naar die eerdere Exchange-exploitaties met ProxyShell en ProxyLogon, ontdekten we vaak dat zelfs klanten die binnen drie, vier, vijf dagen hadden gepatcht...

...die om eerlijk te zijn nogal snel is voor een Exchange-server, ze zijn erg moeilijk te patchen, en er komt veel testen bij kijken om er zeker van te zijn dat het betrouwbaar is voordat je je e-mailservers verstoort.

Dat was genoeg tijd voor die servers om te krijgen webshells, cryptominers, allerlei soorten backdoors erop geïnstalleerd.

En dus, als de officiële patch uit is, moet je niet alleen snel handelen...

…*na* je actie hebt ondernomen, is het de moeite waard om terug te gaan en die systemen grondig te controleren op bewijs dat ze misschien zijn aangevallen in de periode tussen het moment waarop de patch beschikbaar kwam en het moment waarop je hem kon toepassen.

Ik weet zeker dat er genoeg gesprekken zullen zijn over Naked Security, en verder Twitter en andere plaatsen, praten over de soorten aanvallen die we zien, zodat u weet waar u op moet letten.

---

EEND.  Terwijl je op zoek kunt gaan naar een heleboel hashes van bekende malware die al in een beperkt aantal aanvallen is verspreid...

… het komt er eigenlijk op neer dat allerlei soorten malware mogelijk zijn.

En dus, zoals ik denk dat je zei in de laatste mini-aflevering dat we hebben gedaan, is het niet langer voldoende om te wachten op waarschuwingen van iets ergs dat toevallig in je dashboard is verschenen:

Je moet proactief op pad gaan en kijken of er al boeven in je netwerk zijn geweest en ze iets hebben achtergelaten (dat er al eeuwen kan staan!) dat je nog niet is opgevallen.

---

CHET.  Dus ik denk dat dat ons leidt naar, "Wat doen we nu, terwijl we wachten op de patch?"

De blog van Microsoft Security Research Center (MSRC) vrijgegeven wat mitigatieadvies en details ... zoveel als Microsoft op dit moment bereid is bekend te maken.

Ik zou zeggen, als je een pure bent Microsoft ExchangeOnline klant, u bent vrij duidelijk en u moet gewoon opletten voor het geval er dingen veranderen.

Maar als je in een hybride situatie zit, of als je Microsoft Exchange nog steeds on-premise draait, denk ik dat er waarschijnlijk wat werk is dat de moeite waard is om vanmiddag of morgenochtend te doen, als er niets anders is.

Op het moment van opnemen is dit natuurlijk vrijdagmiddag... dus echt, als je hiernaar luistert: "Onmiddellijk, wanneer je het hoort, als je het nog niet hebt gedaan."

Wat zijn hier de beste praktijken, Duck?

Het is duidelijk dat een ding dat u kunt doen, is gewoon de externe webtoegang uitschakelen totdat er een patch beschikbaar is.

Je zou gewoon je IIS-server kunnen afsluiten en dan is het genoeg!

---

EEND.  Ik vermoed dat veel bedrijven niet in die positie zullen verkeren.

En Microsoft somt twee dingen op die ze zeggen... nou ja, ze zeggen niet, “Dit gaat zeker lukken.”

Ze suggereren dat het uw risico aanzienlijk zal beperken.

Een daarvan is dat er een regel voor het herschrijven van URL's is die u op uw IIS-server kunt toepassen. (Ik heb begrepen dat IIS de inkomende verbinding accepteert die verandert in de toegang tot Exchange Web Services [EWS].)

Er is dus een IIS-instelling die u kunt maken die zoekt naar waarschijnlijke exploitaties van het eerste gat, waardoor wordt voorkomen dat de PowerShell-triggering wordt gestart.

En er zijn enkele TCP-poorten die u op uw Exchange Server kunt blokkeren.

Ik geloof dat het poort 5985 en 5986 zijn, die zullen stoppen met wat wordt genoemd PowerShell Remoting… het zal voorkomen dat deze malafide PowerShell-opdrachten voor externe uitvoering in de Exchange-server worden gepord.

Houd er echter rekening mee dat Microsoft zegt dat dit uw blootstelling zal "beperken", in plaats van te beloven dat ze weten dat het alles oplost.

En dat kan zijn omdat ze vermoeden dat er andere manieren zijn waarop dit kan worden geactiveerd, maar ze zijn er gewoon nog niet helemaal achter wat ze zijn. [LACHT]

Geen van beide instellingen doet u in Exchange zelf.

Een daarvan is in IIS en de andere is een soort netwerkfilterregel.

---

CHET.  Dat is handig om de komende dagen door te komen, terwijl Microsoft ons een permanente oplossing geeft.

Het goede nieuws is dat ik denk dat veel beveiligingssoftware, of dat nu een IPS is die mogelijk in uw firewall is geïntegreerd, of eindpuntbeveiligingsproducten die u heeft om uw Microsoft Windows Server-infrastructuur te beschermen...

…de aanvallen hiervoor lijken in veel gevallen (althans vroege rapporten) erg op ProxyLogon, en als gevolg daarvan is het onduidelijk of bestaande regels bescherming bieden tegen deze aanvallen.

Dat kan, maar daarnaast lijken de meeste leveranciers te proberen ze een beetje aan te scherpen, om ervoor te zorgen dat ze zo klaar mogelijk zijn, op basis van alle indicatoren die momenteel openbaar zijn gedeeld, zodat ze zullen detecteren en u waarschuwingen sturen als deze zich voordoen op uw Exchange-servers.

---

EEND.  Dat klopt, Chester.

En het goede nieuws voor Sophos-klanten is dat u Sophos-specifieke detecties kunt volgen als u uw logboeken wilt bekijken.

Niet alleen voor IPS, of dat nu de IPS op de firewall of het eindpunt is, maar we hebben ook een heleboel gedragsregels.

Je kunt die detectienamen volgen als je ze wilt gaan zoeken ... volg dat op de @SophosXops Twitter-feed.

Omdat we nieuwe detectienamen krijgen die u kunt gebruiken voor het opsporen van bedreigingen, publiceren we ze daar zodat u ze gemakkelijk kunt opzoeken:

Sophos X-Ops heeft de volgende detecties toegevoegd:

Troj/WebShel-EC en Troj/WebShel-ED detecteren de bij aanvallen besproken webshells.

IPS-handtekening sid:2307757 gebaseerd op de informatie die door Microsoft is gepubliceerd voor zowel Sophos XG Firewall als Sophos Endpoint IPS.

— Sophos X-Ops (@SophosXOps) 30 september 2022

---

CHET.  Ik weet zeker dat we in de podcast van volgende week meer te vertellen hebben, of het nu gaat om Doug die weer bij je is, of dat ik weer in de gaststoel zit.

Maar ik heb er alle vertrouwen in dat we dit voorlopig niet in bedwang kunnen houden….

---

EEND.  Ik denk dat, net als ProxyShell, net als Log4Shell, er geruime tijd een echo zal zijn.

Dus misschien kunnen we beter zeggen, zoals we altijd doen, Chester:

Tot de volgende keer…

---

BEIDE.  Blijf veilig.

[MUZIEK MODEM]