Fare clic e trascinare sulle onde sonore sottostanti per passare a qualsiasi punto. Puoi anche ascolta direttamente su Soundcloud.

[MODE MUSICALE]

ANATRA.  Ciao a tutti.

Benvenuti in un altro mini-episodio speciale del podcast Naked Security.

Sono Paul Ducklin, affiancato di nuovo dal mio amico e collega Chester Wisniewski.

Ciao, Chet.

CHET.  [FALSO ACCENTO AUSSIE] Buongiorno, Papera.

ANATRA.  Bene, Chet, sono sicuro che tutti ascoltano. se stanno ascoltando poco dopo l'uscita del podcast, sa di cosa parleremo!

E deve essere questa doppia canna Microsoft Exchange zero-day che è uscito in lavatrice praticamente l'ultimo giorno di settembre 2022:

I nostri amici delle vendite stanno dicendo: "Oh, è fine mese, è fine trimestre, è un periodo frenetico... ma domani tutti avranno un reset a $ 0".

Non sarà così questo fine settimana per amministratori di sistema e responsabili IT!

CHET.  Duck, credo, nelle parole immortali del caro e scomparso Douglas Adams, "NIENTE PANICO" potrebbe essere in ordine.

Molte organizzazioni non ospitano più la propria posta elettronica in locale sui server Exchange, quindi una buona parte della gente può fare un respiro profondo e lasciar passare un po' di tempo questo fine settimana, senza stressarsi troppo.

Ma se esegui Exchange in locale...

…se fossi in me, potrei fare degli straordinari solo per mettere in atto alcune mitigazioni, per essere sicuro di non avere una spiacevole sorpresa lunedì o martedì quando questo, con ogni probabilità, si svilupperà in qualcosa di più drammatico.

ANATRA.  Così è CVE-2022-41040 ed CVE-2022-41042... è un bel boccone.

L'ho visto essere chiamato su Twitter come ProxyNotShell, perché ha alcune somiglianze con il ProxyShell vulnerabilità che era la grande storia poco più di un anno fa,

Ma sebbene abbia queste somiglianze, è una coppia completamente nuova di exploit che si concatenano, dando potenzialmente l'esecuzione di codice in remoto – è corretto?

CHET.  Ecco come suona.

Queste vulnerabilità sono state scoperte durante un attacco attivo contro una vittima e un'organizzazione vietnamita chiamata GTSC ha svelato queste due nuove vulnerabilità che hanno consentito agli avversari di accedere ad alcuni dei loro clienti.

Sembra che abbiano rivelato responsabilmente quelle vulnerabilità alla Zero Day Initiative [ZDI] gestita da Trend Micro per la segnalazione responsabile delle vulnerabilità zero-day.

E, naturalmente, ZDI a sua volta ha condiviso tutta questa intelligenza con Microsoft, poco più di tre settimane fa.

E il motivo per cui uscirà oggi è che penso che il gruppo vietnamita...

…sembra che stiano diventando un po' impazienti e preoccupati per il fatto che siano trascorse tre settimane e che nessun avviso o consiglio sia stato inviato per aiutare a proteggere le persone contro questi presunti attori dello stato-nazione.

Così hanno deciso di lanciare il campanello d'allarme e far sapere a tutti che devono fare qualcosa per proteggersi.

ANATRA.  E, per essere onesti, hanno detto con attenzione, "Non riveleremo esattamente come sfruttare queste vulnerabilità, ma ti forniremo delle mitigazioni che abbiamo trovato efficaci."

Sembra che uno dei due exploit da solo non sia particolarmente pericoloso...

...ma incatenato, significa che qualcuno al di fuori dell'organizzazione che ha la capacità di leggere la posta elettronica dal tuo server potrebbe effettivamente utilizzare il primo bug per aprire la porta e il secondo bug per impiantare essenzialmente malware sul tuo server Exchange.

CHET.  E questo è un punto davvero importante da sottolineare, Papera, che hai detto, "Qualcuno che può leggere la posta elettronica sul tuo server."

Questo non è un attacco *non autenticato*, quindi gli aggressori devono disporre di informazioni sulla tua organizzazione per eseguire con successo questi attacchi.

