Uncovering Critical Vulnerabilities in Magento: A Deep Dive - Surfacing Security Ep 5

MG:
So today, Shubs, bit of a milestone, six years to the day of Asset Note.

Shubs: Yeah, I mean, it's all been, yeah, yeah, crazy. It's all been, it's all gone so quickly, to be honest. Yeah, I mean, six years, dude, I mean, it's, it's been pretty interesting six years, we've gone through so much stuff together. So it's been pretty exciting.

MG: But yeah, well, you just reminded me, because like, we don't really celebrate that sort of stuff. Typically, we kind of forget about those things. You know, because we're sort of heads down in the thick of it. But um, but yeah, I mean, pull back and reflect, right.

Shubs: Yeah, 100%. I think that's kind of one of the things when we're so focused on on, you know, building the best product, sometimes you can forget about these milestones, but it's definitely worth worth celebrating. Yeah, it's been a good good six years.

MG: Yes, for sure. For sure. So speaking of building the product, there was some interesting stuff that came out recently with Magento that I know you and the team were working on. Do you want to talk about that a bit more?

Shubs: Yeah, I mean, that was really interesting. Kind of a trend that I've seen. Really, really something weird, I guess, is, you know, we have all these different ASM companies that are trying to do the same sort of security research we're doing.

null: And

Shubs: We have all these vulnerabilities that come out of the blue, and we have things like EPSS and whatever else, but it's never an accurate reflection. One of the things that I realized with this Magento bug, and it's very similar to what we found with the Citrix fleet bug, is everyone just slept on it. This critical bug gets released in Magento. Adobe releases an advisory two weeks ago. It's a 9.8, and it's pre-authentication and XXE. And there's like no chatter on the internet about it. Like no one's talking about it. The EPSS score, if I recall, was like, like 0.98 or something. And you had like the progress move it bug as like a 98 like EPSS or what some really high EPSS or whatever it is, right? But it was a much higher EPSS. But that was really wild to me. Because when we saw that Magento bug, at least when I saw it, I realized that this is a much more critical bug that needs to be investigated. And to be completely honest, way higher priority than the move it transfer bug, because, and let me just explain it real quick. Yeah, the move it transfer bug, even though it got heaps of traction in the public, just because it's move it transfer, it is like one of the least Yeah, because of the history, right? It is like one of the least exploitable bugs that I've had the chance to dig into in the last like, you know, six months. It's like, not only do you need to like, know a username on the system, you also need to make sure that user has been enabled for that SFDPS access. Which, to be honest, those preconditions alone make it quite a, you know, difficult bug to exploit in the wild, just generally, right? Yes, it's an authentication bypass, but what do you get to access? Just the files on SFTP, not like the full panel and exploit things further or whatever. So anyways, regardless of that bug and our investigation there, what we found was the Magento bug everyone slept on, and there was no publications except for, and this was really funny as well, as I was digging into the bug, the only publication I found was from the author of the bug itself, who was Space Wasp, his name's Sergei, or Sergei, whatever his name is, but he works at AWS, he's been researching Magento for some time, and he had published a GitHub gist with some details of the bug. Now, I was already maybe six, seven hours into reversing the bug. And honestly, his GitHub post was very, very helpful when it came to understanding the issue. But it was still not enough. It wasn't enough to recreate the POC, basically. But yeah, the Magento bug, for those that are listening to this that don't know about it, basically pre-authentication bug that relies on deserialization that leads to XML entity injection. And you can steal any local files from the system. The impact is a lot more than just being able to steal, you know, the ETC password or whatever. You can steal the env.php file, which contains a cryptographic key that then lets you sign your own JWTs that lets you log into the REST API as an admin user, basically.

MG: Right. Right. So, so, you know, very impactful. What's, what's sort of the scale of Magento, right? Cause Magento is used everywhere. Um, and I think contextually as well, the other, the other issue with Magento is it's, it's used in commerce, right. Um, it's used for, um, you know, payment, you know, um, payment apps and like, you know, short storefront apps and things like that. Right. So, so there's a, a bit of an impact that's perhaps a bit broader than just, um, you know, a single organization, right? It also can really affect the users of those apps, right?

