Durant els últims dies a la xarxa s'ha estat parlant força sobre la vulnerabilitat de Log4j en la qual s'han descobert diversos vectors d'atac i que a més s'han filtrat diversos exploits funcionals per poder explotar la vulnerabilitat.
La gravetat lassumpte rau que aquest és un marc popular per organitzar el registre en aplicacions Java, que permet l'execució de codi arbitrari quan s'escriu un valor amb format especial al registre en el format «{jndi: URL}». L'atac es pot fer en aplicacions Java que registren valors obtinguts de fonts externes, per exemple, en mostrar valors problemàtics en missatges d'error.
I és que un atacant realitza una sol·licitud HTTP en un sistema de destinació, que genera un registre usant Log4j 2 que utilitza JNDI per realitzar una sol·licitud al lloc controlat per l'atacant. Després, la vulnerabilitat fa que el procés explotat arribi al lloc i executi la càrrega útil. En molts atacs observats, el paràmetre que pertany a l'atacant és un sistema de registre de DNS, destinat a registrar una sol·licitud al lloc per identificar sistemes vulnerables.
Tal com ja compartio el nostre company Isaac:
Aquesta vulnerabilitat de Log4j permet explotar una validació dentrada incorrecta a LDAP, permetent execució remota de codi (RCE), i comprometent el servidor (confidencialitat, integritat de dades i disponibilitat del sistema). A més, el problema o importància d'aquesta vulnerabilitat rau en la quantitat d'aplicacions i servidors que la usen, incloent-hi programari empresarial i serveis al núvol com Apple iCloud, Steam, o videojocs tan populars com Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash, i un llarg etc.
Parlant sobre l'assumpte, fa poc l'Apache Software Foundation va donar a conèixer mitjançant una publicació un resum dels projectes que aborden una vulnerabilitat crítica a Log4j 2 que permet que s'executi codi arbitrari al servidor.
Els següents projectes d'Apache es veuen afectats: Arxiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl i Calcite Avatica. La vulnerabilitat també va afectar els productes de GitHub, inclosos GitHub.com, GitHub Enterprise Cloud i GitHub Enterprise Server.
En els darrers dies s'ha produït un augment significatiu de lactivitat relacionada amb lexplotació de la vulnerabilitat. Per exemple, Check Point va registrar al voltant de 100 intents d'explotació per minut als seus servidors ficticis a el seu punt màxim, i Sophos va anunciar el descobriment d'una nova botnet per a la mineria de criptomonedes, formada a partir de sistemes amb una vulnerabilitat sense pegat a Log4j 2.
Quant a la informació que s'ha estat donant a conèixer sobre el problema:
- La vulnerabilitat s'ha confirmat a moltes imatges oficials de Docker, incloses couchbase, elasticsearch, flink, solr, imatges de tempesta, etc.
- La vulnerabilitat és present al producte MongoDB Atlas Search.
- El problema apareix en una varietat de productes de Cisco, incloent-hi Cisco Webex Meetings Server, Cisco CX Cloud Agent, Cisco
- Advanced Web Security Reporting, Cisco Firepower Threat Defense (FTD), Cisco Identity Services Engine (ISE), Cisco CloudCenter, Cisco DNA Center, Cisco. BroadWorks, etc.
- El problema és present a l'IBM WebSphere Application Server i als següents productes de Red Hat: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse i AMQ Streams.
- Problema confirmat a Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
- Molts productes d'Oracle, vmWare, Broadcom i Amazon també es veuen afectats.
Els projectes d'Apache que no es veuen afectats per la vulnerabilitat Log4j 2: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper i CloudStack.
Es recomana als usuaris de paquets problemàtics que instal·lin urgentment les actualitzacions publicades per a ells, actualitzeu per separat la versió de Log4j 2 o establiu el paràmetre Log4j2.formatMsgNoLookups en veritable (per exemple, afegint la clau «-DLog4j2.formatMsgNoLookup=True» a l'inici ).
Per bloquejar el sistema és vulnerable al que no hi ha accés directe, es va suggerir explotar la vacuna Logout4Shell, que, a través de la comissió d'un atac, exposa l'ajust de Java log4j2.formatMsgNoLookups=true, com.sun.jndi .rmi.object. trustURLCodebase=false » i» com.sun.jndi.cosnaming.object.trustURLCodebase=false «per bloquejar més manifestacions de la vulnerabilitat en sistemes no controlats.