Log4jShell Vulnerability Patch – Yotam Perkal, Rezilion

This is texturing TV. Hey guys. Thanks for the throw.

We're here with yotin purkle whose head of vulnerability research for resilient and we'll be talking about log4j shell vulnerabilities and why they're still with this, you know, welcome the show. Thanks, Mike that to be here. So you guys just did a study on how many of these vulnerabilities are out there and it's kind of surprisingly high.

So why is that? So the there are several reasons. I think one of the main ones is the fact that although it sounds like at least to me or security repetitioners that are in the field that are dealing with these vulnerabilities on a day-to-day basis that you know, no one there's no one that have hasn't heard of luck for Shell.

There are probably organizations that are less security aware that have less mature processes in place that probably don't even have the ability to To validate whether they're vulnerable or not. So not alone do the actual patching. So if they don't know that they're vulnerable then they won't patch and and they'll still have systems that are exploitable.

So that's I think that's a major reason like the the more mature organizations the the corporations. Hopefully they they are more in this point in time. There are already patched and and Um, but but there's always a long tail of less mature organizations small organizations that that are probably still that could explain that.

that fact It's not easy to find these things though because they are embedded so deeply within job application. So is that part of the challenge? Yeah, definitely definitely one of the things with specifically with blog for Shell which is the vulnerability and lack for Jay, which is the underline vulnerable library is because it should it's a Java library and it's often often a dependency.

So it's not like the application that you run but you have an application that has to log and then it basically uses the lock for J. Library is a dependency and because of the way Java is structure basically that the way the flexibility did Java enables to package code then you can have an executable that has several layers. Of like you have a jar which is a Javan executable and within and within it you have an additional jar Etc.

So that layer of those layers of nesting make it difficult for some of the scanners to actually be able to detect it. So that's one problem. There's there are also I won't go into it too much but they're also a various way to package Java application and some of the scanners have certain gaps this also research that we published a while back that they are not well equipped to identify all these cases.

So that's another thing. Yeah, I think that yeah, those are like the major difficulties with regards to to detecting. So what's your organizations be doing to detect this vulnerability?

Is there a set of best practices or their tools or you know what's missing in the equation? Yeah, so a term that is often thrown in the air like in the last six months or so, even a bit before is the his ass bomb like you software below materials. You have to know what you have.

What are the components? There are? That your software is comprised of and once you have a way to know that then identification is easier.

You don't have to scan your system constantly to to understand what's in there. If you already have this software develop materials that you can refer to in case of vulnerability such as log for shells turns out you simply look on across your ecosystem and all those software materials and identify where what are the applications that are vulnerable the problem is that The landscape for it is still not completely mature. Like it's one thing when you have your code then then you know, usually or hopefully or the likelihood that you know, what's running in it is is higher but you know in our dnage people don't write quotes from scratch.

They use third party libraries. So in in one hand this enables the organization to run faster release code faster, but on the other hand, it's you basically get an inherited security risk and with this third party software and it could be open source, and it could be even commercial software that you use you don't always know what's in there and that's again an additional challenge. Do you think that the bad guys are out looking for this vulnerability now and do they have tools to go scan for it or how are they find it?

Yeah, so basically that the same procedure that we did, you know research the same goes for attackers like you can have a diversary that does the same thing it's not basically it is pretty common knowledge what applications at least like a large amount of the services that are impacted released, you know security advisories said okay, we were impacted we Pat this in version X so, you know, what are those services and what's left for an attacker is basically to try to identify services that you know, there are vulnerable just in versions there are still not patched and that you can do in several ways the way that we went about it in our research is using shonan which is like an open source. Tool that allows you basically like a search engine, but for Internet connected devices, so if you're you have a server. That is internet facing then Showdown will be able to identify and children is one example, but there are other services like that.

And then if you have a service that is exposed to the internet, there are ways that you can deduce in some in some cases versions of software that is running in it. And if you identify a vulnerable version then that's a Target that is exploitable. That's basically the methodology that we use in our research, right?

We've been talking about devsecops forever today. Do you think that these vulnerabilities are going to drive more people down that path and one of the challenges and actually getting there. Yeah, so I do think that you know step by step.

The industry is improving in that sense. And and that's a cops practices are being adopted more and more and that's a cop maturity. There are organization that are more mature in the on you know, if it there's a like a spectrum of maturity then then we do see organizations that are more mature that have proper Tooling in place and in CI and CD mechanisms and the monitoring that allows them to detect these kinds of vulnerabilities, but I think we still have a long way to go and if we really discussed a bit about as bomb.

