Dopo pochi giorni dal rilascio del bollettino di sicurezza di Citrix, online sono disponibili alcuni esempi per sfruttare la brutta vulnerabilità di Remote Code Execution resa nota il 18 luglio!Come accaduto a gennaio 2020, la pubblicazione di codice per sfruttare la vulnerabilità del NetScaler mette a rischio tutti gli apparati esposti su internet e non ancora aggiornati. L’aggravante è che ci sono ancora moltissimi apparati in versione 12.1, ormai fuori supporto, per la quale non è stato rilasciato pubblicamente un firmware aggiornato. Se l’aggiornamento del firmware mantenendo la medesima release è solitamente un procedura consolidata, il passaggio di major release implica per molte realtà enterprise una serie di verifiche che richiedono maggior tempo.
Per tutti i clienti con manutenzione attiva che stanno ancora utilizzando la versione 12.1 e che non sono in grado di aggiornare alla versione 13.0 o 13.1 molto rapidamente, raccomando di contattare il supporto Citrix per chiedere una private fix.
L’unica vera soluzione per proteggersi, dunque, è quella di aggiornare il firmware!
Questa vulnerabilità è stata individuata a seguito di un attacco realmente effettuato con parziale successo. Gli attaccanti sono riusciti a installare una backdoor, scaricare i file di configurazione e le chiavi di cifratura dal NetScaler e con queste informazioni sono riusciti ad ottenere le credenziali per collegarsi via LDAP ad un Domain Controller, riuscendo quindi ad esfiltrare una serie di dati. Fortunatamente gli apparati erano posizionati in una DMZ con aperture puntuali, e pertanto gli attaccanti non sono riusciti a spostarsi su altri sistemi e fare ulteriori danni.
Che cosa possiamo imparare da questo attacco?
- Posizionare il NS in una DMZ: sembra una buona prassi, ma non sempre viene applicata. Sia la network dove sono posizionati i VIP, sia la network dell’NSIP (se abbiamo il management out-of-band) devono essere il più possibile isolate e controllate. In caso di compromissione dell’apparato, gli attaccanti potranno muoversi solo verso indirizzi censiti e ben definiti, limitando il rischio di lateral movement.
- Bloccare la navigazione dal NetScaler: anche se talvolta risulta comodo, il NetScaler deve solo ricevere connessioni inboud da internet. Pur non impedendo potendo proteggere da una vulnerabilità come questa, rende sicuramente più macchinoso il lavoro di un attaccante.
- Autenticare tramite IDP esterni: è prassi estremamente comune utilizzare LDAP per autenticare gli utenti, almeno per l’amministrazione interna degli apparati. Per gli accessi ai Gateway e AAA è possibile utilizzare Identity Provider esterni (uno per tutti, SAML), anche se questo comporta l’aggiunta di componenti aggiuntive come il FAS per gli ambienti Virtual Apps and Desktops. Per gli accessi amministrativi, è anche possibile sfruttare RADIUS o TACACS che ci possono permettere di proteggere meglio i nostri Domain Controller.
Il NetScaler è un grandissimo prodotto e non è più vulnerabile di molte altre soluzioni (anche F5 ha riportato una vulnerabilità la scorsa settimana), ma, data la natura dell’uso per cui viene installato, risulta critico. E’ fondamentale avere delle procedure affidabili e snelle per gestire gli aggiornamenti per poter intervenire molto rapidamente: questi apparati vanno aggiornati ciclicamente e mantenuti con costanza.
Per chi volesse approfondire ulteriormente, vi lascio il link all’analisi dell’attacco pubblicato dal National Institute of Standards and Technology (NIST) :
Nel documento troverete anche una serie di Indici di Compromissione per cercare di capire se i vostri apparati sono stati attaccati e/o compromessi.
Come suggerito da Francesco Marciello (che ringrazio) ne riporto solo alcuni….
Controllare error logs http alla ricerca di anomalie che potrebbero indicare un tentativo di exploit:
- zgrep ‘\.sh’ /var/log/httperror.log*
- zgrep ‘\.php’ /var/log/httperror.log*
Controllare i log della shell alla ricerca di comandi inusuali post-ex , come per esempio:
- grep ‘/flash/nsconfig/keys’ /var/log/sh.log*
Cercare binari con il setuid impostato (usare la data dell’ultimo aggiornamento firmware):
- find /var -perm -4000 -user root -not -path “/var/nslog/*” -newermt [YYYYMMDD] -exec ls -l {} \;
Controllate i log interni del NetScaler ADC internal (sh.log*, bash.log*) alla ricerca di tracce di potenziali atività malevole (di seguito alcune parole chiave di esempio):
- database.php
- ns_gui/vpn
- /flash/nsconfig/keys/updated
- LDAPTLS_REQCERT
- ldapsearch
- openssl + salt
Controllare l’internal access logs (httpaccess-vpn.log*) per 200 successful access da risorsse web sconosciute.
Augurandovi di non trovare nulla, mi raccomando sempre di affidarvi al vostro partner di fiducia e a persone qualificate, vista la delicatezza di questo tipo di attività.