Siamo a fine anno e iniziano le speculazioni su quali saranno gli attacchi più comuni nel prossimo anno o comunque quali i vettori e le tecniche che vedremo crescere di più. Partendo dalla base che tutti gli attacchi che abbiamo visto finora continueranno a esser portati anche nell’anno prossimo, costringendoci a non tralasciare nulla di quanto abbiamo già preparato in passato, CrowdStrike punta i riflettori su alcune tecniche che sembrano essere particolarmente comuni nelle discussioni nei forum del darkweb e che quindi potrebbero vedere un consistente incremento nell’utilizzo durante il 2023.
Al primo posto, l’azienda americana vede come vettore di accesso primario gli attacchi basati sulle identità informatiche. Attenzione, però, non stiamo parlando solo di phishing o BD di credenziali rubate acquistabili sul darkweb, ma di attacchi che sono in grado in molti casi di aggirare anche le autenticazioni a due fattori. Si parla di pass-the-cookie, golden-SAML e tecnica di ingegneria sociale che sfruttano la MFA fatigue che andranno a diventare sempre più comuni. Il pass the cookie, per esempio, bypassa la MFA grazie al furto di cookie appartenenti a un browser già “legalmente” autorizzato dal sistema di MFA a navigare sul servizio attaccato. Ci sono varie contromisure applicabili, ma bisogna pensarci. Il Golden-SAML è ancora più complesso da evitare e implica la compromissione di un IdP (identity provider) o la creazione e successiva autorizzazione di un IdP all’interno di un circuito protetto. Infine, la MFA Fatigue è una tecnica di ingegneria sociale per cui si inonda un utente di richieste di autorizzazione provenienti dal legittimo sistema di MFA finché quest’ultimo non inizia a pensare che si tratti di un malfunzionamento e accetti una di queste richieste pur di far terminare il flusso. Di queste, sicuramente la più complessa da bloccare è il golden-SAML, che è anche il più complesso da portare a termine, ma per mettere in atto le contromisure bisogna riconoscerle come priorità. Ed è venuto il momento.
Un altro trend che vedrà una rapida crescita, che in realtà era già stato messo sotto i riflettori alla fine dello scorso anno, è quello degli attacchi alle API. Tutti i servizi cloud sono sempre più progettati per essere interconnessi e semplici da usare, ma come sappiamo la semplicità è spesso nemica della sicurezza. In particolare, i sistemi tendono a rispondere con troppa facilità alle richieste generiche dall’esterno, anche quando non sono autenticate, fornendo tutte le informazioni necessarie per impostare attacchi automatici: dal nome del servizio disponibile su quella determinata porta alla sua versione, passando per le caratteristiche del server che lo ospita. Mettete un bavaglio ai servizi chiacchieroni ed eliminate tutte le facilitazioni alle connessioni: chi dovrà connettersi sicuramente avrà a disposizione una knowledge base alla quale far riferimento, mentre chi non ce l’ha è bene che stia fuori e spenda tempo e denaro per fare le sue operazioni di scouting (che magari possono venir riconosciute come tali e sollevare un warning quando necessario).
Infine, dedichiamo due parole al panico che ormai è generato “automaticamente” nei reparti IT dalla pubblicazione dei Zero-Day Tuesday, ovvero da quella serie di attacchi che seguono sistematicamente alla pubblicazione di una patch per uno zero day. I criminali sono dannatamente attenti a tutti questi eventi e al rilascio di notizie su vulnerabilità potenzialmente sfruttabili. Sono in continuo ascolto su tutti i canali e appena viene rilasciata una patch o annunciata una vulnerabilità in un servizio (anche senza grandi dettagli), iniziano a lavorare per capire come sfruttarla e iniziare delle campagna prima che le patch vengano applicate. Questa metodologia è in netta crescita e l’unica possibilità per evitare guai è quella di applicare le patch appena queste vengono rilasciate e poi monitorare la rete per attacchi che possano sembrare metodi di aggiramento delle correzioni applicate dalla patch. Non sapete quante volte sia già successo quest’anno che una patch che doveva mettere al sicuro un sistema abbia in realtà tappato solo un aspetto della vulnerabilità lasciandone aperti altri.
