Il vostro IBM i è vulnerabile agli attacchi informatici di Log4j?

Log4Shell presenta la vulnerabilità più grave

Il software viene utilizzato per registrare tutti i tipi di attività che si svolgono sotto il cofano di un’ampia gamma di sistemi informatici, tra cui l’IBM i.

Jen Easterly, direttore della U.S. Cybersecurity & Infrastructure Security Agency, ha descritto Log4Shell come la vulnerabilità più grave È anche uno dei migliori colleghi di sicurezza che abbiamo visto nella sua carriera, Bruce F. Bading. Ci sono già stati centinaia di migliaia, forse milioni, di tentativi di sfruttare la vulnerabilità.

Cosa fa Log4j?

Log4j registra gli eventi – errori e operazioni di routine del sistema – e comunica messaggi diagnostici su di essi agli amministratori e agli utenti del sistema. Si tratta di un software open source fornito da Apache Software Foundation.

Come funziona Log4Shell?

Log4Shell funziona abusando di una caratteristica di Log4j che consente agli utenti di specificare un codice personalizzato per formattare un messaggio di log. Questa funzione consente a Log4j, ad esempio, di registrare non solo il nome utente associato a ogni tentativo di connessione al server, ma anche il nome reale della persona, se un server separato contiene una directory che collega nomi utente e nomi reali. Per fare ciò, il server Log4j deve comunicare con il server che detiene i nomi reali.

Log4j apre le porte agli “hacker” e alle falle di sicurezza

Purtroppo, questo tipo di codice può essere utilizzato non solo per la formattazione dei messaggi di log. Le versioni vulnerabili di Log4j consentono ai server di terze parti di inviare codice software in grado di eseguire ogni sorta di azione sul computer preso di mira. Questo apre la porta ad attività nefaste come il furto di informazioni sensibili, il controllo completo del sistema preso di mira e il trasferimento di contenuti dannosi ad altri utenti che comunicano con il server interessato.

Log4Shell è facile da usare

Log4Shell è relativamente facile da usare. Sono riuscito a riprodurre il problema nella mia copia di Ghidra, un framework di reverse-engineering per ricercatori di sicurezza, in pochi minuti. La soglia per l’utilizzo di questo exploit è molto bassa, il che significa che un numero maggiore di persone con intenti malevoli può utilizzarlo.

Log4j è ovunque, anche su IBM i

Una delle preoccupazioni principali di Log4Shell è la posizione di Log4j nell’ecosistema software. La registrazione è una funzione fondamentale della maggior parte dei software, che permette di Log4j è molto diffuso. Viene utilizzato in IBM WebSphere (WAS), IBM i Navigator, Apache HTTP, nel software IBM i HA, nei servizi cloud come Apple iCloud e Amazon Web Services, nonché in un’ampia gamma di programmi di strumenti di sviluppo software a strumenti di sicurezza e qualsiasi versione di IBM i Client Solutions precedente a 1.8.8.7.

Ciò significa che gli hacker hanno un’ampia gamma di obiettivi tra cui scegliere: utenti IBM i, fornitori di servizi, sviluppatori di codice sorgente e persino ricercatori di sicurezza. Così, mentre le grandi aziende come IBM e Amazon sono in grado di patchare rapidamente i loro servizi web per impedire agli hacker di sfruttarli, molte altre organizzazioni impiegheranno più tempo per patchare i loro sistemi, e alcune potrebbero non sapere nemmeno di averne bisogno.

I danni che possono essere causati

Gli hacker setacciano Internet alla ricerca di server vulnerabili e configurano macchine in grado di fornire payload dannosi. Per effettuare un attacco, interrogano i servizi (ad esempio i server Web) e cercano di attivare un messaggio di log (ad esempio un errore 404). La richiesta include un testo costruito in modo malevolo, che Log4j tratta come istruzioni.

Queste istruzioni possono creare un reverse shell, che consente al server attaccante di controllare da remoto il server preso di mira, oppure possono integrare il server preso di mira in un sistema di botnet. Le reti bot utilizzano diversi computer violati per eseguire azioni coordinate per conto degli hacker.

Gli hacker stanno già abusando di Log4Shell… e in modi nuovi. Ahi!

A un gran numero di pirati stanno già cercando di abusare di Log4Shell. Queste vanno da bande di ransomware a gruppi di hacker che cercano di estrarre bitcoin e gli hacker associati al Cina e Corea del Nord cercando di accedere alle informazioni sensibili dei loro rivali geopolitici. Il Ministero della Difesa belga ha riferito che i suoi computer sono stati attaccato utilizzando Log4Shell.

