Le email sono ordinario veicolo di molte minacce per ognuno di noi: spam, phishing, malware. Molto spesso siamo bersaglio senza rappresentare un diretto interesse per gli agenti di minaccia. Abbiamo già visto varianti di attacchi via posta elettronica che mirano a obiettivi più specifici e noti, ma ora parliamo di una versione ancora più specializzata: la compromissione delle email commerciali, una forma che si configura in una vera e propria truffa telematica. 

Questa minaccia individua i propri obiettivi tra il personale amministrativo di aziende commerciali e finanziarie, personale che viene studiato per diverso tempo per verificarne la responsabilità e coinvolgimento dei processi di pagamento. A tal fine si utilizzano differenti tecniche di social engineering, phishing e furto di credenziali. Lo scopo ultimo è poter intervenire fraudolentemente all’interno del processo amministrativo con comunicazioni falsificate che possano dirottare capitali verso l’attaccante, unico beneficiario di questa truffa. 

Lo studio può durare molto tempo perché l’attaccante deve impossessarsi non solo delle informazioni relativamente alla possibilità di un attacco (conoscenza di relazioni commerciali, contratti, compravendite, ecc), ma anche e soprattutto ha bisogno di impossessarsi di informazioni utili alla falsificazione delle comunicazioni, quindi non solo nomi, ruoli ed indirizzi email, ma anche linguaggio, comportamenti e carattere dei personaggi che verranno falsificati, tipicamente i dirigenti che sono al vertice dei processi decisionali sui pagamenti.

CybersecurityUP è la Business Unit che eroga i servizi di Cybersecurity di Fata Informatica e tra questi il training specialistico è certamente un’eccellenza su tutto il territorio italiano.

L’offerta di formazione specialistica di CybersecurityUP non ha pari, vantando corsi che coprono le più importanti aree della Cybersecurity come la Malware Analysis, l’Analisi forense, la formazione per Soc Specialist piuttosto che per Ethical Hacker e Penetration Tester.

Il coordinatore didattico dei corsi è il Prof. Antonio Capobianco, docente di Cybersecurity Threats Analysis presso l’Università degli Studi Guglielmo Marconi, e autore del libro “La minaccia Cyber: se la conosci la eviti?”.

Tra i docenti di CybersecurityUP troviamo sia Vincenzo Alonge che Andrea Tassotti entrambi docenti nel Master di secondo livello in Cybersecurity del dipartimento di ingegneria informatica Roma3.

Con questi docenti la qualità è garantita! Ma la particolarità è che, grazie all’esperienza nella docenza maturata anche in ambiente universitario, i corsi sono stati strutturati per fornire le basi sui sistemi operativi e sulle reti per poi arrivare alle lezioni in ambito hacking.

Si parte dalle basi sino ad arrivare agli argomenti più difficili.

A partire dal 13 Febbraio 2023 entrerà a catalogo un nuovo format formativo denominato Hacker Academy.

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).