Report sui bug - Dicembre 2021

Di Philippe Laulheret · 19 gennaio 2022

Un po' di umorismo sulla sicurezza informatica

Perché sono qui?

Se stai leggendo queste parole, CONGRATULAZIONI! Hai raggiunto il traguardo del nuovo anno. Meglio ancora, stai leggendo la rubrica mensile sulla sicurezza di ATR, che fornisce aggiornamenti sulle vulnerabilità più importanti degli ultimi 30 giorni. Congratulati con te stesso e preparati una tazza di caffè, tè, un’acqua tonica o anche una bevanda energetica se hai i nervi saldi. Ora che sei rinvigorito e a tuo agio, iniziamo!

Vulnerabilità di attraversamento di directory (path traversal) Grafana: CVE-2021-43798

Di cosa si tratta?

Come afferma il sito in lingua inglese Wikipedia, Grafana è un'applicazione Web open source e multipiattaforma per la visualizzazione interattiva e l'analisi. È ampiamente utilizzata nel settore, con clienti paganti come Bloomberg, eBay, PayPal, ecc. All'inizio di dicembre è circolata la notizia che una vulnerabilità di attraversamento di directory consentiva a un criminale informatico di accedere ai file locali a causa di una pulizia impropria della stringa "../../../" nel percorso d’accesso del suo plug-in. Questo è anche uno dei tempi di divulgazione più brevi conosciuti fino ad oggi:

Chi è interessato?

Sicuramente chi potrebbe biasimarti per non aver sentito parlare di vulnerabilità diverse da Log4Shell negli ultimi 30 giorni? Tuttavia, se la tua azienda utilizza questo software, dovresti aver seguito attentamente la divulgazione il mese scorso, altrimenti rischi che i tuoi file "/etc/passwd" siano noti a tutti su Internet. A parte questo, vale la pena riflettere su due punti mentre sorseggi il tuo zabaione a fine anno (senza voler sminuire la questione). Data la facilità con cui questa vulnerabilità è stata sfruttata, il semplice fatto che il fornitore abbia scelto di correggere il bug tramite il suo GitHub pubblico è stato apparentemente sufficiente per attirare l’attenzione generale e produrre POC pubblici per questa vulnerabilità in meno di tre giorni dopo il rilascio della patch. Se sei interessato a sapere in che modo le basi di codice open source più mature gestiscono questo tipo di rischio, tieni presente che progetti come Chromium si basano su un'infrastruttura di tracciamento dei bug separata, che limita l'accesso a queste segnalazioni di bug (con dettagli sui rischi per la sicurezza e scenari di test) combinati con messaggi di convalida (commit) pubblici la cui semplice formulazione è intesa ad evitare di attirare l'attenzione.

Un altro fatto interessante: la causa di questo bug è un uso improprio di un'API Go per ripulire i percorsi d’accesso, come spiegato in questo thread di discussionedi Twitter. Si è scoperto che la funzione filepath.Clean utilizzata per ripulire le voci elaborate dal codice vulnerabile rimuove solo l'eccesso "../../" se si tratta di un percorso d’accesso assoluto. Questo è un esempio abbastanza comune di un'API che si comporta come previsto, ma con conseguenze pericolose. Sei sicuro che la base di codice della tua azienda non sia interessata da questo tipo di problema? L'impatto delle vulnerabilità senza patch può in questo caso consentire l'accesso o l'esfiltrazione di dati estremamente sensibili. *Qui la riflessione si fa frenetica*

Cosa si può fare?

Ovviamente aggiornare il software se lo stai usando. Puoi anche utilizzare delle regole Sigma per rilevare i tentativi di attacco. In un mondo ideale, la tua piattaforma di analisi non dovrebbe essere esposta a Internet, come lo sono queste 87.000 istanze, di cui 16.000 sono ancora vulnerabili secondo Shodan. Come minimo, assicurati che la tua istanza Grafana si trovi dietro un prompt .htaccess o un'interfaccia simile. Dal punto di vista dello sviluppo, devono essere effettuati test di sicurezza e d’unità per verificare che il filtraggio implementato funzioni come previsto. Inoltre, se decidi di gestire l'input di utenti non approvati, non trascurare il filtraggio e applica schemi di codice attentamente verificati invece di disabilitare gli avvisi dal tuo strumento di sicurezza.

