Report sui bug - Gennaio 2022

Di Kevin McGrath · 2 febbraio 2022

Un po' di umorismo sulla sicurezza informatica

Perché sono qui?

Omicron è la 15a lettera dell'alfabeto greco. È stata suggerita da Donald Knuth per rinominare la notazione O grande, che rappresentava lo zero nell'Almagesto di Tolomeo e aveva come valore isosefico. Ma per la maggior parte di noi evoca solo una pandemia IN- TER- MINA- BILE. Come mai non sei interessato alle nostre divagazioni filosofiche sulla parola più citata nel gennaio 2022? Sei davvero venuto su questa pagina per saperne di più sulle vulnerabilità? Non importa. Benvenuto nell’edizione di gennaio del Report sui bug!

• CVE-2022-0185: gli sviluppatori Java non sono gli unici che dimenticano di convalidare gli input.
• CVE-2021-42392: scusa? Pensavi davvero che Log4Shell sarebbe scomparso?
• CVE-2022-21907: non ti abbiamo dimenticato, piccolo verme.
• CVE-2021-4034: PwnKit entra in gioco quando decidi che sudo non è abbastanza.

CVE-2022-21907: la vulnerabilità HTTP.sys può essere sfruttata da un worm.

Di cosa si tratta?

Nella patch Tuesday di gennaio 2022, Microsoft ha rivelato una vulnerabilità worm nel driver del kernel HTTP.sys. Questa è la seconda vulnerabilità sfruttabile da un worm identificata in HTTP.sys in sette mesi. Considerando la maturità del codice di questo driver, è molto. La vulnerabilità CVE-2021-31166 non ha fatto esplodere Internet. Si spera che lo stesso sia vero per la vulnerabilità CVE-2022-21907. Questa sfrutta la correzione incompleta della vulnerabilità CVE-2021-31166, che sfrutta il supporto per l'intestazione HTTP Trailer (metadati alla fine di un messaggio segmentato). Non si sa se questo exploit si basa sulla presenza di un'intestazione Trailer nel segmento finale. La RFC indica che questo è facoltativo. Questo può essere un problema per gli autori di firme di prodotti di rete se non possono fare affidamento sull'intestazione Trailer.

Lo sapevi? A questo proposito, prove di concetto (PoC) sono disponibili su GitHub.

Altra informazione importante: stiamo iniziando a vedere questa vulnerabilità sfruttata nel mondo reale. Per informazioni aggiornate sulle minacce in circolazione, prendi seriamente in considerazione l'utilizzo di McAfee Insights.

Sebbene possa sembrare logico che solo IIS utilizzi HTTP.sys, in realtà non è così. HTTP.sys è il driver del kernel che fornisce il codice di gestione HTTP principale. Altri sottosistemi utilizzano questo codice:

• ADFS
• WinRM
• Assistente di supporto Intel

Per visualizzare i servizi che utilizzano questo driver, esegui il comando:

PS > netsh http show servicestate

Otterrai l'elenco delle code di richiesta e degli URL associati in esecuzione sul sistema attivo.

Chi è rimasto fermo alle versioni di Windows Server 2019 o Windows 10 1809 sono al sicuro... a meno che non abbiano abilitato il supporto dei trailer nel registro.

Chi è interessato?

