Overview
Co-hosts Michael and Shubs reflect on the six-year milestone of Assetnote and do a deep dive into a critical Magento bug. They explore the importance of proactive and reactive security research, the limitations of traditional vulnerability scoring systems like CVSS and EPSS, and the significance of their Magento findings.
Full Transcript
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 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, you know, building the best product, sometimes you can forget about these milestones, but it's definitely worth celebrating. Yeah, it's been a 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. And 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 0.98 or something. And you had like the Progress MOVEit bug as like a 98 EPSS or some really high EPSS or whatever it is, right? 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 MOVEit Transfer bug, because — and let me just explain it real quick. Yeah, the MOVEit Transfer bug, even though it got heaps of traction in the public just because it's MOVEit Transfer, it is like one of the least — 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, you know, six months. It's like, not only do you need to know a username on the system, you also need to make sure that user has been enabled for that SFTP 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/passwd 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 the scale of Magento, right? Cause Magento is used everywhere. And I think contextually as well, the other issue with Magento is it's used in commerce, right. It's used for, um, you know, payment apps and like, you know, storefront apps and things like that. Right. So there's 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 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 Sansec, and the initial mitigations weren't — were able to be bypassed, right? I think you found in your research.
Shubs: Yeah, yeah. And to be honest, the mitigations also gave us a huge hint of where to look 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" or "data is URL." And 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 was a very weak mitigation. And then Sergei went out and he wrote his post on GitHub and he had a mitigation that looked at the word "source data" inside the HTTP post body. Which 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 Sergei, neither of them are good enough. Sergei then wrote his final iteration of the mitigation. He was 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, when I spoke with Sergei, 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 Sergei'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 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 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 patch that's not easily quantified when there's these 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 wasn't much going on. People weren't like, oh, guys, drop everything and deal with Magento right now. 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, 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 Sansec. 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 on 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 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 this is — you know, I really appreciate that our team is 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. Often, something you've told me about, Michael, is 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 isn't immediately obvious where it's being run or who's running it, it might still be worth us doing our research on that reactively.
MG: Yeah. I mean, standard, right? Like, you know, there's no point going hard against, you know, my first FTP server, somebody finding a CVE in that, right? Because it's used by three people in the entire world, right? Or even, you know, 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 — what really is the impact here? Like, you know, there's been so many times where 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 not relevant from an enterprise perspective. They're just random boxes on the internet.
MG: And 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 it's because, depending on where it comes out, you know, there's a lot of promotion of this sort of stuff. Right?
Shubs: And yeah, but 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 struggling right now to get on top of the mountain of work that they have from a patching and remediation perspective — they don't need to hear from the CISO about some random bug that's been marketed in a sense where 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 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 topic to touch on — like one of the reasons that we invest so heavily in research as part of 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 value 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 kind of what we're trying to do here. We're not just trying to, you know, showcase this bug or whatever. We're trying to show the process, the step-by-step process that we took to discover the issue. And that's so different from the traditional marketing-like security advisories, which is all like, you know —
MG: Hey, look how cool we are. Right. And we never struggle at all, because we're elite hackers and all that kind of stuff. But really it's about not just from that perspective, right, where we're providing that kind of information for other researchers who might find that sort of stuff very valuable, and that learning kind of experience — but also just in general, 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 are 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 — we keep 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 critical or high or whatever, 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. And 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, it's about also providing that more broadly than just our customers. So, you know, our customers obviously get the benefit of that in a really automated way — it's just running in the platform and running against their assets. But, you know, broader than that, you've got our blog post that kind of sits alongside a really generic advisory that doesn't really tell you much. And that doesn't give you the context. I mean, you were pointing out some of the challenges with just high level ratings like CVSS and EPSS, right, not providing the full context and the full information for people to be able to make 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 — and they're like, why don't you just then put it against a list of CVEs and then they can see what they're vulnerable to. 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 into 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 — 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 the vast majority of them are false positives or not nearly as critical as 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 — other techniques, you know, they're looking at things 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 this approach that, you know, for us, 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 amongst the broader industry as well. But it is a lot of work, right? Because you do have to really understand the vulnerability to get something that is actually truly high signal and not susceptible to false positives.
Shubs: Yeah. And, you know, one of the things that this industry is kind of moving towards and more just generally what I've seen is a lot of people relying on some of the open source tooling out there to do this level of exploitability checking. And honestly, I'd been tracking the template that they had come 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?
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 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 going to miss that. So, you know, this is why I find it really intriguing that people can sometimes think that, oh, you know, Assetnote — we're just using open source tools off the shelf, whatever. No, 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 it's set once and done.
MG: Yeah, anyway, 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 signal. Signal is key. Yeah. And it might be easy to say, oh, well, these cases are rare or not, or this is good enough. But, you know, when you start to think about it 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 take that responsibility very seriously. And, um, you know, certainly I think these folks appreciate the level of effort that we put 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 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 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, it's kind of interesting talking about open source tooling, 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 a vulnerability — it's 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 for certain, right? However, in practice, it is a lot harder to achieve that standard than it might seem once you simplify the concept. But 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, we talk about EPSS and all this stuff — this vulnerability has been around for a really long time. Where's the EPSS score of that? Like there's no real metric for this. Right. So it's like, well, the reality is like, you don't even know the real threats that your products have or the vulnerabilities that they have. 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 from a more positive perspective, 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, 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 we're vulnerable, or that this has been an issue for a while — 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. They don't want to give this information to people and they want to sort of buy into this narrative that, you know, it's only an issue because a security researcher has found it. It's like, no, that's not how these things come to be. So that is kind of an interesting insight there. And yeah, I mean, you know, that's also part of the reason why we do the proactive side. And particularly focused on, you know, actually impactful technologies that people use — broadly deployed enterprise software where it's hard 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 customers — you know, like our customers and security teams — 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. 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 Assetnote, 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 MOVEit 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 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 us as security researchers, it's more a failing of the current systems and the way things are ranked and triaged and conveyed by companies.
MG: It doesn't give you enough insight. You really do need to understand the vulnerabilities. And I think that's the thing — 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 rating things with CVSS is that they have some degree of impact in mind that they're trying to achieve and then they just 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 CVEs — and everybody was tearing it apart. The CVE heads, I'll call them, are the folks that were tearing them apart — 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 more measured risk-based perspective to how you manage your attack surface. And you really want to have full information. You know, if you look at the CVE database, there's the ID, there's really high level descriptions that don't provide half the context or detail 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 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, 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 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 — 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, Adobe has completely misclassified this vulnerability as an XXE instead of Insecure 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 the Magento codebase, which I'm pretty sure 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 — 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 idea of more bugs here is very plausible. 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. 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 there may also be attention 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 Magento was a gigantic target for bad guys 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 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. And I think it's important context and information and insight that security teams, you know, really need to be aware of — it is really valuable insight to making informed decisions 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 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 quite enough. But we've touched on it for a little bit. I think we can go celebrate six years, man.
Shubs: 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. Have a good one.
