Klicka och dra på ljudvågorna nedan för att hoppa till valfri punkt. Du kan också lyssna direkt på Soundcloud.

[MUSIKALT MODEM]

ANKA.  Hej alla.

Välkommen till ännu ett speciellt miniavsnitt av podcasten Naked Security.

Jag är Paul Ducklin, återigen sällskap av min vän och kollega Chester Wisniewski.

Hej, Chet.

CHET.  [FAKE AUSSIE ACCENT] Goddag, Duck.

ANKA.  Tja, Chet, jag är säker på att alla lyssnar. om de lyssnar kort efter att podden kom ut, vet vad vi ska prata om!

Och det måste vara så här dubbelpipigt Microsoft Exchange nolldagar som kom ut i tvätten i stort sett den sista september 2022:

Våra säljare säger, "Åh, det är slutet av månaden, det är slutet av kvartalet, det är en hektisk tid... men imorgon får alla en återställning till $ 0."

Det kommer inte att bli så i helgen för Sysadmins och IT-chefer!

CHET.  Duck, tror jag, med de odödliga ord av den avlidne Douglas Adams, "FÅ INTE PANIK" kan vara i sin ordning.

Många organisationer är inte längre värd för sin egen e-post på plats på Exchange-servrar, så en hel del människor kan ta ett djupt andetag och låta lite tid passera denna helg, utan att bli alltför stressad över det.

Men om du kör Exchange på plats...

…om det var jag kanske jag skulle jobba lite övertid bara för att sätta några begränsningar på plats, för att vara säker på att jag inte får en obehaglig överraskning på måndag eller tisdag när det här med all sannolikhet kommer att utvecklas till något mer dramatisk.

ANKA.  Så det är CVE-2022-41040 och CVE-2022-41042… det är en hel mun.

Jag har sett att det hänvisas till på Twitter som ProxyNotShell, eftersom det har vissa likheter med ProxyShell sårbarhet som var den stora historien för drygt ett år sedan,

Men även om det har de likheterna, är det ett helt nytt par exploateringar som kedjar ihop, vilket potentiellt ger fjärrkörning av kod – är det korrekt?

CHET.  Det är så det låter.

Dessa sårbarheter upptäcktes under en aktiv attack mot ett offer, och en vietnamesisk organisation som heter GTSC avslöjade dessa två nya sårbarheter som gjorde det möjligt för motståndarna att få tillgång till några av sina kunder.

Det låter som att de på ett ansvarsfullt sätt avslöjat dessa sårbarheter till Zero Day Initiative [ZDI] som drivs av Trend Micro för att rapportera nolldagars sårbarheter på ett ansvarsfullt sätt.

Och naturligtvis delade ZDI sedan i sin tur all denna intelligens med Microsoft för lite över tre veckor sedan.

Och anledningen till att den kommer ut idag är att jag tror att den vietnamesiska gruppen...

…det låter som att de börjar bli lite otåliga och oroliga över att det har gått tre veckor och att inga varningar eller råd har gått ut för att skydda människor mot dessa påstådda nationalstatsaktörer.

Så de bestämde sig för att slå på varningsklockorna och låta alla veta att de måste göra något för att skydda sig själva.

ANKA.  Och för att vara rättvis sa de försiktigt, "Vi kommer inte att avslöja exakt hur man utnyttjar dessa sårbarheter, men vi kommer att ge dig begränsningar som vi fann effektiva."

Det låter som om endera exploateringen i sig inte är särskilt farlig...

…men sammankopplat betyder det att någon utanför organisationen som har förmågan att läsa e-post från din server faktiskt kan använda den första buggen för att öppna dörren, och den andra buggen för att i huvudsak implantera skadlig programvara på din Exchange-server.

CHET.  Och det är en väldigt viktig poäng att göra, Duck, att du sa, "Någon som kan läsa e-post på din server."

Detta är inte en *oautentiserad* attack, så angriparna behöver ha viss intelligens om din organisation för att framgångsrikt kunna utföra dessa attacker.