ANATRA.  Ora, non sappiamo esattamente di che tipo di credenziali abbiano bisogno, perché nel momento in cui stiamo registrando questo [2022-09-30T23:00:00Z], tutto è ancora in gran parte segreto.

Ma da quello che ho letto (da persone che sono propenso a credere), sembra che i cookie di sessione o i token di autenticazione non siano abbastanza buoni e che in realtà avresti bisogno della password di un utente.

Dopo aver fornito la password, se invece esistesse l'autenticazione a due fattori [2FA], si attiva il primo bug (quello che apre la porta) *tra il punto in cui viene fornita la password e il punto in cui verrebbero visualizzati i codici 2FA richiesto*.

Quindi ti serve la password, ma non il codice 2FA...

CHET.  Sembra che si tratti di una "vulnerabilità di autenticazione intermedia", se vuoi chiamarla così.

Questa è una benedizione mista.

Significa che uno script Python automatizzato non può semplicemente scansionare l'intera Internet e potenzialmente sfruttare ogni server Exchange nel mondo in pochi minuti o ore, come abbiamo visto accadere con ProxyLogon e ProxyShell nel 2021.

Abbiamo assistito al ritorno del wormage negli ultimi 18 mesi, a scapito di molte organizzazioni.

ANATRA.  "Verme"?

CHET.  Verme, sì! [RIDE]

ANATRA.  È una parola?

Bene, se non lo è, lo è ora!

Mi piace... Potrei prenderlo in prestito, Chester. [RIDE]

CHET.  Penso che questo sia leggermente wormable, giusto?

Hai bisogno di una password, ma trovare una combinazione di indirizzo e-mail e password valida su qualsiasi server Exchange non è probabilmente troppo difficile, sfortunatamente.

Quando parli di centinaia o migliaia di utenti... in molte organizzazioni, è probabile che uno o due di loro abbiano password scadenti.

E potresti non essere stato sfruttato fino ad oggi, perché per accedere correttamente a Outlook Web Access [OWA] richiede il loro token FIDO o il loro autenticatore o qualsiasi secondo fattore che potresti utilizzare.

Ma questo attacco non richiede quel secondo fattore.

Quindi, solo acquisire una combinazione di nome utente e password è una barriera piuttosto bassa...

ANATRA.  Ora c'è un'altra complessità qui, vero?

Vale a dire che però Le linee guida di Microsoft afferma ufficialmente che i clienti di Microsoft Exchange Online possono rinunciare a Blue Alert, è pericoloso solo se si dispone di Exchange on-premise...

...ci sono un numero sorprendente di persone che sono passate al cloud, forse diversi anni fa, che eseguivano contemporaneamente sia i propri servizi on-premise che i propri servizi cloud durante il passaggio, che non sono mai riusciti a disattivare i servizi on-premise Server di scambio.

CHET.  Precisamente!

Abbiamo visto questo tornare a ProxyLogin e ProxyShell.

In molti casi, i criminali sono entrati nella loro rete attraverso server Exchange che pensavano di non avere.

Ad esempio, qualcuno non ha controllato l'elenco delle VM in esecuzione sul proprio server VMware per notare che i propri server Exchange migratori che li assistevano durante il forklift dei dati tra la propria rete on-premise e la rete cloud...

…erano ancora, infatti, accesi, abilitati ed esposti a Internet.

E peggio, quando non è noto che siano lì, è ancora meno probabile che siano stati rattoppati.

Voglio dire, le organizzazioni che hanno Exchange almeno probabilmente fanno di tutto per programmare la manutenzione su base regolare.

Ma quando non sai di avere qualcosa sulla tua rete "perché te lo sei dimenticato", il che è davvero facile con le VM, ti trovi in ​​una situazione ancora peggiore, perché probabilmente non hai applicato gli aggiornamenti di Windows o gli aggiornamenti di Exchange.

ANATRA.  E la legge di Murphy dice che se ti affidi davvero a quel server e non lo stai curando correttamente, andrà in crash proprio il giorno prima che tu ne abbia davvero bisogno.

Ma se non sai che è lì e potrebbe essere usato per il male, le probabilità che durerà per anni e anni e anni senza alcun problema è probabilmente piuttosto alta. [RIDE]

CHET.  Sì, purtroppo, questa è stata sicuramente la mia esperienza!

