ZeroHour
DashboardNewsCVEsExploitsIncidentsAIBriefAnalyticsEntitiesWatchlistIOCsAsk the feedSourcesFeeds & APIKiosk mode
Kaspersky Securelistpublished ()ingested @Securelist

Answering Log4Shell

highVulnerability exploited in the wildimportance 60CVE-2021-44228CVE-2021-45046CVE-2021-45105
Read the original
Tagscve-2021-44228cve-2021-45046cve-2021-45105vulnerability

Vulnerabilities mentionedAll →

CVEVulnerabilityCVSSEPSSFlagsAffectedExposurePublished
CVE-2021-44228
JNDI Injection Remote Code Execution in Apache Log4j2 (Log4Shell)

Apache Log4j2, an extremely widely used Java logging library, fails to protect its JNDI lookup feature against attacker-controlled JNDI-related endpoints (CWE-20, CWE-502), so crafted text processed by the logger causes the Java runtime to fetch and load attacker-supplied objects, leading to remote code execution. The flaw is triggered whenever attacker-controlled input reaches the logging API and is parsed for JNDI lookups, a pattern common in web servers and enterprise Java applications that log user-supplied fields such as headers or form values. Successful exploitation yields arbitrary code execution under the privileges of the affected application, giving attackers a foothold for lateral movement, data theft, and ransomware deployment. Any Java application or product that ships or bundles an affected Apache Log4j2 release is exposed, making this one of the most broadly deployed vulnerabilities ever disclosed. Exploitation is confirmed in the wild: CISA added it to the Known Exploited Vulnerabilities catalog on 2021-12-10 with known ransomware use, and EPSS assigns a 100% probability of exploitation within 30 days.

Do: Inventory all Java applications and dependencies for Apache Log4j2 and apply the vendor's patched updates, or remove affected assets from the network, as required by CISA's KEV catalog. Where updates are not yet available, use the temporary mitigations in CISA's ED-22-02 recommended-mitigation guidance, such as disabling message lookups, only until patches are applied. Prioritize internet-facing and business-critical systems and hunt for exploitation activity given known ransomware use.

10.0100% KEV ransomware PoC ×9
  • Apache Log4j2
masshundreds of millions of Java applications/devices, with hundreds of thousands of internet-exposed services
CVE-2021-45046
Remote Code Execution in Apache Log4j2 via Incomplete Log4Shell Fix

CVE-2021-45046 is a remote code execution and information disclosure flaw in Apache Log4j2 (CWE-917) that resulted from an incomplete fix to CVE-2021-44228 (Log4Shell), leaving the Thread Context Lookup Pattern vulnerable in certain non-default configurations. It is triggered when an application logs attacker-controlled data using layouts or patterns that perform Thread Context (MDC) lookups, allowing crafted lookup expressions to be evaluated against untrusted input. A successful attacker can achieve remote code execution, or potentially information disclosure, on the affected service. Any deployment of Apache Log4j2 that relies on the affected non-default lookup configurations is exposed, which given Log4j2's ubiquity in Java applications and embedded products means a very large installed base. Exploitation is confirmed: the flaw is in CISA KEV (added 2023-05-01) with known ransomware use, and EPSS assigns a 100% probability of exploitation within 30 days.

Do: Upgrade Log4j2 to 2.17.0 or later per vendor instructions (or 2.12.3/2.3.1 for the legacy 2.12/2.3 branches), since the 2.16.0 fix was itself incomplete in some non-default configurations. Where upgrading is not immediately possible, remove the JndiLookup class from the Log4j2 jar or disable lookup processing, and audit applications and dependencies that bundle Log4j2 while following the CISA KEV required action to apply vendor updates.

9.0100% KEV ransomware
  • Apache Log4j2 Log4j 2.x; per Apache advisory, 2.0-beta9 through 2.15.0 (and 2.16.0 in some non-default configurations), fixed in 2.17.0 and in 2.12.3/2.3.1 for older branches
massmillions of Java deployments worldwide, with hundreds of thousands of internet-exposed services observed in public scans during the Log4Shell campaign
CVE-2021-45105
Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups.

Apache Log4j2 versions 2.0-alpha1 through 2.16.0 (excluding 2.12.3 and 2.3.1) did not protect from uncontrolled recursion from self-referential lookups. This allows an attacker with control over Thread Context Map data to cause a denial of service when a crafted string is interpreted. This issue was fixed in Log4j 2.17.0, 2.12.3, and 2.3.1.

NVD description · AI analysis pending		5.9100%
  • apache log4j
  • apache cloud manager
  • apache debian linux
  • +1 more
—
Full article1,078 words · extracted from securelist.com · click to collapse

Important notice

On December 18th, Log4j version 2.17.0 was released to address open vulnerabilities. It is highly recommended to update your systems as soon as possible.

History of the Log4j library vulnerabilities

A summary of the Log4Shell situation

On December 9th, a Chinese researcher posted his now-monumental discovery on Twitter: there was a Remote Code Execution vulnerability in the popular Apache Log4j library. This library is used in millions of commercial and open-source applications. Ranked 10 out of 10 in terms of severity, CVE-2021-44228, also known as Log4Shell, is capable of giving attackers full control over targeted systems.