ANKA.  Nu vet vi inte exakt vilken typ av inloggningsuppgifter de behöver, för när vi spelar in detta [2022-09-30T23:00:00Z], är allt fortfarande till stor del hemligt.

Men från vad jag har läst (från folk som jag är benägen att tro), ser det ut som om sessionscookies eller autentiseringstokens inte är tillräckligt bra, och att du faktiskt skulle behöva en användares lösenord.

Efter att ha angett lösenordet, men om det fanns tvåfaktorsautentisering [2FA], utlöses den första buggen (den som öppnar dörren) *mellan punkten där lösenordet tillhandahålls och punkten där 2FA-koderna skulle vara begärda*.

Så du behöver lösenordet, men du behöver inte 2FA-koden...

CHET.  Det låter som att det är en "mid-autentiseringssårbarhet", om du vill kalla det så.

Det är en blandad välsignelse.

Det betyder att ett automatiserat Python-skript inte bara kan skanna hela internet och potentiellt utnyttja alla Exchange-servrar i världen inom några minuter eller timmar, som vi såg hända med ProxyLogon och ProxyShell 2021.

Vi såg hur masken återvände under de senaste 18 månaderna, till nackdel för många organisationer.

ANKA.  "Ordning"?

CHET.  Avmaskning, ja! [skrattar]

ANKA.  Är det ett ord?

Tja, om det inte är det så är det nu!

Jag gillar det... Jag kanske lånar det, Chester. [skrattar]

CHET.  Jag tror att det här är lätt maskbart, eller hur?

Du behöver ett lösenord, men att hitta en kombination av e-postadress och lösenord som är giltig på en given Exchange-server är förmodligen inte så svårt, tyvärr.

När du talar om hundratals eller tusentals användare... i många organisationer har en eller två av dem sannolikt dåliga lösenord.

Och du kanske inte har blivit utnyttjad hittills, eftersom för att lyckas logga in på Outlook Web Access [OWA] krävs deras FIDO-token, eller deras autentisering, eller vilken andra faktor du kan använda.

Men denna attack kräver inte den andra faktorn.

Så, bara att skaffa en kombination av användarnamn och lösenord är en ganska låg barriär...

ANKA.  Nu finns det en annan komplexitet här, eller hur?

Nämligen det fast Microsofts riktlinjer säger officiellt att Microsoft Exchange Online-kunder kan avstå från Blue Alert, det är bara farligt om du har en lokal Exchange...

…det finns ett förvånansvärt antal människor som bytte till molnet, möjligen för flera år sedan, som körde både sin lokala och sin molntjänst samtidigt under övergången, som aldrig kom på att stänga av den lokala Exchange-server.

CHET.  Exakt!

Vi såg detta gå tillbaka till ProxyLogin och ProxyShell.

I många fall kom brottslingarna in i deras nätverk via Exchange-servrar som de trodde att de inte hade.

Som, någon kollade inte listan över virtuella datorer som kördes på deras VMware-server för att märka att deras migrerande Exchange-servrar som hjälpte dem under gaffeltrucken av data mellan deras lokala nätverk och molnnätverket...

...var fortfarande i själva verket påslagna, aktiverade och exponerade för internet.

Och värre, när de inte är kända för att vara där, är det ännu mindre sannolikt att de har blivit lappade.

Jag menar, organisationer som har Exchange går åtminstone antagligen ut av deras sätt att schemalägga underhåll på dem regelbundet.

Men när du inte vet att du har något på ditt nätverk "för att du har glömt", vilket är väldigt enkelt med virtuella datorer, är du i en ännu värre situation, eftersom du förmodligen inte har tillämpat Windows-uppdateringar eller Exchange-uppdateringar.

ANKA.  Och Murphys lag säger att om du verkligen litar på den servern och du inte sköter den ordentligt, kommer den att krascha precis dagen innan du verkligen behöver den.

Men om du inte vet att den finns där och att den kan användas för dåligt, är chansen att den kommer att fungera i åratal och år utan problem över huvud taget ganska stor. [SKratt]

CHET.  Ja, tyvärr, det har verkligen varit min erfarenhet!