Sembra sciocco, ma scansionare la tua rete per scoprire cosa hai è qualcosa che ti consigliamo di fare comunque regolarmente.

Ma certamente, quando si sente parlare di un bollettino come questo, se si tratta di un prodotto che sai di aver utilizzato in passato, come Microsoft Exchange, è un buon momento per eseguire quel Scansione Nmap...

...e forse anche accedere shodan.io e controlla i tuoi servizi esterni, solo per essere sicuro che tutte quelle cose siano state disattivate.

ANATRA.  Ora sappiamo dalla risposta di Microsoft che si stanno allontanando freneticamente per ottenere le patch.

Quando compaiono quelle patch, faresti meglio ad applicarle abbastanza velocemente, vero?

Perché se una patch verrà mai presa di mira per il reverse engineering per capire l'exploit, sarà qualcosa del genere.

CHET.  Sì, assolutamente, Anatra!

Anche dopo aver applicato la patch, ci sarà una finestra di tempo, giusto?

Voglio dire, in genere Microsoft, comunque per i Patch Tuesdays, rilascia le patch alle 10.00:XNUMX ora del Pacifico.

In questo momento siamo in Daylight Time, quindi è UTC-7... quindi, intorno alle 17:00 UTC è in genere il momento in cui Microsoft rilascia le patch, in modo che la maggior parte del personale abbia l'intera giornata per rispondere alle domande in arrivo a Seattle. [Il quartier generale di Microsoft si trova a Bellevue, Seattle, WA.]

La chiave qui è che c'è una specie di "corsa" di ore, forse minuti, a seconda di quanto sia facile sfruttarla, prima che inizi a succedere.

E ancora, tornando a quei precedenti exploit di Exchange con ProxyShell e ProxyLogon, abbiamo spesso riscontrato che anche i clienti che avevano applicato le patch entro tre, quattro, cinque giorni...

...che ad essere onesti, è piuttosto veloce per un server Exchange, sono molto difficili da correggere, con molti test necessari per essere sicuri che sia affidabile prima di interrompere i server di posta elettronica.

Era abbastanza tempo per ottenere quei server webshell, cryptominers, tutti i tipi di backdoor installato su di essi.

E così, quando uscirà la patch ufficiale, non solo dovrai agire in fretta...

…*dopo* che hai agito, vale la pena tornare indietro e controllare a fondo quei sistemi per la prova che forse sono stati attaccati nel divario tra quando la patch è diventata disponibile e quando sei stato in grado di applicarla.

Sono sicuro che ci saranno molte conversazioni su Naked Security, e così via Twitter e in altri luoghi, parlando dei tipi di attacchi che stiamo vedendo in modo da sapere cosa cercare.

ANATRA.  Mentre puoi andare a cercare un mucchio di hash di malware noto che è stato già distribuito in un numero limitato di attacchi...

... davvero, la linea di fondo è che tutti i tipi di malware sono possibili.

E così, come penso tu abbia detto nel ultimo mini-episodio che abbiamo fatto, non è più sufficiente solo aspettare che gli avvisi di qualcosa di brutto che è successo vengano visualizzati nella tua dashboard:

Devi uscire in modo proattivo e guardare, nel caso in cui i truffatori siano già stati nella tua rete e abbiano lasciato qualcosa dietro (che potrebbe essere lì da secoli!) che non hai ancora notato.

CHET.  Quindi penso che ci porti verso, "Cosa facciamo adesso, mentre aspettiamo la patch?"

Pubblicato il blog del Microsoft Security Research Center (MSRC). qualche consiglio di mitigazione e dettagli... per quanto Microsoft è disposta a rivelare in questo momento.

Direi, se sei un puro Microsoft Exchange in linea cliente, sei praticamente in chiaro e dovresti solo prestare attenzione nel caso in cui le cose cambino.

Ma se ti trovi in ​​una situazione ibrida o stai ancora eseguendo Microsoft Exchange in locale, penso che probabilmente ci sia del lavoro che vale la pena fare questo pomeriggio o domani mattina se non altro.

Ovviamente, al momento della registrazione, questo è venerdì pomeriggio... quindi, davvero, quando ascolti questo, "Immediatamente, ogni volta che lo senti, se non l'hai già fatto".

Quali sono le migliori pratiche qui, Papera?

