Salve! Posso darti maggiori informazioni
o rispondere a qualche domanda?
Come possiamo esserti utili?
Seleziona uno dei nostri esperti
Alberto Bedin
Supporto Commerciale
Sono online
Luisa Soranno
Supporto Commerciale
Sono online

tratto dall'articolo

Critical Log4j Vulnerability Hits Everything, Including the IBM i Server

15 dicembre 2021 Alex Woodie

Gli hacker si sono fatti un regalo di Natale anticipato quest'anno con un difetto di sicurezza critico in Log4j, un popolare framework di registrazione utilizzato in molti programmi, inclusi alcuni eseguiti su IBM i. I aziende conIBM i sono incoraggiati a prendere molto sul serio questo difetto, poiché la vulnerabilità viene già sfruttata attivamente in natura. Tuttavia, trovare dove esiste Log4j nel tuo stack non è sempre semplice, il che rende questo particolare difetto particolarmente sgradevole.

La vulnerabilità zero-day di Log4j, che è stata divulgata la scorsa settimana dai ricercatori di sicurezza con CERT New Zealand , è stata registrata nel National Vulnerability Database come CVE-2021-44228 . Ha ottenuto un punteggio perfetto 10 su 10 sulla scala di valutazione CVSS v3 (sebbene Nadia Comăneci sarà felice di sapere che ha ottenuto solo 9,3 sulla vecchia scala CVSS v2).

Il difetto, presente nelle versioni 2.0 e 2.14.1 di Log4j, offre ai criminali informatici la possibilità di eseguire codice arbitrario su tutti i sistemi interessati inviando codice dannoso alla coda di Log4j. Gli esperti di sicurezza affermano che è un difetto relativamente facile da sfruttare e che gli aggressori non hanno bisogno di essere autenticati per sfruttarlo.

Il difetto, noto anche come "LogJam" e "Log4Shell", dovrebbe essere considerato "una grave minaccia per i sistemi IBM i", 

"La pacifica API 'write to log' può essere aggirata per eseguire i comandi", 
“Tutto ciò che serve è rendere [il] registro una struttura speciale di informazioni. Log4j interpreta quindi il contenuto dei messaggi, recupera i comandi dai sistemi remoti e li esegue".

Una correzione per LogJam è stata rilasciata dalla Apache Software Foundation , che supervisiona il progetto Log4j. Gli amministratori di sistema sono incoraggiati ad aggiornare i propri sistemi a Log4j-2.15.0-rc1 per mitigare il problema. Tuttavia, la libreria basata su Java può essere incorporata in altre applicazioni, il che complica il problema per gli amministratori.

È stato scoperto un difetto critico nel framework Log4j.

"Le aziende con IBM i dovrebbero essere preoccupati poiché c'è molto Java utilizzato dalle applicazioni dei fornitori", scrive Tony Perera, CEO dello sviluppatore di software di sicurezza IBM i Trinity Guard . "Fortunatamente, non usiamo Java, quindi i prodotti Trinity Guard non sono vulnerabili a questo attacco.".

HelpSystems sta attualmente analizzando il suo software per vedere se ci sono vulnerabilità, afferma Robin Tatam, un esperto di sicurezza di IBM i con l'azienda. "Non tutti questi aziende con[IBM i] sono interessati, ma valutare attivamente il rischio è sempre l'approccio migliore ed è fondamentale se si sa che le applicazioni Java sono in esecuzione", dice a IT Jungle . "Le persone possono quindi determinare se è possibile eseguire l'aggiornamento a una versione successiva di Log4J e disabilitare la funzionalità di ricerca di Log4J."

Jesse Gorzinski, IBM s’architetto di business per l'open source per IBM i e il suo uomo di punta per Java, ha detto IBM i aziende condi concentrarsi sulle proprie applicazioni basate su Java e la loro Dependencies-‘in particolare tutto ciò che le entità esterne possono alimentare dati,’ ha twittato : “Purtroppo la risoluzione non è facile. Se stai eseguendo app Java di terze parti, chiedi al fornitore una patch".

IBM è un grande negozio Java e utilizza il linguaggio di programmazione in tutti i suoi prodotti. IBM WebSphere e il server Web Tomcat sono entrambi basati su Java e sono vulnerabili agli attacchi LogJam. Lunedì, IBM ha emesso un bollettino sulla sicurezza per WebSphere Application Server 8.5 e 9.0 in esecuzione su tutte le piattaforme supportate, incluso IBM i. (Il server HTTP per IBM i, quello sviluppato da Apache, è scritto in C e non è interessato.)

