Precis när du hoppades att veckan skulle lugna ner sig och ge dig lite SecOps-stopp under helgen...

…och tillsammans kommer ett helt nytt nolldagshål i Microsoft Exchange!

Mer exakt, två nolldagar som tydligen kan kedjas samman, med den första buggen som används på distans för att öppna tillräckligt med ett hål för att utlösa den andra buggen, vilket potentiellt tillåter fjärrkodexekvering (RCE) på själva Exchange-servern.

Microsoft publicerade snabbt officiell vägledning om dessa sårbarheter och sammanfattar situationen på följande sätt:

Microsoft undersöker två rapporterade nolldagarssårbarheter som påverkar Microsoft Exchange Server 2013, 2016 och 2019. Den första sårbarheten, identifierad som CVE-2022-41040, är en Server-Side Request Forgery (SSRF) sårbarhet, medan den andra, identifierad som CVE-2022-41082, tillåter fjärrkörning av kod (RCE) när PowerShell är tillgängligt för angriparen.

För närvarande är Microsoft medveten om begränsade riktade attacker som använder de två sårbarheterna för att komma in i användarnas system. I dessa attacker kan CVE-2022-41040 göra det möjligt för en autentiserad angripare att fjärrutlösa CVE-2022-41082. Det bör noteras att autentiserad åtkomst till den sårbara Exchange-servern är nödvändig för att framgångsrikt kunna utnyttja någon av de två sårbarheterna.

Så vitt vi kan se finns det två silverfoder här:

• Buggarna kan inte utlösas av vem som helst. Visst, alla fjärranvändare som redan har loggat in på sitt e-postkonto över internet och vars dator är infekterad av skadlig programvara, kan i teorin få sitt konto omstörtat för att starta en attack som utnyttjar dessa buggar. Men att bara ha din Exchange-server åtkomlig över internet räcker inte i sig för att utsätta dig för attack, eftersom s.k. oautentiserad anrop av dessa buggar är inte möjligt.
• Blockering PowerShell Remoting kan begränsa attacker. Enligt Microsoft kommer blockering av TCP-portarna 5985 och 5986 på din Exchange-server att begränsa (om inte faktiskt förhindra) angripare från att kedja från den första sårbarheten till den andra. Även om attacker kan vara möjliga utan att förlita sig på att utlösa PowerShell-kommandon, verkar intrångsrapporter hittills antyda att PowerShell-exekveringen var en nödvändig del av attacken.

Minnen från ProxyShell

Om denna attack påminner dig om ProxyShell sårbarhet från ungefär ett år sedan är du inte ensam om att tycka det.

Enligt GTSC, det vietnamesiska cybersäkerhetsföretaget som först undersökt och rapporterat dessa nya hål, forskare "upptäckte exploateringsförfrågningar i IIS-loggar med samma format som [den] ProxyShell-sårbarheten".

Särskilt den sortens hotjaktsfråga som vi rekommenderade för ProxyShell-exploateringen verkar spelunking redan 2021 också fungera för att upptäcka missbruk av dessa nya nolldagar:

SELECT grep.*
FROM file
CROSS JOIN grep ON (grep.path = file.path)
WHERE
file.path LIKE 'C:inetpublogsLogFilesW3SVC%u_ex210[89]%'
AND grep.pattern = 'autodiscover.json'

Microsoft också, anteckningar den där "[detektionen vi] skapade som svar på ProxyShell kan användas för frågor eftersom det finns likheter i funktionen med detta hot."

Naturligtvis vet vi ännu inte om den nya attacken kan avbrytas utan att lämna denna specifika kontrollampa i dina loggar.

Med andra ord, om du hittar triggertecken som liknar de som lämnats efter av PowerShell-exploateringar, har du förmodligen bevis på en attack, men frånvaron av dessa tecken är inte bevis på frånvaro.

Enligt GTSC, i attacker som de hittills har undersökt, använde cyberbrottslingarna sina obehöriga RCE-befogenheter för att implantera och köra en mängd uppföljande skadlig programvara, inklusive:

• Webbskal implanterade för att öppna en webbaserad bakdörr för senare. Webbskal tillåter vanligtvis uppföljande attacker för att bädda in godtyckliga systemkommandon, med godtyckliga kommandoargument, i vanliga HTTP-förfrågningar. Webbskalet alltså utför det önskade kommandot direkt med privilegierna för själva webbservern.
• Autentiseringsdumpning av skadlig programvara. Autentiseringstjuver letar vanligtvis runt på disken och i minnet (om de har tillräcklig behörighet) och letar efter lösenord i klartext, sessionscookies och autentiseringstokens som kan tillåta vad som kallas lateral rörelse till andra datorer i nätverket.
• Zombieskadlig kod i form av DLL:er som laddas in i processer som ser legitimt ut. Ett DLL-exempel som GTSC-forskare analyserade kunde fjärrmatas med krypterade instruktioner för att dumpa systeminformation, köra godtyckliga kommandon, starta C#-moduler och ändra filer och mappar på det infekterade systemet.

Vi kommer att uppdatera den här artikeln när vi lär oss mer, inklusive rapportering när Microsoft får ut patchar för att stänga dessa hål.

Hotjaktråd

För råd om hotjakt från GTSC, som upptäckte och rapporterade felen, från Microsoft och från Sophos, se:

▶ https://gteltsc.vn/blog/warning-new-attack-campaign-utilized-a-new-0day-rce-vulnerability-on-microsoft-exchange-server-12715.html

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

▶ https://news.sophos.com/en-us/2021/08/23/proxyshell-vulnerabilities-in-microsoft-exchange-what-to-do/

Vad göra?

Åtgärderna inkluderar:

• Blockera PowerShell Remoting för att minska risken för RCE. Som nämnts ovan kommer blockering av TCP-portarna 5985 och 5986 att begränsa attacker på din Exchange-server, enligt Microsoft.
• Använd Regel för omskrivning av URL för att blockera kända attackutlösare. GTSC och Microsoft har förklaringar om hur man använder IIS Server URL-omskrivningsregler för att upptäcka och neutralisera vanliga former av denna attack.
• Se till att detektering av beteendemässiga slutpunktshot är aktiverad, även på servrar. Som nämnts ovan rapporterar GTSC att attacker som hittills har setts inkluderar implantering av webbskal och skadliga DLL:er för att köra godtyckliga kommandon, manipulera filer och extrahera systeminformation. Detta ger dig många potentiella indikatorer för upptäckt och svar för att komma över en framgångsrik attack.
• Överväg att avautentisera inloggade e-postanvändare. Om du kan utföra någon slags slutpunktssäkerhetsbedömning på varje användares enhet innan du tillåter dem att autentisera på nytt, kommer du att minska (om än inte eliminera) risken för att redan komprometterade enheter samordnas för att starta attacker. Du kommer också att minska vad som kallas din overall attackytan genom att inte ha autentiserade användare hängande som inte behöver vara inloggade, eller som inte ens kommer ihåg att de någonsin loggat in från första början.
• Applicera eventuella plåster så snart de är tillgängliga. Hittills har endast begränsade attacker rapporterats, mestadels i Sydostasien, och GTSC undanhåller medvetet detaljer om sårbarheterna tills patchar är ute. Men kom ihåg att när patchar har publicerats kommer cyberbrottslingar omedelbart att börja arbeta baklänges mot fungerande bedrifter i hopp om att fånga upp de som är sena med att tillämpa uppdateringar.

Hittills [2022-09-30T13:30Z] verkar det som om de viktigaste sakerna att tänka på är: [a] tipsen och teknikerna du lärt dig för att jaga ProxyShell-attacker kommer nästan säkert att vara till hjälp här, om inte de enda verktyg du kan behöva; [b] trots likheterna (och oavsett allt du kan ha sett online), detta är inte ProxyShell, så dina ProxyShell-lappar kommer inte att skydda dig från det; och [c] när patchar anländer, anta att de kommer att reverse engineering tillbaka till fungerande bedrifter mycket snabbt, så dröj inte med att applicera dem.

LÄS MER OM WEBSHELL OCH HUR DU FÖREBYGGER DEM