Thread by @mubix

10 #Log4Shell Facts vs Fiction: a 🧵
1. 1.x is NOT vuln to this RCE. While it doesn't have another RCE, it requires access to send serialized data to a listener ON the log server. This is much MUCH harder to exploit and kind of rare for a Log4j server to be running.

2. #Log4Shell attacks can show up hours after the trigger is sent. We are just starting to understand how deep this rabbit hole goes. I personally had BurpCollaborator and CanaryTokens hit 6-8 hours after they were sent.

3. It's not just web servers that are vulnerable. All the avenues that attackers are still being researched. I have seen SSID AP names, email headers, usernames on social media, Pastebin file names, book reviews, SMS, trouble tickets, and pull requests with attack strings.

4. It's a library, you can NOT 100% confirm this via a list of "installed" software. The JAR file can be anywhere. It's OSS, so it can be compiled by anyone, so hash lists (like my own) don't work well. BUT the developer has versions in the file name, which is a godsend.

5. JNDI RMI/LDAP requests CAN use proxy settings, but most of time they won't, so egress filtering blocks a lot of attack attempts. There are very few reasons why an internal server needs to make requests to the Internet (outside of software update services). Use allow lists!

6. What makes exploitation particularly hard to find in IR is that if the exploitation is successful, the JDNI string is NOT actually logged (because it's interpreted by the Log4j logger). You are looking for blank spots in your logs...

7. Just because a vendor says they aren't vulnerable doesn't mean they aren't. This is a 96 hour old bug in the eyes of many and it takes time to be sure. See number 4.

8. Web Application Firewalls are doing a very good jobs at blocking attacks against web services. Just because there are bypasses for them, doesn't mean they aren't blocking the majority of attacks. Bypasses get used and added to blocks pretty quickly. Think AV.

9. If you are a pentester/bug bounty researcher/red teamer, you should NOT be using public services to exfiltrate secrets over unencrypted channels to websites that you do not control. You have no idea what they are doing with your customer's data.

10. Ripping the class file out of the JAR, or functionality out of active running Java programs could be a great band-aide, but it may break software updates or SBOMs in the future. It may also introduce instability in the application.

Of course I mess up #1. While 1.x DOES have another RCE, it's rough to exploit.

Correction to number 6: @zaicurity @jstnkndy and @d0nutptr all are saying that this is not the case in their testing. I’ll do more testing when I have time but I trust them that this statement is false. I only tested 3 apps and that is definitely not representative.