Chiunque abbia accesso a un endpoint con una versione software vulnerabile può eseguire comandi arbitrari mediante una richiesta HTTP senza bisogno di un header di autorizzazione. La risposta attesa a questa richiesta sarebbe un errore 401 “Unauthorized”. L’utente può tuttavia eseguire dei comandi senza privilegi “root”. Queste minacce sono state osservate nel 2017 durante l’attacco Equifax.
Due minacce recentemente scoperte sono l’ultima evoluzione di questo genere di attacchi: la vulnerabilità di tipo Injection Atlassian Confluence OGNL e una vulnerabilità dell’Azure Open Management Infrastructure (OMI). I ricercatori di Barracuda hanno analizzato gli attacchi tentando di sfruttare queste vulnerabilità per un periodo di 45 giorni tra agosto e settembre, scoprendo picchi di attacchi provenienti da più di 500 indirizzi IP unici.
Di seguito, un’analisi delle vulnerabilità, dei recenti schemi di attacco e delle soluzioni utilizzabili per proteggersi.
La minaccia
Vulnerabilità RCE (remote code execution) – RCE è il termine usato per descrivere l’esecuzione di codice arbitrario su un sistema informatico, in cui l’attore non ha accesso diretto alla console. È come se chi ha lanciato l’attacco si trovasse fisicamente di fronte al sistema e ne assumesse il controllo.
I dettagli
L’injection Atlassian Confluence OGNL è stata pubblicata per la prima volta da Atlassian il 25 agosto scorso e poco dopo è stata aggiunta al National Vulnerability Database (CVE-2021-26084). Questa vulnerabilità permette agli attori della minaccia di lanciare una richiesta “POST” usando il template engine Confluence, senza un header di autorizzazione. Ciò consente all’attore un accesso “root” al sistema. Usando i parametri “queryString” e “linkCreation”, l’hacker può iniettare codice Java.
Atlassian ha annunciato che “tutte le versioni dei server e data center Confluence presentavano, prima del rilascio della patch, questa vulnerabilità”.
Analizzando i dati raccolti tra agosto e la fine di settembre, i ricercatori di Barracuda hanno scoperto che gli attacchi contro la vulnerabilità Confluence iniziavano a diffondersi continuando a mantenersi elevati dato che molti utenti continuano ad avere una versione vulnerabile del software.
Azure ha rilasciato CVE-2021-38647 il 15 settembre 2021. Questa vulnerabilità interessa l’Azure Open Management Infrastructure (OMI). OMI è un agente software che è installato in modo silente e utilizzato negli ambienti cloud. Questa installazione silente ha posto i clienti Azure a rischio fino all’installazione dell’ultima versione di OMI.
Gli hacker attaccano questi sistemi inviando un particolare messaggio HTTPS a una delle porte in ascolto del traffico OMI (Porte 1270/5985/5986), conquistando così un primo accesso alla macchina. I comandi inviati dall’hacker saranno eseguiti dal servizio SCXcore, consentendo all’hacker di sfruttare le vulnerabilità. Questi può quindi passare un comando alla macchina senza un header di autorizzazione, che il server OMI tratterà come fidato, dando così all’hacker un accesso “root” alla macchina.
Nel suo blog, Microsoft ha scritto: “L’ExecuteShellCommand RunAsProvider eseguirà qualunque comando UNIX/Linux usando la shell /bin/sh”.
Osservando i dati raccolti da Barracuda a partire da metà settembre, i ricercatori hanno rilevato un brusco aumento nel numero di attacchi che cercavano di sfruttare questa vulnerabilità. Dopo il picco iniziale il 18 settembre, il numero di tentati attacchi è diminuito, per poi continuare a impennare e diminuire.
Nell’analisi degli attacchi avvenuti nei 45 giorni di agosto e settembre, sono stati scoperti 550 IP unici che hanno tentato di sfruttare la vulnerabilità Atlassian Confluence e 542 che hanno tentato di sfruttare la vulnerabilità Azure OMI.
Dietro ogni IP vi erano molteplici hacker, a significare che il numero di attacchi è stato molto più alto del numero di IP: i ricercatori hanno scoperto queste informazioni usando il client fingerprinting e altre tecniche.
Come è possibile verificare nella mappa, la maggior parte degli IP si trova negli USA, probabilmente perché qui si trova gran parte delle server farm. Gli attacchi avevano origine anche in Russia, Regno Unito, Polonia e India. Ma gli hacker da tutto il mondo stanno cercando di sfruttare queste vulnerabilità e le organizzazioni dovrebbero quindi cercare di essere sempre un passo avanti per proteggere le proprie applicazioni web.
Come proteggere le applicazioni web da queste vulnerabilità
A causa del crescente numero di vulnerabilità individuate nelle applicazioni web, proteggersi da questi attacchi è sempre più difficile. Fortunatamente, sono disponibili soluzioni complete che permettono di proteggere le applicazioni web. Soluzioni WAF/WAF-as-a-Service come servizi WAAP (Web Application and API Protection) possono aiutare a proteggere le applicazioni web mettendo a disposizione tutte le più recenti soluzioni di sicurezza in un solo prodotto di facile utilizzo.
Gartner ha dichiarato: “i servizi cloud per la protezione di API e applicazioni web rappresentano l’evoluzione dei servizi cloud web application firewall”.
La necessità di una soluzione WAF-as-a-Service o WAAP non è mai stata evidente come oggi, nel momento in cui molte persone lavorano da remoto e molte applicazioni si stanno spostando online. Le organizzazioni devono disporre di una soluzione che offra sia la mitigazione sia la protezione DDoS sia la sicurezza delle API.