Shubs: Yeah, yeah, yeah, exactly. And the EPSS score won't tell you that. But that is very true. It is one of the most widely used commerce solutions there is on the internet. Because just the history, right? Like Magento has historically been an open source solution anyone can spin up. Everyone has invested heavily into Magento due to how heavily customized it could be. There's around 140,000 plus instances of Magento on the internet, which is no small number. That's a pretty large presence for Magento. Some of the largest brands in the world use Magento quite heavily. It's probably one of the most popular open source e-commerce solutions there is out there.

MG: Yeah. And so, so, you know, going back a little bit, Sergei found this bug, had this write-up, and there was also some mitigations that were put out, right? I think by both Sergei and Sansek, and the initial mitigations weren't, were able to be bypassed, right? I think you found in your, your research.

Shubs: Yeah, yeah. And to be honest, the mitigations also gave us a huge hint of where to look at in the in the code base as well. But they were flawed, they were heavily flawed. So the first mitigation released by Sansec was looking at the HTTP post body for is data, data is URL. Um, and that, that was just, I think that was just completely incorrect in terms of, well, very, very weak mitigation because you never need to include that in the post body if you don't want to, to exploit the bug. So that, that was a very weak mitigation. And then, so then Sergei went out and he wrote his post on GitHub and he had a mitigation that looked at, uh, the word source data inside the HTTP post body. Which was, yeah, was an appropriate mitigation, but someone quickly found that due to encoding and JSON, you can actually bypass his mitigation as well. So the first mitigation from Sansec, the second mitigation from Sergey, neither of them are good enough. Sergey then wrote his final iteration of the mitigation. He was, I guess, you know, updating his post on GitHub. over the last few days when the bug was released. But that mitigation finally, I think, was good enough. And the funny thing is, I think the really funny thing is, when I spoke with Sergey, when he read our blog post, he was like, Oh, I didn't even know that's how they patched it. I didn't even do the patch diff. Like I didn't understand that that was the actual patch that they did. But they finally updated all their mitigation. So whatever's on SanSec and whatever's on Sergey's post are valid emergency mitigations. Now, obviously, I don't recommend people applying these emergency mitigations if they can just patch.

MG: Yeah, yeah, yeah, 100%. That's going to be the most effective way to address this issue. For sure. But you know, is it valuable, right? If the if they can't patch immediately, to apply some mitigations?

Shubs: I think I heard something about Adobe releasing a new patch that just patches this issue instead of all these other things bundled into the patch. I think because of the severity and because of us raising some awareness and obviously people on the internet exploiting this much more readily now because it's now recognized as a serious vulnerability and people actually, or companies actually raising this to Adobe as a serious issue to fix. Adobe's probably decided that, okay, we'll release like a patch that will just patch this issue. I think I read something about that. It should be out there. Yeah. But yeah, the mitigation is valuable because I think there's a lot of risk with sometimes applying a risk that's not easily to be quantified when there's this e-commerce shop owners that don't want to stop business because the patch includes like 20 other things it fixes or does. So yeah, I can see it being quite valuable.

MG: Yeah, for sure, for sure. So it's kind of interesting, right? So in terms of the way that we do security research, there's a few things that we do, right? So there's the proactive side, where we're doing novel research into whether it's various kinds of products or frameworks, other sorts of things that are widely used. Fortinet, ServiceNow, those sorts of things. And then there's also this stuff, which is reactive. So we weren't the original authors or discoverers of this bug, but there was patch notes that were out relating to this vulnerability. There was some chatter there. And not really, there was much going on. People weren't like, oh, guys, drop everything and deal with Magento right now kind of thing. And so with that, we kind of consider that a reactive kind of research flow, where somebody else has released something or released a technique or reported something to a vendor that's relevant. And then we sort of take it from there. But the kind of work is in a lot of ways very similar, right, in terms of the actual research work. You talk a bit about how you and the team kind of approach the research, whether it's proactive or reactive, in this case, you know, to sort of build something for our platform.

