During the last days on the net there has been a lot of talk about the vulnerability of Log4j in which various attack vectors have been discovered and various functional exploits have also been filtered in order to exploit the vulnerability.
The seriousness of the matter is that this is a popular framework for organizing the registry in Java applications., which allows arbitrary code to be executed when a specially formatted value is written to the registry in the format "{jndi: URL}". The attack can be carried out on Java applications that log values obtained from external sources, for example by displaying problematic values in error messages.
And is that an attacker makes an HTTP request on a target system, which generates a log using Log4j 2 Which uses JNDI to make a request to the attacker-controlled site. The vulnerability then causes the exploited process to arrive at the site and execute the payload. In many observed attacks, the parameter that belongs to the attacker is a DNS registration system, intended to register a request on the site to identify vulnerable systems.
As our colleague Isaac already shared:
This vulnerability of Log4j allows to exploit an incorrect input validation to LDAP, allowing remote code execution (RCE), and compromising the server (confidentiality, data integrity and system availability). In addition, the problem or importance of this vulnerability lies in the number of applications and servers that use it, including business software and cloud services such as Apple iCloud, Steam, or popular video games such as Minecraft: Java Edition, Twitter, Cloudflare, Tencent , ElasticSearch, Redis, Elastic Logstash, and a long etc.
Speaking on the matter, recently the Apache Software Foundation released through a publication a summary of projects that address a critical vulnerability in Log4j 2 which allows arbitrary code to run on the server.
The following Apache projects are affected: Archiva, Druid, EventMesh, Flink, Fortress, Geode, Hive, JMeter, Jena, JSPWiki, OFBiz, Ozone, SkyWalking, Solr, Struts, TrafficControl, and Calcite Avatica. The vulnerability also affected GitHub products, including GitHub.com, GitHub Enterprise Cloud, and GitHub Enterprise Server.
In recent days there has been a significant increase of the activity related to the exploitation of vulnerability. For example, Check Point logged around 100 exploit attempts per minute on its fictitious servers in its peak, and Sophos announced the discovery of a new cryptocurrency mining botnet, formed from systems with an unpatched vulnerability in Log4j 2.
Regarding the information that has been released about the problem:
- The vulnerability has been confirmed in many official Docker images, including couchbase, elasticsearch, flink, solr, storm images, etc.
- The vulnerability is present in the MongoDB Atlas Search product.
- The problem appears in a variety of Cisco products, including 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
- The problem is present in IBM WebSphere Application Server and in the following Red Hat products: OpenShift, OpenShift Logging, OpenStack Platform, Integration Camel, CodeReady Studio, Data Grid, Fuse, and AMQ Streams.
- Confirmed issue in Junos Space Network Management Platform, Northstar Controller / Planner, Paragon Insights / Pathfinder / Planner.
- Many products from Oracle, vmWare, Broadcom, and Amazon are also affected.
Apache projects that are not affected by the Log4j 2 vulnerability: Apache Iceberg, Guacamole, Hadoop, Log4Net, Spark, Tomcat, ZooKeeper, and CloudStack.
Users of problematic packages are advised to urgently install the released updates for them, separately update the version of Log4j 2 or set the parameter Log4j2.formatMsgNoLookups to true (for example, adding the key "-DLog4j2.formatMsgNoLookup = True" at startup).
To lock the system is vulnerable to which there is no direct access, it was suggested to exploit the Logout4Shell vaccine, which, through the commission of an attack, exposes the Java setting "log4j2.formatMsgNoLookups = true", "com.sun.jndi .rmi.object. trustURLCodebase = false "and" com.sun.jndi.cosnaming.object.trustURLCodebase = false "to block further manifestations of the vulnerability on uncontrolled systems.