"IBM sta continuando un'analisi prodotto per prodotto per gli impatti di Log4j", ha scritto la società nel suo post sul blog PSIRT il 12 dicembre. "Se un prodotto IBM Software o Systems è interessato, verrà pubblicato un bollettino su questo blog come la riparazione o la correzione diventa disponibile.”

Il rischio rappresentato da LogJam è così grande che Scott Forstie, il business architect IBM i per il database Db2, ha creato rapidamente una query SQL per aiutare i aziende con IBM i a trovare dove Log4j può essere incorporato nei loro stack software IBM i. La query trova automaticamente gli oggetti nell'IFS che hanno la stringa "log4j" nel nome. Ha condiviso i dettagli sulla sua pagina GitHub .

Rimediare al difetto Log4j richiederà molto di questo.

I membri della comunità IBM i hanno anche condiviso suggerimenti su come risolvere i problemi di Log4j nei forum di discussione, inclusi Ryver e MIDRANGE -L . Molti utenti hanno condiviso piccoli script che hanno creato per aiutare a scovare il codice Log4j. Sebbene la ricerca di file .JAR sia un buon inizio, gli esperti raccomandano agli utenti di esaminare anche i file .EAR e .WAR per la libreria Log4j, poiché gli sviluppatori a volte possono riconfezionare il codice Java in altre librerie.

Note e Domino generalmente non sono interessati. Ma secondo questo post sul blog di HCL Software (che ora sviluppa e mantiene il software), esiste un'estensione opzionale per Notes-Domino che è interessata dal difetto. Indubbiamente, il numero di applicazioni suscettibili al difetto di LogJam crescerà nelle settimane e nei mesi a venire.

Il difetto viene attivamente sfruttato ora. Da quando la falla è stata segnalata per la prima volta venerdì 10 dicembre, il numero di attacchi che sfruttano la falla ha superato gli 800.000, ha scritto Check Point Software Technologies in un post sul blog .

"Da quando abbiamo iniziato a implementare la nostra protezione, abbiamo impedito oltre 1.272.000 tentativi di allocare la vulnerabilità, oltre il 46% di questi tentativi è stato effettuato da noti gruppi malintenzionati", ha scritto nel suo blog il produttore di firewall e dispositivi di sicurezza di rete. "Si tratta chiaramente di una delle vulnerabilità più gravi su Internet negli ultimi anni e il potenziale di danni è incalcolabile".

Check Point Research ha documentato più di 60 varianti dell'attacco Log4j in meno di 24 ore dalla sua prima divulgazione.

Il difetto di Log4j è il "Momento Fukushima" della sicurezza informatica, ha dichiarato l'esperto di sicurezza Renaud Deraison in un post sul blog di Tenable il 13 dicembre. Proprio come gli impatti dello tsunami del 2011 e della fusione nucleare parziale continuano a farsi sentire oggi nella prefettura giapponese, così anche gli impatti di LogJam sulla più ampia comunità IT.

"Stiamo scoprendo nuove app ogni minuto che utilizzano Log4j in un modo o nell'altro", ha scritto Deraison. “Influisce non solo sul codice che crei, ma anche sui sistemi di terze parti che hai in atto. Tutto, dalla nuova stampante che hai acquistato per l'ufficio al sistema di ticketing che hai appena distribuito, è potenzialmente interessato da questo difetto. Alcuni sistemi interessati potrebbero essere on-premise, altri potrebbero essere ospitati nel cloud, ma non importa dove si trovino, è probabile che il difetto abbia un impatto".

Nello specifico, Deraison ha citato due variabili che potrebbero potenziare l'impatto di LogJam ed estenderne l'impatto nel futuro: il modo in cui le organizzazioni generano e archiviano enormi quantità di dati di registro e la dipendenza da software open source per creare applicazioni.

"Il difetto di Apache Log4j getta una luce brillante sulla pratica rischiosa di affidarsi a librerie di codice open source per creare applicazioni su scala aziendale", ha scritto. "Questa dipendenza da quello che è effettivamente un selvaggio west di librerie di codici continuerà a lasciare le organizzazioni vulnerabili finché non investiranno il tempo e le risorse necessarie per renderle più sicure".

Oltre ai difetti di LogJam, questa settimana IBM ha anche corretto cinque difetti che incidono sui componenti open source utilizzati in Rational Developer for IBM i (RDi). Le patch, che variano in gravità da 6.7 a 8.2, derivano da vulnerabilità scoperte di recente in OpenSSL e Node.js. Puoi