Shubs: Yeah, yeah, sure. Well, first things first, I think that this vulnerability, there was awareness raised in the e commerce area from Sensex. Which, you know, to be fair, they did a good job at raising awareness, but they didn't really, I guess, in the interest of customers of Magento, they didn't release enough information for anyone to really critique their hotfix or understand what the vulnerability really is. But yeah, I mean, when it comes to reactive and proactive, For things like this, which is really to the reactive side, that basically means that we have to mobilize our team at any given point in time, if we realize that there's something of high severity that needs to be done. Now, we understand that based on all the data that we have and the analysis that we can do, we understand what the technologies are that we need to focus on and what we care about for our customers. And that's really where this comes in. We had a really good understanding of which customers do have Magento, as well as it can be fingerprinted. And we knew that it would have a really big impact on our customers. So it's something that we jumped on pretty quickly once we realized that it was worth working on. But that means working weekends, that means working odd hours, whatever it may be, we have to get on top of it to get these vulnerabilities out the door. And oddly today, we're competing not only with the malicious attackers, but generally we're competing with other companies reversing this. as well. And because, you know, we don't want that payload to come out and suddenly our customers have to worry about, you know, bug bounty hunters hitting them up or whatever it may be. So we have to be really quick when it comes to these sort of things. And, and this is, you know, I really appreciate that our team is, you know, able to reverse engineer these bugs in the speed that we do and put it in the platform that we do. But reactive security research is always very interesting because we have to make an assessment on whether or not it's going to be impactful for our customers. But generally, we try to capture as much as we can from a reactive perspective that makes sense. Um, you know, often something you've told me about Michael is, you know, sometimes we may not even know that a customer is running a specific technology, but it's worth reversing that. So there's also that element where, you know, if there's some large enterprise software that, um, you know, isn't immediately obvious where it's being run or who's, who's running it, it might still be worth us doing our research on that reactive.

MG: Yeah. I mean, standard, right? Like, you know, there's no point going hard against, you know, my first FTP server, somebody, you know, finding a CVE in that, right? Or, you know, some issue in that, because it's used by three people in the entire world, right? Or whatever, right? Or even, you know, like, I don't know, like consumer stuff that's not really deployed in enterprise.

Shubs: You know, we do this assessment. Yeah, 100%. I mean, we do do this assessment. Every time we look at any software, we're going to focus on whether it's proactive or reactive is what really is the impact here? Like, you know, there's been so many times where, you know, we'll be looking at some research that's come out or whatever it may be. And we'll be like, yeah, there's like 40 instances on the internet. like, and those 40 instances are like, not relevant from an enterprise perspective. They're just random boxes on the internet.

MG: And even even the bug itself, there's like then preconditions for those 40 boxes. Only a handful of them are actually exploitable. Yeah. But then everybody kind of makes a fuss sometimes, you know, and, and it's because, you know, because depending on where it comes out, you know, there's a lot of, there's a lot of promotion of this sort of stuff. right?

Shubs: And yeah, but this is this is the fear, uncertainty. This is the fear, uncertainty and doubt that I absolutely hate in security research. Like, look, don't get me wrong. I understand that you want to be really proud of your security research, you want to showcase it, you want to market it. That's fantastic, right? But we already have security teams that are like struggling right now to get on top of the the mountain of work that they have from from a patching and remediation perspective. they don't need to hear from the CISO about like some random bug that's been marketed in a sense where it's like, you know, it's not even that impactful. Well, I mean, sure, they can hear from the CISO, and they're gonna have to answer to them, right, which I understand. But at the same time, if it's a bug that doesn't actually have impact, and it doesn't actually affect, you know, their organization or a large number of assets on the internet, then isn't that isn't that really just adding to the fear, uncertainty and doubt in this?

MG: That's the noise, right? So like, you know, one of the I mean, this is probably a good good topic to touch on, like one of the reasons that, you know, we invest so heavily in in research as part of the the platform development, and the findings is that we have a focus on high signal findings, right? That's the key. And the reason is, it's just to reduce the noise, because overall, the noise is reducing your security posture at the end of the day, right? It's obscuring the real risk in your attack surface, and by extension, obscuring what you need to be focusing on and prioritizing. And so, you know, part of the reason for doing this, going to the depth that we do with the research, I mean, the ultimate goal of the research for us is not the blog post that we put out, it's the check that's in our platform. And that's sort of just an extension of it. I mean, we make a real effort with our blog posts to be really straight and to the point with it, very technical, very in-depth. We talk a lot about the process as well, which I think adds a lot of value.

