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

Da marzo di quest’anno gli analisti hanno evidenziato differenti bug su Teams, il popolare strumento di collaborazione di Microsoft. Lo strumento della società di Redmond è divenuto in tempi di pandemia molto popolare e per questo molto attraente per gli agenti di minaccia. Non è dunque un caso che diverse campagne (l’ultima molto recente con il coinvolgimento di diverse decine di migliaia di utenti) abbiano mirato a tecnologie collegate come Office 365 attraverso un phishing che si presenta con un oggetto molto eloquente: "C'è una nuova attività in Teams". Un messaggio naturalmente che vuole fare intendere di essere stato generato da notifica automatica proprio di Microsoft Teams. Cosa c’è sotto? 

Probabilmente proprio quei bug che sono stati individuati e ancora (alcuni) non risolti da Microsoft. Facciamo ordine; i bug in questione sono: 

- un bug che consente la falsificazione degli URL nella funzione di “anteprima dei collegamenti” capace di divenire strumento per attacchi di phishing o per nascondere collegamenti dannosi nei contenuti inviati agli utenti. Essenzialmente questo può essere fatto impostando la destinazione del collegamento di anteprima "su qualsiasi posizione indipendente dal collegamento principale, dall'immagine di anteprima e dalla descrizione, dal

L’emergere di un PoC che dimostra lo sfruttamento di alcuni bugs in Windows Active Directory ha creato una certa urgenza nell’applicare correttivi a questi bugs. Si tratta di correttivi già predisposti da Microsoft lo scorso mese. L’implementazione funzionante del PoC è stata resa disponibile su GitHub a poche settimane dal rilascio della patch: questo atto ha innescato il criterio di urgenza. 

È così che Microsoft è stata costretta a lanciare (lo scorso lunedì) una allerta ai sui clienti, perché predispongano urgentemente la correzione alle vulnerabilità collegate al PoC. È risaputo(anche da Microsoft) il cronico ritardo che molti utenti aziendali hanno nell’aggiornare il loro asset, esponendosi così a rischi derivanti da minacce fin troppo note, ma anche facilmente evitabili.  

Le vulnerabilità oggetto di tutto questo interesse sono state registrate come CVE-2021-42287 e CVE-2021-42278 (con gravità 7.5), e come detto già corrette da Microsoft con l’aggiornamento “November 2021 Patch Tuesday”. Le vulnerabilità consentono all’attaccante di

Avevamo già parlato di uno scivolone simile operato da Microsoft, e in qualche misura avevamo predetto la inevitabilità di eventi di tal genere. 

Con la versione 2.15 di log4j appena rilasciata (che ci aveva tranquillizzato), ecco emergere la conoscenza di differenti mutazioni dell’attacco, ed in particolare un vettore di attacco che potrebbe sfruttare Log4Shell rompendo anche il limite dei soli servizi esposti in rete come obiettivi possibili. In questo caso, tramite un server vulnerabile (strategia watering hole), un attaccante potrebbe fare innescare tramite un URL l’attivazione (silente all’utente) di una Javascript WebSocket al caricamento della pagina e porre questa in comunicazione con una destinazione esterna tramite una connessione JNDI: questo perché le WebSocket non rispettano la Same-Origin-Policy. A differenza di altre varianti osservate, questo caso è solo una PoC, quindi una idea e non una certezza, ma un brivido corre lungo la schiena. 

Ma ancora una volta non si fa

Molte realtà hanno la cattiva abitudine di amministrare le proprie infrastrutture direttamente da Internet, esponendo interfacce amministrative direttamente nel cyberspazio e così facendo esponendosi alle potenziali ed inevitabili conseguenze. 

È quello che è stato possibile per un lungo periodo e su differenti versioni (dalla 2010 alla 2019 upd 4) di Microsoft Exchange Server per la vulnerabilità CVE-2020-0688 (di cui Microsoft ha rilasciato correzione nel febbraio del 2020) quando si rendesse esposto Exchange Control Panel (ECP, uno degli strumenti amministrativi Web che si sono susseguiti nella storia evolutiva di Exchange). Questo poteva rendere possibile, mediante la precedente vulnerabilità (Microsoft Exchange Memory Corruption Vulnerability), di ottenere una remota code execution (RCE). 

La medesima strategia è stata ora utilizzata in un nuovo attacco sviluppato a partire dall’esecuzione remota di uno script PowerShell capace di impiantare un modulo per Internet Information Services (IIS, la suite di software per server Web/hosting Web di Microsoft) con

Non si rammentava una vulnerabilità così grave dalla scoperta di Heartbleed (che permetteva di ottenere informazioni da protocollo sicuro come SSL/TLS) e Shellshock (che consentiva di eseguire codice su una macchina remota attraverso la Bash shell). 

Non solo per gravità, ma anche in termini di dimensione. 

La nuova vulnerabilità raggiunge infatti un Base CVSS Score tondo tondo di 10.0; si tratta della vulnerabilità censita come CVE-2021-44228 e che colpisce la libreria Log4j, software della Apache Foundation per la gestione dei messaggi di log nelle applicazioni Java. 

Ma la dimensione del fenomeno è straordinaria vista anche la condizione di utilizzo di questa libreria: si tratta infatti della libreria più utilizzata in assoluto dalle applicazioni web per la gestione delle registrazioni eventi (log) in questo contesto, pertanto il numero di implementazioni concrete è certamente esplosivo. 

Inizialmente individuata sui server del gioco Minecraft, è stata poi individuata su server di altri giochi come Steam, ma anche più minacciosamente sui server di Apple iCloud, e chissà dove altro ancora. 

Mentre è chiaro lo sfruttamento possibile sui