Discussione CVE-2021-31166: HTTP Protocol Stack Remote Code Execution Vulnerability

Stato
Discussione chiusa ad ulteriori risposte.

Netcat

Utente Jade
17 Gennaio 2022
455
129
331
691
Sono sempre stato contrario alla pubblicazione di PoC su exploit che hanno un unico scopo: distruggere. Gli exploit che causano un crash andrebbero mantenuti privati, ma purtroppo, alcuni di loro sono open-source, come nel caso di CVE-2021-31166.
Quest'exploit non si limita solamente a creare un blue screen dall'altra parte, ma c'è anche il rischio di un crash permanente. Ma perché? Non mi dilungo troppo su quest'exploit, desidero più che altro che quante più persone lo conoscano cosicché possano installare la patch, e anche per questo motivo userò un linguaggio meno tecnico possibile.

La formula di questi exploit che sfruttano http.sys per fare casini è più o meno sempre questa (perché c'era anche una variante più vecchia dell'exploit):

una richiesta che contiene un header invalido. Quando un server non vulnerabile vede questa richiesta la scarta, e restituisce un errore (400 bad request), dal momento che la richiesta non è valida, e va trattata come tale.
Un server vulnerabile invece, quando vede questa richiesta la interpreta come legittima (restituendo 200 OK), ma dato che in realtà non è legittimo un bel niente, la memoria dell'OS che sta hostando il server crasha, perché ha accettato e provato a elaborare una richiesta che normalmente andrebbe rifiutata. Quando i server restituiscono 400 Bad Request c'è un motivo dopotutto.

Tuttavia, niente paura. Se Microsoft Update è sempre attivo sul tuo dispositivo (dato che l'exploit affligge solamente Microsoft IIS, e quindi Windows) non hai di che preoccuparti. In caso contrario, puoi installare la patch direttamente dal loro catalogo online, chiamato "Microsoft Update Catalog", raggiungibile da una semplice ricerca su Google.

Per i cacciatori come me, l'unico modo che hanno per testare la consistenza di quest'exploit è installare localmente un'istanza di IIS vulnerabile, ma sinceramente non vale proprio la pena sbattersi per un exploit che schiacci Enter e tira giù un server, mentre testarlo su dispositivi altrui caccia solo nei guai:
Quindi direi che dopo questo thread, quest'exploit può andare tranquillamente a /dev/null (almeno per me)
 
Ultima modifica:
Molti PoC che riguardano remote code execution sono incompleti proprio per evitare che vengano usati a tutto spiano da script kiddie che vogliono piazzare backdoor ovunque. Il crash in questo caso non è dato dalla vulnerabilità in sè che ha una reliability alta (è una use-after-free stabile), ma proprio dal PoC che è incompleto: non fa gli "aggiustamenti" che dovrebbe oltre a non eseguire altro codice e quindi va a finire che il kernel nota che qualcosa non va nella linked list corrotta a metà e chiama fastfail causando la BSOD.

Il ricercatore ha postato il PoC solo dopo la pubblicazione della patch da Microsoft, di solito lo pubblicano per permettere a cybersecurity firm che sviluppano tool di network monitoring, intrusion detection systems eccetera di poter creare delle regole per la detection. Non dimentichiamo che il mondo è pieno di aziende che non sono pronte a fare upgrade a versioni di OS moderne per via di strumenti legacy essenziali al business, e si affidano a firewall, WAF, XDR moderni che stanno in mezzo. Per quanto mi riguarda è una pessima scelta ma capisco che se non sono pieni di soldi potrebbe essere un problema sviluppare da capo una roba che il decennio scorso (o anche più) è costata anni di lavoro e molti soldi e che ancora fa il suo lavoro.

Poi si, è vero che anche solo come DoS può far danno, però dopo non aver patchato, non aver installato altre soluzioni di sicurezza e dopo una bella bsod se continui a riavviare senza fare niente allora meriti di stare col server offline per sempre :asd:
Il danno è comunque minore, se non avessero pubblicato il PoC, i gruppi ransomware avrebbero reversato la patch, scritto la loro RCE funzionante e a quel punto non ci sarebbero state regole di detection (da quelle firm che in autonomia non reversano la vuln), solo la patch ufficiale funzionerebbe.
 
  • Mi piace
Reazioni: --- Ra --- e 0xbro
Molti PoC che riguardano remote code execution sono incompleti proprio per evitare che vengano usati a tutto spiano da script kiddie che vogliono piazzare backdoor ovunque. Il crash in questo caso non è dato dalla vulnerabilità in sè che ha una reliability alta (è una use-after-free stabile), ma proprio dal PoC che è incompleto: non fa gli "aggiustamenti" che dovrebbe oltre a non eseguire altro codice e quindi va a finire che il kernel nota che qualcosa non va nella linked list corrotta a metà e chiama fastfail causando la BSOD.

Il ricercatore ha postato il PoC solo dopo la pubblicazione della patch da Microsoft, di solito lo pubblicano per permettere a cybersecurity firm che sviluppano tool di network monitoring, intrusion detection systems eccetera di poter creare delle regole per la detection. Non dimentichiamo che il mondo è pieno di aziende che non sono pronte a fare upgrade a versioni di OS moderne per via di strumenti legacy essenziali al business, e si affidano a firewall, WAF, XDR moderni che stanno in mezzo. Per quanto mi riguarda è una pessima scelta ma capisco che se non sono pieni di soldi potrebbe essere un problema sviluppare da capo una roba che il decennio scorso (o anche più) è costata anni di lavoro e molti soldi e che ancora fa il suo lavoro.

Poi si, è vero che anche solo come DoS può far danno, però dopo non aver patchato, non aver installato altre soluzioni di sicurezza e dopo una bella bsod se continui a riavviare senza fare niente allora meriti di stare col server offline per sempre :asd:
Il danno è comunque minore, se non avessero pubblicato il PoC, i gruppi ransomware avrebbero reversato la patch, scritto la loro RCE funzionante e a quel punto non ci sarebbero state regole di detection (da quelle firm che in autonomia non reversano la vuln), solo la patch ufficiale funzionerebbe.
No, il danno non è minore. Il bsod causa perdita di dati volatili, perché un os non può salvare le operazioni in corso durante un arresto anomalo. Il danno è sicuramente minore in un ambiente controllato, ti basta un reboot. In una situazione reale non credo proprio.
 
Stato
Discussione chiusa ad ulteriori risposte.