thanks for the added info. You can see my java knowledge is kinda old :D

@@LiveOverflow But your work is amazing..... 🤗

@@spotlightsrule If you can run kotlin, you can upgrade your JVMs. Stop whining.

@@Dragiux It's not whining, it's facts, Java 8 is heavily used even today.

In the Devoxx UK 2018 conference, Oracle's chief architect Mark Reinhold said that their long-term goal is to remove serialization from Java. But there is no JEP about it yet, so it'll likely still take many more years.

I agree with you, I hate how most of the videos show us a payload without explaining why the payload is working

adding a 2nd thumbs-up here

Facts!

@Dzhimy really bro, in this world we need more expert on Cybersecurity... And better programmers that not do mistakes

@@Mrx-dw4py no shit bro why don't you become one then? it's not that easy. We're humans, besides making kids, we make mistakes; hell even the kids can be mistakes!

@@stevegremory3849 I mean, they should be more careful ... it won't be perfectly because nobody is perfect

@@stevegremory3849 but let's stop fighting, I just want to talk, have no problems

@@Mrx-dw4py nah nah bro sorry if I gave the impression that i was out to fight lmao

Maybe it was not noticed earlier because serious companies have their server in VPC so that servers cannot connect to a random server on the internet that hosts malicious code. For example in AWS they motivated people to have servers in VPC. When you create a Redshift server, Dax, or RDBS by default it is in VPC so that it cannot access the internet so Log4J2 could not connect to another server. That is the main reason why we don't have a catastrophe now.

> 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. I agree. After hearing about this vulnerability, I was scanning through the documentation and couldn't find a description how to trigger the lookups from log messages. > 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. I don't agree. It is still a stupid design. Just reading the first sentence of issues.apache.org/jira/browse/LOG4J2-905 should trigger alarm bells in everyone's head. Running string interpolations, which are intended for the developers, on untrusted strings is negligent in my opinion. This is a vulnerability even without JNDI, although it would be less critical. For example, secrets (like API tokens) are often stored in environment variables. With ${env:MY_API_TOKEN} and nothing else, everyone with access to the log files could "steel" the secrets. And even if you don't find a way to exploit this feature, it still makes the log files untrustworthy since you never know what was actually logged. Besides, deserialization is known to be unsecure for a long time. I think most Java developers know that. I learned that in my first year at the university. Even if nobody had built a RCE for JNDI, the exploitability might have been expectable. Furthermore, triggering network requests to arbitrary addresses is already pretty bad and can already be used to extract sensitive information, so you don't need the RCE after all.

Wow that's actually a brilliant idea. It should be integrated into static analysers.

These kinds of things already exist. Snyk for example

Maybe it was not noticed earlier because serious companies have their server in VPC so that servers cannot connect to a random server on the internet that hosts malicious code.

@@srki22 a secure application should be secure on several layers. Relying on a firewall means that all you need is one vulnerability on the firewall to crack open your application.

@@FlorianWendelborn the scanners that exist only warn about confirmed vulnerabilities, not possible ones.

Yep, SQL injection is the first thing I thought of when I saw the exploit, the feature really is questionable.

The assumption seems to be that logs are not returned/exposed to users and that macro expansion is useful for debugging.

log4j lookup is the new format string

Well. This is also possible because developers tend to log data, they shouldn't. By logging user provided data you are essentially creating a database in terms of GDPR. If developers would log only non user data (user internal identifier for example), this vector of attack should not be possible. Log4j is exposing interface for devs, a trusted people, who should know what to put inside that string. But, people don't think about it. Let's just toString on everything!

My thoughts exactly. Even from a functionality standpoint it is stupid to pass user input directly into such a method. I mean what if some legit user input contains "${...}"? Is an exception thrown and the message not logged? Is the message just scrambled? Either way it shouldn't have been done like this just due to functionality. And security wise it is a well known issue and bad practice. It is known from contexts of SQL injections, shell injections and so on. And even for the pretty old printf function it is clear Zou have to pass user input as a later argument and not as the first/format Parameter. I mean obviously how the Log4j stuff works and is used is problematic. However all in all it seems to be more of a usage issue/mistake than an actual bug in the library. The whole jndi thing is well dangerous too. Such requests should for one be made explicitly and secondly be made once at startup. But to meet the whole java stuff seems to be a mess anyway...

its beyond me

it's basically spicy SQL injection

@@hhvhhvcz This is much worse than that. This is "SQL injection" iff the injection part would work on prepared statements... that is the bonkers part. Imagine someone would process SQL commands in your query parameters.

@@pavelhoral this is SQL injection if the RDBMS could be convinced to download arbitrary code and execute it.

Agreed 100%... The most sane approach for this would simply be to require the developer to perform the JNDI lookup themselves and log whatever contents are desired using the more standard Log4J formatting options. Even ignoring security implications, requiring some type of (slow) network transfer simply to log a string is bizarre. I understand the getting some data from some network location and logging some of that data, but only in a scenario where you're also going to *use that data for something!* If you just download something, log it, then throw it away... why?

This is probably the case for a lot of vulnerabilities. I heard the NSA is just hoarding zero days. The probability that another person discovers the same zero day completely on their own is more than 0%

Pretty sure NSA and the likes used it in their ops.

Not that baffling to me, looks like it was a combination of far too specific scope/mindset during that JNDI research/talk so they did not even consider the software using JDNI, and the classic 'someone else's problem to fix'. Also I think you mean "yet it was NOT treated as the serious security flaw"

Absolutely. And library developers should also collect feedbacks on how frequent a certain feature has been used, in order to align with user expectations.

actually this template substitution happes in the parameters, not in the format string.

en.wikipedia.org/wiki/Principle_of_least_astonishment ;)

Yeah that makes sense. At least from the documentation it seems that way. However the issue in 2014 with the unexpected lookup should have lead them to realize it. They treated it as an expected behaviour, no?

@@LiveOverflow Yeah that is a good point. I see that a symptom of feature inertia. The developers saw this and thought "well that's weird but I guess we can add config to disable it" without stopping to think whether or not this was a feature that should exist at all.

When you talk about patterns or messages, you mean the patterns used in configuration files and the messages that are sent to logger, right? I wonder how that same lookup feature could really slip in unintentionally then. Something like the pattern values being expanded first and lookups being performed as the next step? But that seems to immediately raise a question of "what if the expanded values had lookup substrings in them"

@@aspuzling That is why this mess is really the developers fault.

LOL that is so bad, that is like using Prepare Statement where the SQL is coming from user input instead of hard configuration file within the application itself. Yeah people do these kind of stupid stuff.

yelled at for not writing docs, yelled at for writing too detailed damned if you do, damned if you dont LOL

Remember folks, separation of stateand logic in code is essential (I know, completely opposite of what you were taught at UNI in OOP classes 😁)

The feature is already part of the earliest java versions, in a time when the internet wasn't as widespread, hacking and security was still a thing a few people did for the lolz and there was not as much care about data and how to best protect them. Legacy things don't have the best track record for security.

Serialization is from back when Java was the dream of commoditized classes. The dream was that business people would just slap together premade objects downloaded directly from the internet in GUIs, and that would be programming. The dream was big marketplaces if custom objects and effortless integration. Reality fell far short, but that's why serialization is what it is.

This was engineered long before even microservices was a thing. But yes, that was a very idiot idea 😅

That one dev be like: If object can used everywhere in Java, why can just sent it in the network also... That would be COOL...