Det låter dumt, men att skanna ditt eget nätverk för att ta reda på vad du har är något som vi skulle rekommendera att du gör regelbundet ändå.

Men visst, när du hör om en sådan här bulletin, om det är en produkt som du vet att du har använt tidigare, som Microsoft Exchange, är det en bra tid att köra den interna Nmap skanning.

...och kanske till och med logga in shodan.io och kontrollera dina externa tjänster, bara för att vara säker på att allt det där stängdes av.

ANKA.  Vi vet nu från Microsofts eget svar att de frenetiskt slänger iväg för att få ut patchar.

När de där plåstren dyker upp är det bäst att du applicerar dem ganska snabbt, eller hur?

För om någon patch någonsin kommer att bli inriktad på reverse engineering för att ta reda på utnyttjandet, kommer det att bli något av det här slaget.

CHET.  Ja, absolut, Anka!

Även när du har patchar kommer det att finnas ett tidsfönster, eller hur?

Jag menar, vanligtvis Microsoft, för Patch Tuesdays i alla fall, släpper deras patchar klockan 10.00 Stillahavstid.

Just nu är vi i Daylight Time, så det är UTC-7... så runt 17:00 UTC är vanligtvis när Microsoft släpper patchar, så att de flesta av deras personal har hela dagen på sig att sedan svara på inkommande frågor i Seattle. [Microsofts huvudkontor ligger i Bellevue, Seattle, WA.]

Nyckeln här är att det finns ett slags "lopp" på timmar, kanske minuter, beroende på hur lätt detta är att utnyttja, innan det börjar hända.

Och återigen, när vi går tillbaka till de tidigare Exchange-exploateringarna med ProxyShell och ProxyLogon, fann vi ofta att även kunder som hade patchat inom tre, fyra, fem dagar...

...som för att vara ärlig, är något snabb för en Exchange-server, de är mycket svåra att korrigera, med en hel del tester inblandade för att vara säker på att det är tillförlitligt innan du stör dina e-postservrar.

Det var tillräckligt med tid för dessa servrar att få webbskal, cryptominers, alla möjliga bakdörrar installerat på dem.

Och så, när den officiella patchen är ute, behöver du inte bara agera snabbt...

…*efter* du har agerat är det väl värt att gå tillbaka och noggrant kontrollera dessa system för bevis på att de kanske har attackerats i gapet mellan när plåstret blev tillgängligt och när du kunde applicera det.

Jag är säker på att det kommer att bli mycket samtal om Naked Security och vidare Twitter och andra ställen, talar om de typer av attacker vi ser så att du vet vad du ska leta efter.

ANKA.  Medan du kan gå och leta efter ett gäng hash av känd skadlig programvara som redan har distribuerats i ett begränsat antal attacker...

… egentligen är slutsatsen att alla typer av skadlig programvara är möjligheter.

Och så, som jag tror du sa i sista miniavsnittet som vi gjorde, räcker det inte längre att bara vänta på varningar om något dåligt som har råkat dyka upp i din instrumentpanel:

Du måste gå ut proaktivt och titta, ifall skurkar redan har varit i ditt nätverk och de har lämnat något bakom sig (som kunde ha funnits där i evigheter!) som du inte har märkt ännu.

CHET.  Så jag tror att det leder oss mot "Vad gör vi nu, medan vi väntar på plåstret?"

Bloggen Microsoft Security Research Center (MSRC) släpptes några begränsningsråd och detaljer... så mycket som Microsoft är villig att avslöja just nu.

Jag skulle säga, om du är ren Microsoft Exchange Online kund, du är ganska tydlig och du bör bara vara uppmärksam ifall saker förändras.

Men om du befinner dig i en hybridsituation, eller om du fortfarande kör Microsoft Exchange på plats, tror jag att det förmodligen finns en del arbete som är väl värt att göra i eftermiddag eller i morgon bitti om inte annat.

Naturligtvis, vid inspelningstillfället är det fredag ​​eftermiddag... så, verkligen, när du lyssnar på det här, "Omedelbart, närhelst du hör det, om du inte redan har gjort det."

