Ricorderete Log4Shell, la vulnerabilità più grave del decennio che ha spaventato molti vendor? 

Censita con CVE-2021-44228 è stata oggetto di rapide correzioni; a volte correzioni “troppo rapide”; non è un caso che il rischio si sia ripresentato in varie forme attraverso le vulnerabilità CVE-2021-45046 e CVE-2021-45105 che affrontavano differentemente le debolezze del codice Log4j. La natura del problema evidentemente era complessa e capillare nella struttura del software da creare non pochi problemi nell’individuazione delle cause e soprattutto nella costruzione di una soluzione definitiva. 

La costruzione di un correttivo “definitivo” è stato un problema per molti vendor, soprattutto per uno come Amazon che nel suo ecosistema AWS (Amazon Web Services) ha un uso

È noto come le vulnerabilità affliggano applicazioni, servizi e sistemi operativi. È noto come questi siano sottoposti a revisione continua e correzioni (patch) per diminuire o risolvere l’impatto di queste vulnerabilità. È altresì noto come, in casi di estrema necessità, solo degli attenti ed efficaci sistemi di sicurezza automatici possano divenire baluardo, mitigazione e soluzione per vulnerabilità all’interno del perimetro. 

Ma cosa accade quando la vulnerabilità affligge persino gli strumenti di difesa? Ebbene, questo non è certamente un caso irrealistico (i sistemi di difesa sono pur sempre software), e nemmeno, ahimè, un caso d’accademia: è infatti cronaca recente l’individuazione di una grave vulnerabilità (CVSS 7.5) che affligge Snort, il famoso software open source per l’implementazione di un sistema IDS/IPS salito sugli altari del

Dopo Microsoft, anche un altro dei Big del mondo IT come Oracle corre pesantemente ai ripari per i guai al suo esteso parco software; faremmo prima ad elencare i prodotti non coinvolti che quelli coinvolti in questo mega aggiornamento. 

Si tratta infatti di una quantità considerevole di correzioni, per relativi problemi di funzionalità e di sicurezza, questi ultimi censiti attraverso CVE che riguardano prevalentemente il 2021 e 2022, ma anche qualcosa ancora del 2019 e 2020. 

Il secondo aggiornamento trimestrale rilasciato da Oracle, il Critical Patch Update (CPU) aprile 2022, porta con sé 520 patch, corregge difetti per 221 CVE, di cui “solo” 27 di natura critica (per la cui risoluzione sono state coinvolte ben 77 patch), il 14,8% dell’intera patch. 

L’elenco completo e i dettagli possono essere letti nell’avviso pubblicato da

Con il bollettino di sicurezza VMSA-2022-0011 del 2022-04-06, VMWare ha focalizzato l’attenzione su alcune gravi vulnerabilità che affliggono alcuni suoi prodotti. In particolare si tratta di VMware Workspace ONE Access (Access), VMware Identity Manager (vIDM), VMware vRealize Automation (vRA), VMware Cloud Foundation, vRealize Suite Lifecycle Manager. 