Shubs: You know, that's kind of a really important part that a lot of people miss. A funny fact about this Magento bug. I spent more time setting up a development environment for Magento than we did actually discovering the bug. And that's summarized in a blog post in like one paragraph, but you have no idea how much work it took to figure that out initially. And, you know, I had a friend reach out to me and he was like, actually, the biggest goal in that blog post is the fact that you're showing people how to set up a development environment for Magento so easily. I was like, yeah, I mean, that's, that's kind of what we're trying to do here. We're not just trying to, you know, um, showcase this bug or whatever. We're trying to show the process, the, the, the, the, the step-by-step process that we took to discover the issue. And that's, that's so different than, you know, the traditional marketing, like security advisors, which is all like, you know,

MG: hey, look how cool we are. Right. And we never struggle at all, because we're, we're, we're elite hackers and all that kind of stuff. Um, uh, but, but really it's about, it's about not, not just, not just from that perspective, right. Where we're providing that kind of information for, for other researchers who might find that sort of stuff very valuable. Um, and that learning kind of experience, but, but also just in general, uh, to, to folks who want to understand these vulnerabilities at a deeper level. And, you know, because a lot of the advisories that tend to come out, you know, very high level, very vague, right? And again, this is the reason why we do that depth of research. You know, obviously one, so we can have a high signal check in our platform that actually, you know, we keep that threshold of exploitability. You know, we have that threshold of exploitability. And the reason we have that is because there's a clear nexus to actionability. doesn't always mean it's going to be like critical or high or whatever, but, but if you've got an exploitable issue that we've proven is exploitable, right, then you know, you can do something with it. I mean, like we hear that all the time. It's like something fires. I know it's real. I can just send it off to devs or I can just jump on it or whatever I need to do with it. Um, and so. So that's why we do it. But then, you know, the level of depth that's required to do that well, and to do that properly to the level of signal that we expect, you really need to understand the bug, right? And then, you know, with the blog post, you know, it's about also providing that more broadly than just our customers, right? So, you know, our customers obviously get the benefit of that in a really automated way, right? It's just running in the platform and running against their assets. But, you know, broader than that, you know, You know, you've got our blog post that kind of sits, you know, alongside a really generic advisor that doesn't really tell you much, right? Yeah. And that doesn't give you the context. I mean, you were pointing out, you know, you know, some of the challenges with your just high level ratings, like CVSS. you know, and an EPSS, right, not providing the full context and the full information for people to be able to make, you know, informed risk decisions. And so that's why we do it. And, you know, for us, I think that concept of exploitability is really important. You know, we've often been asked, you know, why don't you just sort of match against a CVE, right? Like, so just get a patch level or detect the technology because we have all that capability in our platform, right? You know, and they're like, why don't you just then take that at that point and then you know, put it against a list of CVS and, you know, then they can see what they're vulnerable. Why do you put all this effort into going to the next step? Because it's not just the security research effort, right? It's the engineering effort that goes to supporting that scanning at scale. And as fast as we want to do it, like we do it hourly, right? So it's real time. So there's a real engineering effort that goes into that. Plus, you know, the stuff with signal that I mentioned earlier. So, you know, why do we go to that extra effort? And it's this reason, right? It's the signal. And the lack of signal in security tooling right now, I think, is endemic. And ideas like EPSS, like you mentioned, you know, to me, they're a solution to a problem that's been created by these vendors, right? And it's not even the best solution. And yes, it's more work. It's more difficult. And you actually need to understand what you're doing. But the output is so much greater. And the value to the end users is so much greater. Security vendors should be taking that workload. off the teams, not putting it onto them, right? They're already under resourced and overworked as it is. And like playing CVE whack-a-mole where, you know, the vast majority of them are false positives or not nearly as critical as, you know, suggested by the tooling or the advisory or whatever. Then, you know, it's just adding to that. It's making it worse for these teams. So, you know, I think it's an interesting kind of concept to dive into, but that's the reason, right? And when we talk about exploitability, you know, another thing that often comes up is conflating that with impact, right? But I see them as two different things. Exploitability is the purest way to identify if a vulnerability exists on an asset. you know, there's no other way around it, right? Like either it exists and it's exploitable or it doesn't exist, right? If you can't exploit it, it's not a vulnerability, I think is sort of the purest expression of that. And so, you know, things like EPSS or other measures, because there's more than just EPSS, but other techniques, you know, they're looking at things, I think from a data analyst point of view as opposed to a hacker's point of view. You know, they're looking at, oh, there's public exploits, there's this, there's that, you know, there's all these different factors, and then they're providing some predictor of exploitability. Like, why? you know, just honestly, just test it. Just try and exploit it. If you can exploit it, well, then it is exploitable. If it's not, it's not, right? And, you know, there's so much noise that's caused by by this approach that, you know, for us, you know, at least philosophically, it's really important for us to drive that signal for our customers and the people who use our product. And certainly we encourage that, you know, amongst the broader industry as well. But, you know, it is a lot of work, right? Because you do have to really understand the vulnerability to get something that is actually like truly high signal and not susceptible to false positives.

