Non è la prima volta che accade, ma ci risiamo! 

Era il lontano 2016 quando il codice sorgente del malware alla base della botnet Mirai fu sottratto agli autori e finì pubblicato sulla piattaforma github (https://github.com/jgamblin/Mirai-Source-Code). Questo è evidente portò ad una più rapida evoluzione del fenomeno: la possibilità di avere questa piattaforma software consentitì a differenti attori di produrre una propria variante del malware Mirai (Moobot, Satori, Masuta, ecc), ognuna con proprie funzionalità e caratteristiche che le rese uniche e sempre più aggressive. Il risultato: l’esplosione di milioni di infezioni. 

Il terreno di cultura per queste infezioni è stato ed è il mondo IoT, ormai proverbialmente noto per essere refrattario ai più ordinari e semplici principi di sicurezza. 

Medesimo destino sembra ora aver portato un'altra vecchio gloria del mondo del malware orientato all’IoT al medesimo approdo. 

Correva il 2021 quando i laboratori Alien Labs della AT&T scoprivano il primo malware realizzato nel linguaggio di programmazione golang (Mirai era in C), il linguaggio di programmazione open-source di

Con gli ultimi aggiornamenti per macOS Monterey 12.2 (https://support.apple.com/en-us/HT213054), iOS 15.3 e iPadOS 15.3 (https://support.apple.com/en-us/HT213053), ha rimosso il rischio di sfruttamento di tutta una serie di vulnerabilità censite per i suoi prodotti (da CVE-2022-22578 a CVE-2022-22579, da CVE-2022-22583 a CVE-2022-22587 e da CVE-2022-22589 a CVE-2022-22594). 

Particolare interesse destano la CVE-2022-22594 (in quanto ne avevamo già parlato e attendevamo la pubblicazione della patch) e la CVE-2022-22587. Entrambe sono state (o sono) vulnerabilità 0-day; entrambe hanno infatti mostrato un ritardo nella pubblicazione dei dettagli “durante” le azioni correttive implementate da Apple. Per la prima avevamo ancora evidenze nel sistema bugzilla del progetto di uno stato transitorio tra scoperta e soluzione, mentre le seconda è ancora associata (nel momento che scriviamo) ad un CVE indicato come “riservato” sul sito di MITRE (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-22587), quindi senza alcuna attribuzione. Entrambi i fenomeni sono caratteristici della riservatezza alla pubblicazione dovuta nel caso di uno 0-day rilevato da ricercatori indipendenti al vendor relativo. 

La CVE-2022-22594 trova finalmente correzione alla violazione della Same Origin Policy

ePO, ePolicy Orchestrator, è lo strumento enterprise di McAfee per il governo della sicurezza in una infrastruttura IT: è un punto focale per l’amministrazione della sicurezza per host ed endpoint, capace si integrare analisi e reazione alle minacce. Proprio nel comparto della protezione dell’endpoint, ePO dialoga con l’agente di McAfee Endpoint Security, ossia McAfee Agent. 

Quindi, se vogliamo, è questo lo strumento che agisce per la sicurezza: ma cosa accade se proprio questa componente ha un difetto tale da consentire un attacco proprio attraverso di essa? 

Di difetti, ossia vulnerabilità, McAfee Agent ne ha esattamente due, così come sono state censite sul database NIST NVD con identificativo CVE-2021-31854, CVE-2022-0166: il NIST non ha ancora eseguito una analisi sulle vulnerabilità, quindi stiamo alle dichiarazioni del vendor che classifica entrambe con uno score alto (7.7 per la CVE-2021-31854 e 7.8 per la CVE-2022-0166). 

Una prima vulnerabilità (CVE-2021-31854) nasce dalla possibilità di iniettare codice nel programma cleanup.exe che fa parte del processo di installazione/disinstallazione/aggiornamento dell’agent: un

Nel cuore del browser dei sistemi di Apple batte un sistema comune a più del 50% dei browser utilizzati sul pianeta: WebKit. Questo ovviamente non per esclusivo merito di Apple (che non detiene quella fascia di mercato), ma per il fatto che questo sistema è frutto della collaborazione di differenti società di sviluppo software. Ricordiamo tra queste Samsung (con il suo Dolphin ed in generale il suo sistema Tizen), Amazon (con il suo Kindle), KDE e fino al 2013 anche Google (con il suo Chrome), che però ha creato un suo sviluppo autonomo del medesimo progetto (ora denominato Blink). 

Naturalmente il progetto comune non contempla un destino comune, in quanto le differenti tecnologie su cui è destinato necessitano di sviluppo autonomo, aprendo lo spazio a che problematiche differenti affliggano le differenti implementazioni. 

È il caso appunto del problema di confidenzialità che è stato riscontrato in questo sistema su dispositivi Apple, che date le convergenze delle tecnologie nei differenti sistemi non ha più importanza indicare se macOS, iOS o iPadOS, ma bensì la generazione: si tratta di generazione 15 per melafonini e pad e 12 per sistemi desktop. 

Tutto nasce da una questione: i programmi utente, pure sul

Nel suo portafoglio di soluzioni alle imprese, Cisco presenta due prodotti per supportare i servizi di assistenza al cliente. Si tratta di Unified Contact Center Enterprise (UCCE) e Cisco Unified Contact Center Express (UCCX). 

UCCE è una applicazione di gestione di livello enterprise basata su tecnologie web utilizzabile da amministratori, utenti e supervisori di un “contact center”, insomma l’assistenza ai clienti. UCCX è la corrispondente per realtà più piccole. 

Naturalmente si tratta di strumenti complessi, che vanno dalla gestione degli operatori, alle chiamate (in ingresso e uscita), sondaggi e business intelligence. In particolare UCCE è adottato da attori effettivamente “molto grandi”. 

Con la vulnerabilità CVE-2022-20658 viene reso pubblico un problema per entrambi i prodotti, ed in particolare (nel solo caso si UCCE che è una suite) la applicazione Cisco Unified Contact Center Management Portal (CCMP), l’insieme delle componenti server per la gestione back-end, inclusa l'autenticazione e altre funzioni di sicurezza nonché la gestione delle risorse coinvolte (da personale ai contatti) e le azioni intraprese (come chiamate telefoniche). 

Il bug ha una valutazione critica di 9.6 e potrebbe consentire ad aggressori remoti e autenticati di elevare i propri privilegi ad amministratore, con la possibilità di creare altri account amministratore. Naturalmente a

Microsoft ha appena corretto un importante bug di sicurezza per il protocollo RDP (Remote Desktop Protocol): ha distribuito la correzione con la Patch Tuesday del 11 gennaio 2022, ma il problema è molto più vecchio, e sembra risalire fino a Window 8.1 e Windows Server 2012 R2. 

Microsoft non è stata la responsabile della scoperta, che è frutto di un team di ricerca indipendente da questa (CyberArk), avvenuta prima del 19/08/2021, data di prima segnalazione a Microsoft del problema. 

L’analisi non compare ancora nel database NVD del NIST, pur essendo la vulnerabilità già censita con CVE-2022-21893: l’analisi completa è invero ottenibile, seguendo le indicazioni di Microsoft nell’annuncio della patch all’indirizzo https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2022-21893, sul sito dei ricercatori, all’indirizzo https://www.cyberark.com/resources/threat-research-blog/attacking-rdp-from-inside. 

Abbiamo a che fare con una vulnerabilità importante, con base score 8.8, che consentirebbe (se non corretta) ad un utente malintenzionato all’interno del perimetro di accedere alle risorse di qualsiasi altro utente si connetta al sistema attraverso la comunicazione RDP. 

In buona sostanza, e semplificando, l’attaccante, con una prima connessione RDP, senza alcun particolare privilegio, prenderebbe il controllo di

Una recente ricerca dei ricercatori di ZecOps ha costruito un PoC che dimostra la possibilità per gli agenti di minaccia di costruire una formidabile tattica per la persistenza. 

È risaputo che il problema fondamentale di qualsiasi software è la sopravvivenza allo spegnimento (o riavvio) del dispositivo fisico su cui viene eseguito: questa sopravvivenza è detta appunto “persistenza”, in quanto consente al software di rimanere, ovvero di riprendere la sua esecuzione anche a dispetto della volontà dell’utente. 

È quello a cui aspirano gli agenti di minaccia quando progettano uno scenario di attacco basato di malware (il termine è a dire il vero utilizzato anche per altre forme di persistenza che riguardano la presenza della minaccia con forme di accesso). 

È quindi corretto poter pensare che la corretta profilassi contro i malware che non possano disporre di un ancoraggio di persistenza possa essere quella di riavviare il proprio dispositivo: ma tutto questo è stato spazzato via dalla ricerca di ZecOps, almeno per i possessori di iPhone. 

La ricerca ha dimostrato infatti che è possibile interagire a livello software con il meccanismo con cui il sistema operativo iOS esegue la sequenza di spegnimento (o riavvio), a tal punto da impedirla. Certo, questo allarmerebbe l’utente; ma il passo successivo degli aggressori sarebbe quello di

Il servizio dockerd di norma non dovrebbe essere accessibile per l’amministrazione direttamente via rete ed è fortemente sconsigliato che lo sia in quanto questo canale non è previsto né crittografato né autenticato. Eppure una rapida ricerca su Shodan rileva 618 istanze docker (tra l’altro in maggioranza rispondente alla medesima versione) in ascolto sulla porta standard per questo meccanismo di accesso. 

Siamo di fronte ad una evidente misconfiguration che consente l’accesso pubblico al demone di gestione dei container docker di tutte queste infrastrutture che abbiamo rilevato, e questo pone due possibili rischi di sicurezza: il primo e più drammatico è la possibilità di ottenere il privilegio amministrativo della macchina che ospita dockerd (mediante alcuni exploit noti che sfruttano capacità amministrative proprie di docker), mentre il secondo è la costruzione di un nuovo container predisposto alle finalità dell’attaccante, in maniera occulta ed efficace. 

Naturalmente la seconda ha un più ampio spettro di applicazioni, in quanto tale sfruttamento punta alla risorsa di calcolo e non all’appropriazione di un sistema. Ed è proprio quello che è osservabile nella campagna che gli analisti hanno chiamato Autom, dal

Già da differenti anni sono apparsi nel cyberspazio servizi per la registrazione di domini che indirizzano il mercato a nuove forme di utilizzo dei nomi di domini: la spinta maggiore è stata data certamente dal largo diffondersi del cybersquatting a cui si è reagito con il domain parking, favorendo appunto lo svilupparsi di questi servizi (Afternic, CashParking, Namecheap, ParkingCrew, ecc.). Il domain parking è una questione assai semplice: servizi accreditati ICAAN come registrar consentono l’acquisto e registrazione di domini che non verranno attivamente utilizzati: questo è perfetto e legittimo nel caso si intenda proteggere domini legittimi dalle forme di cybersquatting di cui potrebbero soffrire. Ma c’è un lato oscuro in tutto questo. In questo sistema di gestione dei domini di inserisce un meccanismo perverso per cui le finalità d’uso del dominio divengono secondarie, lasciando spazio a varie altre forme di abuso. Tutto nasce dalla forma “leggera” di registrazione del dominio, registrazione che può prevedere l’assenza di ogni sorta di configurazione per il dominio stesso: in questo vuoto lasciato dal proprietario del dominio si inserisce l’opportunità economica del servizio di registrazione di costruire una nuova forma di business sul dominio che ha appena “venduto”. Impostando il proprio DNS, il

La prospettiva non è delle migliori: il numero di indirizzi e-mail e password compromessi supera i 5 miliardi e si avvicina inesorabilmente al numero degli abitanti della terra (circa 8 miliardi); le probabilità parlano chiaro: almeno una delle nostre credenziali potrebbe essere stata compromessa. Ovviamente questo è possibile in quanto troppe tra quei 5 miliardi sono termini identici, sono password comuni utilizzate troppo spesso, da troppe persone. 

Il problema delle password è annoso e probabilmente divenuto talmente costante da non destare più meraviglia o, peggio, attenzione. 

L’ultima indagine della National Crime Agency (unità britannica per il cyber crimine) ha scovato in uno storage cloud aziendale uno zibaldone di materiale contenente anche password compromesse, benché non associabili a nessuna specifica campagna e dunque origine della compromissione. Per questo motivo NCA, per verificare la compromissione, si è rivolta al più grande database di password compromesse HIBP (Have I Been Pwned) per confrontare quanto trovato con tale riferimento. NCA ha trovato 586 milioni di credenziali che confrontate con i 613 milioni di HIBP hanno evidenziato ben 226 milioni mai viste prima. 

La questione ha un duplice aspetto: prima di tutto il