Update 1-22-2020

Ora esiste uno strumento di FireEye che aiuterà a scansionare questi elementi qui sotto. Il punto chiave è che devi avere abbastanza log per risalire all'1-9-2020 per avere la possibilità di vedere cosa è stato fatto oltre l'esecuzione dell'exploit. Se trova file payload .XML, devi utilizzare le informazioni seguenti per decidere quali azioni intraprendere. https://www.fireeye.com/blog/products-and-services/2020/01/fireeye-and-citrix-tool-scans-for-iocs-related-to-vulnerability.html

Download dello strumento

https://github.com/citrix/ioc-scanner-CVE-2019-19781 https://github.com/fireeye/ioc-scanner-CVE-2019-19781/

Rilevamento dello sfruttamento

Al momento non esiste un modo semplice per dimostrare cosa sia stato fatto. Con 4 exploit pubblici, ciascuno lascia un artefatto/firma diverso, utile per il rilevamento ma non al 100%. Il punto da ricordare è che questi sono gli exploit pubblici che erano privati fino al 10 e ciò non significa che non ce ne siano altri in circolazione che le persone non condividono per i propri guadagni. Gli exploit sono modificabili nella maggior parte dei casi: qualcuno può cambiare il nome del file che verrà rilasciato, il nome dell'account utente, il nome del processo, il percorso della query e molte altre opzioni, il che significa che le possibilità aumentano esponenzialmente che qualcuno abbia sfruttato il sistema. Ci sono anche attaccanti avanzati e attaccanti basilari; uno pulirà le proprie tracce e troverà modi molto astuti per scomparire nel sistema per sfuggire al rilevamento.

Se utilizzi Nessus, puoi usare questo file .YAR qui sotto per eseguire una scansione privilegiata alla ricerca dei metodi di rilevamento comuni. https://github.com/Neo23x0/signature-base/blob/master/yara/exploit_shitrix.yar

Audit dell'exploit

Ottimi link su questo processo di audit. https://nerdscaler.com/2020/01/13/citrix-adc-cve-2019-19781-exploited-what-now/amp/ http://deyda.net/index.php/en/2020/01/15/checklist-for-citrix-adc-cve-2019-19781/

Disclaimer: come già detto, questo non rileverà tutti gli exploit, ma potrebbe aiutare a rilevare alcune anomalie se l'attaccante non ha modificato gli exploit pubblici e/o non ha pulito le proprie tracce. La maggior parte degli attaccanti utilizzerà l'exploit predefinito, e questi sono alcuni degli artefatti documentati che potrebbero essere lasciati. Questo elenco di comandi è stato preso da molte fonti e sarà molto dinamico man mano che emergeranno altre varianti, soluzioni alternative e nuovi sviluppi. Possiamo contarci che questo cambierà costantemente con l'aumento delle infezioni e il completamento di ulteriori analisi forensi su un campione più ampio.

Guarda prima a queste cose che non hai fatto tu. Se normalmente non fai molto sul tuo ADC, queste dovrebbero essere molto silenziose; inoltre, potrebbero esserci voci di settimane, mesi o anni fa, l'ultima volta che hai operato. Ci sono query più precise appena sotto. Comprendi anche che questo è un gioco del gatto e del topo anche in questo blog. Mentre divulghiamo ciò che abbiamo visto e come individuare gli attaccanti, loro usano queste informazioni contro di noi cambiando le loro tattiche per evitare il rilevamento.

Elenco rapido di controllo dello sfruttamento v1

• 1. Controlla la tua licenza. Ho sentito di alcuni che hanno riavviato i loro dispositivi e avevano effettivamente una licenza scaduta.
• 2. Ottieni un file di supporto, ovvero Backup System -> Diagnostics -> Get Support File e salva quel file.
• 3. Tutti i comandi seguenti sono in NSCLI e se accedi tramite SSH alla macchina e usi Shell, puoi omettere il prefisso Shell.
• 4. Controlla la data sulla macchina per aiutare a correlare i risultati dei log
  • a. shell date