Shubs: Yeah. And, um, you know, one of the things that, uh, that this industry is kind of moving towards and more just generally what I've seen, uh, is a lot of people relying on some of the open source tooling out there to do this level of exploitability checking. And honestly, like I'd been tracking the template that they had came up with for Magento. And I saw the several iterations that got through. and even the last iteration will still miss a whole bunch of these.

MG: Can you give some examples of that, like in terms of what sort of stuff it would have missed and why? Yeah.

Shubs: Yeah, yeah, I can give an example. So the first thing is, this relies on an out of band check, which is fine. These open source tools can do out of band checks. But the thing is, it also matches on something in the response. And it's expecting that the response from Magento is going to be like a clean JSON response, which has certain keys in it. That's not the case. In many cases, Magento is going to come with a an error page, which is HTML, doesn't have JSON in it, whatever else. Anyways, that's still an issue with this template right now, right? It's not, it's going to miss that. So, you know, this is, this is why, like, I find it really intriguing that, you know, you know, people can sometimes think that, oh, you know, Asinote, we're just using open source tools off the shelf, whatever. No, that's not the case. It's not just the case. It's not just, that's not the case. It's also that the engineering we put into our security checks for our platform is of much higher quality than what you'll see in the open source communities. Because we have several review stages. We have several tests. We have several different things that we do to reduce false positives. We have several different things that we do to really go through this rigorous QA process before we even put it into the platform. And we're iterating all the time. So it's not like, you know, it's set once and done.

MG: Yeah, anyway, we've got a we've got a deeper understanding of it as well in the first place. But like, it all comes down to I think, that philosophy that we spoke about, which is a philosophy we've had from day dot like this point six years ago, which is, which is signal signal is key. Yeah. And, um, And it might be easy to say, oh, well, these cases are rare or not, or whatever the case, or this is good enough. But, you know, when you start to think about in an attack surface management kind of context, where you're looking at attack surfaces holistically, you end up operating at a scale where something that might seem like an edge case or seem small, suddenly is not an edge case anymore. Once you scale it out, it becomes a bigger issue. Um, you know, and I guess the difference for us is, you know, we are serving customers, right? And we, we take that responsibility, you know, very seriously. And, and, um, you know, certainly I think, I think these folks appreciate the, the level, um, of, of effort that we put into, into maintaining that signal, because it's not about being, you know, sort of saying like, Oh, well, you know, we do all this work. So, so we're awesome. Right. It's about the outcome at the end of the day. It's really pragmatism more than anything else in terms of making it easy for security teams to really understand the true exposure in their attack surface and not have to not have to be hackers themselves, right? And not have to do the level of research that we do to really truly understand an issue and truly understand if they're affected and to be able to make decisions on what they should be doing and how they should be reacting to things. I think that's really important. That's why we go to that effort and that's why we do that. So, yeah, I think You know, I think it's kind of interesting, you know, talking about like open source tooling, you know, EPSS and stuff like that. At the end of the day, the idea of exploitability as sort of this baseline for determining the presence of vulnerability, it's like simple conceptually, right? It makes a lot of sense. conceptually, it's like, yeah, well, you know, if you can exploit it, then it's vulnerable. And you know, you know, for certain, right? However, however, in practice, it is it is a lot harder to achieve that standard. Then then it might seem, you know, once you once you sort of simplify the concept, but I mean, it's just, just to just to add to that, right?

