Ten Things You Must Know About Log4j

This guest post was originally posted on LinkedIn and has been reposted with permission.

If you are just finding out about log4j, here’s what you need to know as a defender:

1. It’s bad. VERY bad. The level of badness can’t be overstated.

2. Don’t think you’re exposed because you don’t use java? I guarantee you at least one of your SaaS vendors/cloud hosting providers/web server providers does.

Java was the most popular programming language of the 90s and early 00s. Hell, it’s still in Stack Overflow’s Top 10 and taught widely in high school & college.


3. Go through EVERY app, website, and system that you own/use that talks to the internet. This includes self-hosted installs of vendor products and cloud-based services.

Focus on systems that are internet-facing that contain sensitive data, secrets, etc. Focus on older “legacy” vendors.

4. This exploit is not only publicly known, the barrier to entry is LOW. Anyone, including your 5yo playing Minecraft, can use this exploit. It’s as simple as typing in a few characters into a chat box.

5. Don’t think you’re protected because aUthEnTiCatIoN. This exploit is pre-auth. Which means an attacker DOESN’T NEED TO SIGN IN to your web app/system/whatever in order to pop you.

6. Once you finish assessing your hosted apps, vendor systems, etc. – move on to endpoint applications. Java-based apps like WebEx, Minecraft, JetBrains IDEs, Citrix, Filezilla FTP are all
vulnerable. You need to patch, patch, patch. If no patch is available, uninstall.

7. Once you’re done with endpoint apps, make sure all your work from home folks update their personal devices and home routers.

Yes, home routers are susceptible.

I told you it was bad.

Note – don’t rely on your work from home folks to do this right, even with clear instructions.

A lot of them will ignore you.
Prepare for this eventuality.
Make nice with your IT team.
You’re gonna need them.

7. Your immediate reaction will be to set gateway rules to block the exploit string.

Don’t. It won’t work.

There are an infinite number of ways to obfuscate the string. Your regex will be no match, I assure you.

8. Instead, focus on patching. Focus on limiting outbound traffic.
If you can block the LDAP/LDAPS protocol entirely from your outbound traffic, do it.

If you can’t, well, at least block the default LDAP/LDAPS ports. It’s not much, but it’s something.

9. Lastly, communicate with your senior leaders. They should be in the know about this one.

If your leaders ignore you, go to the leadership level above them.

If they ignore you, go to the CEO.

If the CEO ignores you, go to the board.

I told you it was bad.

10. Don’t think this is going to go away any time soon. We’re just starting to get a glimpse of what is being tried out there in the wild.
Buckle up. It’s going to be a wild Christmas.

One final thing to add: if you don’t have edge protection, you can still set firewall rules at the host level. Send outbound traffic to only trusted IPs. This should be a small list.

• • •
To recap:
1. log4j is very bad
2. you are susceptible
3. patch & filter outbound traffic
4. get IT to help you
5. tell your senior leaders


Naomi Buckwalter is an experienced CISO and non-profit director, and is a featured speaker among the Data Connectors Cybersecurity Community. Find her on LinkedIn. 

Ten Things You Must Know About Log4j

Hot Topics in Cybersecurity Posted by Naomi Buckwalter on Dec 14, 2021

Leave a Reply

Your email address will not be published. Required fields are marked*