Apache Log4j Vulnerability: Info, Updates & Mitigation

  • Thread starter sandy stone
  • Start date
In summary: So Log4j has a feature to get system info when a logging message is printed. The info could be useful to web admins diagnosing system issues with a running web app. However, the app programmer didn’t properly scan user input and instead decided to just print it to the app log then a knowledgeable hacker could insert some properly formatted string to do damage.The Log4j vulnerability is being exploited daily. A patch was released and urged users to install it. The flaw can be exploited to inject malicious code on the target server.
  • #1
sandy stone
232
158
TL;DR Summary
What can be done about this? What is being done?
I have been reading the news reports about the recently discovered (?) "Apache Log4j" vulnerability, and they make it sound pretty bad, but lack substantive details. Does anyone in this community have more info about how this threat is being handled? How does one update software in millions of industrial and consumer devices in order to mitigate the problem?
 
Computer science news on Phys.org
  • #2
sandy stone said:
Summary:: What can be done about this? What is being done?

I have been reading the news reports about the recently discovered (?) "Apache Log4j" vulnerability, and they make it sound pretty bad, but lack substantive details.
Substantive details are discussed outside the public domain, e.g., among cybersecurity experts.
sandy stone said:
Summary:: What can be done about this? What is being done?

Does anyone in this community have more info about how this threat is being handled? How does one update software in millions of industrial and consumer devices in order to mitigate the problem?
A patch is available - from trusted sources - as well as originator of the code.

Last Thursday, the world learned of an in-the-wild exploitation of a critical code-execution zero-day in Log4J, a logging utility used by just about every cloud service and enterprise network on the planet. Open source developers quickly released an update that patched the flaw and urged all users to install it immediately.

https://arstechnica.com/information...as-its-own-vulnerability-thats-under-exploit/

https://logging.apache.org/log4j/2.x/security.html
 
  • Like
Likes sysprog and Wrichik Basu
  • #3
It is indeed difficult. The module is buried so deep in open source stacks that most people using it are not aware that they have it.

From https://www.schneier.com/
The range of impacts is so broad because of the nature of the vulnerability itself. Developers use logging frameworks to keep track of what happens in a given application. To exploit Log4Shell, an attacker only needs to get the system to log a strategically crafted string of code. From there they can load arbitrary code on the targeted server and install malware or launch other attacks. Notably, hackers can introduce the snippet in seemingly benign ways, like by sending the string in an email or setting it as an account username.
At that point it was reported that there were over 100 attempts to exploit the vulnerability every minute. “Since we started to implement our protection we prevented over 1,272,000 attempts to allocate the vulnerability, over 46% of those attempts were made by known malicious groups,” said cybersecurity company Check Point.

And according to Check Point, attackers have now attempted to exploit the flaw on over 40% of global networks.
In some sense, it challenges the fundamental notion of sharing software. Any software. If there is anyone in the world who wrote every single line of software on their system personally, that person would not have LOG4j.

But that's preposterous. We would be stuck in the stone age if we didn't share. But the more we do share, we make ourselves vulnerable to a flawed shared object.

Software seems to have the property that flaws can remain undetected much longer than hardware flaws. I see no reason why that must be true, but it seems to be true nevertheless.
 
  • Informative
  • Like
Likes sysprog and Astronuc
  • #4
A key tenet of secure programming is to never reference user input and print it without a scan and replacement of key metacharacters.

In the early days of web programming, it wasn’t uncommon to use a scripting language to process data from a web page and to assume user input was simply text. Hackers discovered that properly formatted strings with back ticks could be input and would be executed on the host serving the web page.

As an example, a field might ask for my name so I would type

john ‘ls’ smith

and if the server script went to print my name back to me on the web page refresh then I might see a listing of files and directories on the web server.

Why? Because the backtick is recognized by the server script as a request to execute the ls command before it prints the string. It was a great feature to get current date and time using unix commands when the scripting language didn’t have function calls for date and time.

other types of commands could be further used to find and access a database, make it available to anyone…. And extract its data.

The solution has been to first scan the user input and replace characters like the backtick with a quoted backtick or to remove the backtick or to reject the user name and have the user retype it.

in log4j the developers added a feature to get system info when a logging message is printed. The info could be useful to web admins diagnosing system issues with a running web app. However, the app programmer didn’t properly scan user input and instead decided to just print it to the app log then a knowledgeable hacker could insert some properly formatted string to do damage to the web server.

Sophos wrote up a great description with examples:

