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

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

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

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