 Time here for more on systems and it is December 18th of 2021. And yes, another vulnerability was found and posted on December 17th of 2021 and the log for J. But I wanted to talk about the Center for Internet Security and their log for J playbook. Because ultimately a playbook is good because I'm sure by the time you're watching this or it could be possibly one or even more vulnerabilities found since the publishing of this video. So going back to a process and procedure, a playbook and walking you through it is extremely helpful in terms of how you can help mitigate this particular problem. And what this playbook does is it's walks you through the basic procedures of looking for the software, remedying the software. And of course has a list of resources linked down below that will offer you tools so you can do your own testing on this. Now the links that are included is one to the CISA GitHub, which does have a really long list of software because the first step is figuring out what software is in your environment and then determining if that software is vulnerable. The list that CISA has over on GitHub is a long, long list of software, but it is by no means an exhaustive list of every single piece of software that could be out there and doesn't cover at all really any one-off written applications that maybe people had custom coded. In those cases, you'll have to rely on those vendors and contacting them directly and figuring out if there's a patch available. Now a couple of the interesting things is Huntress has a testing tool and MAP has a testing tool. And a little bit more controversial is a tool by Cyber Reason, which is interesting because instead of using the exploit and determining if it's there, this tool actually removes part of the functionality of the library that allows it to be exploit. I don't know if it's the way I would recommend patching because there's some big risks that comes with this, but nonetheless, it's another tool in the toolkit that's out there and use at your own risk. And of course only use on servers that you have permission to use because, well, as much as there's a vigilante idealism that went with this, I've seen posted a few times of, hey, can't we just spray it out there and that'll fix all the ones that don't get patched? Ideally, it sounds good, but it's still not legal for you to go around patching other people's servers and just sending things out there for things that you do not have authorization to modify. So interesting thought, I don't know where you may fall on this, but in terms of the legal ramifications, it's not legal. That part is pretty clear right now. You can't just manipulate other people's servers. It is unfortunate because yes, I'm highly aware that this will not be patched anytime soon just because there's a patch available doesn't mean people will patch. We're still looking at old vulnerabilities that are so, well, completely available on the internet long and long after the patch has been available for them. I will leave links to everything I mentioned down below. This is gonna be an interesting and bumpy ride getting things updated. I've done a couple of videos talking about Unify who their controller specifically is based on Java. Therefore, vulnerable to this, the only other thing in my environment that I had to directly address was gray log because it's built on elastic and elastic is built with Java. Therefore, there was a vulnerability within that. So that was quite scary having my logging application potentially be the potential exploit by logging something that wasn't vulnerable but by piping it into logging. So I'm glad that they were very quick and they've been very on top of keeping these libraries up-to-date. So far there's no other software in my environment that I have to directly address but go ahead and check that list. Look for anything that might be using it. Go ahead and use those testing tools on software that you control. Those are all linked out in there and I think it's a great guide and hopefully it helps you understand better what to do whenever the next vulnerability comes out for log4j whether it's this one we're dealing with that's available today or the ones that we may find in the future because the first one was the worst one but obviously attacks and the payloads are gonna get better. So they're undoubtedly gonna find more as security researchers have more and more time to poke at this. That's just the nature of things. The tax get better, not worse. As there's more time given, they're gonna keep fuzzing it until they find new commands that do new fun things with log4j until there's yet another update for it. 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 laurancesystems.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. 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.