Operazioni e sicurezza sono da sempre antagonisti. Richiedere maggiore sicurezza implica sempre un qualche costo nelle operazioni. A questa legge non scritta non si sfugge. 

Nell’aggiornamento di novembre, Microsoft ha fatto una scelta che molte altre realtà che maneggiano algoritmi di sicurezza hanno fatto o faranno: abbandonare algoritmi vulnerabili sacrificando la compatibilità con infrastrutture e configurazioni non più compatibili per la più elevata base di riferimento scelta. Certamente è una operazione che probabilmente viene mal digerita da una comunità di utenti abituata alla garanzia di compatibilità a ritroso nel tempo, anche decennale, da parte dei software Microsoft; ma il panorama delle minacce impone pur qualche sacrificio. 

Per risolvere il bypass della sicurezza e la vulnerabilità derivante dall'elevazione di privilegio presente nelle autenticazioni che utilizzino la negoziazione RC4-HMAC (CVE-2022-37966) del DES (Data Encryption Standard), Microsoft si è

Anche questo mese Microsoft ha lavorato pesantemente per correggere i problemi in tutti i suoi territori, da Azure alle soluzioni on-premise: si contano quasi 40 differenti campi di azioni su cui si è visto l’intervento della casa di Redmond. 

Il risultato è il rilascio di correzioni per problemi di sicurezza (oltre alla correzione di errori funzionali) per ben 62 CVE includenti anche vulnerabilità 0-day già viste sfruttate in natura. 

Di queste CVE, ben 9 risultano di livello critico (per il 14.5%) e 53 di livello alto (per l’85.5%). 

In particolare le tecniche maggiormente sfruttabili per via delle vulnerabilità individuate sono l’Elevazione del privilegio (EoP – Elevation of Privilege) per il 41.9% del totale, seguita dall’Esecuzione di codice Remoto (RCE – Remote Code Execution) per il 24.2% del totale. Non potevano mancare, anche se in misura nettamente minore, tecniche si Denial of Service (DoS – per il 6% del totale), Spoofing (per il 3% del totale) ed evasione di meccanismi si sicurezza (Security Features Bypass, per il 4% del totale). 

Con questa patch dobbiamo finalmente sottolineare l’attenzione e risoluzione a problemi di sicurezza mancanti nella patch del mese precedente, ossia la correzione per le CVE-2022-41040 e CVE-2022-41082 (ProxyNotShell) di cui avevamo già parlato. 

Una settimana prima dal rilascio della nuova versione 3.0.7 del progetto OpenSSL (pubblicata il 1° novembre), il team aveva preavvisato dell’arrivo di una correzione ad una vulnerabilità critica. Al dunque si è scoperto che esistono correttivi “soltanto” per due vulnerabilità di gravità alta: la CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) e la CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”), entrambe capaci di rendere possibile un attacco BOF (Buffer Overflow) ed il conseguente DoS (Denial of Service). Le vulnerabilità affliggono tutte le versioni di OpenSSL dalla versione 3.0 in avanti, quindi tutte le versioni in giro da almeno settembre del 2021. Allo stato non si hanno notizie di PoC o avvistamenti in natura di attacchi rispetto a queste vulnerabilità, pertanto è difficile capire le motivazioni per una comunicazione così allarmistica prima di un naturale rilascio di un insieme di correttivi ad un software. La spiegazione la fornisce direttamente il progetto OpenSSL che indica la CVE-2022-3602 responsabile della valutazione allarmistica iniziale: questa infatti è una vulnerabilità che causa un overflow arbitrario del buffer dello stack di 4 byte e inizialmente sembrava poter portare all'esecuzione di codice da remoto (RCE).

