Negli ultimi giorni in rete si è parlato molto della vulnerabilità di Log4j in cui sono stati scoperti vari vettori di attacco e sono stati anche filtrati vari exploit funzionali per sfruttare la vulnerabilità.
La serietà della questione è che questo è un framework popolare per organizzare il registro nelle applicazioni Java., che consente l'esecuzione di codice arbitrario quando un valore formattato in modo speciale viene scritto nel registro nel formato "{jndi: URL}". L'attacco può essere effettuato su applicazioni Java che registrano valori ottenuti da fonti esterne, ad esempio visualizzando valori problematici nei messaggi di errore.
Ed è che un utente malintenzionato effettua una richiesta HTTP su un sistema di destinazione, che genera un registro utilizzando Log4j 2 Che utilizza JNDI per effettuare una richiesta al sito controllato dall'attaccante. La vulnerabilità fa sì che il processo sfruttato arrivi al sito ed esegua il payload. In molti attacchi osservati, il parametro che appartiene all'attaccante è un sistema di registrazione DNS, destinato a registrare una richiesta sul sito per identificare i sistemi vulnerabili.
Come ha già condiviso il nostro collega Isaac:
Questa vulnerabilità di Log4j permette di sfruttare una validazione di input errata a LDAP, permettendo esecuzione di codice remoto (RCE) e compromettere il server (riservatezza, integrità dei dati e disponibilità del sistema). Inoltre, il problema o l'importanza di questa vulnerabilità risiede nel numero di applicazioni e server che la utilizzano, inclusi software aziendali e servizi cloud come Apple iCloud, Steam o videogiochi popolari come Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash e un lungo ecc.
Intervenendo sulla questione, di recente rilasciata la Apache Software Foundation attraverso un post un riepilogo dei progetti che affrontano una vulnerabilità critica in Log4j 2 che consente l'esecuzione di codice arbitrario sul server.
Sono interessati i seguenti progetti Apache: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl e Calcite Avatica. La vulnerabilità ha interessato anche i prodotti GitHub, inclusi GitHub.com, GitHub Enterprise Cloud e GitHub Enterprise Server.
Negli ultimi giorni c'è stato un aumento significativo dell'attività connessa allo sfruttamento della vulnerabilità. Per esempio, Check Point ha registrato circa 100 tentativi di exploit al minuto sui suoi server fittizi in il suo picco e Sophos ha annunciato la scoperta di una nuova botnet di mining di criptovaluta, formata da sistemi con una vulnerabilità senza patch in Log4j 2.
Per quanto riguarda le informazioni che sono state rilasciate sul problema:
- La vulnerabilità è stata confermata in molte immagini ufficiali di Docker, tra cui couchbase, elasticsearch, flink, solr, storm images, ecc.
- La vulnerabilità è presente nel prodotto MongoDB Atlas Search.
- Il problema si verifica in una varietà di prodotti Cisco, tra cui Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Report avanzati sulla sicurezza Web, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, ecc.
- Il problema è presente in IBM WebSphere Application Server e nei seguenti prodotti Red Hat: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse e AMQ Streams.
- Problema confermato in Junos Space Network Management Platform, Northstar Controller/Planner, Paragon Insights/Pathfinder/Planner.
- Sono interessati anche molti prodotti Oracle, vmWare, Broadcom e Amazon.
Progetti Apache che non sono interessati dalla vulnerabilità Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper e CloudStack.
Si consiglia agli utenti di pacchetti problematici di installare urgentemente gli aggiornamenti rilasciati per loro, aggiornare separatamente la versione di Log4j 2 o impostare il parametro Log4j2.formatMsgNoLookups su true (ad esempio, aggiungendo la chiave "-DLog4j2.formatMsgNoLookup = True" all'avvio).
Per bloccare il sistema vulnerabile a cui non c'è accesso diretto, è stato suggerito di sfruttare il vaccino Logout4Shell, che, attraverso la commissione di un attacco, espone l'impostazione Java "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.oggetto. trustURLCodebase = false "e" com.sun.jndi.cosnaming.object.trustURLCodebase = false "per bloccare ulteriori manifestazioni della vulnerabilità su sistemi non controllati.