ICYMI, this is how the #log4j #Log4Shell flaw works (in simple english), a 🧵
1. Victim is running a Java Web that uses the log4j logging lib
2. The victim web app has code that logs http request payloads/headers with log statements (example User-Agent)
1/
1. Victim is running a Java Web that uses the log4j logging lib
2. The victim web app has code that logs http request payloads/headers with log statements (example User-Agent)
1/
3. Attacker identifies vulnerable app and makes a request to the server with the User-Agent Value set to this. What does this mean? 2/
jndi == Java Naming and Directory Interface. Allows Java apps to access multiple apis for LDAP, Remote Method Invocation (RMI), etc through the JNDI Interface
4. The attacker tries to get the log4j library to lookup an LDAP server through JNDI 3/
4. The attacker tries to get the log4j library to lookup an LDAP server through JNDI 3/
If the log4j library is vulnerable, it will attempt to call the URI (ldap server).
5. The attacker runs the purported LDAP server and feeds a "malicious" class that contains some code that they want your app to run.
4/
5. The attacker runs the purported LDAP server and feeds a "malicious" class that contains some code that they want your app to run.
4/
6. Because your log4j library is vulnerable. It makes the LDAP call, receives the class, runs the code and you have RCE
Ok, now why is this sooo bad (other than the fact that its an RCE) 5/
Ok, now why is this sooo bad (other than the fact that its an RCE) 5/
a - because log4j is one of the most common libraries in any java app. Its basically as common to Java as OpenSSL is to the world. So think, heartbleed, but for Java apps
b - just like OpenSSL, log4j may be a nested dependency. An app's library's dependency. Therefore, hard 6/
b - just like OpenSSL, log4j may be a nested dependency. An app's library's dependency. Therefore, hard 6/
This vulnerability is bad. So please deal with it ASAP.
1. Check if you're running a version of the Java JDK that seems to not be vulnerable to this flaw (because it sets a trust URLcodebase value to false), which is good. Versions above these 👇 are supposedly not vulnerable
7/
1. Check if you're running a version of the Java JDK that seems to not be vulnerable to this flaw (because it sets a trust URLcodebase value to false), which is good. Versions above these 👇 are supposedly not vulnerable
7/
2. For log4j libraries 2.10.0 and above, you can use formatMsgNoLookups=true. Older versions also have (slightly more involved) fixes
3. Tune rules for payloads in WAF/APIGW
4. Scan for vulnerable log4j libs and patch immediately
3. Tune rules for payloads in WAF/APIGW
4. Scan for vulnerable log4j libs and patch immediately
For those following this thread. In light of new evidence. The Java jdk versions don’t make a difference. Please ignore. You have to either patch log4j or use the formatNoMsgLookups config flag to fix the issue
• • •
Missing some Tweet in this thread? You can try to
force a refresh