Una grave vulnerabilità affligge i sistemi del vendor di sicurezza: è stata Già sfruttata in natura e quindi ben studiata, tanto che sono già liberamente disponibili vettori di attacco che vanno oltre il PoC. Ciò pone l’accento sull’urgenza si porre rimedio a tale vulnerabilità, la CVE-2022-40684, che consente di aggirare il sistema di autenticazione dell’interfaccia amministrativa Web nei dispositivi che eseguano FortiOS, FortiProxy e FortiSwitchManager. Tale procedura di infrazione consente all’attaccante di ottenere l’accesso come amministratore sui sistemi colpiti. In particolare le versioni colpite sono: per i prodotti FortiOS, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.2.0, 7.2.1; per i prodotti FortiProxy, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.2.0; per i prodotti FortiSwitchManager, 7.0.0 e 7.2.0. Consentendo l’accesso amministrativo, tale vulnerabilità porta all’attaccante la facoltà di creare nuovi utenti nel sistema compromesso, ruotare il traffico verso destinazioni a lui gradite, catturare il traffico di rete e dunque ottenere dati sensibili, scaricare l’intera configurazione del sistema (per studiarla in seguito).

Una nuova vulnerabilità è emersa nel software sviluppato dalla fondazione; anche in questo caso la violazione è di tipo RCE ed è stata per questo battezzata in modo simile alla precedente (log4shell) con riferimento alla libreria ora responsabile del trasporto di tale problema: dunque text4shell in riferimento al pacchetto Apache Commons Text. 

La vulnerabilità è critica, con un punteggio CVSS 9.8, ed è stata classificata come CVE-2022-42889. Si riferisce a versioni dei pacchetti di Apache Commons Text dalla versione 1.5 alla versione 1.9. 

Il difetto consente ad un attore di minaccia di sfruttare il processo di espansione dinamica delle proprietà di cui Apache Commons Text è capace per innescare l’esecuzione di codice non previsto o il contatto con server remoti (al minimo) non attendibili (per non dire di peggio). 

Ancora una volta dunque (come fu per Log4J con Log4Shell) colpevoli della debolezza software riscontrata sono la capacità di espansione dinamica dei parametri. Con espressioni come “${prefix:name}”, dove prefix indica l’istanza capace di eseguire la sostituzione dinamica, anche pacchetto Apache Commons Text consente così di ottenere differenti manipolazioni dinamiche del testo.

“INABIAF”, un acronimo forse sconosciuto ai più. Forse è più conosciuta la sua versione estesa: “it's not a bug, it's a feature” (“non è un bug, è una funzionalità”). Quante volte ci è capitato sentire gli sviluppatori affermare questo a fronte a nostre lamentele su un problema del loro software? 

Abbiamo sempre ritenuto questa affermazione dominio di programmatori distratti e superficiali (per non dire altro), specie quando il difetto riguardava problemi di sicurezza. 

Ed invece ci troviamo a commentare l’utilizzo di questa espressione da parte di un grande vendor: Microsoft. 

Un gruppo di ricercatori di sicurezza avrebbe individuato un problema di sicurezza in Office Online Server e lo ha prontamente segnalato a Microsoft: ma di conseguenza si sono sentiti rispondere con la suddetta locuzione. 

Office Online Server è un prodotto server Microsoft per supportare l’utilizzo via browser di note applicazioni di Redmond quali Word, PowerPoint, Excel e OneNote attraverso il protocollo WOPI (Web app Open Platform Interface). Questo supporto consente ad utenti SharePoint Server, Exchange Server o semplici cartelle condivise e siti Web di poter comodamente aprire documenti Office direttamente da browser durante la navigazione, senza dover necessitare di una propria istanza di tali software e naturalmente della relativa licenza. 

Sono arrivati gli aggiornamenti dell’ultimo quadrimestre 2022 per i prodotti Oracle, il CPU (Critical Path Update) ottobre 2022. Anche questa volta gli interventi sono molti, ma non tutti i prodotti godranno di interventi sulla sicurezza. Da questo aggiornamento, infatti, vengono esclusi interventi sulla sicurezza per alcuni prodotti, benché vengano introdotti i correttivi per quelle componenti terze parti che ne facciano parte (componenti utilizzate da Oracle nella costruzione di tali prodotti), con CVE che risalgono fino al 2019 (es. la CVE-2019-10086). Le famiglie di prodotti affette da questa “esclusione” sono: Oracle Airlines Data Model, Oracle Big Data Graph, Oracle NoSQL Database, Oracle SQL Developer, Oracle TimesTen In-Memory Database. Non sembra essere un dramma: è auspicabile che la correzione delle componenti terze parti sia a tutela dell’intero prodotto. 

