Pubblicare gli exploit PoC dopo la produzione di una patch, è corretto?

Massimiliano Brolli : 7 Maggio 2021 08:00

Autore: Massimiliano Brolli
Data Pubblicazione: 05/05/2021

Questa domanda da sempre ha fatto appassionare i ricercatori di sicurezza informatica e gli esperti del settore che spesso si trovano in forte disaccordo se sia corretto o meno, pubblicare una exploit PoC (proof of concept) subito dopo la produzione della patch di sicurezza, o peggio ancora quando di fatto è uno zero-day.

In modo più sottile si tratta di un tema molto simile all’argomento se sia corretto o meno svolgere la full-disclosure di un bug di sicurezza, oppure fornire solo la versione e la tipologia di bug, per evitare successivi sfruttamenti.

CORSO NIS2 : Network and Information system 2
La direttiva NIS2 rappresenta una delle novità più importanti per la sicurezza informatica in Europa, imponendo nuovi obblighi alle aziende e alle infrastrutture critiche per migliorare la resilienza contro le cyber minacce. Con scadenze stringenti e penalità elevate per chi non si adegua, comprendere i requisiti della NIS2 è essenziale per garantire la compliance e proteggere la tua organizzazione.

Accedi All'Anteprima del Corso condotto dall'Avv. Andrea Capelli sulla nostra Academy e segui l'anteprima gratuita.
Per ulteriori informazioni, scrivici ad [email protected] oppure scrivici su Whatsapp al 379 163 8765 

Supporta RHC attraverso:

• L'acquisto del fumetto sul Cybersecurity Awareness
• Ascoltando i nostri Podcast
• Seguendo RHC su WhatsApp
• Seguendo RHC su Telegram
• Scarica gratuitamente "Dark Mirror", il report sul ransomware di Dark Lab

Ti piacciono gli articoli di Red Hot Cyber? Non aspettare oltre, iscriviti alla newsletter settimanale per non perdere nessun articolo.

Ma sulla scia degli exploit di sicurezza zero-day di Microsoft Exchange ProxyLogon e F5 BIG-IP divulgati all’inizio di quest’anno, la discussione si è riaccesa anche perché, molti exploit PoC sono stati eliminati da GitHub il 9 di marzo, subito dopo la loro pubblicazione, creando grosse critiche da parte della community hacker.

Sicuramente gli aspetti sono molti e i numeri in gioco importanti.

Ad esempio, attraverso il bug di Microsoft Exchange ProxyLogon (che ha permesso l’accesso come amministratore ai server windows), il cybercrime ha colpito inizialmente più di 100.000 macchine in tutto il mondo, di cui 30.000 negli Stati Uniti.

Ma come sappiamo una volta che una cosa è pubblica su internet, anche se la rimuovi subito, di fatto è persa per sempre. Questo anche vista l’attenzione da parte del crimine informatico e dei ricercatori, ossessionati nel trovare per primi una PoC funzionante, per poter mietere il successivo “raccolto”.

Pertanto tali PoC sono state utilizzate dal cybercrime da profitto per attaccare le infrastrutture e dai national-state-actors, per inoculare il ransomware, ma anche per accedere alle reti, creando persistenza, portando di fatto alla compromissione delle infrastrutture di 30.000 organizzazioni attraverso DearCry del 9 marzo, l’attacco di cryptomining LemonDuck del 12 marzo e l’attacco ransomware Black Kingdom il 19 marzo.

A livello logico, la pubblicazione di un exploit PoC capace di sfruttare una vulnerabilità, comporta un aumento del rischio che i criminali informatici possano utilizzarlo a loro vantaggio per attaccare migliaia di server non ancora protetti.

Ma pubblicare una PoC permette anche una serie di vantaggi, soprattutto se li vediamo non dal punto di vista “del singolo”, ma dal punto di vista della “comunità”.

Per tutti quelli che non vogliono che le PoC vengano pubblicate subito, vorrei porre la seguente domanda:

Dopo quanto vorresti che il tuo strumento preferito di Vulnerability Assessment abbia al suo interno un plug-in capace di valutare se gli Asset ICT siano affetti da quella specifica vulnerabilità di sicurezza?

La risposta sarà ovviamente il prima possibile.

Ma per poter scrivere un plug-in capace di ispezionare una falla di sicurezza, in modo corretto (non parlo di banner-grabbing), occorre avere accesso all’Exploit PoC, pertanto se questo non viene pubblicato, non sarà possibile implementarlo.

Lasciamo perdere il caso Microsoft, che aggiornino via. Ma per tutti gli altri software del mondo open source, la cosa si complicata e anche di parecchio.

Quindi, quale dovrebbe essere il tempo dopo giusto dopo il quale i ricercatori possano pubblicare un exploit di sfruttamento di un bug?

10 giorni?

un mese?

dopo che tutti i sistemi siano stati patchati?

Una domanda semplice che ci pone di fronte ad una difficile risposta.

Inoltre c’è anche il fattore “dark”, in quanto non divulgando la PoC, essendo tale codice conosciuto solo ad una cerchia ristretta di persone, si lascerebbe ai singoli l’agire in modo etico, pertanto quella cerchia ristretta di ricercatori potrebbero beneficiare di questo malware, sfruttandolo o rivendendolo (ad esempio) nelle community underground.

Il grande maestro Bruche Schneier, riferendosi alla full-disclosure disse:

“La full-disclosure, la pratica di rendere pubblici i dettagli delle vulnerabilità di sicurezza, è una dannata buona idea”

Ma poi aggiunse:

“l controllo pubblico è l’unico modo affidabile per migliorare la sicurezza, mentre la segretezza ci rende solo meno sicuri”.

Anche se risulta difficile rispondere a queste domande, personalmente credo che in certe situazioni come questa, che risultano a prima vista “borderline”, affidarsi all’etica e alla trasparenza abbia sempre premiato.

Massimiliano Brolli
Responsabile del RED Team e della Cyber Threat Intelligence di una grande azienda di Telecomunicazioni e dei laboratori di sicurezza informatica in ambito 4G/5G. Ha rivestito incarichi manageriali che vanno dal ICT Risk Management all’ingegneria del software alla docenza in master universitari.
Visita il sito web dell'autore