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 pipe con nome (TSVCPIPE) che l’infrastruttura RDP utilizza per la comunicazione tra il server RDP esposto e l’istanza di processo che servirà i client remoti. In realtà l’attaccante ne creerà una copia, per cui l’istanza originale opererà per la sua connessione RDP, mentre la seconda opererà per le connessioni subentranti (utente vittima). Questo consentirà (con un certo artificio tecnico) una postura man-in-the middle quando un nuovo utente connetterà al sistema e verrà servito dalla pipe TSVCPIPE nella disponibilità dell’attaccante.
Come è possibile però che si crei un oggetto (in particolare pipe) con il medesimo nome di un oggetto di sistema, pur essendo l’utente attaccante non privilegiato? Qualsiasi processo può creare una pipe con nome, anche omonima di una esistente, se il descrittore di sicurezza di tale pipe lo consente: e questo è quanto è (erroneamente) per la pipe TSVCPIPE.
La postura man in the middle è la sola cosa che serve, in quanto attraverso questa pipe (che è una comunicazione inter-processo interna al sistema) i dati passano in chiaro e senza controlli di integrità, benché su “canali” differenti e con “protocolli” differenti. Interagendo con questi protocolli attraverso un suo software, l’attaccante può realizzare il controllo delle risorse sul client della vittima.
Come informa anche Microsoft, ovviamente l’utente malintenzionato dovrebbe convincere la vittima a connettersi a un server RDP predisposto allo sfruttamento della vulnerabilità, ossia dove abbia provveduto a compiere i passi preliminari per lo sfruttamento. Al momento della connessione, il server compromesso, in virtù delle naturali capacità del protocollo RDP, consentirà all’attaccante di leggere o manomettere il contenuto degli appunti e il contenuto del filesystem della vittima, nonché prendere il controllo di altri dispositivi e sistemi di autenticazione (come le smart card di cui la PoC utilizzata da CyberArk).
Come difendersi? Naturalmente applicare la patch, ma anche ridurre l’utilizzo indiscriminato di RDP oppure condurlo all’interno di un’architettura ZeroTrust.