Il grosso degli interventi Oracle invece è stato distribuito su altre 27 famiglie di prodotti per le quali sono stati realizzati 370 aggiornamenti di sicurezza per l’eliminazione di 179 CVE. 56 delle correzioni sono classificate critiche (correggono 32 CVE critici), 144 di gravità elevata (correggono 57 CVE di gravità elevata) e 163 di medio impatto (correggono 83 CVE di gravità media). Rimangono 7 patch per altrettanti CVE di gravità bassa per il totale complessivo che dicevamo. 

La National Security Agency (NSA) degli Stati Uniti d’America ha recentemente (inizio mese) diramato un allarme di sicurezza relativo allo sfruttamento attivo di vulnerabilità da parte di attori di minaccia supportati dal governo cinese e da questo indirizzati a perseguire interessi nazionali. 

In particolare l’allarme indica come vittime di questo nuovo interesse cinese sia l’insieme di industrie e organizzazioni varie negli Statu Uniti d’America, con l’intenzione comune di sottrarre proprietà intellettuali e ottenere accessi a reti sensibili. 

L’allarme è corroborato da un rapporto che tiene conto delle valutazioni sulle debolezze sfruttate dagli agenti di minaccia così come eseguite dalla NSA stessa, dal Cybesercurity and Infrastructure Security Agency (CISA) e dal Federal Bureau of Investigation (FBI). 

Nel rapporto vengono evidenziate le principali vulnerabilità sfruttate fin dal 2020 da attori di minaccia supportati dalla Repubblica Popolare Cinese, sottolineando come lo sfruttamento continua indisturbato su vulnerabilità ormai note. 

Microsoft ha rilasciato il Patch Tueday di ottobre e al solito ha risolto molti problemi, ma non tutti. 

Tra le 84 correzioni a vulnerabilità è rumorosa l’assenza di correzioni alle vulnerabilità di cui abbiamo parlato nel precedente articolo, ossia lo zero-day denominato ProxyNotShell, per via della sua similitudine alla vulnerabilità ProxyShell del 2021. 

Niente, dunque, a correzione dei CVE-2022-41040 e CVE-2022-41082. 

L’attenzione e l’attesa era evidentemente su quanto precedentemente segnalato e visto in natura; pertanto, un po’ di delusione ci può stare, ma è evidente che lo sforzo di Microsoft non è stato mal posto, in quanto si è data da fare su differenti vulnerabilità classificate critiche, capaci di eseguire elevazione privilegi (EoP), esecuzione di codice da remoto (RCE), ma anche vulnerabilità più moderate capaci di falsificazioni (Spoofing), come la CVE-2022-41035. Soprattutto è da segnalare come Microsoft in questo caso sia riuscita a correggere altre due vulnerabilità zero-day, delle quali una è stata già vista sfruttata in natura. Si tratta delle vulnerabilità CVE-2022-41033 e CVE-2022-41043. 

Da Microsoft stessa, oltre che dalle segnalazioni di Zero Day Initiative (ZDI) di Trend Micro, arriva la conferma dell’avvistamento in natura di una variante di ProxyShell (rilevata nel 2021), una pericolosa minaccia per Microsoft Exchange Server. 

Già nella precedente variante si trattò di scoprire una vulnerabilità zero-day: anche in questo caso l’identificazione in natura ha riguardato una minaccia di cui si ignorava l’esistenza fino all’evidenza del suo agire dannoso. 

Ancora una volta la minaccia è costituita prevalentemente dall’esecuzione di codice da remoto; come per ProxyShell, anche in questo caso ciò risulta possibile qualora sia disponibile all’attaccante una PowerShell: questo è reso possibile, in sistemi in cui operano istanze di Microsoft Exchange Server 2013, 2016 e 2019, a causa di una catena di vulnerabilità identificate con CVE-2022-41040 e CVE-2022-41082. 

La prima (CVE-2022-41040), valutata con un punteggio CVSS 6.3, è una vulnerabilità di tipo Server-side Request Forgery (SSRF) presente nei server Exchange capace, ad un utente remoto autenticato, di rendere possibile la vulnerabilità successiva.