La crescita di un Ethical Hacker non può avvenire esclusivamente all’interno di una scuola; l’Ethical Hacker ha bisogno di una palestra in cui potersi allenare quotidianamente. Per quanto si possa eseguire esercitazioni nel periodo di apprendimento, senza una palestra continuamente a disposizione è impossibile costruire una esperienza pratica quale è necessario possedere durante l’attività in campo aperto. 

È per questo motivo che CybersecurityUp ha creato HackMeUp, il nuovo cyberrange per accompagnare l’Ethical Hacker in quella crescita continua che deve. 

La piattaforma verrà resa disponibile a tutti gli allievi iscritti al corso Certified Professional Ethical Hacker edizione Extreme: tramite HackMeUp i neo Ethical Hacker potranno continuare a mettere alla prova se stessi per un intero anno dalla fine del corso, accompagnati nella loro crescita professionale fino alla piena consapevolezza delle proprie capacità. 

La piattaforma è definita di gioco, ma non si scherza! La piattaforma non abbandona la vocazione di mettere alla prova le conoscenze acquisite, né rinuncia a porre nuove e più dure sfide, in quel processo di crescita continuativa che è l’esercizio quotidiano. 

Nelle ultime due settimane Google è dovuta correre urgentemente ai ripari per due distinte e nuove vulnerabilità 0-day di Chrome (in realtà sono vulnerabilità presenti nel sorgente chromium). 

La prima vulnerabilità (pubblicata il 28 novembre sul National Vulnerability Database del NIST) è stata censita come CVE-2022-4135 con CVSS 9.6. Si tratta di una violazione dei limiti in scrittura della memoria del processo (CWE-787 – “Out-of-bounds Write”), comunemente nota come “buffer overflow dell’heap” nella componente GPU di Chrome. 

Questa vulnerabilità consentirebbe ad un malintenzionato, che abbia compromesso il processo di rendering, di eseguire una evasione dalla sandbox tramite una pagina HTML appositamente creata. 

Le conseguenze di un buffer overflow sono tipicamente l’arresto anomalo del software, ma anche la possibilità di porre il programma in un ciclo infinito: in ogni caso si raggiunge l’obiettivo di negazione del servizio (DoS), in questo caso negazione nell’uso del browser. Non è escluso che da un buffer overflow possano innescarsi meccanismi di esecuzione di codice arbitrario o evasione dai meccanismi di protezione esistenti, come nel caso descritto. 

La presenza in un sistema di molteplici vulnerabilità consente agli aggressori di combinare le differenti proprietà dei difetti insite in esse, in una amplificazione delle capacità offensive: si dice concatenare le vulnerabilità 

È quanto è stato scoperto nel sistema Cisco Identity Services Engine, il servizio di identità su cui è possibile basare un sistema di controllo dell’accesso alla rete (NAC) con cui è possibile controllare l’accesso degli endpoint alla rete e gestire gli stessi dispositivi di rete. 

Colpire questo servizio è colpire al cuore la sicurezza di una rete. 

Sono state rinvenute ben 4 vulnerabilità di differente gravità, anche con possibilità di concatenazione (con una quinta già nota) per rafforzarne la potenza detonante, in particolare l’esecuzione di comandi arbitrari, l’aggirare protezioni di sicurezza ed eseguire attacchi XSS (cross-site scripting). 

Ma andiamo con ordine. 

Non è la prima volta che ne parliamo, non è la prima volta che accade: le vulnerabilità di sicurezza non invecchiano mai, ovvero l’opportunità di sfruttamento sembrano non finire mai, e non stupisce dunque che i ricercatori abbiano per una volta ancora segnalato l’allarme di sfruttamento di vulnerabilità molto vecchie. 

Questa volta si tratta di vulnerabilità relative ad un server Web non più sviluppato dal lontano 2005 e pertanto parliamo di vulnerabilità “forever day”. Queste vulnerabilità sono un cavallo di battaglia noto nel panorama, in quanto si tratta vulnerabilità appartenenti ad un software sì abbandonato, ma impiantato in differenti dispositivi IoT che lo portano ancora a bordo, procurandosi in questo modo un alto rischio. 