2,4 milioni di utenti di Twitter. Chiunque esegua IIS nel proprio ambiente. Chiunque utilizzi Docusign (e sono tanti, visto il numero di atti legali autenticati da DocuSign, soprattutto dall'inizio della pandemia). Secondo un recente report, circa il 7% dei siti Web utilizza IIS. Anche Microsoft non ha tanti sistemi connessi a Internet, il che significa che molti siti al di fuori di Microsoft utilizzano IIS. Sono interessate anche tutte le persone che utilizzano versioni vulnerabili di Windows per impostazione predefinita:

• Windows 10 2004 e versioni successive (ARM e x64)
• Windows Server 20H2 e versioni successive

Cosa si può fare?

Applicare le patch. Microsoft ha pubblicato una patch per questa vulnerabilità insieme all'annuncio. Se non è possibile applicarla, è meglio rimuovere questi sistemi dai ruoli connessi a Internet. Sfortunatamente, nessuna funzionalità di prevenzione basata su host è disponibile per le versioni correnti di Windows.

Se utilizzi Windows Server 1909 o Windows 10 1809, non sei vulnerabile di default. Per determinare lo stato di vulnerabilità, esegui il comando:

PS > Get-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" | Select-Object EnableTrailerSupport

Se viene restituito un valore diverso da zero, il sistema è vulnerabile. Per limitare i rischi, esegui il comando:

PS > Set-ItemProperty "HKLM:\System\CurrentControlSet\Services\HTTP\Parameters" -name EnableTrailerSupport -Value 0

In caso contrario, elimina semplicemente questa chiave di registro.

Il riferimento

La buona notizia è che è disponibile una patch. Assicurati di applicarla. Se non puoi, non temere. Trellix ti protegge con le firme NSP (Network Security Platform) per questa vulnerabilità. Quindi controlla di aver aggiornato il database delle firme.

CVE-2021-42392: una vulnerabilità simile a Log4Shell colpisce H2

Di cosa si tratta?

La vulnerabilità CVE-2021-42392 è ​​simile a Log4Shell nella gestione del caricamento remoto delle classi JNDI. Sebbene non sfrutti il ​​bug presente in Log4j (che non è nemmeno richiesto), si basa sulla stessa tecnologia sottostante (JNDI). Qualsiasi URL controllato da un criminale informatico che riesca ad accedere al database può eseguire codice remoto nel contesto del componente RDBMS H2. Ma ovviamente sei al sicuro perché hai pulito, impostato e archiviato tutte le query sul database. Non è vero?

Chi è interessato?

L'utilizzo H2 è stimato in quasi 7.000 progetti, incluso Log4j. Viene da chiedersi se il problema sia davvero Log4j. In caso contrario, potrebbe essere necessario rinominare Log4Shell e non è solo per gli utenti Log4j. La natura prende sempre il sopravvento...

Cosa si può fare?

Le versioni del database H2 da 1.1.100 a 2.0.204 sono interessate. La versione 2.0.206, rilasciata il 5 gennaio 2022, risolve questa vulnerabilità. L'ideale sarebbe fare l’aggiornamento alla versione 2.0.206 o successiva.

Si potrebbe cambiare il motore del database, ma questa opzione può sembrare estrema. Curare la malattia uccidendo l'ospite non è raccomandato tanto in informatica quanto in medicina.

Potresti anche smettere di usare Java. In questo caso, il consiglio è valido. Questa è in realtà l'opzione migliore. Java non ha più un posto sui server.

Il riferimento

Se non è possibile applicare le patch, rimuovere tutto il codice Java a favore di un altro linguaggio o modificare il motore del database, Trellix garantisce la tua protezione, poiché gli exploit saranno molto simili a Log4Shell.

I clienti Trellix sono protetti sotto diversi angoli (per saperne di più, consulta questo articolo della Knowledge Base):

• Le regole avanzate 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 (MWG) 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).
• Le soluzioni MVISION Endpoint Detection and Response (EDR) e McAfee Active Response (MAR) possono essere utilizzate anche per cercare sistemi vulnerabili utilizzando query RTS (Real-Time Search).
• La soluzione McAfee SIEM ha ricevuto un aggiornamento (Exploit Content Pack versione 4.1.0) che attiverà un allarme in caso di potenziali tentativi di exploit.

CVE-2022-0185: un overflow di numeri interi influisce sugli spazi dei nomi del kernel Linux.

Di cosa si tratta?