The exploit takes advantage of Apache’s Java Naming and Directory Interface (JNDI), which provides programmers with an easy way to process remote commands and remote objects by calling external objects. However, with Log4Shell, attackers can inject their own code into the JNDI lookup command: code that will then be executed on the targeted system.


Log4Shell attack path

Attackers have been seen using the vulnerability in numerous ways, one of which is to execute XMRig, an infamous cryptominer. Another is to execute the Kinsing malware, a cryptominer that uses rootkits to hide malicious activity.

So far, exploitation attempts have been observed around the globe and are expected to continue in the coming months.

To safeguard systems, it is important to:

  • Check if Log4j is installed
  • Update to the latest version
  • Monitor application logs

You can find more information about the vulnerabilities (technical details, mitigation steps, statistics) in our blogpost titled, “CVE-2021-44228 vulnerability in Apache Log4j library“.

In addition, check out the answers to some of users’ biggest security questions about the Log4Shell vulnerability. The questions were asked during our “The Log4Shell Vulnerability – explained: how to stay secure” webinar.

The Log4Shell vulnerability webinar FAQ

  1. Is it safe to use version 1.x?

    2. Log4j 1.x is an outdated version that is no longer supported. The last version, 1.2.17, was released in 2016. In general, software that is not updated or maintained poses a serious security risk as this software may contain unknown and unpatched vulnerabilities that will weaken your security.

  2. Have you seen exploitation attempts using Log4j directly as something like ${attack code} without using any jndi strings?

    3. No, we have not seen this kind of string so far.

  3. On the map and graphs of hits, are exploits being shown or exploits plus scans? How do you differentiate between the two?

    4. The graphs only contain Log4j-related exploitation attempts. Basic scanning and other types of attacks are not included. We are using deep parsing and filtering methods to reveal malicious requests in any of the relevant sections (e.g., header entries, such as user-agent or referer).

  4. Is IoT vulnerable to Log4j?

    5. This greatly depends on the device/vendor. There are most likely devices that contain vulnerable Log4j versions, e.g., if the interface or core application running is built on Java and incorporates this module.

  5. Is there any information based on IoCs about when the first attack occurred?

    6. The first attacks we saw occurred on December 10, 2021. Of course, this greatly depends on visibility, and the amount and sources of data. There are posts suggesting earlier attacks (beginning of December). Based on our data, we currently cannot confirm this.

  6. Am I safe if I only remove the JNDILookup class from Log4j?

    7. According to the latest updates to the vendor publications’, you can disable the JNDILookupfeature in the Log4j library, and this modified configuration will help reduce exploitation impact; however, the vendor recommends updating to the latest version if possible.

  7. Is there a way to check if the vulnerability exists on a server? Are there any traces that the attackers leave?

    8. All the JNDI exploitation attempts observed contain at least the ${jndi string in the request; however, attackers have applied several obfuscation techniques and character replacements. In addition, the Github community includes several log analyzers’ scanners to verify the presence of an exploitation attempt in your system.

  8. What is the mitigation plan for this vulnerability when it comes to Linux servers?

    9. The mitigation strategy will always depend on the environment where the Log4j library is executed. The vendor recommends updating to the latest version if possible, which will fix the current exploitation issue. Other recommendations are:

    • Restrict outbound connections to unknown remote servers
    • Disable the JNDI lookup feature
    • Deploy WAF technologies and custom rules to block exploitation attempts.
    • Block connections within your perimeter to IPs that are exploiting servers worldwide. We provide free IOCs relating to Log4j exploitation attempts.
  9. I have seen a lot of RMI Port 1099 connection attempts on my IPS. Is this type of traffic normal?

    10. It will always depend on whether your infrastructure uses this type of service. For security, we recommend enabling this service only when necessary to reduce the attack surface of your organization. We have seen the RMI service used in Log4Shell exploitation attempts.

  10. If I have Java 8 installed on my machine, does that automatically mean I have the Log4j exploit?

    11. In order to be vulnerable, the system has to execute software that uses the Log4j component as part of the execution.

  11. Is Kaspersky providing free IDS rules?

    12. No, we provide the rules to those of our customers who use our Threat Intelligence services.

  12. Do you see any vulnerabilities on IIoT devices?

    13. This will depend on the vendor/software running on these IoT devices. We have no information about specific exploitation attempts targeting just that ecosystem.

  13. Is there a way to check if the vulnerability exists in third-party libraries? I am referring to projects that are built without Java but might have some dependencies under the hood.

    14. We recommend following the DevSecOps principle by scanning the software repositories using various SAST technologies.

  14. When using the Base64 method, is an LDAP server still required?

    15. The exploitation attempt will use various types of services like LDAP, RMI, DNS, etc. The exploit uses a malicious Java class in order to exploit the vulnerability, so the attacker will set up a listener on the malicious infrastructure side.

  15. Is Log4j effective even if Java is disabled?

    16. Java can be disabled on the server but the library can still be embedded or used by other software running in your infrastructure.

  16. Am I vulnerable if I have Java installed on my server or end-user device?

    17. The vulnerability affects either the client side or server side.

Text extracted automatically; images, tables and formatting may be missing. Original: https://securelist.com/answering-log4shell-related-questions/105402/