Ad una settimana di distanza da quel bollettino sono state pubblicate le attese correzioni (KB88099), ponendo sostanzialmente un freno a un fenomeno che stava diventando oggettivamente rischioso, viste le prime conferme sull’avvistamento “in natura” di exploit per una delle vulnerabilità descritte nel bollettino, la CVE-2022-22954, nonché un ampio fiorire su GitHub (https://github.com/search?q=CVE-2022-22954) di PoC per lo sfruttamento della stessa. 

L’insieme di questa vulnerabilità e le successive CVE-2022-22955 e CVE-2022-22956 rappresentano

Benché nel contesto di un aggiornamento pianificato, il “April 2022 Security Updates”, Microsoft ha rilasciato 128 correzioni per vulnerabilità di sicurezza. 

Di queste 10 sono ritenute critiche, 2 sono 0-day, tra l’altro capaci di elevazione di privilegio e già rilevati attivi e 3 consentono exploit (RCE) con capacità di propagazione (Worm) senza interazione utente.  

Sono anni che Microsoft non usciva con un volume così massiccio di correzioni, per numero di bug risolti e soprattutto per superficie d’intervento: i bug infatti sono stati trovati (e corretti) in una gran parte del portafoglio software di Microsoft. 

In particolare gli 0-day sono stati classificati con CVE-2022-24521 (CVSS 7.8) e CVE-2022-26904 (CVSS 7), mentre le vulnerabilità di esecuzione codice remoto (RCE) sono state

Ricercatori anonimi hanno aiutato anche questa volta Apple nel riconoscere e dunque consentire la correzione di una nuova insidiosa vulnerabilità 0-day che potrebbe consentire l’utilizzo di privilegi kernel nell’utilizzo di codice arbitrario da parte di applicazioni malevole. 

Non è chiaro se la minaccia sia stata già sfruttata, ma sembrerebbe molto probabile (visto che Apple dice di avere rapporti su probabili attività di sfruttamento), pertanto l’applicazione degli aggiornamenti forniti da Cupertino è certamente urgente. 

Come ormai siamo abituati a vedere, i difetti che causano le vulnerabilità nell’ecosistema Apple colpiscono esattamente nel medesimo modo macOS e iOS per la ormai forte convergenza dei due prodotti. 

Naturalmente classificazione e aggiornamenti rispetto alle vulnerabilità seguono percorsi differenti, ma la fonte e la natura del problema risulta essere la medesima. 

La vulnerabilità che interessa i sistemi macOS (Monterey) è stata classificata come CVE-2022-22674 e viene corretta con la versione 12.3.1 appena rilasciata da

“Ransom” è un riscatto: subito pensiamo ad un reato estorsivo. Nessun brutto ceffo alla nostra porta, ma qualcosa di simile comunque può avvicinare, non tanto noi, quanto i nostri dati. Questa forma di estorsione infatti non è portata avanti minacciando la nostra incolumità, ma bensì quella delle nostre informazioni, ovvero delle informazioni che noi conserviamo nei nostri dispositivi IT. L’estorsione è realizzata mediante le forme tecnologiche del cyberspazio, ovvero attraverso un “emissario” in forma digitale, un software dalle intenzioni malevole, un “malware” che minaccia le nostre informazioni, la loro disponibilità. “Ransomware” è infatti un portmanteau dei termini “ransom” e “malware”. 

Le forme di minaccia alla disponibilità delle informazioni può variare, ma è invalso l’uso che le minacce ransomware optino per una inibizione dell’accesso alle “nostre” informazioni mediante meccanismi crittografici, ossia metodi che trasformano la nostra informazione in un insieme di dati per noi non più intellegibili ma teoricamente ripristinabili allo stato originario, da cui

Non finiscono, anzi aumentano i guai per gli utenti del sistema di backup della taiwanese QNAP. 

Abbiamo appena finito di parlare del bug derivante dal problema al Kernel Linux (Dirty Pipe), problema ancora non risolto nel mondo QNAP, che abbiamo un ulteriore guaio a completare il fosco quadro già reso tale da un continuo martellamento da parte di gruppi di minaccia ransomware sui dispositivi QNAP esposti (improvvidamente) su Internet dai loro proprietari. 

Ci si mette ora anche (o meglio sarebbe dire “di nuovo”) la libreria OpenSSL. 

Un problema nella libreria è presente in tutti i dispositivi NAS (Network-Attached Storage) di QNAP, e consente di ottenere una negazione di servizio (DoS) per l’innesco di un ciclo infinito all’interno degli algoritmi sviluppati da questa libreria. 

Anche in

Non c’è pace per Google Chrome. 

Abbiamo appena finito di descrivere una vulnerabilità zero-day nei suoi confronti che già un’altra è stata rilevata e sanata. 

Ancora una volta la vulnerabilità è risultata attivamente sfruttata in precedenza alla scoperta, confermando quanto dicevamo sulla pericolosità di certe minacce. 

In questo caso si tratta di una vulnerabilità che colpisce qualcosa di maggiormente sfruttato in tutti i campi di utilizzo del noto browser, ossia la componente open source che è il cuore delle forme moderne del web, ossia il motore JavaScript V8. 

L’essere open source di questa componente fallace porta guai naturalmente anche a tutti gli altri browser della ormai ampia famiglia Chromium (come Edge di Microsoft e l’omonimo browser in Linux). 

La

Quando si parla di zero-day si fraintendono molte cose. Zero-day è il termine con cui viene denotato una nuova vulnerabilità, un nuovo attacco, una nuova minaccia non precedentemente nota, ma questo non significa “non precedentemente attiva”. 

Il termine zero-day nasce da lontano, nel mondo del warez, della cosiddetta “pirateria informatica dei software”, in cui i “giorni” (day) erano il metro di valutazione della “freschezza”, della “qualità” dell’oggetto piratato, in genere un software di qualche produttore ben in vista: zero-day significava “fresco di giornata” e pertanto molto appetibile. Oggi il termine ha il medesimo significato di “freschezza”, ma indica solo la conoscenza, non la disponibilità, perché questa è già nelle mani degli agenti di minaccia che ne abbiano determinato l’essenza, ovvero la possibilità di