Vilka är de bästa metoderna här, Duck?

Uppenbarligen är en sak du kan göra bara att stänga av den externa webbåtkomsten tills en patch är tillgänglig.

Du kan bara stänga av din IIS-server och sedan löser det sig!

ANKA.  Jag misstänker att många företag inte kommer att vara i den positionen.

Och Microsoft listar två saker som de säger... ja, de säger inte, "Det här kommer definitivt att fungera."

De föreslår att det kommer att avsevärt begränsa din risk.

En är att det finns en URL-omskrivningsregel som du kan tillämpa på din IIS-server. (Jag förstår att det är IIS som accepterar den inkommande anslutningen som förvandlas till åtkomst till Exchange Web Services [EWS].)

Så det finns en IIS-inställning du kan göra som kommer att leta efter troligt utnyttjande av det första hålet, vilket kommer att förhindra att PowerShell-utlösningen startas.

Och det finns några TCP-portar som du kan blockera på din Exchange Server.

Jag tror att det är port 5985 och 5986, som kommer att stoppa det som kallas PowerShell Remoting... det kommer att stoppa dessa oseriösa PowerShell fjärrexekveringskommandon från att petas in i Exchange-servern.

Observera dock att Microsoft säger att detta kommer att "begränsa" din exponering, snarare än att lova att de vet att det fixar allt.

Och det kan bero på att de misstänker att det finns andra sätt som detta kan utlösas på, men de har bara inte riktigt kommit på vad de är än. [skrattar]

Ingen av inställningen är något du gör i Exchange själv.

En av dem är i IIS, och den andra är någon form av nätverksfiltreringsregel.

CHET.  Tja, det är till hjälp för att ta oss igenom de närmaste dagarna medan Microsoft ger oss en permanent fix.

Den goda nyheten är att jag tror mycket på säkerhetsprogramvara, oavsett om det är en IPS som kan vara integrerad i din brandvägg, eller slutpunktssäkerhetsprodukter som du har som skyddar din Microsoft Windows Server-infrastruktur...

…attackerna för detta, i många fall (åtminstone tidiga rapporter), ser väldigt lika ut som ProxyLogon, och som ett resultat är det oklart om befintliga regler kommer att skydda mot dessa attacker.

De kanske, men utöver det verkar de flesta leverantörer försöka skärpa dem lite, för att säkerställa att de är så redo som möjligt, baserat på alla indikatorer som för närvarande har delats offentligt, så att de kommer att upptäcka och skicka dig varningar om dessa skulle inträffa på dina Exchange-servrar.

ANKA.  Det stämmer, Chester.

Och de goda nyheterna för Sophos kunder är att du kan spåra Sophos-specifika upptäckter om du vill gå och titta igenom dina loggar.

Inte bara för IPS, oavsett om det är IPS på brandväggen eller slutpunkten, utan vi har också en massa beteenderegler.

Du kan spåra dessa upptäcktsnamn om du vill leta efter dem... följ det på @SophosXops Twitter flöde.

När vi får nya upptäcktsnamn som du kan använda för hotjakt, publicerar vi dem där så att du enkelt kan slå upp dem:

Sophos X-Ops har lagt till följande upptäckter:

Troj/WebShel-EC och Troj/WebShel-ED upptäcker webbskalen som diskuteras i attacker.

IPS-signatur sid:2307757 baserat på informationen publicerad av Microsoft för både Sophos XG Firewall och Sophos Endpoint IPS.

— Sophos X-Ops (@SophosXOps) September 30, 2022

CHET.  Jag är säker på att vi kommer att ha mer att säga i nästa veckas podcast, oavsett om det är Doug som återvänder till dig eller om jag är i gästsätet igen.

Men jag är ganska säker på att vi inte kommer att kunna lägga det här på ett bra tag nu...

ANKA.  Jag tror, ​​precis som ProxyShell, som Log4Shell, det kommer att finnas ett eko som ekar ganska länge.

Så vi kanske borde säga, som vi alltid gör, Chester:

Tills nästa gång…

BÅDE.  Håll dig säker.

[MUSIKALT MODEM]