Shubs: There is one other point. that I heard about from the author of this bug, it took him multiple months, I think he said something like a couple months, six months almost to convince Adobe that this was a valid issue that they need to fix. It then took Adobe another six months to fix the issue and release a patch. So, so like we talk about EPSS and all this, all this stuff. It's like, well, this vulnerability has been around for a really long time. Where's the EPSS score of that? Like there's, there's no real metric for this. Right. So it's like, well, the reality is like, you don't even know, um, the real threats that your products have or the vulnerabilities that they have. Uh, there's, there's no help from EPSS or CVSS in that case.

MG: Well, I mean, the other thing as well that we get that's kind of interesting is I think there is a certain crowd that kind of thinks that a bug exists when a security researcher finds it. It's like, no, that's not the case. That's not how bugs are created. And it's kind of an interesting perspective, particularly if you take it from a negative perspective, right? You know, certainly, certainly from a more positive perspective, you know, understanding that allows you to look at this a bit differently, and be a lot more, I guess, focused on being reactive, right? Because, you know, hey, you know, if this comes up, and it's getting a lot of traction, and it seems like it's impactful, there's a good chance that, you know, we're vulnerable, or that this has been an issue for a while, like, and it gives you that kind of context to take things a bit more seriously and handle things properly. But then there's also the flip side of it, which is the negative interpretation of that, which is this sort of concept that, yeah, it only exists because a security researcher found it. So those blasted security researchers, putting out these vulnerabilities, it's like, mate, this has been present for a long time, typically, in many cases. Sometimes not, but in a lot of cases it has been. And I think that kind of narrative and that kind of attitude not only is not the right perspective to take if you're interested in securing your assets and securing this technology, but also it gives these vendors a pass at the end of the day. If you kind of support that view, the vendors, in many cases, a lot of vendors, not all of them, there's plenty of great vendors, but the ones that perhaps don't care about the end user security as much as a priority, I mean, it supports them, right? I mean, that's what they want. They want opacity when it comes to the security of their products. They don't want transparency. um they don't want to give this information to people and they want to sort of you know buy into this narrative that um you know it's only an issue because a security researcher has found it it's like no it's it's that's not the that's not how these things come to be so that is kind of an interesting um insight there and and yeah i mean you know that that's also part of the reason why we do the proactive side right so um you know in that regard and particularly focused on you know, actually impactful kind of technologies that people use, you know, broadly deployed enterprise software, where it's hard for for security teams to really get visibility into that security, right? Because like you said, this bug had existed for a long time, right? And there's many instances of that. But but customers, you know, like our customers and security teams, right? They're security teams. And they don't have the resources or the capabilities, in many cases, to do this level of depth when it comes to assessing these products and go to that. They have to rely on this really high-level approach, you know, security questionnaires and SOC 2 reports and stuff like that.

Shubs: Speaking about the reactive side of security that we do at AcidNote, and, you know, other vendors do as well, you know, I think what you've raised is a pretty hard thing even for us security researchers. Like, you know, earlier, I talked about the talk about the move it bug compared to the Magento bug. Now, if you look at them on paper, and what's being put out there from a CVSS perspective, you'll think that they're both very, very critical bugs. But it's not until we actually like dig into the security research and do the security research that we understand how critical it really is. And that's, in my opinion, that's not a failing of you know, us as security researchers, it's more failing of the current systems that things like the way things are ranked and triaged and conveyed by companies.

