Migliaia di piccole e medie imprese stanno soffrendo poiché Rackspace ha subito un incidente di sicurezza sul proprio servizio Hosted Exchange.

Ieri, 2 dicembre 2022, Rackspace ha annunciato un'interruzione del proprio server Exchange ospitato:

Gli aggiornamenti sono seguiti nel corso della giornata, ma erano un po' vaghi:

Alla fine sono stato coinvolto, poiché ho notato qualcosa e l'ho documentato in questo thread:

Principalmente al servizio gestito di Rackspace utilizza i nomi host mex*.emailsrvr.com per Exchange e OWA:

E poi, guardando i dati Shodan più recenti, era chiaro che il cluster di Exchange mostrava numeri di build lunghi di Exchange che erano vecchi:

Questo numero di build di Exchange risale ad agosto 2022, prima che le patch ProxyNotShell diventassero disponibili:

I numeri di build lunghi dello scambio non sono sempre affidabili ... ma è un segno che vale la pena tenere a mente.

Ho scritto di ProxyNotShell, una vulnerabilità che ho chiamato — scusate, qui: ProxyNotShell — la storia dei dichiarati zero giorni in Microsoft Exchange | di Kevin Beaumont | Doppia Pulsar

Questa mattina presto, Rackspace ha chiarito che si tratta di un incidente di sicurezza:

Contesto della minaccia

Ora, è possibile che la violazione di Rackspace sia avvenuta a causa di altri problemi, ma come promemoria generale suggerirei alcuni punti chiave sulla minaccia:

• Le mitigazioni fornite da Microsoft per ProxyNotShell sono escludibili. IIS Rewrite, utilizzato da Microsoft per le mitigazioni, non decodifica correttamente tutti gli URL e come tale può essere ignorato per lo sfruttamento. Se hai fatto affidamento sulla mitigazione di PowerShell o sull'applicazione EEMS, il tuo Exchange Server è ancora vulnerabile : Microsoft non te l'ha detto chiaramente . La soluzione è patchare.
• Sebbene la vulnerabilità richieda l'autenticazione, gli exploit funzionano senza l'autenticazione a più fattori poiché Exchange Server non supporta ancora l'autenticazione moderna, poiché Microsoft ha depriorizzato il lavoro di implementazione (trattato nell'altro blog).
• Se sei un MSP che esegue un cluster condiviso, come Hosted Exchange, significa che un account compromesso su un cliente comprometterà l'intero cluster ospitato. Questo è ad alto rischio.

• È molto importante che gli amministratori di Exchange Server ottengano sia l'ultimo aggiornamento cumulativo che l'aggiornamento della sicurezza per Exchange Server 2013/2016/2019.
• Nel caso di Exchange Server 2013, si tratta di CU23 Nov22SU ovvero build 10.0.1497.44. Puoi controllare i tuoi numeri di build da Shodan o gli amministratori di Exchange possono utilizzare questo Powershell di seguito. Doppio controllo .

$ExchangeServers = Get-ExchangeServer | Sort-Object Name
ForEach ($Server in $ExchangeServers) {
    Invoke-Command -ComputerName $Server.Name -ScriptBlock { Get-Command Exsetup.exe | ForEach-Object { $_.FileversionInfo } }
}

• Se usi Microsoft Defender Vulnerability Management, controlla i numeri di build nel prodotto anziché fare affidamento sulle vulnerabilità identificate (noterai perché).
• Se esternalizzi la gestione di Microsoft Exchange e disponi di risorse, dovresti richiedere una prova che ogni server sia aggiornato per ogni aggiornamento. Mi rendo conto che la maggior parte delle organizzazioni che esternalizzano non avranno questa risorsa.
• Dovresti spazzare i tuoi server Exchange, se hai presentato OWA a Internet in particolare, per webshell (backdoor per dopo) e segni di attività post compromissione. Il modo più semplice per eseguire questa operazione è eseguire Microsoft Safety Scanner e Sophos Scan & Clean , che sono strumenti di scansione una tantum, per spazzare e pulire automaticamente un sistema.

L'applicazione di patch a Exchange Server è estremamente contorta, in alcuni casi rischiosa: quanti amministratori hanno avuto guasti ai server? - e confuso. Microsoft ha bisogno di modernizzarlo. Inoltre, l'autenticazione moderna deve essere implementata in Exchange Server da Microsoft: l'autenticazione di base non va bene nell'anno spaziale 2022.

Mi aspetto continui attacchi alle organizzazioni tramite Microsoft Exchange fino al 2023. E per coloro che dicono "usa Exchange Online, sciocchi!", ci sono ancora alcune sfide da affrontare: l'autorità federale tedesca per la protezione dei dati e 17 regolatori statali (DSK) hanno pubblicato un rapporto in Microsoft 365 dopo due anni di collaborazione con Microsoft e dichiara che Microsoft 365 non soddisfa ancora il GDPR citando un'ampia gamma di problemi .

Il risultato è che i clienti MS e gli ingegneri MS vengono lasciati in questa situazione: