what is the log4shell vulnerability? (beginner - intermediate) anthony explains #370

hello and welcome to another video in this one we're going to be talking about the log for shell vulnerability which has just recently come out um i had a bunch of questions in my stream which were like what what is this what does it mean and i wanted to break it down into terms that should be basically understandable by anyone uh and give you some best advice on how to move forward uh but anyway without further ado let's jump into it i'm gonna start by talking about what log4j is and log4j is a logging library is i think the most popular logging library at least it was last time i wrote a bunch of java and this means that a lot of applications use log4j you can basically expect that if you're running java you are probably running some library which is using log4j to do its logging it's you know it's ubiquitous and extremely popular and it's open source and it's been around for decades and you know since since java is uh fairly popular you're going to have quite a few things that are running log4j and so you know over the next couple of days you're probably going to have lots of software updates and if your company isn't already trying to mitigate this they're probably scrambling to upgrade everything and make sure that they're not running this version all right so the next thing that we have to talk about in log for j and log for show is jndi and kind of explaining what that is uh admittedly the documentation for jndi is not that thorough it doesn't really go into a lot of the details here it really just talks about you know you have a java application you use the jndi api and that integrates with these external services it doesn't really talk about the scope of just how wild jndi is or at least how wild it would seem in the modern day jndi again has been around for a really long time you know modern clouds are relatively new and you know the the models of security that we've designed for today are very different than the ones that may have existed even five or ten years ago where it was fairly common to plop some binary of enterprise software on some machine and that would never connect to the internet never connect outside of the network and so the the threat models were very different then but let me kind of show you how i think about jndi um so we have a little a little paint diagram here uh the way jndi works is you have your main java program here uh and this is independent of log4j this is just jndi is a separate technology from log4j uh and what your java program and admittedly this was much more common back then not as common today hopefully not as common today uh your java program may have shipped with some you know very specific functionality that it needs to do but some company may need special behavior from that and so what you essentially do in code and this is not exactly how the code works but you can kind of imagine it working this way you call some sort of jndi function with a string usually this string refers to these little building blocks down here which are external services ldap is the one that was called out most specifically in the vulnerability ldap is oftenly used often used for usernames and passwords and logins and managing sort of your your user space of uh you know a company but ldap is a generalized directory protocol and you can store whatever you want in there and so what you would usually do with with jdni is you would call out to some sort of ldap server usually one that you own so you know on 10.0.0. whatever should move this down here so so let's say you know you you're running an ldap server on this particular port and you may access some uh resource here and what this resource represents is a bit of executable java code at least that's how you can think about it like more specifically it's a class file or something like that but this lives on some external ldap server and this lookup here is going to go to that ldap server and pull down that binary blob and uh instantiate that inside of the jvm and that binary blob is going to contain some amount of code oops that is not the squiggly line that i wanted it to be there we go uh and so you know you you store inside of ldap uh a particular you know executable java blob you can kind of think of this as like you know java.exe it's not actually an exe it's more like a code a class file that gets loaded into the java virtual machine it's not an actual executable but you can basically think of it as an executable um we'll call it java.class so that it's slightly less it's it's not actually that but you can think of it that way and what this uh jndi call does is it pulls that object into the jvm and executes it so this could be used as like a dynamic plug-in system think of it like you know i've downloaded this enterprise software uh i don't need to update that software but i can customize its behavior by injecting my own custom code into it or at least that's the idea this kind of idea is a little bit insane in uh in modern software you usually don't want to reach out to the network to pull code down uh you know rpc magic like that is a little bit a little bit concerning uh but this is jndi you know this this was much more necessary in a in a previous age of programming um okay so that's jndi and you know there's many other plugins rather than lnap like you can see here you could even use dns or i don't know what these other ones are but you could use some other naming interface plugin to store this jndi data so you know this may not be ldap but it could be any other thing in the particular vulnerability in log for shell they call it ldap and ldap s which i believe is the ssl equivalent of that but okay so that's jndi we've also talked we've already talked about log4j let's talk about the cve itself so the cv itself is this one here i'm not gonna read this uh but the the tl dr of it is when logging so if we go back to here our java program this is usually an explicit piece of code that does this um but in log for che there are a bunch of placeholders and so let's actually just make a new paint diagram so in long4j uh you might have like log dot warning this is not the exact method uh because i i don't know the exact method i haven't worked with log4j in a while um you might log some sort of data like this uh you know something maybe common like um i know the user agent maybe your web app uh see so probably not warning it would probably be info in that case um request user agents and maybe you would substitute in the request.useragent or something like that this is this is of course nonsense code uh of course in java it would probably be user agent or whatever but you can imagine a log request like this log4j supports a bunch of different substitutions inside of this string and one of the ones that it supports is a substitution that looks like this um jndi and then ldap and then you know similar to what i had listed before with song host and you know some string here and what what log for j will do with this substitution here is it will do a lookup uh using jndi similar to what we did here with with our jndi lookup against this ldap resource pull down that blob execute it and then insert whatever the result is into this string so it's basically a string placeholder and this could allow you to customize the logging behavior at runtime without having to recompile the code and without having to change you know whatever is going on in there you can just kind of adjust this here but as soon as you allow any user controllable content such as you know user agent chat messages like for instance minecraft was vulnerable to this you could type this this sort of string into chat and the log4j machinery would pull down this this particular blob and execute it but yeah basically any time you allow user generated content into this string it could take these placeholders and execute them which is a big problem you really do not want to allow user accessible content to execute code that's why it is a remote code vulnerability but if we look in kind of a blob diagram of how this would work you could imagine you're running either your server say this is minecraft.jar or whatever [Music] and you could have a malicious so we'll call it this i don't know reddish i guess that's pink whatever this is a malicious uh malicious ldap server that the attacker controls uh so this is controlled by the attacker and then the attacker needs all they need to do is issue some sort of request to oh i took the squiggly line wrong again they need to issue some sort of request to this server here which contains that little string so if we you know assume that this string was sent by by that that request here let's put this in it's parent oops so let's say the attacker sends this here maybe this is in a chat message in game or something like that now this server is going to interpolate this jndi string call out to this ldap server here that the attacker controls pull down the malicious code here and run it directly in here and as soon as they you know as soon as you're running arbitrary code you can do all sorts of stuff you know steal whatever information is running on the server or you know infect other people or infect other servers and control other stuff inside the network now when you have arbitrary code you can basically do anything and so this is kind of the basics of how this vulnerability works um so the the next question that most people have is like this this jndi thing is insane how did this possibly get into log4j and i i kind of harp back a little bit to you know programming was a very different thing five ten years ago and uh you know log4j is an open source piece of software and so people send requests to it all the time and logger j has all sorts of different other lookups already so if you look at the logs or the docs for their lookups see there's you know date formatting there's specific stuff for docker there's environment variables there's just like all sorts of stuff that you can look up you can look up stuff about the java runtime there's of course the jndi bit which is the problematic one you can look up jvm arguments there's specific stuff for kubernetes in there even there's all sorts of features that are built into log4j for a crazy amount of things that are doing lookups here and so admittedly adding another one for jndi is just another lookup it's just another feature there's already a bunch of them so it's not super surprising that some feature like this was accepted um and in fact we can actually look at the original bug report that was created for this this was back in 2013 and again clouds were like brand new in 2013 the internet was a very different place and the security models were not exactly the same as what you would expect today enterprise java was still like a huge thing i mean it still is a huge thing today but imagining some some enterprise situation but yeah this was just a issue add jndi look and look up support uh they even provided a full patch for this and they linked to other lookups and were like hey you know there's a whole bunch of them here it'd be really nice if we could have this feature as well uh they attached the patch the maintainers reviewed it and merged it the patch is actually very straightforward pretty readable you can see they added a new look up here this is the implementation of jndi so you can see this is where they do the jndi lookup this is very similar to the imaginary function that i wrote earlier today um and yeah basically we're able to get this into uh log4j and have it be a supported and released feature and that's not all that surprising like if you look at the amount of lookups that log4j has there's a lot of complexity here and adding just a little bit of incremental complexity more was you know not a big deal okay so let's talk about mitigation strategies next like how do you prevent yourself from getting owned from this vulnerability if you're a user of software the best that you can really do right now is pay attention to upgrades for software that you're using and make sure that you're updating them like if you're running a minecraft server restart it if you're running any sort of other java software try and get updates as soon as possible but from a server perspective there's a kind of a couple of things here and i'm not going to go over all of them and they will probably change over time so this is you know these are the mitigations that are in place today there may be better ones in the future uh the easiest one by far is to upgrade from log4j to at least version 215.0 this has been disabled by default you can still enable it if you absolutely need jndi which hopefully you don't but you may need it and you can also disable some of the features in previous versions through a configuration or you can just compile you can just remove this class you can remove this class from the jar entirely so you can just avoid having that functionality just by cutting that part out and it should still function properly so these are some mitigations here they're not perfect some other mitigations that i've seen as well so if you imagine you know this is let's let's not make this a minecraft server let's make this instead just like an http server some http server and let's imagine that this string is being sent as a user agent some mitigations that i've seen is to take your load balancer which probably exists between your servers and the external part and just block any strings that contain any requests which contains strings like this and i've seen a couple websites which have done this already and i think this is what cloudflare is doing to protect their downstreams basically saying hey if you send a request which looks malicious because it has this jndi string in it we're just going to drop your request usually with like a 406 or something like that basically just preventing the request from even getting to the server uh you know in case it's easier to do that rather than upgrade some stuff that's vulnerable so those are some of the strategies that i've seen before um and the other thing that i've heard a lot from this is like man what what the heck how how is how is this okay how did somebody get this committed in and i don't know this one this one hits a little close to home to me because i am also an open source material and i completely understand the perspective of the log for j maintainers here they're doing this entirely in their in their free time they're not paid to work on j uh they they do it it's essentially charity work and um you know there's a lot of complexity in log4j it's very popular it's existed for a really long time so i i don't i don't blame the maintainers whatsoever uh but the other part about this is like you know we should we should probably um should probably start paying people a little bit better like open sources somewhat unsustainable i'm not to get into politics but like it makes a lot of sense from you know capitalist society why open sources proliferate proliferated in this way but i would love to see it change um a year or so ago i lost my job and i was trying to make open source work as a full-time thing and it didn't work out for me so now i have a new job but like yeah i would love to make open source a mistake a sustainable source of income and make that a way to be uh you know sustainable but yeah there's an xcc comic i'm going to not reiterate this here feel free to click through on that if you want and you know i work on a lot of important software in the python community so if you feel like this is something you feel strongly about you know you could sponsor me as well here um but yeah that's kind of the the uh overall thought that i had about log4j hopefully i explained how jndi work works and how this vulnerability works so you can understand it as well yeah if you have any questions leave them in the comments and i'll see you around in the next one you

Channel: anthonywritescode

Views: 937

Keywords:

Id: A5BLKKYIQ28

Length: 18min 8sec (1088 seconds)

Published: Mon Dec 13 2021