Gruppi hacking cinesi (sponsorizzati dallo Stato: si parla di RedEcho) hanno condotto differenti campagne già in passato (con differenti vettori di attacco), e ora le ripetono, contro operatori del settore energetico indiano e anche altre organizzazioni strategiche, proprio a partire da questa debolezza nel mondo dei dispositivi IoT. Microsoft segnala lo sfruttamento delle vulnerabilità proprio di quel server Web Boa che dicevamo interrotto nel 2005: questo è componente IoT per l’accesso alla console di gestione dei dispositivi e le sue vulnerabilità aumentano in modo significativo il rischio per questi sistemi quando esposti su Internet. 

Con l’aggiornamento 12.4 per sistema macOS Monterey di maggio (https://support.apple.com/en-us/HT213257), Apple ha messo al sicuro i suoi sistemi da un importante difetto di sicurezza già noto un anno fa e sanato solo con tale aggiornamento. 

Il tempo ora è sufficientemente maturo, se, come auspicabile, tutti gli utenti Apple hanno disposto l’aggiornamento dei loro sistemi, perché si parli pubblicamente del difetto e soprattutto del meccanismo di sfruttamento che ne è alla base, arrivando alla pubblicazione di un PoC del codice di prova per lo sfruttamento. 

Stiamo parlando della vulnerabilità CVE-2022-26696 dell’applicazione Terminal.app, un difetto grave (CVSS 7.8) che consente di aggirare il sistema di sandbox imposto alle applicazioni dal sistema operativo macOS. Apple accredita rispetto alla vulnerabilità i ricercatori Ron Waisberg (già scopritore della vulnerabilità CVE-2021-30677 sul superamento del sandboxing via LaunchServices) e Wojciech Reguła: ed è proprio quest’ultimo a pubblicare dettagli importanti sulla questione, non risparmiando un po’ di polemica sul ritardo. 

Un problema al sandbox era stato già visto e segnalato da Regola infatti nel lontano 2020, problema che forniva la possibilità da parte di una applicazione in sandbox di avviare una applicazione priva dell’eredità

Operazioni e sicurezza sono da sempre antagonisti. Richiedere maggiore sicurezza implica sempre un qualche costo nelle operazioni. A questa legge non scritta non si sfugge. 

Nell’aggiornamento di novembre, Microsoft ha fatto una scelta che molte altre realtà che maneggiano algoritmi di sicurezza hanno fatto o faranno: abbandonare algoritmi vulnerabili sacrificando la compatibilità con infrastrutture e configurazioni non più compatibili per la più elevata base di riferimento scelta. Certamente è una operazione che probabilmente viene mal digerita da una comunità di utenti abituata alla garanzia di compatibilità a ritroso nel tempo, anche decennale, da parte dei software Microsoft; ma il panorama delle minacce impone pur qualche sacrificio. 

Per risolvere il bypass della sicurezza e la vulnerabilità derivante dall'elevazione di privilegio presente nelle autenticazioni che utilizzino la negoziazione RC4-HMAC (CVE-2022-37966) del DES (Data Encryption Standard), Microsoft si è

Anche questo mese Microsoft ha lavorato pesantemente per correggere i problemi in tutti i suoi territori, da Azure alle soluzioni on-premise: si contano quasi 40 differenti campi di azioni su cui si è visto l’intervento della casa di Redmond. 

Il risultato è il rilascio di correzioni per problemi di sicurezza (oltre alla correzione di errori funzionali) per ben 62 CVE includenti anche vulnerabilità 0-day già viste sfruttate in natura. 

Di queste CVE, ben 9 risultano di livello critico (per il 14.5%) e 53 di livello alto (per l’85.5%). 

In particolare le tecniche maggiormente sfruttabili per via delle vulnerabilità individuate sono l’Elevazione del privilegio (EoP – Elevation of Privilege) per il 41.9% del totale, seguita dall’Esecuzione di codice Remoto (RCE – Remote Code Execution) per il 24.2% del totale. Non potevano mancare, anche se in misura nettamente minore, tecniche si Denial of Service (DoS – per il 6% del totale), Spoofing (per il 3% del totale) ed evasione di meccanismi si sicurezza (Security Features Bypass, per il 4% del totale). 

Con questa patch dobbiamo finalmente sottolineare l’attenzione e risoluzione a problemi di sicurezza mancanti nella patch del mese precedente, ossia la correzione per le CVE-2022-41040 e CVE-2022-41082 (ProxyNotShell) di cui avevamo già parlato. 

Una settimana prima dal rilascio della nuova versione 3.0.7 del progetto OpenSSL (pubblicata il 1° novembre), il team aveva preavvisato dell’arrivo di una correzione ad una vulnerabilità critica. Al dunque si è scoperto che esistono correttivi “soltanto” per due vulnerabilità di gravità alta: la CVE-2022-3786 (“X.509 Email Address Variable Length Buffer Overflow”) e la CVE-2022-3602 (“X.509 Email Address 4-byte Buffer Overflow”), entrambe capaci di rendere possibile un attacco BOF (Buffer Overflow) ed il conseguente DoS (Denial of Service). Le vulnerabilità affliggono tutte le versioni di OpenSSL dalla versione 3.0 in avanti, quindi tutte le versioni in giro da almeno settembre del 2021. Allo stato non si hanno notizie di PoC o avvistamenti in natura di attacchi rispetto a queste vulnerabilità, pertanto è difficile capire le motivazioni per una comunicazione così allarmistica prima di un naturale rilascio di un insieme di correttivi ad un software. La spiegazione la fornisce direttamente il progetto OpenSSL che indica la CVE-2022-3602 responsabile della valutazione allarmistica iniziale: questa infatti è una vulnerabilità che causa un overflow arbitrario del buffer dello stack di 4 byte e inizialmente sembrava poter portare all'esecuzione di codice da remoto (RCE).

Una grave vulnerabilità affligge i sistemi del vendor di sicurezza: è stata Già sfruttata in natura e quindi ben studiata, tanto che sono già liberamente disponibili vettori di attacco che vanno oltre il PoC. Ciò pone l’accento sull’urgenza si porre rimedio a tale vulnerabilità, la CVE-2022-40684, che consente di aggirare il sistema di autenticazione dell’interfaccia amministrativa Web nei dispositivi che eseguano FortiOS, FortiProxy e FortiSwitchManager. Tale procedura di infrazione consente all’attaccante di ottenere l’accesso come amministratore sui sistemi colpiti. In particolare le versioni colpite sono: per i prodotti FortiOS, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.2.0, 7.2.1; per i prodotti FortiProxy, 7.0.0, 7.0.1, 7.0.2, 7.0.3, 7.0.4, 7.0.5, 7.0.6, 7.2.0; per i prodotti FortiSwitchManager, 7.0.0 e 7.2.0. Consentendo l’accesso amministrativo, tale vulnerabilità porta all’attaccante la facoltà di creare nuovi utenti nel sistema compromesso, ruotare il traffico verso destinazioni a lui gradite, catturare il traffico di rete e dunque ottenere dati sensibili, scaricare l’intera configurazione del sistema (per studiarla in seguito).

Una nuova vulnerabilità è emersa nel software sviluppato dalla fondazione; anche in questo caso la violazione è di tipo RCE ed è stata per questo battezzata in modo simile alla precedente (log4shell) con riferimento alla libreria ora responsabile del trasporto di tale problema: dunque text4shell in riferimento al pacchetto Apache Commons Text. 

La vulnerabilità è critica, con un punteggio CVSS 9.8, ed è stata classificata come CVE-2022-42889. Si riferisce a versioni dei pacchetti di Apache Commons Text dalla versione 1.5 alla versione 1.9. 

Il difetto consente ad un attore di minaccia di sfruttare il processo di espansione dinamica delle proprietà di cui Apache Commons Text è capace per innescare l’esecuzione di codice non previsto o il contatto con server remoti (al minimo) non attendibili (per non dire di peggio). 

Ancora una volta dunque (come fu per Log4J con Log4Shell) colpevoli della debolezza software riscontrata sono la capacità di espansione dinamica dei parametri. Con espressioni come “${prefix:name}”, dove prefix indica l’istanza capace di eseguire la sostituzione dinamica, anche pacchetto Apache Commons Text consente così di ottenere differenti manipolazioni dinamiche del testo.