 Happy Friday, December 10th of 2021 and less happy Friday for anyone dealing with the vulnerability that was recently disclosed on, well, just December 9th of 2021 in the Java log4j library. This is a pretty widespread application affecting companies ranging from Tesla to Twitter to Minecraft. And yes, it apparently is actively exploitable in Minecraft. So there's a lot of servers being pushed out and updated right now. And I'll be covering from the blog post here over at Huntress and along with a Reddit post and of course some details that I wanna cover including the fact that this has a base CVSS score of 10. Yes, 10, the worst you can get. Let's start with though a big thanks to Kevin Beaumont who's been discussing this. If you're not familiar or follow Kevin Beaumont AKA Gossy the Dog does some really great and solid security research. Definitely worth following on Twitter. And I like to thank him for this wonderful logo because I think every exploit needs a logo. And I actually like this one because it's a trivially exploit with a trivially drawn logo in MS Paint. So it made me smile because nothing else about this vulnerability makes me smile with one more minor exception the Minecraft, John Hammond targeting Minecraft because why not if you're gonna do a proof of concept on something, why not start with a game? Obviously this is very serious but let's talk about just how trivial this is. There's a lot of places affected by this. What should you do? Now this is where we'll start. If your organization uses the log4j library upgrade to and they've got the new version right here log4j 2.150 RC2 but I wanna talk about where your risk factor is and kind of how this actually works. Because the how it works part is mind-blowingly simple and the attacker vector is extremely trivial for threat actors. A single string of text can trigger an application to reach out to an external location if it is logged via the firmable instance of log4j. So if you have a web server, a unified controller or a mail server, any different service that runs that maybe you want logging. And when you think about how it logs it's going to take this log information and we write it to var log and the Linux world that's pretty common. And the facilities that write it are just kind of boring. They're gonna take the log data and drop it there and boring is okay but sometimes you wanna look at it in a little bit more depth and maybe take some action on it and that's where log4j comes in. So you actually take in your logs prior to doing them just settling them somewhere for archival reasons you'll actually parse them with log4j. That's where the problem comes in. And this is what makes this such an easy vulnerability to exploit and I've already seen these exploits coming against my own servers. But just because you see the exploit being targeted at you does not mean it can be exploited because the way it works is any of these logs being collected, the people sending out the requests and the threat actors that have set up beacons and just hammering away at Apache servers and anything they can find publicly available on the internet and sending and seeing what comes back. They send that command and if the back end of your system is using this log4j, this is where companies like Tesla, Twitter and Elasticsearch and all these different services have this and if they're using it to parse that log data it's as trivial as that command right here. They put in this right here and that's it. It will then execute at the permission levels at the level that that log4j library has. So if you've run vulnerability application as a high level permission, it now can start executing whatever payload was sent to it. So it's not necessarily though that everything that depends on this library is going to be exploitable but there's a high probability that things that depend on this library are. And essentially this comes down to wondering how long this has been around. We'll actually start here in 2013. So I wanted to do a little bit of research because I was curious, is this new? Is this from some update something opened up and it was on parse? I did find a few references to this and it makes complete sense. This was implemented right around 2013 and it was lookup plugin support. Basically what this log facility does is if you want to take more action on your log and actually have it trigger different things. This is actually very handy. We can say, hey, look up these resources, do this information, not only look at the log but then take action on it so we can have our server do some type of defined actions and look things up based on the information we find in a log. So that implementation was done, but it wasn't done properly because they didn't sanitize the input. So the execution part comes because of the way you can simply use these couple commands as pointed out right here. If you add this right here, that's it. It will then go, oh, I think you mean to run this. So you're taking kind of an advantage of unparsed information that was supposed to be parsed out and sanitize before it went through so it can run the commands and jumping it right to the command. So you're injecting a command in a spot that the person who would have wrote the logging tool would have had their command. So it's a little bit of a clever hack in terms of finding it but really trivial in terms of exploiting it. So any type of server that happens to be sending input data through this logging facility potentially could be exploited. There's gonna be all kinds of nuance to how different companies actually do their implementation but obviously it's big enough to have this high of a CVS score and cause a lot of stir in the tech industry right now because it's obviously very, very exploitable. I was actually happy to see Unify had a patch out right away. There's no known as of the making of this video vulnerabilities in Unify from it but the fact that they're dependent on that library there could be some way even if it's not an obvious way that you could send or get a Unify endpoint to create a log that it would parse and then do that because that becomes a little bit tricky because it's not exactly open to the public. It's more like the logging facility of each device could possibly make this malformed thing but then could you take over a device and use it? This is where a lot of people and other friends of mine including Riley Chase over at Hostify who's been pushing up patches as well. A lot of people are looking to see if there's a deeper vulnerability that can be found within this because I think it's very important to be clear when I say right now there's not unknown but as long as we know that libraries hanging out in different applications that gives you the idea of poking at each thing until there's a way you can get around it and see if it will actually execute code. And this is what people have been doing. I've seen people do things like, well, a little bit confusing but it looks like they can rename even their phone and put in the payload as the name of a phone and allegedly based on a Twitter post I seen that was a way they were able to see if it would beacon out and do a lookup. So anything that puts you a little bit closer to there because like I said, Apple, Twitter, lots of places are using this particular log library. It is immensely popular. So this is going to be kind of the ripple effect where even though we see a lot of major companies doing it now we know there's probably a lot of things that later on down the road someone will be looking things up and find an application that never updated this particular library and then start poking away at it. So it's hard to really determine the entire extent having that library does not always mean exploitable but it certainly means potential for exploit and we'll just kind of have to watch as companies patch this and hopefully they patch it and it's better to patch first before you find out there's a vulnerability which is what Unify did. They updated to the newer version of library that parses the data properly but has I even seen companies like VMware and I don't know what version they're using but even large companies like that are still using some of these libraries in there. So we're going to probably see a just chain of updates that are going on for a long time on this. I'll leave links to everything I talked about. Leave your thoughts and comments down below. If you have a system you need to patch, patch it. If you're running a Unify controller which I know a lot of my audience do go ahead and update that to the latest version as of today it was released and I'll leave links to that down below as well. All right, thanks. And thank you for making it all the way to the end of this video. If you've enjoyed the content, please give us a thumbs up. If you would like to see more content from this channel hit the subscribe button and the bell icon. If you'd like to hire a short project head over to lauranceystems.com and click the hires button right at the top. To help this channel out in other ways there's a join button here for YouTube and a Patreon page where your support is greatly appreciated. For deals, discounts and offers check out our affiliate links in the description of all of our videos including a link to our shirt store where we have a wide variety of shirts that we sell and designs come out well randomly. So check back frequently. And finally our forums, forums.laurancesystems.com is where you can have a more in-depth discussion about this video and other tech topics covered on this channel. Thanks again for watching and look forward to hearing from you.