MG: It doesn't give you enough insight, like you really do need to understand the vulnerabilities. And I think that's the thing that I mean, CVSS is just, you know, it's just a scoring system. And what I find in a lot of cases for folks that are you know, rating things with CVSS is that they have some degree of impact in mind that they're trying to achieve and then they just, you know, work their calculators to get to that output anyway. And, you know, the CVE database is just a cataloging of vulnerabilities. It's not One, it's not complete. It's not the be all and end all. That's another interesting debate that's sort of been going around where there were some folks recently that were doing some analysis and suggested that there were over 100,000 vulnerabilities that didn't have CDEs. and everybody was tearing it apart. The CVE heads, I'll call them, are the folks that were tearing them apart. So the kinds of people that like to do visualizations of the CVE database and things like that. And they were tearing it apart. But again, it goes to this sort of concept that we're talking about. In my opinion, if you've hacked anything, or you've tried to submit research to vendors, it's absolutely plausible that there is a ton of stuff out there, a ton of vulnerability that's not captured in the CVE database. It's just as simple as that. And there's so many scenarios. And so this sort of over-reliance on something like that is not the right way to go if you're looking at trying to be holistic. You need to take a sort of more measured risk-based perspective to how you manage your attack surface. And B, you really want to have full information. You know, if you look at the CV database, you know, if there's the ID, right, there's really high level descriptions that don't provide, you know, half the context or detail on the on the on the vulnerability, and then a random set of scores, CVSS, EPSS, etc. And like, that's it, you know? How do you figure that out if you don't have the capability to really dive into a bug, right? Then you're just left with trying to make a decision based on these numbers. And how do you know you're making the right decision? And if you had infinite resources and infinite capabilities, right? Well, who cares? You know, you just deal with it all, right? That's the ideal, sure. But that's… so far away from the reality of security teams trying to actually secure their attack surfaces that the approach is sort of falling apart. But it is an easy approach to take. It would certainly be easier for us to just sort of you know, not do any of the work that we do to really dive into an issue and just match against CVEs. But it just leads to, you know, such a dramatic reduction in usability and value for people who are trying to protect their systems.

Shubs: Yeah. And you look at this Magento bug, right? On the surface, you see that it's XXE and you just think, oh, it's just an XXE and whatever else. And I even had this happen to me as we were discussing the bug elsewhere. But people were just like, oh, an XXE in Magento. How is that possible in 2024? I thought they would have patched that easily. And then you dig into the bug a little bit more and you realize, no, it's not actually an XXE. It's an insecure deserialization bug. And then you realize, oh, wow, actually, this bug has a potential for things that are even more critical than XXE. And then you realize, oh, wow, the patch is just blocking this single class from being instantiated. And the entire root cause of this vulnerability still exists. All of the insecure deserialization stuff is still there and still exploitable. Well, you quickly realize that one, Derby has completely misclassified this vulnerability as an XXE instead of Insecure or Deserialization. They've rated it based on the XXE, but they haven't done anything about the deserialization. They've got all this magic in Magento codebase, which I'm pretty sure that a lot of engineers are scared to touch and scared to fix, which as a result, that insecure deserialization piece still lives. And, you know, it's a, not only for us, but it is also for the author, the original author, and other people that picked up on this in the blog post. now a really prime candidate for security research, because the the idea of more bugs here is it's very plausible that there are many more critical bugs to be found.

MG: And there might be a perspective that people take, like going to what we were talking about earlier, where, oh, well, is that a good thing? And now there's going to be more bugs here. It's like, well, it is a good thing. One, hopefully there should be some more effort and focus on addressing the deeper root causes of this. And two, like you said, You know, these bugs exist, right? Like these issues exist. They're not going away unless somebody makes them go away, right? Somebody has to fix the bugs. And you don't know what's there. You don't know what's there. And so I think, you know, the attention that comes from this is actually quite positive in that respect. And I get it, right? I get it in the sense that, you know, there may also be attention. you know, from the bad guys looking at this sort of stuff. But at the end of the day, it would be completely naive to not suggest that Magenta was a gigantic target for bad guys, right? Already, right? And they're not the ones that are going to build security companies or report stuff to folks. You know, they're the ones that are actually going to look at exploiting this. And so, So yeah, I think it's the overall positive outcome with respect to that. But you know, that's the reason why you dig deeper, you know, all of that context is actually really important. And it provides a much better perspective on the risk of using software like Magento, right. And I think it's important context and information. an insight that customer, well, you know, customer teams, but like broadly speaking, like security teams, right, you know, because that's who our customers are, you know, security teams, you know, really need to be aware of like, it is really valuable insight to making informed decisions about about their risks and where they allocate their resources. So it's worth it in the end. But yeah, I think there's a lot to mine here with this. I think it'd be interesting to discuss maybe in a future discussion just around you know, this idea of that sort of vendor landscape and the attack surface, you know, and the exposure in that kind of attack surface, which is something that I don't think gets talked about, you know, quite enough. But, you know, we've touched on it for a little bit. I think we can go celebrate six years, man. Sounds good. Yeah. probably many more after that. We kind of keep our heads down and keep working hard, but we love what we do. But yeah, it's good to see six years, man. Yeah, likewise. Cool. All right, man.

Shubs: Have a good

‍