Log4Shell Security Exploit Deep Dive (Using Spring Boot and Maven application example)

hello and welcome back to devexplaining channel i recently did a video on lock for shell uh vulnerability and exploit towards log4j framework and java based applications uh the video got a lot of attention and i actually got a lot of questions so i promised and wanted to do a deep dive and here we go today i will demonstrate in a bit more concrete manners what this exploit is about in which scenario you are definitely vulnerable and i will demonstrate also some ways how you can protect yourself and because this is pretty nasty exploit and i think we have just began to see the effects i think this might be worth the watch even though this is a little bit longer than my previous video so let's get started let's dive into it i already mentioned that if you are running java application and if you have log4j in your class path and version is vulnerable then there's a high possibility that your application may be compromised um vulnerable versions begin from 2.0 from the betas all the way to 2.15 and only way to kind of guarantee that you are as safe as you can be would be to use 2.15.0 full version okay so if you're running 4j version 1 there are even more exploits so i wouldn't say you are safe but some claim that this vulnerability does not affect you if it does that would be really bad news because it's a kind of outer end of life so it's not getting any updates anymore what triggers the vulnerability well when users are able to somehow effect something that gets locked so something that goes through lock4j and you have a vulnerable version running then that will trigger the vulnerability for example i've seen minecraft servers log userchat somewhere that triggers it there's some videos on exploits already being made with it might be some access logging http headers might be triggering this content might be triggering this and sometimes when you have an exception the handling might be logging something through log4j and then if the exception itself contains something from the kind of user you might be hit by this exploit so a lot of things might be triggering this and also uh i cannot tell if you are i cannot tell hundred percent if you are vulnerable because it depends um it might depend on java version but let's get back to that later uh it it does depend on log4j library version or if you even have it in your class path if you don't have log4j this doesn't apply to you at all so no java no log4j no problem for this particular exploit but if you have a 4j then the lock4j version becomes really really interesting and lock4j 2.15 is extremely recent so if you haven't updated like right now uh odds are that you are running a vulnerable version okay so i wanted to play with this a little bit and make some things more concrete for your benefit and therefore i created a spring boot application this is straight from spring boot initializer and therefore very kind of basic uh basic application and i'm running spring boot starter version 2.5.7 and that's uh containing positive that's possibly vulnerable i will explain shortly um by default it's using internal java logging library so by default if you just get this one and you don't add any dependencies you might be safe from this exploit but many people have either included directly log4j starter dependency or they are using some library that indirectly declares a dependency for log4j it's extremely common library so you might have transitive dependency it might not be visible in your palm straight away it might be deeper in the dependency path okay so how do you know let's say you have a maven application it can be spring boot or something else but how would you know if you are vulnerable well modern tools typically i'm running a vs code but your tool probably has same thing with different name but there's something called show effective palm if i run it i'm going to see not not just what i declared as a dependency but all the transitive dependence is resolved so this is actually giving me a manifest of all the things i have in my application and if i search for log4j well we can see that there is a vulnerable dependency version already declared and if i search for more what i'm looking for is log4j core so log4j core is the library that contains the nasty vulnerable code so if this is somehow included in your class path and the version is vulnerable version so something before 2.15 official then then you might be vulnerable depending on what you do with your logging but then i would really advise you to do something about it test it try to fix it immediately people are already exploiting this uh quite actively in the in the world wide web somebody asked are you safe if you have a if you don't have external apis so so if you're not connected to internet are you safe well yes and no your application might easily be hit from within as well so internal attacks are not that uncommon but i don't know so if anything is compromised within your network or if you have users that might like to get more uh foothold there within your internal network they might be exploiting this as well but typically i would say you get a lot more attacks still right now from outside but you are not safe from the inside ever security wise i can never say that you are safe from from inside attacks because those happen all the time but the biggest mass is of course in the internet facing side okay so i have a vulnerable application i have included the jar file last component that i need to to demonstrate the vulnerability is something that logs something that may be affected from outside and this is not my own doing i grabbed the code from another repository i'll drop the link in the description section of my video as always so there is a christopher uh who has been active in this and he's written many blogs and many tweets and also there's a github where you can grab this application and i think i have it open here so it looks like this so my code is not the same but i did use one controller from here because that was a convenient but there's a lot more information and this includes also the exploits that can be used i have been a little bit light footed on the exploits uh it's not the focus i want to show today i'm more on the protection side so i'm more showing how you can protect and figure out if you are vulnerable but there's a lot more videos what nasties you can do with the exploits okay let's get uh i i will go a little bit there but not too heavily okay so i have a controller that exposes me so i have vulnerable lock for j version and i have one innocent line logging something but that something happens to come from http header and for sure i can effect that header so whether it's header whether it's content whether it's something from chat whether it's a deliberately caused exception that might contain the string if there is a possibility for somebody to put a string and if you are logging it and you have vulnerable version well you should pay attention you might be hit by hit by nasties okay let's demonstrate i'm not going to do too dramatic demonstration but just the bare minimum so i have a little bit of code here run vulnerable doesn't matter how you run it so it doesn't matter if it's spring boot or maven but i'm just using this to demonstrate the topic so if i run this script i'm starting my spring boot run application and it has the vulnerable uh vulnerable uh lock for sha look for j version in the class path that's all i need so let's hit it let's go here and let's go here and let's grab one very tiny and innocent version to test this so i'm connecting my server port 8080 by default i'm sending a single header and the header is containing this nasty injection so the nasty injection is obviously dynamic code that vulnerable versions of log4j try to resolve and when they resolve it there is comment to con contact to jnd ilda observer at the 120 127.00 sorry yeah zero zero one slash a that's not up for me i don't have any nasty server there but if i had the server would be able to inject code that would be executed within my springboot application with the permissions it has and if you are wondering what that code can do well anything the permissions allow it to do anything really so some people have been injecting crypto mining servers that's pretty nasty and pretty common so you might get some code that starts crypto mining in your machine whether it's server or client doesn't matter and you are not even getting paid for that but there might also be code that will be looking crawling through your files and looking for interesting things like passwords or ssh keys or anything it can use to leverage and go even deeper or it might be scanning your network and trying to find other machines that it could inject that are running running suitable exploits so as i said nasty nasty nasty but this is innocent because i don't have this server by the way of course the server can be external it can be outside internet and it typically is but i don't have that server so when i run this what's going to happen is exception but the exception is telling me that i could have been hit right now so i did a very nasty a non-harmful penetration test but this is telling me that it was trying to look up it was trying to reach the server so very nasty i was vulnerable i was kind of hit with this right now okay so that's that's my test that's the proof of concept i need so uh let's go to next phase that might interest you more how do you protect yourself how do you make yourself not vulnerable or at least try to protect yourself as i said if your class path contains a vulnerable version of log4j however you set up your class path you might be vulnerable the best fix oh okay let's go back one thing before i go to the fix there's also a command maven dependency tree so if you're running maven if you're not running a vs code if you're not finding this uh show the kind of uh final form file effective palm file then you can do simply this one and you can see what's included and if log4j is included and if the version is bad then fix it immediately if you're not running any maven or something like that then you probably might have a folder containing jar files so then just go and look that folder up okay so how to make yourself safe well best option update log4j version 2.15.0 either that or drop it all together if you can do that if you don't have lock 4j or you have 2.15.0 you're safe let me demonstrate well safe is a dangerous world but at least you are protected from this particular exploit let me show you so there is a in spring boot blog there is a page again i'm dropping this link in your in your in the description of the video but they are telling you what to do pretty much there there's also instruction for gradle some other options you can do and they are also mentioning that in future release they are going to change the default version to be safe again so most applications over time will just give you good versions but right now they are recommending that because nasties are already out there actively trying to exploit this if you feel you are you are vulnerable do something right now so what i can do is something like this and let's do it so i'm going to go back to my palm and i'm going to unleash this thing that i already tested here so log4j2 version is now 2.15 and if i uh analyze my effective palm you can see that my core dependency just got pumped up to the safe version is it safe let's test so i'm going to run the same script same command to start this up but the dependencies are now better so log for log4j shouldn't be vulnerable anymore and i'm trying to attack my server failed there was no exception no attempt to resolve this it was just static text so they have changed it so that this resolution doesn't happen anymore and if you see this being locked that's okay but there was no network calls being made so all good in that sense so simple as that that's the best option for you really right now what if you cannot do that well let's go back before i i will demonstrate this as well let's actually go back to vulnerable so what if you cannot for some reason for one reason or another you cannot update the dependency perhaps it's a software that's in a package and you don't know how to update it and there is no fixes available yet there is another way that might work for you it's quite convenient but bad news is that it only works if you have at least version 2.10 of the log4j but not 2.15 so if you are somewhere here between you can try setting a property or environment variable and if you set it like so you are protected again let me demonstrate so i have another script version here that runs my boot application but i'm adding this little innocent thing that says when formatting message do no lookups please don't don't do lookups don't resolve the links so let's run my application with this one so i'm using a vulnerable version of log4j but i'm telling it to not do any lookups okay let's try to hit it i'm protected at least from this one at least from this variation i have to be a bit cautious here because there's already some variations going on and people are trying to modify this so that it would get through but if it's not doing any lookups at least this doesn't work so i'm in much better place right now so two ways to protect yourself if you are running older version where these things don't work and you cannot update the library well we have some nasty options but we are starting to get desperate here there are some claims that java versions might protect you so some people are saying that java 8 update 121 or 8 update 192 would protect you by setting these environment properties to false but i tried this and it's not working for me let me demonstrate so i'm actually running java 17. you would suppose that the late latest version of 17 should be safe as an extra kind of precaution i'm adding these extra parameters that are claimed to resolve the problem now i might be doing something wrong you never know but i have a point here so bear with me so i'm trying to run this with later latest java version that i have available and i'm trying to use these extra properties and i'm trying to hit it with the attack and i succeeded to do so i also tried java 8 versions that are supposedly protected and same results so i'm not convinced and the problem is that before you try to doing any desperate measures would be great if you managed to somehow figure out a way to test this so are you logging something that users can input are you able to input injection like that that is harmful unless you are actually running a server in that address in localhost address so so if you manage to test this then you manage to try these fixes and see if some of them work for you but otherwise if you just blindly try this don't assume they would protect you because they might or might not it's easy to miss with these so what else can you do well already mentioned that drop log 4j but if you have been leveraging log4j apis this might not be a convenient possibility for you you might need to do a lot of work there is another related thing you can modify the logging patterns like so but i don't like this at all because it requires extensive modifications to application and you might still miss some places so i wouldn't go there you can find the lock for j core jar and you can for example remove jndi lookup class but first of all there's already few versions of the exploit and some are using rmi so are you really protected if you remove it secondly if you manage to do as much why are you not just updating the latest version the whole package because you have to like open the package deleted class repackage it i think you might just want to update to the latest version it's if it's minor version update you should be safe but perhaps if you are running lock for j1 and feel that like you might be vulnerable you can try to do these desperate measures or log4j2 i would try to find a way how i could update it to version two and if you are on higher level if you are running applications that might contain vulnerable versions if you are not building them yourself you have to probably wait for official releases so i know that confluence and minecraft patches are already being made and over time you will get many more but right now writing this there might be some releases where you don't have a fix available you can see if you are able to fix it yourself using the guidelines i showed you but might be might be a bit bit of a kind of nasty place might be you are not able to do so okay so i'll drop the links in my video descriptions i think hopefully this was interesting for me uh sorry for you it was interesting for me and uh i have to say that i don't typically like to spook people about security because you could theorycraft a lot and make anything sound scary but well this is wide attack service so many applications out there written in java using log4j and vulnerable versions so many people not even knowing they are doing that and this is rather new finding but who knows how long people have been already trying to exploit it if you check your logs for this pattern you might find some interesting or scary stuff there so at least save your locks for forensics later and if you have been dealing with any personally identifiable information prepare kind of to do more more more forensics in that case and reporting okay um this is rather easy to exploit and there's plenty of videos that show you nasty extremely nasty things that you can do and nasty things that have been done so as i said uh cryptocoin miners file crawlers network scanners anything is possible if you open up this vulnerability so thanks for watching these videos uh just watching this made you hopefully wiser more aware and then analyze if you are vulnerable or not it might be useful to know if you are definitely not vulnerable for this exploit and if you are vulnerable might be at least good to understand it and start planning for it and there might be some things you can do right now to protect yourself so um as last a kind of tidbit uh the mars uh mars lander recently just proudly demo explained that they are using lock4j for the helicopter so hopefully nobody needs to go and do an on-site patching for the mars crawler helicopter lock4j is so commonly used that it's even in mars these days so even that might be vulnerable i don't know hopefully they can remote patch it to make sense so this was the bad joke section at the end thanks for watching see you in the future bye bye

Channel: DevXplaining

Views: 1,437

Keywords: java exploit, log4j vulnerability, spring boot, exploit, java, cve-2021-44228, cve 2021 exploit, cve 2021 44228, log4shell, security, cybersecurity, vulnerability, deepdive, log4j exploit explained

Id: tn496lRyJ_A

Length: 23min 4sec (1384 seconds)

Published: Sun Dec 12 2021