• 5. Controlla la data di modifica della configurazione
  • a. Shell ls -l /netscaler/ | grep netscaler
  • b. Shell ls -l /nsconfig | grep netscaler
    • i. Qual è la data del tuo netscaler.conf?
    • ii. Ti sembra giusta? Cerca collegamenti di file verso altre posizioni.
• 6. Controlla il file delle password degli account locali
  • a. Shell ls -lh /etc/passwd
    • i. Verifica quando è stato modificato il file. Se dopo l'exploit e non eri tu, allora devi cambiare quella password il prima possibile.
    • ii. Raccomando di cambiare la password di nsroot o di qualsiasi account locale se vengono rilevati exploit. In molti casi
  • b. Shell cat /etc/passwd
    • i. Cerca di vedere quali account sono presenti.
    • ii. Root, nsroot, daemon, operator, bin, nobody, sshd, nsmonitor sono predefiniti.
• 7. Controlla i tuoi log
  • a. shell ls -lh /var/logfile
    • i. I file ci sono? Sono molto piccoli?
    • ii. https://support.citrix.com/article/CTX121898
• 8. Controllo dei file dannosi
  • a. Se uno di questi file ha una lunghezza diversa da 8-9 caratteri e un nome file casuale, questo è un segno di un attaccante più avanzato che ha modificato l'exploit standard. Se vedi questo, devi adattare la tua correzione di conseguenza. Pwnpzi1337.xml è il nome del file per l'exploit di Project India
  • b. shell ls /netscaler/portal/templates/*.xml
    • i. Non dovrebbero esserci file XML qui.
    • ii. Se infetto, controlla le date dei file qui.
    • iii.shell ls -lh /netscaler/portal/templates/
  • c. shell ls /var/tmp/netscaler/portal/templates

Se sfruttato

Il tuo chilometraggio varierà sempre su cosa devi fare in base al tuo panorama di minacce. Ecco alcuni dei pensieri che ho comunicato ai clienti che hanno trovato prove di un exploit eseguito.

Quali organismi di conformità coprono la tua azienda? Finanza/Banche, SOX, PCI, HIPAA, leggi statali/locali e governative.

Se rientri in uno di questi quadri normativi, allora devi seguire quelle procedure per quegli organismi di conformità. Ci sono anche considerazioni etiche basate sulle certificazioni e sui gruppi professionali di cui fai parte che hanno disposizioni per la risposta agli incidenti e la divulgazione.

Ecco i link a queste due guide ben note per i processi di risposta agli incidenti: https://security.berkeley.edu/incident-response-planning-guideline https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final

Una cosa che sappiamo finora è che intorno al 10-1-20 è stato rilasciato il primo exploit pubblico e ci sono alcune segnalazioni di infezioni il 9, proprio quando è uscito. Nella maggior parte dei casi, il rischio è molto più basso se hai patchato il sistema prima del 2020 rispetto a più avanti questo mese.

Rischio stimato della minaccia CVE-2019-19781

17 dicembre - 31 dicembre: Rischio più basso di sfruttamento 1-8 gennaio: Rischio più basso di sfruttamento 9-13 gennaio: Rischio più alto di sfruttamento 14 gennaio - Presente: Rischio più alto di sfruttamento

Questo dovrebbe far parte del tuo processo per i prossimi passi.

Ho trovato tracce di uno sfruttamento, e ora? Dipende ancora; una cosa che la maggior parte delle distribuzioni Citrix ADC non configura è una buona registrazione SNMP e SYSLOG, e potrebbero non avere un buon modo per cercare, filtrare o allertare se vengono trovati artefatti. Se hai una registrazione assoluta e sei sicuro che non abbiano fatto nulla, potresti essere in grado di andare avanti. Poi se hai trovato qualcosa e sei stato in grado di rimuovere con sicurezza il loro accesso remoto, potresti andare avanti.

Ma la maggior parte troverà alcune tracce e potrebbero non essere in grado di collegare i punti su cosa è stato fatto e dove potrebbero essere andati, e potrebbe essere più facile dopo il rilevamento semplicemente resettare i dispositivi.

Il mio prossimo consiglio cambierà nelle prossime 2 settimane.

Esempi di percorsi di risposta agli incidenti

Non esiste una risposta giusta e perfetta che possa andare bene per tutti; questi sono i miei pensieri al 19-1-20 e potrebbero cambiare dopo man mano che imparo di più sui prossimi passi e mentre vengono rilasciati elementi sul lato difensivo o offensivo relativi a questa vulnerabilità. Non esiste una risposta giusta; la sicurezza IT è come la maggior parte dei territori, governata da "dipende". Suggerisco vivamente che se trovi qualcos'altro oltre a questi file solo in quelle 3 directory, considererei la macchina compromessa e seguirei il percorso più cauto. In alcuni di questi suggerisco di prendere il percorso più cauto, specialmente quando non ci sono log per confermare cosa hanno fatto o non fatto. Devi lavorare con il tuo team per decidere la migliore linea d'azione in base alla tua situazione, perché questo è uno sport di squadra. Può sempre esserci un modo migliore per risolvere cose come queste, ma in base alle prove che hai sul dispositivo e intorno al dispositivo (bersagli di livello 1), potresti stare bene riducendo il rischio e procedendo da lì.

• Mitigare: Questo è da dove dovresti iniziare, indipendentemente da tutto. Con il nuovo firmware o la politica di risposta.
• Exploit rilevati durante il tuo audit.
  • Avvia il tuo processo di risposta agli incidenti.
• Con una buona registrazione del dispositivo
  • Segni di attacchi avanzati o persistenza
    • Costruisci nuovo e migra
  • Nessun segno di attacchi avanzati o persistenza
    • Correggi e continua a eseguire
• Senza registrazione del dispositivo
  • Segni di attacchi avanzati o persistenza
    • Costruisci nuovo e migra
    • Reset di fabbrica
  • Nessun segno di attacchi avanzati o persistenza
    • Costruisci nuovo e migra
    • Reset di fabbrica
• Con una buona registrazione dei bersagli di livello 1
  • Segni di attacchi avanzati o persistenza
    • Costruisci nuovo e migra
    • Reset di fabbrica
  • Nessun segno di attacchi avanzati o persistenza
    • Correggi e continua a eseguire
• Nessuna registrazione dei bersagli di livello 1
  • Segni di attacchi avanzati o persistenza
    • Costruisci nuovo e migra
    • Reset di fabbrica
  • Nessun segno di attacchi avanzati o persistenza
    • Costruisci nuovo e migra
    • Reset di fabbrica

Definizione e riflessioni sulla risposta

• Costruisci nuovo e migra – Avvia il tuo processo di risposta agli incidenti, poi puoi iniziare questo processo https://docs.citrix.com/en-us/citrix-hardware-platforms/mpx/migrating-configuration-of-existing-appliance-to-another-appliance.html. Questo è relativamente facile per i clienti VPX e SDX a causa della natura virtuale e della flessibilità della piattaforma di configurazione. Le migrazioni MPX sono un'altra storia a causa di come funziona il reset di fabbrica e come viene mantenuta l'immagine base; potrebbe esserci un rischio molto basso se fosse un attaccante avanzato per persistere attraverso un aggiornamento del firmware e/o un reset di fabbrica. La probabilità potrebbe essere più bassa, ma è comunque possibile (come tutto nel mondo cyber).
• Reset di fabbrica – Avvia il tuo processo di risposta agli incidenti e rimuovi i file .xml e qualsiasi altra cosa rilevata, riavvia e controlla di nuovo la persistenza. Poi inizia il processo per eseguire il reset di fabbrica. Ci sono script ottenibili da Citrix che eseguiranno il processo. Questo cancellerà il sistema al livello più basso prima di ricaricare il sistema operativo, ma tutti si fideranno di questo metodo finora in base al loro panorama di minacce e potrebbero volere di più.
  • Il metodo più drastico sarebbe quello di restituire i dispositivi (RMA) per far ricaricare i dischi; questo potrebbe essere una buona o cattiva idea in base al tuo ciclo di vita, piattaforma e piano di ridondanza. Lo suggerirei solo se hai visto tecniche avanzate utilizzate e hai confermato movimento laterale basato sulle loro tecniche per eventualmente seguire questa strada. So che Citrix sta lavorando a opzioni per i casi e
• Correggi – Avvia il processo di risposta agli incidenti e rimuovi i file .xml e qualsiasi altra cosa rilevata, riavvia e controlla di nuovo la persistenza. Se hai buoni log, saprai se è stato fatto qualcosa; altrimenti, guarderei il tuo panorama di minacce e se hai registrazione sui bersagli di livello 1 o altro per sapere se devi considerare la necessità di un reset di fabbrica e/o se devi costruire nuovo e migrare.

Livelli di registrazione

• Buona registrazione locale
  • Sei nella posizione migliore per vedere cosa è successo localmente per sapere se ci sono stati tentativi di movimento laterale o se l'exploit è stato solo eseguito come la maggior parte.
• Buona registrazione dei bersagli di livello 1
  • Sei nella posizione migliore per vedere se il movimento laterale è avvenuto o anche tentato. Questi dovrebbero essere le prime cose che potrebbero essere state prese di mira e se hai visto un movimento laterale riuscito, allora dovresti essere il più preoccupato e procedere con più cautela nel tuo percorso di correzione. Altrimenti, puoi ridurre il rischio della minaccia e semplicemente intraprendere il percorso di correzione.
• Nessuna registrazione locale
  • Sei nella posizione peggiore per vedere cosa è successo localmente per sapere se ci sono stati tentativi di movimento laterale o se l'exploit è stato solo eseguito come la maggior parte. Devi procedere con più cautela nel tuo percorso di correzione.
• Nessuna registrazione dei bersagli di livello 1
  • Sei nella posizione peggiore per vedere se il movimento laterale è avvenuto o anche tentato. Questi dovrebbero essere le prime cose che potrebbero essere state prese di mira e se hai visto un movimento laterale riuscito, allora dovresti essere il più preoccupato e procedere con più cautela nel tuo percorso di correzione.

Spero che le persone possano rimuovere l'infezione e avere una registrazione sufficientemente buona per sentirsi sicuri che non siano più dentro e poter riprendere le normali attività senza alcuni di questi passaggi.

Altri buoni passaggi successivi

Ci sono due cose principali su cui devi prendere una decisione se ci sono tracce di sfruttamento.

• 1. Cambia la password di NSROOT
  • a. Raccomando di farlo indipendentemente da cosa trovi o da quali log hai. Questa è un'opportunità per mettere nsroot in rotazione per i cambi password. La gestione dell'ADC dovrebbe essere legata a LDAP e NSROOT dovrebbe essere usato solo per le emergenze.
• 2. Cambia l'account di servizio LDAP (o un altro servizio di autenticazione)
  • a. Cambia questa password insieme a quella che raccomando di cambiare con un altro account se possibile, così avrai anche un SID diverso. Questo può essere un cambiamento passivo senza che nessuno se ne accorga se testato prima del rollout.
• 3. Cambia le chiavi SSL
  • a. Buona registrazione
    • i. Forse stai bene se sei sicuro al 100% che sia a posto.
    • ii. C'è ancora una parte di me che vuole dire rigenera tutto, ma so quanto lavoro possa essere in un grande ambiente.
  • b. Nessuna registrazione
    • i. Penso che tu debba rigenerare tutto su quella macchina. C'è protezione PEM e PFX, ma ho visto molti posti che usano password molto semplici per quelle e potrebbero essere forzate offline. Poiché non sappiamo, dobbiamo proteggere l'azienda.

Riflessioni sulle password

Raccomando di cambiare le password per tutti i tuoi account locali sulla macchina se c'è anche un sentore di exploit riuscito. Vai avanti e cambiala perché in molte implementazioni potrebbe non essere mai stata cambiata dopo il deployment iniziale 4-7 anni fa. Se vedi segni di accesso da riga di comando e/o manomissione, puoi quasi certamente contare sul fatto che l'attaccante sia stato in grado di rompere la password su firmware pre-11.0 era AES256 e nelle build successive usa AES512, che può essere anch'esso suscettibile al cracking. Assicurati che sia legato a LDAP in modo sicuro e che tu abbia allarmi per gli accessi NSROOT.

Riflessioni su LDAP

Se hai visto alcuni livelli di sfruttamento, ti consiglio anche di cambiare qualsiasi account di servizio definito nella configurazione di Citrix ADC. Il più comune è l'account di bind LDAP/Kerberos. Qualcuno che riesce a eseguire un exploit su un Citrix ADC non significa che sia un amministratore di dominio, ma potrebbe non volerci molto tempo a seconda dei tuoi controlli e registrazioni. Questo è un cambiamento molto semplice che, se testato, può essere trasparente per gli utenti.

Riflessioni sui certificati

A seconda di cosa hai trovato con il tuo audit, aiuterà a capire anche questo. Se avevi una buona registrazione e puoi vedere che è stato richiesto l'accesso a questo file, allora devi rigenerare. Se non hai una buona registrazione, dovresti anche rigenerare. Se hai un certificato wildcard, allora questo è anche un altro grande problema e più siti a cui è legato, maggiore sarà il tuo rischio ed esposizione. La cosa peggiore che può accadere è che supponi che vada bene e qualcuno stia mettendo in piedi un sito di phishing con il tuo certificato che tutta la tua formazione non impedirà i clic. Questo può portare a problemi molto più grandi se qualcuno ha accesso ai tuoi certificati; suggerirei di procedere con cautela e fare una rigenerazione. Questo potrebbe essere un buon momento basato sulla data di scadenza del certificato attuale. Ho visto alcuni passare a un altro registrar di certificati in questo processo solo per cambiare le cose, ma avevano log che il file era stato accesso e scaricato insieme ad altre tecniche avanzate rilevate.

Crediti ###Ultimo ma non meno importante, alcuni ringraziamenti per alcune delle persone che hanno lavorato su questo problema sin dal suo arrivo. Ci sono molte altre persone che non sono in questa lista perché sono dietro le quinte e non le ho viste nemmeno io.

• Citrix Team – Lavorando per diffondere le informazioni insieme allo sviluppo di questi nuovi firmware. Devono lavorare su 5 patch contemporaneamente a causa delle differenze tra le famiglie di codice, il che rende tutto molto più difficile.
• Daniel Weppeler @_DanielWe – Policy del Responder di Logging per Rilevare Sondaggi\Attacchi
• Florian Roth @cyb3rops – File YAR di Nessus per il Rilevamento di Exploit
• CTP Anton van Pelt @AntonvanPelt & CTA Mads Petersen @mbp_netscaler & Jan Tytgat @jantytgat – Lavoro costante con i team CTP\CTA e Citrix su molti fronti.
• KevTheHermit @KevTheHermit – Divulgazione della vulnerabilità della password dell'istanza AWS oltre alla CVE
• Bad Packets Report @bad_packets – L'intero team Bad Packets https://badpackets.net
• Kevin Beaumont @GossiTheDog – Molta promozione dei problemi osservati insieme ad alcuni dettagli sul suo honeypot e su ciò che ha visto.
• Mpgn @mpgn_x64 – Dettagli sull'exploit e variazioni degli exploit
• Nick Carr @ItsReallyNick – Dettagli sull'exploit e suggerimenti per la risposta agli incidenti.
• Digi Cat u/digicat – Utente Reddit, fantastico blog di notizie in tempo reale.
• Ben Sadeghipour @NahamSec – Video DFIR su YouTube e altri contributi
• Team SANs – Articoli, video DFIR e approfondimenti
• Craig Dods @0xCraig – Implicazioni delle password e ricerca
• Manuel Kolloff @manuelkolloff – Walkthrough post-exploit
• FireEye e Mandiant Team Team Grazie a Rick Cole per aver creato la nostra prima copertura di rilevamento e al team di responder agli incidenti di Mandiant per il contributo a questo blog—in particolare Austin Baker, Brandan Schondorfer e John Prieto—e a tutti i consulenti che stanno rispondendo o proteggendo i propri ambienti client da questa vulnerabilità. Grazie anche a Nicholas Luedtke del nostro team di Intelligence sulle vulnerabilità per il suo aiuto nel perfezionare la tempistica di divulgazione e degli strumenti di questo blog.