Log4j Vulnerability (Log4Shell) Explained // CVE-2021-44228

Let's try to make sense of the Log4j vulnerability called Log4Shell. First we look at the Log4j features and JNDI, and then we explore the history of the recent log4shell vulnerability. This is part 1 of a two part series into log4j.

Log4j Issues:

A JOURNEY FROM JNDI/LDAP
MANIPULATION TO REMOTE CODE

---

00:00 - Intro
01:05 - BugBounty Public Service Announcement
02:23 - Chapter #1: Log4j 2
03:38 - Log4j Lookups
04:15 - Chapter #2: JNDI
06:01 - JNDI vs. Log4j
06:35 - Chapter #3: Log4Shell Timeline
07:33 - Developer Experiences Unexpected Lookups
09:51 - The Discovery of Log4Shell in 2021
11:08 - Chapter #4: The 2016 JNDI Security Research
11:56 - Java Serialized Object Features
13:27 - Why Was The Security Research Ignored?
14:44 - Chapter #5: Security Research vs. Software Engineering
16:49 - Final Words and Outlook to Part 2
17:23 - Outro

-=[ ❤️ Support ]=-

-=[ 🐕 Social ]=-

[Ashnurazg]

It's important to mention that the SecurityManager is deprecated in Java 17 for removal in Java 18.

Why - you might ask?
- It's very old, it was implemented back in the old days where Java was run inside of applets at websites.
No one uses applets anymore, it's a dead feature and JEP 398 (-> Java 17) deprecated it for removal as well. All browsers removed support for applets. Nowadays JS, WebAssembly, etc. are used.
- SecurityManager's configuration is very complicated, it has poor performance and it's not widely used.

For securing object de-/serialization the JEP 290 (-> Java 9) and JEP 415 (-> Java 17) implemented filters for object serialization and deserialization.

[CarlosVieiraCrowSec]

This is the first video I've seen the real and correct explanation of how JNDI works and how deep this vulnerability was...

Awesome work!

[seanvinsick]

I'm a software engineer, and I love your videos. Especially binary exploitation and the sudoedit series. Security is everyone's responsibility, not just the researchers. That's like saying bugs are QAs responsibility to find. Writing code without security in mind is what leads to stuff like this.

[roberttuck]

This is exactly the analysis I was hoping someone would do. I believe one of the reasons that the problem was not found earlier, is that although many developers are aware of developments in the hacking world, none of them were aware that this lookup facility was a feature in log4j. In fact, even after I looked at the documentation, it wasn't immediately clear that message lookup was something that is not only available in config files, but also in log messages and even log parameters.
Log4j is something that is typically set up early on in the life of a project and most developers although they may make use of it extensively will probably never really delve much into configuration or advanced features, so it is very much a fire-and-forget thing.

One thing that is very clear from your video is that what in hindsight looks like an incredibly stupid design feature in log4j, was much more innocuous when it was conceived in 2013, and that it was only after the JNDI exploit was discovered that its security should have been reconsidered. Having said that, even without the JNDI lookup RCE, further security concerns have been raised which have led them to remove message lookups completely from their latest update.

[bryan]

Dude, doesn’t matter how much content there is on the internet! You always make amazing videos! So never doubt! You’re one of my favourite youtube channels

[soviut]

Don't worry too much about repackaging existing material, especially when it comes to vulnerabilities. I'm a software developer and the only things I've heard/seen on the topic are "check that these apps are patched". So hearing you amplify what others have said about the cause of the vulnerability are good for folks like me.

[dzhimy]

The problem in security is that there's this weird corporate push to express the "you don't need to code to get into security" idea, which if what you're doing is exploiting software, you need to know how software is built, you basically need to have previously been a developer, that's not gatekeeping, it's literally a job requirement.
I think there's more people than we would like to admit in the security field testing and exploiting software with zero software development experience, or basic coding experience when what we need is people who know how to build software, we need more software engineers in security, and we need more security testers in software development and software QA.

[TheCardil]

Fascinating view on Log4Shell, and why it wasn't noticed earlier. Maybe we should build linters controlled by security researchers to hint us, developers, about possible vulnerabilities.

[pavelhoral]

For me it is absolutely unbelievable, how someone could have thought that it is a good feature to do any processing on the message part itself. That is simply bonkers...

[falxie_]

Actually knowing why that feature existed in the first place is something I haven't heard anywhere else

[guiorgy]

Honestly, the best video on Log4J that I watched so far!

[umlal]

Thanks for the video, still added some value for me.
As a security professional seeing the internet evolves and dented with this magnificent exploit is euphoric, such an amazing journey!

[TigerWalts]

Before even considering the RCE exploit, I think that it's insane that by default log4j allowed lookups to be parsed in a log message. You wouldn't dream of adding an unsanitised string to an SQL command, so why allow this?

The moment someone noticed that it's possible to log an environment variable by logging a lookup string, it should have been made an opt-in feature.

In this age of micro-services, security credentials are passed to containers primarily using environment variables. The names of these variables are publicly documented in open source projects. So if your logger echos back to the user their input, but with the lookups parsed and populated, this feature can be used to leak usernames, passwords and and keys.

[gostly]

This was genuinely beyond what other creators shared. Thank you for helping us understand the timeline and giving a broader understanding of the issue.

[MajorNr]

And here I was, thinking that hosting a little Minecraft server for me and my friends WASN'T going to ruin christmas.

[dorb]

I do believe that there are many videos and resources about this topic and any other topic on the tech fields. But, and it's a big 'but', it's a matter of who delivers this material and how. To the bottom line - most of the times, your explanations and talks are much more simple to understand than the others :) so keep sharing your knowledge with us .

[faran]

Well the most critical 0 day explained by the legend himself.🤩

[magawla]

The best explanation I've ever listened to about Log4j.

[danielmoreno]

It's baffling to me how the issue was identified years ago, yet it was not treated as the serious security flaw it is up until recently. Really makes me wonder how much was this vulnerability exploited accross the years it managed to stay under the radar, and how didn't it get the attention it deserved for so long.

[THeMin]

Thank you for your amazing work. And yes I believe specialization is great is how we reach a higher level in terms of potential in a field, understanding the emergence when fields combine is where we generally overlook.