Apparentemente, la vulnerabilità CVE-2022-0185 è un semplice overflow di intero in un percorso di codice legacy. Fortunatamente per coloro che utilizzano i container, questo percorso del codice legacy si trova nella funzione File System Context (FSC). Sebbene questa sia stata sostituita dall'API Filesystem Context, alcune funzionalità sono state mantenute per supportare la compatibilità con le versioni precedenti, incluso il percorso vulnerabile. L’overflow di intero crea una scrittura fuori limite per un criminale informatico nel contesto del processo contenitore stesso. Un criminale informatico con accesso a un contenitore può sfruttare questo difetto per attaccare l'host sottostante, consentendo l’accesso a tutti gli altri contenitori in esecuzione su quel nodo. Data la popolarità di strumenti come Kubernetes (k8s), questa scoperta è potenzialmente preoccupante per chiunque utilizzi i contenitori per isolare i processi in presenza di utenti non attendibili. Questo problema riguarda solo i contenitori che utilizzano spazi dei nomi senza privilegi, i contenitori che consentono il comando unshare e quelli con il privilegio CAP_SYS_ADMIN (disabilitato per impostazione predefinita). Il comando unshare è bloccato per impostazione predefinita sui contenitori Docker dal filtro seccomp. Sfortunatamente per gli utenti di k8s, il filtro seccomp non è abilitato per impostazione predefinita, il che significa che qualsiasi cluster Kubernetes è a rischio.

Il passato è un freno al progresso. In altre parole, la compatibilità con le versioni precedenti è raramente un criterio che consente di migliorare le cose.

Chi è interessato?

Chiunque utilizzi la tecnologia dei contenitori. E anche gli amministratori che non ne eseguono uno, ma consentono agli utenti di farlo. Chiunque esegua un contenitore su un server condiviso dovrebbe esserne preoccupato e potenzialmente rimuovere qualsiasi risorsa mission-critical da quel server fino a quando il kernel sottostante non sarà stato aggiornato.

Gli autori hanno scritto un articolo del blog dettagliato e pubblicato il codice PoC per questa vulnerabilità. Dobbiamo essere tutti vigili, perché è solo questione di tempo prima che i criminali informatici lo sfruttino.

Cosa si può fare?

Se controlli l'host, devi aggiornare il kernel. Se ciò non è possibile (o se il proprietario rifiuta), esegui il comando:

# sysctl -w kernel.unprivileged_userns_clone = 0

Ciò limiterà questa vulnerabilità ai contenitori con il privilegio CAP_SYS_ADMIN. La rimozione di questo privilegio per i tuoi contenitori ridurrà anche questa vulnerabilità (È disabilitato per impostazione predefinita).

Per i sistemi che non eseguono contenitori, Red Hat consiglia semplicemente di disabilitare del tutto gli spazi dei nomi:

# echo "user.max_user_namespaces=0" > /etc/sysctl.d/userns.conf # sysctl -p /etc/sysctl.d/userns.conf

Ciò inoltre impedisce all'host di eseguire contenitori, che è comunque una buona idea se non ne usi uno.

Il riferimento

A questo punto, l'applicazione di patch o misure preventive è la scelta migliore. Poiché i contenitori vengono utilizzati come meccanismo di isolamento, è improbabile che un processo esterno ottenga visibilità in un contenitore in esecuzione. Assicurati di eseguire un host con patch o di abilitare il filtro seccomp su k8s.

CVE-2021-4034: PwnKit

Di cosa si tratta?

La vulnerabilità CVE-2021-4034, denominata PwnKit, sfrutta un bug logico in PolKit (precedentemente conosciuto come PolicyKit). PolKit è un kit di gestione delle policy a livello di sistema che offre ai processi senza privilegi un accesso sicuro (o almeno così si pensava) ai processi con privilegi. Il bug esiste specificamente nello strumento pkexec (apparentemente sudo non era sufficiente, ed era necessario un altro programma setuid per eseguire esattamente la stessa funzione). Assumiamo che la variabile argc sia maggiore o uguale a 1. Questo è indiscutibilmente vero quando si chiamano i programmi. Qualsiasi sfruttamento anomalo dovrebbe essere identificato come indicatore di compromissione e rifiutato in fase di esecuzione, ma purtroppo non è così.