https://nakedsecurity.sophos.com/20...works-why-you-need-to-know-and-how-to-fix-it/

Don’t be that guy using it for nefarious purposes, be the guy that finds and fixes their web applications to not do these bad things with user input.
 
  • Informative
  • Like
Likes Twigg, sysprog, Wrichik Basu and 1 other person
  • #5
Log4j is taking the brunt of criticism on this issue when in fact its the app developers who are at fault for not properly following security guidelines.

It makes sense though to fix log4j as that requires the least resources overall. It will be sad to remove this feature which people could use to diagnose web app problems at the point and time they occur.

I used log4j version 1 in all my java apps and something similar but more limited to my code for diagnostic use because version 1 had no such feature.

The other issue is that logging now is more than just diagnostics. Web systems will glean info from the log for use in data mining or traffic analysis.

Log4j and its partner libs for other languages is a great tool. It allows you to annotate anything in your program with logging and to let the admin decide what output he/she wants to see by controlling level of logging and what java classes will show their logging output at runtime while running and across multiple threads. One can also control the formatting of logging messages annotating with runtime millisecs, thread name, java class…
 
  • Like
Likes sysprog
  • #6
This vulnerability has a CVSS score of 10.0, the highest possible.

This article says how you can find out log4j dependencies in your system:

https://www.techrepublic.com/article/how-to-test-if-your-linux-server-is-vulnerable-to-log4j/

In my Ubuntu laptop, I found that IntelliJ IDEA, Android Studio, and even MATLAB use log4j.

The above article states,
This zero-day flaw affects the Log4j library and can allow an attacker to execute arbitrary code on a system that depends on Log4j to write log messages.
Does that mean that not only servers, even my PC is vulnerable? What if I use a firewall (UFW in Ubuntu) to restrict all incoming connections?
 
  • #7
It's really down to software vendors to alert customers if their products are affected. I work for a cloud provider and we have been contacted by some vendors and others you can lookup online to see if they have published anything related to this. It's a big task which has had everyone scrambling to patch / implement workarounds.

Log4j is basically around a unused / little used feature in the which allows a remote attacker full admin access to run whatever they want on a system. Log4j was last updated in 2016 and the developers working on it knew this specific functionality which has been compromised was outdated and probably unused anywhere but they were fearful of someone actually still using it and so didn't want to break the backwards compatibility so they left it enabled.

As has been demonstrated a large number of commercial products have been affected, commercial companies often use open source software but are reluctant to actually "give back" anything in terms of funds to help those developing the core of their systems which they rely on. Perhaps if there was more appreciation and assistance to those developing open source software issues like this would come up less.
 
  • Like
Likes Twigg, Wrichik Basu, jim mcnamara and 1 other person
  • #9
Log4j is practically included by default on a typical Java web server stack. A lot of web servers are running java.
 
  • #10
sandy stone said:
How does one update software in millions of industrial and consumer devices in order to mitigate the problem?
Because the problem lies in such a deep buried module, most programs have to wait for a sub-program they use to provide a patch before making their own patch, which themselves also use log4j thru a program they use and they are waiting for a patch from that program, and so and so forth.

So before all patches are available and passed on through the chain, it can take a long time.
 
  • Like
Likes Wrichik Basu

FAQ: Apache Log4j Vulnerability: Info, Updates & Mitigation

What is the Apache Log4j vulnerability?

The Apache Log4j vulnerability is a security vulnerability found in the Apache Log4j logging library. This vulnerability allows attackers to remotely execute code on a server, potentially gaining access to sensitive information and compromising the security of the system.

How was the Apache Log4j vulnerability discovered?

The vulnerability was first discovered by security researchers who noticed abnormal traffic patterns in their logs. Upon further investigation, they found that the vulnerability was due to a flaw in the Log4j library.

Has the Apache Log4j vulnerability been fixed?

Yes, the Apache Software Foundation has released a security update to fix the Log4j vulnerability. It is important for system administrators to update their Log4j libraries as soon as possible to mitigate the risk of a potential attack.

How can I check if my system is vulnerable to the Log4j vulnerability?

To check if your system is vulnerable, you can use a vulnerability scanning tool or check if your Log4j library is using versions 2.0 to 2.15.0. If so, you should update to the latest version (2.16.0) to fix the vulnerability.

What can I do to protect my system from the Log4j vulnerability?

In addition to updating your Log4j library, you can also implement additional security measures such as restricting access to your server and monitoring for any suspicious activity. It is also recommended to stay informed about any future security updates and promptly apply them to your system.

Back
Top