Ovviamente, una cosa che puoi fare è semplicemente disattivare l'accesso al Web esterno fino a quando non sarà disponibile una patch.

Potresti semplicemente spegnere il tuo server IIS e poi lo farà!

ANATRA.  Sospetto che molte aziende non saranno in quella posizione.

E Microsoft elenca due cose che dicono... beh, non dicono, "Questo funzionerà sicuramente."

Suggeriscono che limiterà notevolmente il rischio.

Uno è che esiste una regola di riscrittura degli URL che puoi applicare al tuo server IIS. (La mia comprensione è che è IIS che accetta la connessione in entrata che si trasforma nell'accesso a Servizi Web Exchange [EWS].)

Quindi c'è un'impostazione IIS che puoi fare che cercherà probabili sfruttamenti del primo buco, che impedirà l'avvio del trigger di PowerShell.

E ci sono alcune porte TCP che puoi bloccare sul tuo Exchange Server.

Credo che siano le porte 5985 e 5986, che fermeranno ciò che viene chiamato Comunicazione remota PowerShell... impedirà che questi comandi di esecuzione remota di PowerShell non autorizzati vengano inseriti nel server di Exchange.

Nota, tuttavia, che Microsoft afferma che ciò "limiterà" la tua esposizione, piuttosto che promettere di sapere che risolve tutto.

E ciò potrebbe essere dovuto al sospetto che ci siano altri modi in cui ciò potrebbe essere attivato, ma non hanno ancora capito bene cosa siano. [RIDE]

Nessuna delle impostazioni è qualcosa che fai in Exchange stesso.

Uno di questi è in IIS e l'altro è una sorta di regola di filtraggio della rete.

CHET.  Bene, questo è utile per farci passare i prossimi giorni mentre Microsoft ci offre una soluzione permanente.

La buona notizia è che penso che un sacco di software di sicurezza, sia che si tratti di un IPS che può essere integrato nel firewall, o di prodotti per la sicurezza degli endpoint che hai per proteggere la tua infrastruttura di Microsoft Windows Server...

...gli attacchi per questo, in molti casi (almeno i primi rapporti), sembrano molto simili a ProxyLogon e, di conseguenza, non è chiaro se le regole esistenti proteggeranno da questi attacchi.

Potrebbero, ma in aggiunta a ciò, sembra che la maggior parte dei fornitori stia cercando di rafforzarli un po', per assicurarsi che siano il più pronti possibile, sulla base di tutti gli indicatori che sono stati attualmente condivisi pubblicamente, in modo da rilevare e inviarti avvisi se questi dovessero verificarsi sui tuoi server Exchange.

ANATRA.  Esatto, Chester.

E la buona notizia per i clienti Sophos è che è possibile tenere traccia dei rilevamenti specifici di Sophos se si desidera esaminare i registri.

Non solo per IPS, sia che si tratti dell'IPS sul firewall o dell'endpoint, ma abbiamo anche una serie di regole comportamentali.

Puoi tenere traccia di quei nomi di rilevamento se vuoi cercarli ... seguilo sul @SophosXops Feed di Twitter.

Man mano che riceviamo nuovi nomi di rilevamento che puoi utilizzare per la caccia alle minacce, li pubblichiamo lì in modo che tu possa cercarli facilmente:

Sophos X-Ops ha aggiunto i seguenti rilevamenti:

Troj/WebShel-EC e Troj/WebShel-ED rilevano le webshell discusse negli attacchi.

Firma IPS sid:2307757 in base alle informazioni pubblicate da Microsoft sia per Sophos XG Firewall che per Sophos Endpoint IPS.

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

CHET.  Sono sicuro che avremo altro da dire sul podcast della prossima settimana, sia che si tratti di Doug che si unisce a te, sia che io sia di nuovo al posto degli ospiti.

Ma sono abbastanza fiducioso che non saremo in grado di metterlo a letto per un bel po' di tempo ormai...

ANATRA.  Penso che, come ProxyShell, come Log4Shell, ci sarà un'eco che riverbererà per un bel po' di tempo.

Quindi forse faremmo meglio a dire, come facciamo sempre, Chester:

Fino alla prossima volta…

TUTTI E DUE.  Stai al sicuro.

[MODE MUSICALE]