So again, even if you have like a third party vendor That you acquire software from then I think there's still some amount of Education to be made like for you for that particular customer to say to the vendor. Okay. I like your software.

I'd like to buy it. But but I I want you to to provide me with the software bit of materials as a precondition to the to the purchase and you know that there are steps that are being made in that direction, you know from the government and on Federal. uh in federal, you know agencies or organizations, but but on the like more commercial front, I think there's still some way to go.

What is your sense of? The role of cybersecurity teams going to be going forward because it feels like you know historically we just kind of through over various vulnerabilities and developers may or may not have chosen to follow up on those. Is that going to get better?

Is there a way to start prioritizing things? So yeah, I think I think prioritization is is actually key. I think because as we said earlier a lot of the software that you use and as an organization is in software that you actually wrote it you don't control you use for example, like a Docker container or that that you can run it in its latest version one day and then you run the latest version the next day and it's a different version and now you introduce a new vulnerability to environment.

So I think two things are are critical and that sense. It's one is visibility. You have to have the Tooling in place in order to know what's running in your environment.

The other thing is like you said prioritization because we live in a world where like there's no organization that doesn't have vulnerabilities at all like from the reasons that that we mentioned so you have some organization tens of thousands of vulnerabilities depending on the size of the organization like the amount of of compute that they have and you need a way smarter way to be able to prioritize fixing these vulnerabilities so that you can focus on the ones that actually matter the ones that are likely to be exploited the ones that are actually being you know that are applicable to code that is actually being used and being run and executed because if you if you have a package that is installed and you just sitting on disk and it's not running then it's not likely to be exploited because you know, you need to have code running loaded to memory in order for an expert to be To have something to exploit have to have a running process so that there are all sorts of strategies and and methods for smarter better partization that will allow these organizations to to actually focus on the vulnerabilities that matter most or they start with them and and that's improving their security posture. Do you think we're going to see more of these so-called zero day vulnerabilities? Because that seems to be where the shock of the system is is people wake up one day and they're just, you know, running around with their heads chopped off because yeah, they weren't expecting this and suddenly it's there and will there be more that kind of yeah, so I think it'd be responsible in mind to say that that we won't be in continuing those because you know as long as People are riding code.

They'll be bugs and those bugs sometimes lead to to you know, I vulnerabilities and those only the abilities would be exploited and there's no Silver Bullet. So again, sometimes you know that I think there's there has to be basically a shift of mindset that You should assume that at some point in in time you would be vulnerable or susceptible to some kind of exploitation and you have to to be ready for it. So whether it's be having the right tools as we said or processes in place, whether it be performing tabletop acts exercises, for example, okay, let's say that tomorrow morning this package.

Why is vulnerable with the critical vulnerability? Please security team. Let me know where we have this package installed in, you know on our environment, you know as a system for example, basically Organization security repetitioners, they can't assume that that these things won't continue to happen and some frequency.

Sometimes it will be relevant or applicable to their organization. Sometimes it won't but but that's the mind that mindset. I think that that we have to to adopt.

All right. What's your best advice to folks? What should they be thinking about in you know, what's the what's the action item?

So I think specifically with the regards to look for Shell or look for Jay vulnerabilities. I think at this point in time. If you haven't addressed it by now, then I think apart from you know, making sure that you're not vulnerable and touching where we're needed.

You have to basically assume compromise because it's been over six months since it's vulnerability was released. There are multiple evidence of it being exploited in the wild. So at this point in time if you find yourself still susceptible after you patch try to to do some incident response actions and and try to identify whether you see any suspicious Behavior or things that are out of place in your system because look for Shell is an initial access type of vulnerability so it could be that someone has used it in order to gain initial access to your organization and it just Waits sits and wait for the right moment to before Any kind of action it can be that it's filtration.

It can be something that is more devastative, you know, like an announcer this and things of that sort. So so that that is what I would say for one. And in general again making sure that that your organization has the right Tooling in place to be able to identify that and also I would say it's not a wine one of thing.

Like you have to have these things running periodically because we saw with one of our customers that you know, they were aware of love for Shell they did patch it but then they have like Ci processes that kept pulling in vulnerable components into the environment and then it's it's irrelevant everything that all the work that they they have accomplished. If if you're not aware of that then then you you still vulnerable and you don't even know so continuous monitoring and visibility I think is key. All right, great.

Hey, it's a never-ending battle yodum. Thanks. Yeah.

My pleasure. Thanks for having me Mike. All right back to you guys in the studio.