In genere, quando si utilizza pkexec, viene visualizzata una finestra a comparsa per l'immissione delle credenziali. Questa vulnerabilità ignora questo controllo delle credenziali e consente l'esecuzione come super-utente root. Un modo divertente per assicurarsi di concedere il pieno accesso a colui che sfrutta una falla!

Questa è la seconda vulnerabilità di PolKit in sei mesi. La vulnerabilità CVE-2021-3560 ha anche ignorato la verifica delle credenziali utilizzando il meccanismo dbus per chiamare PolKit. Entrambe le vulnerabilità sembrano aver sfruttato la stessa falla. A tal proposito, la causa principale è stata segnalata per la prima volta nel 2013, ma l'autore non aveva identificato un rischio di sfruttamento. La patch quindi ha preso polvere ed è finita nel dimenticatoio. Nove anni dopo, è finalmente arrivato il suo momento! Goditi le luci della ribalta, piccola patch!

Chi è interessato?

Difficile negare che questo sia il più grande bug di escalation dei privilegi locali dell'ultimo anno. Questa vulnerabilità esiste nella maggior parte delle principali distribuzioni Linux che eseguono binari PolKit obsoleti. Chiunque esegua una versione di Linux a cui non è stata applicata alcuna patch dal 25 gennaio è quindi vulnerabile. I numeri di versione di PolKit non sono molto precisi, dal momento che Debian gestisce la propria offerta, ma se esegui

• una versione precedente a 0.105-26ubuntu1.2 sotto Ubuntu 20.04 (LTS),
• una versione precedente a 0.105-31ubuntu0.1 sotto Ubuntu 21.10,
• una versione precedente a 0.105-31+deb11u1 sotto Debian Bullseye, oppure
• una versione precedente a polkit-0.115-11.el8_4.2 sotto RedHat Enterprise Linux (RHEL) 8.4 EUS,

allora sei vulnerabile. Ancora una volta, sei vulnerabile se non hai applicato una patch dal 25 gennaio. È disponibile anche il codice PoC. È quindi solo questione di tempo prima che venga sfruttato attivamente.

Che dici, ti fidi di tutti i tuoi utenti? In that case, you have nothing to worry about. Compromised accounts are readily available. Fidarsi degli utenti è una cosa. Fare affidamento sugli account utente è ben diverso, in quanto possono essere compromessi da phishing, cracking delle password, riutilizzo delle password di altri account e molti altri metodi di attacco.

Sebbene questo bug sia stato scoperto su Linux, altre distribuzioni UNIX utilizzano PolKit, comprese le licenze BSD. Almeno OpenBSD ha sempre integrato funzionalità di prevenzione. In particolare, rifiuta di eseguire un programma con una variabile argc pari a 0. Solaris utilizza PolKit, ma Oracle mantiene così tanta segretezza intorno a Solaris che ha persino reso a pagamento i bollettini sulla sicurezza. Ovviamente, questo è il modo migliore per fidelizzare i clienti!

Cosa si può fare?

Installare gli aggiornamenti. Le patch sono disponibili presso i principali fornitori di Linux e dovrebbero essere applicate. Non è necessario riavviare. Se scegli di non applicare le patch, puoi rimuovere setuid da pkexec:

# chmod 0755 /usr/bin/pkexec

Sfortunatamente, questo impedirà anche a pkexec di svolgere la sua funzione principale. Ma è comunque meglio di un attacco, giusto?

Red Hat ha scritto una guida alla prevenzione specifica per RHEL nel suo bollettino sulla sicurezza.

Il riferimento

Poiché questa è una versione coordinata per tutte le distribuzioni Linux, deve essere applicata. Va sottolineato che i punti di origine delle connessioni anomale devono essere registrati, segnalati ed eventualmente bloccati senza alcuna altra forma di autenticazione. Stai usando l'autenticazione a più fattori, giusto? L'autenticazione a più fattori impedisce alle minacce esterne di sfruttare questa vulnerabilità bloccando il loro accesso al sistema. Per quanto riguarda le minacce interne... questo è un problema per un altro giorno.