Il riferimento

“È il viandante che sceglie il sentiero o il sentiero che sceglie il viandante” si chiede Garth Nix nel suo romanzo Sabriël. In ogni caso, una cosa è certa, la strada sopra descritta non sarà intrapresa, né attraversata da un criminale informatico per i clienti di NSP (Network Security Platform). Quei fortunati sono già protetti dagli attacchi di attraversamento della directory con una regola generica e possono migliorare ulteriormente la loro protezione creando regole personalizzate incentrate su attacchi specifici.

CVE-2021-44228: Log4Shell

Di cosa si tratta?

Chi poteva immaginare che l'analisi (e talvolta l'esecuzione) di voci non attendibili fosse davvero una pessima idea? Eppure questo è esattamente ciò che fa il codice di registrazione log4j di Apache, e se la stringa registrata contiene i caratteri magici $(jdni:…) è persino possibile estrarre ed eseguire codice Java non approvato. Le iterazioni eseguite su questo attacco hanno anche rivelato la possibilità di far trapelare segreti locali, archiviati in variabili di ambiente, come per esempio le chiavi AWS, e data la ricorsività dell'elaborazione, offre anche molti modi per eludere il rilevamento basato sul confronto dei modelli.

Chi è interessato?

Il problema è serio e tutti dovrebbero preoccuparsene. Scrivi codice Java e registri eventi? Bene, è tempo di reagire. Utilizzi applicazioni o servlet Java? Probabilmente troverai registrazioni di utenti non approvati. Il tuo datore di lavoro utilizza appliance o servizi Java? Fai un brindisi alla salute del tuo SOC e a tutti gli informatici che probabilmente saranno impegnati durante le “vacanze” di Natale. Come avrai capito, questo problema riguarda l'intero settore e, con ogni probabilità, le sue conseguenze si faranno sentire per molti anni. A peggiorare le cose, il bug è molto facile da sfruttare. Penetration tester, analisti SOC, aspiranti hacker e criminali informatici sponsorizzati al soldo degli Stati hanno tutti iniziato a esplorare questo vettore di attacco. Abbiamo osservato attacchi su larga scala e di lunga durata con un'ampia gamma di carichi utili, dai cryptominer ai carichi utili di tipo “rm -rf /*” e persino un tentativo fallito di distribuire il worm Mirai. E il peggio deve ancora venire.

Cosa si può fare?

A rischio di parodiare Erica nella serie Stranger Things “You can’t spell America without Erica.” (Non puoi scrivere America senza Erica) Non esiste Apache senza una patch. Beh, quasi. Non aspettare a fare un aggiornamento! Applica piccole patch mirate. Monitora il traffico. Un consiglio: se la tua applicazione esclusivamente interna inizia a inviare richieste LDAP a un server remoto in un paese in cui la tua azienda non ha alcuna attività, forse sta succedendo qualcosa di sospetto...

Se ti piace il caos e/o hai difficoltà a convincere il team IT dell'importanza di questo bug, chiedi loro il permesso di dimostrare i rischi che presenta! Quindi assegna questo valore magico $(jdni:ldap…) alle stringhe che puoi controllare (agente utente, nome Twitter, SSID wifi, …) e puntalo a una porta IP che controlli, o a una servizio di terze parti come Canarytoken di cui ti fidi. Se rilevi risposte a questo indirizzo, puoi informare il tuo team IT di aggiornare il loro stack tecnologico con i proprietari degli indirizzi in entrata. È in questa fase che è essenziale chiedere prima l’autorizzazione. In effetti, se fai cadere quel filo magico dappertutto per vedere cosa succede dopo (come potresti aver visto su varie piattaforme di social media), è probabile che a un certo punto “qualcuno” proverà a contattarti per scoprire “di più” sul tuo strano agent utente. Naturalmente, prima di intraprendere questo tipo di attività, considera che potrebbe essere spiacevole ricevere una denuncia per frode a Natale.

Il riferimento

I clienti Trellix sono protetti in diversi modi. (Per i dettagli, consulta questo articolo della Knowledge Base.) Ad esempio:

• Le regole avanzate (Expert Rules) nella soluzione ENS (Endpoint Security) possono identificare schemi pericolosi nella memoria, come descritto in questo articolo del blog.
• Endpoint Security (ENS), VirusScan Enterprise (VSE), Web Gateway (WG) possono offrire un rilevamento generico come Exploit-CVE-2021-44228.C tramite il rilevamento di “software potenzialmente indesiderato”. Questo rilevamento è inoltre completato da un elenco di hash di esempio relativi a campagne attive che sfruttano questa vulnerabilità.
• Network Security Platform (NSP) può anche rilevare l'attacco per mezzo di una firma definita dall'utente (fornita nell'articolo della Knowledge Base menzionato sopra).
• È inoltre possibile utilizzare le soluzioni Endpoint Detection and Response (EDR) e Active Response (AR) per cercare sistemi vulnerabili utilizzando query RTS (Real-Time Search).
• La soluzione SIEM ha ricevuto un aggiornamento (Exploit Content Pack versione 4.1.0) che attiverà un allarme in caso di potenziali tentativi di exploit. Insights offre anche informazioni interessanti nell'ambito della campagna di minacce “Log4Shell - A Log4j Vulnerability - CVE-2021-44228”. Guarda la presentazione di MVISION Insights.

CVE-2021-43527 – Big Sig

Di cosa si tratta?

Big Sig è un po' come il soprannome dato a Freud da sua madre. Questo bug non è meno accattivante. All'inizio di dicembre, Google Project Zero ha pubblicato un articolo sul blog su una vulnerabilità trovata nei servizi NSS (Network Security Services) di Mozilla con un punteggio CVSS di 9,8, secondo le informazioni fornite nella pagina del sito National Vulnerability Database (NVD) del NIST. Il difetto è un overflow dello stack nell'elaborazione di alcune firme DSA e RSA-PSS con codifica DER. In poche parole, NSS raggruppa diverse librerie crittografiche che consentono agli sviluppatori di utilizzare implementazioni più sicure o rigorosamente testate di primitive e standard crittografici (per criptare le comunicazioni, verificare l'autenticità dei dati, ecc.). Il bug è stato scoperto in una funzione responsabile della verifica delle firme che provano l'autenticità dei dati utilizzando vari modelli crittografici pubblici. Questo tipo di funzione viene generalmente utilizzata per firmare email o documenti e confermare l'identità del loro autore. Uno degli aspetti più interessanti di questo bug è la sua relativa semplicità, ma anche la sua età. Secondo l'articolo di Project Zero, era possibile sfruttare questo bug già nel 2012. Il percorso verso il codice vulnerabile si è semplicemente infiltrato attraverso le crepe, ovvero dove i vari fuzzer usati da Mozilla si sovrappongono.

Chi è interessato?

Se vuoi che le tue firme siano verificate e ti affidi alla libreria NSS per farlo, dovresti davvero controllare il bollettino e utilizzare l'ultima versione del software (versione NSS 3.73/3.681 ESR o successiva). Firefox sembra sia stato risparmiato, ma altri software che analizzano le firme potrebbero essere stati colpiti (Thunderbird, LibreOffice, Evolution, Evince e altri).

Cosa si può fare?

Come al solito, dovresti assicurarti che qualsiasi software che usi, che potrebbe essere vulnerabile, sia aggiornato all'ultima versione. La patch è stata rilasciata il 1° dicembre. Pertanto, assicurati che il software potenzialmente vulnerabile sia stato aggiornato dopo questa data. È anche utile identificare il software utilizzando questa libreria. Anche se non c'è una soluzione rapida, i riferimenti a file come nss3.dll su Windows o libnss3.so su Linux sono un buon punto di partenza. A parte questo, l'approccio migliore è controllare le note di rilascio e il potenziale elenco di librerie di terze parti impiegate nelle applicazioni che probabilmente utilizzerai. Se utilizzi la libreria vulnerabile nel tuo prodotto, aggiorna il codice o includi la patch.

Il riferimento

Hai letto i nostri bollettini? Sono una fonte molto utile di informazioni su vulnerabilità critiche di cui potresti non essere a conoscenza. Ciò può includere applicazioni che dovrebbero distribuire patch per la vulnerabilità CVE-2021-43527.