Sebbene la vulnerabilità sia stata oggetto di attenzione per la prima volta il 9 dicembre 2021, le persone continuano a identificare nuovi modi per causare danni attraverso questo meccanismo.

Come si arresta l’emorragia di Log4j?

È difficile sapere se Log4j viene utilizzato in un determinato sistema software, poiché spesso è integrato con altri software. Questo costringe gli amministratori di sistema a inventariare il software per identificarne la presenza. Se alcune persone non sanno nemmeno di avere un problema, è molto più difficile sradicare la vulnerabilità e non ci si può difendere da ciò che non si conosce.

Un’altra conseguenza dei vari usi di Log4j è che non esiste un’unica soluzione per correggerla. A seconda di come Log4j è stato integrato in un determinato sistema, la patch richiederà approcci diversi. Ciò potrebbe richiedere un aggiornamento generale dei sistemi, come nel caso di alcuni router Cisco, o un aggiornamento a una nuova versione del software, o la rimozione manuale del codice vulnerabile per coloro che non sono in grado di aggiornare il software.

Log4Shell fa parte della catena di fornitura del software. Come gli oggetti fisici che si acquistano, il software passa attraverso diverse organizzazioni e pacchetti prima di arrivare al prodotto finale. Quando qualcosa va storto, invece di passare attraverso un processo di callback, il software è solitamente “ patchato “In altre parole, corretto sul posto.

Le patch di Log4Shell potrebbero subire un ritardo

Tuttavia, poiché Log4j è presenti in modi diversi nei prodotti software, la propagazione di una patch richiede il coordinamento degli sviluppatori di Log4j, degli sviluppatori di software che utilizzano Log4j, dei distributori di software, degli operatori di sistema e degli utenti. Di solito, questo introduce un ritardo tra la disponibilità della patch nel codice Log4j e i computer degli utenti che chiudono la porta alla vulnerabilità.

Le stime dei tempi di riparazione del software variano generalmente da da poche settimane a diversi mesi. Tuttavia, se il comportamento passato è indicativo delle prestazioni future, è probabile che il Log4j emergerà negli anni a venire.

In qualità di utenti, vi starete chiedendo cosa potete fare in tutto questo. Purtroppo è difficile sapere se un prodotto software in uso include Log4j e se utilizza versioni vulnerabili del software.

Cosa fare ORA per proteggersi dalle vulnerabilità di Log4Shell

Tuttavia, potete aiutarci ascoltando il ritornello comune degli esperti di sicurezza informatica:

• Assicuratevi che tutti i vostri software siano aggiornati.
• Contattare i fornitori di terze parti per gli aggiornamenti.
• Rimuovete o disabilitate le versioni vulnerabili il prima possibile.

Questo è particolarmente importante se si utilizza una versione precedente o di fine supporto (EOS) di IBM i (prima di V7.3 o V7.4).

Le analisi di ogni sistema IBM i, compresi i sistemi operativi più vecchi e non supportati, trovano decine di file log4j vulnerabili nell’IFS. Nessun sistema è immune e più è vecchio, più è vulnerabile.

Sebbene i primi attacchi contro le versioni vulnerabili di log4j si siano concentrati sui server LDAP remoti, a metà dicembre l’attenzione si è spostata sulla Java Virtual Machine (JVM) Remote Method Invocation (RMI).

Ciò significa che qualsiasi server, compreso IBM i che esegue JVM RMI, è vulnerabile a un attacco catastrofico.

Questo diagramma mostra come è stato condotto l’attacco.

 

Qualsiasi versione di log4j precedente alla 2.17.1 è vulnerabile.

Il Center of Internet Security offre le informazioni più aggiornate disponibili. Il miglior consiglio che possiamo darvi è quello di fare attenzione a dove ottenete le vostre informazioni, perché questo può rendervi vulnerabili agli attacchi.

La cosa migliore da fare è eseguire la scansione ora, prima che sia troppo tardi.

Risposta alla vulnerabilità zero-day di Log4j (cisecurity.org) – Articolo originale di Bob Losey: https: //cutt.ly/DPAcTSM

Avete domande o progetti riguardanti la vulnerabilità di log4j? I nostri team sono al vostro servizio. Contattateci al numero 01 88 32 12 34 o tramite il modulo di contatto.