Log4j Lookups in Depth // Log4Shell CVE-2021-44228 - Part 2

In this video we dig a layer deeper into Log4j. We get a quick overview how Log4j is parsing lookup strings and find the functions used in WAF bypasses. Then we bridge the gap to format string vulnerabilities and figure out why the noLookups mitigation has flaws.

--

00:00 - Intro
00:38 - Chapter #1: Log4j Lookups in Depth Debugging
03:50 - Log Layout Formatters
06:56 - Chapter #2: Secure Software Design
09:21 - Chapter #3: Format String Vulnerabilities
13:58 - Chapter #4: noLookups Mitigation
15:15 - Final Worlds
15:42 - Outro

-=[ ❤️ Support ]=-

-=[ 🐕 Social ]=-

[rjhornsby]

I’ve always liked your sort of casual handwritten visual style, and it especially shines here. I can more or less read Java, but there’s so much code in just this one tiny - almost incidental - library, it’s nuts. The way you approach highlighting, focus in on small code blocks, and your red/white callouts make it super easy to follow your narration. So, thanks! and Merry Christmas.

[jeffvalore]

your "secure design" section hits the nail on the head. They made the classic mistake of trusting user input, and never considered "how could this be abused?". JNDI aside, it shouldn't have taken a whole lot of thought to consider that anyone who has access to read the logs but not access the server or code directly, can just log all the server env vars (DB connection strings? AWS creds?) and potentially steal information. IMO this entire substitution "feature" of log4j never should have existed. Even if it was "secure" this is still a lot of bloat for features that a very small subset of log4j users would ever utilize.

[monognome]

As a developer, this vulnerability caused so much chaos throughout the weekend in webapps using Java. But you explaining it makes it seem so simple. Amazing video 🙌🏽🔥

[MuhammadBinZafar]

I'm glad that you have 380+ videos. I never want to run out of your videos. I've been listening since 2018🎈. Always enjoyed every single moment with you. Each video is unique, knowledgeable, perfect 🎉. I wish the best for you!

[AFchump]

“I have no clue about Java or maven with dependencies” i felt that in my soul. I went back to 3 deserialization issues after the log4j learning curves to reattempt that exploit after the Java and java development learning curve that log4j caused. Beautiful and tiring at the same time.

[jackbendtsen]

Absolutely, simple code means all of the code that your program could run, not just the code you wrote. I feel like not enough people truly understand this. Thank you for your insights beyond the topic at hand.

[santi]

7:40 totally agree, it's crazy how complex a logging library can be for no reason at all, simplicity is also good for keeping the code maintainable and easy to understand

[EER]

Great video, nice to see an actual dive into the code and not just more talking heads.

I wish it was easy to keep the codebases clean and simple, but so far any project that I worked on with a team devolved in a mess of dependencies. The hardest part about keeping things simple, is to convince stakeholders that it's worth spending hours to implement (e.g.) centralized logging yourself when there's a library like this already available. They'd rather see me working on a shiny new button than on stuff that nobody sees in the backend.

[spicybaguette]

I'm curious whether anyone ever has needed the _recursive_ lookups... It's a logging library! Not a string substitution one! Why is this even enabled by default in the first place?

[cdhagen]

This library is a prime example of over-engineering! That's why I don't 100% agree with people who claim that it's just „because a few overworked guys are thanklessly maintaining this thing for free“. Yes, maybe, but who forces them to build crazy features like this into what *should* be a relatively straightforward logging library?

[superblaubeere]

Some people take it a bit too far with the OOP. Splitting code in three-liner functions and douzens of classes does not really help the readability of the code haha

[klotzklotz]

I think another interesting aspect of this vulnerability is that, if your organization used "defense in depth" and configured firewalls to block outgoing LDAP connections, exploitation of the vulnerability does not easily work. Unfortunately many people do not restrict outgoing network connections of their servers though :-(

[tunasalmon]

The best gift for christmas for an aspiring developer. Thank you so much

[anttijokipii]

Thanks for you content. It is really good. I have worked as programmer/architect/CEO on multiple decades, but have background from hacking. It is interesting that security and development is actually so separated.

[hblaub]

Really nice Java library. I think we should load custom code per socket from somewhere, too. It's going to be totally safe and sane.

[einsjannis]

I really enjoyed your videos about log4j I really happy that some one added something new and I actually wad able to learn sth new

[isitanemail]

I was waiting for something that could explain in depth the full vulnerability, log4j and jndi. These videos helped me a lot in understanding.
I would request to release such content more and probably a little quicker to help clear these things. Some other explanation caused a lot of confusion

[Dropje]

Man, you have no idea how many arguments I’ve had with developers about levels of abstraction. The DRY principle has been taken way out of its original intent and people now just add layers of indirection for the sake of it. So often things can be kept much simpler by repeating yourself.

[comradepeter]

5:18 What was the point of having so many classes and factories and functions if the actual functionality is just shoved into one function?

[anacierdem]

Having the developer pass the contents instead of parsing various things is a much better approach even from a software development viewpoint here. It is inversion of control, which effectively reduces inner complexity.