Citrix ha prontamente comunicato a metà dicembre la presenza di una nuova grave vulnerabilità che affligge i NetScaler con gli step da applicare per mitigare il problema. Purtroppo molti amministratori hanno preso sottogamba la situazione… Vediamo come possiamo verificare se siamo stati attaccati con successo o meno.
La vulnerabilità sfrutta una tecnica chiamata Directory Traversal, attraverso alla quale è possibile avere accesso ad alcune porzioni di file system. Con questa tecnica è possibile chiamare uno script di sistema tramite il quale scrivere dei file sul NetScaler. Con una seconda chiamata si può successivamente eseguire dei comandi precedentemente caricati…. il tutto con sole due chiamate HTTP!
Nonostante la vulnerabilità sia piuttosto semplice da attivare, il NetScaler utilizza un kernel proprietario e un sistema di controllo basato su FreeBSD patchato direttamente da Citrix, quindi l’installazione di backdoor o applicazioni modificate non è così semplice. Più semplice invece scaricare i file di configurazione con gli hash delle password, modificare le configurazione per creare nuove utenze locali e abilitare una VPN, sostituire script e file di sistema, ecc, ecc, ecc.
Per fortuna, lo script che viene utilizzato per scrivere sul file system genera file in formato XML e la ricerca di questi file è un ottimo indice di verifica per controllare se il nostro apparato è stato violato.
Per esempio, con i seguenti comandi possiamo verificare la presenza di file xml strani:
shell ls /netscaler/portal/templates/*.xml shell ls /var/tmp/netscaler/portal/templates shell ls /var/vpn/bookmark/*.xml
Successivamente possiamo controllare i log di apache per verificare se sono arrivate chiamate forgiate (ammesso che non siano stati cancellati; è sempre consigliabile avere un log server esterno!):
shell cat /var/log/httpaccess.log | grep vpns | grep xml shell cat /var/log/httpaccess.log | grep "/\.\./" shell gzcat /var/log/httpaccess.log.*.gz | grep vpns | grep xml shell gzcat /var/log/httpaccess.log.*.gz | grep "/\.\./"
E’ anche consigliato controllare che non ci siano processi perl o python in esecuzione e che l’unico processo che usa intensamente la CPU sia NSPPE-xx (il packet engine) per essere sicuri che non siano stati installati altri software.
Se volete tenere sotto controllo le policy per mitigare gli attacchi, potete creare una log policy per inviare ad un syslog alcune informazioni, come l’IP da cui è stato fatto il tentativo di attacco e l’URL utilizzata.
Il consiglio è quello di rivolgervi al vostro partner Citrix di fiducia per fare un’analisi approfondita.
Trovate ulteriori informazioni ed un elenco dettagliato dei payload utilizzati nei seguenti collegamenti:
Grande Francesco! Come sempre preciso e puntuale.
Grazie Silvio, come sai c’è tanta passione dietro. Nello specifico l’impressione è che molte aziende, sempre in lotta con procedure, budget limitati e tante volte, ahimé, percezione errata o addirittura poca conoscenza in ambito di sicurezza, hanno preso sotto gamba il rischio di questa vulnerabilità e non hanno applicato le misure preventive consigliate da Citrix.
Si stimano più di 80000 appliance vulnerabili e ci sono bot che stanno indicizzando tutte le macchine vulnerabili (basta una singola GET per verificare la vulnerabilità). Negli ultimi 10 gg l’appliance che ho in ufficio (che ha pochi mesi di vita, non ha referral e non ha un certificato univoco, quindi difficile da trovare) ha una media di 4 tentativi al giorno: la scorsa settimana la media era di 2 tentativi al giorno!
Per fortuna a partire dalla prossima settimana saranno disponibili i primi firmware con le patch.