Edition 21

Sfruttato: sì, come zero-day, prima che ne veniste a conoscenza. Esposto: solo dove la management interface è raggiungibile dall'esterno. Tocca: il dispositivo che presidia il perimetro, con privilegi root. Verdetto: ore se quell'interface risponde da internet, giorni dietro un jump box. E si noti cosa ha fatto il punteggio qui. 8.6 è High, che nella maggior parte delle policy concede 30 giorni, mentre CISA ne ha dati tre alle agenzie federali. Se la vostra tabella degli SLA fosse stata l'unico input, avreste pianificato per novembre la gestione di un firewall attivamente compromesso. Il controllo compensativo non costa nulla e Palo Alto lo raccomanda da anni: togliete la management interface da internet stanotte, poi applicate la patch con i vostri tempi.

Sfruttato: sì, quattro giorni prima della divulgazione. Esposto: qualsiasi sistema che gestisce richieste web tramite PHP, il che per la maggior parte delle organizzazioni significa il sito marketing di cui nessuno è responsabile. Tocca: l'esecuzione di codice come account web, sull'host. Verdetto: ore, e nella versione onesta la finestra si è chiusa prima che l'advisory esistesse. Due considerazioni da trarre, oltre al patching. Apache mod_php è stato validato per la piena esecuzione di codice con configurazione predefinita: iniziate da lì. E se una parte del vostro parco macchine esegue ancora PHP 8.1 o precedenti, non arriverà alcuna correzione; diventa quindi una decisione di risk acceptance con un nome a cui rispondere, non un'attività di patching.

Sfruttato: nessuna segnalazione. Esposto: qualsiasi servizio che decomprima Brotli che non ha generato, e sono più di quanti si pensi. Tocca: il runtime sotto le vostre applicazioni. Verdetto: giorni, sul vostro normale percorso di emergenza. La parte problematica è la distribuzione. Ogni container basato su una node base image precedente al 21 ottobre porta questa vulnerabilità, quindi la correzione è una rebuild e un redeploy sull'intero parco macchine, non un aggiornamento pacchetto su un singolo host. E questa release ha anche silenziosamente incluso il certificate distrust dell'elemento successivo, il che è la prova più evidente che il vostro trust store vive dentro le vostre dipendenze.

Sfruttato: nessun abuso confermato, anche se nessuno può dar conto di diciassette mesi. Esposto: non i vostri browser, corretti nel giro di ore. Tocca: la fiducia stessa, ovunque si validi un certificato al di fuori di un browser. Verdetto: questo non ha scadenza perché non ha patch, ed è esattamente per questo che è il più difficile. I vostri container, i vostri appliance, i vostri Java keystore e ogni ambiente Python che porta la propria copia di certifi contengono ciascuno un trust store che qualcuno deve aggiornare. Curl, certifi, Node.js, Go e l'ecosistema Rust hanno tutti distribuito il distrust separatamente. La domanda a cui la vostra organizzazione deve rispondere è dove si fidano delle certification authority e chi può modificarlo ovunque e in una volta sola; e la maggior parte non riesce a rispondere nemmeno alla prima metà. Un dettaglio su cui vale la pena soffermarsi: Helme afferma che un agente AI ha recuperato le chiavi per lui da un singolo prompt.

Non avete superato questa settimana applicando patch. Avete scelto, oppure qualcuno ha scelto al posto vostro. Quindi mettete la scelta per iscritto. Un responsabile nominato, la motivazione, il controllo compensativo se esiste, e una data per rivalutare la situazione. Una vulnerabilità rinviata con una firma è una risk decision. Senza firma è un'omissione che dovrete spiegare in seguito; e dopo otto giorni come questi ci sarà molto da spiegare. Ho scritto l'argomentazione completa, incluso il motivo per cui i punteggi non hanno deciso nulla e perché la maggior parte delle patch policy avrebbe classificato il vettore ransomware come lavoro di second'ordine. Link sopra. La versione breve è che i vostri scanner erano identici a quelli di tutti gli altri questa settimana. Ciò che ha differenziato le organizzazioni era sapere chi aveva il potere di decidere.