Not All Vulnerabilities Are The Same

All right, we'll kick off our keynote now. This is an amazing keynote. I'm so excited for this one. Thanks for coming, Shubs. >> Thank you for having me. >> Uh so Shubs, for those that don't know him, um did a talk actually at our first Bides CRA back in 2016 about a little tool uh that he had used in his bug bounty uh uh work that he opensourced. In fact, he actually sold that. Well, wasn't the tool. He added a lot more to it, but he sold that as part of his business uh earlier this year for over a hundred million dollars. So, watch out for those Besides Camber tools. Shabs is an absolute legend in the

community. He's he's been here every year and supports many many hackathons across uh Australia and helping young hackers get into hacking. um he has come to Besides CRA every year and we feel like this is a full circle moment that he's coming here today and keynoting. He has been uh the ranked number one bug bounty hunter in Australia for three consecutive years and he was 31st on the world on hack hacker one. So an exceptional person but also a great uh a nice kind person as well. So, big round of applause for Shubs.

>> Thank you, Kylie and and Sylvia for the intro. I um really appreciate being able to keynote here today and and thank you everyone for coming to the keynote here today. Today, I'm going to be talking a little bit about um how not all vulnerabilities are the same. And a lot of this experience comes from the last 7 and a half years that my co-founder and I ran Asset Note. But uh to kick things off I want to talk a little bit about the journey uh from 2014 till today. Uh when I started in 2014 uh almost 11 years ago I was um you know I started my professional career in offensive security I had a really keen interest in

web application security and this keen interest came to me when I was a teenager and eventually you know snowballed into a job. But I found pretty quickly that working in web application security uh essentially the main way that we delivered value was through pentesting and writing reports for customers. Uh it made me think a little bit back then and really uh what I was really keen on was you know why why didn't we have more time to do research in web application security? Why were there no roles that existed for research in web application security in Australia? Um, you know, I I started thinking to myself, was our passion always tied to writing pentest reports?

It seemed like the world was really moving towards this idea of having almost everything accessible as a web application. But it seemed that we were still stuck in this idea of we need to be writing pentest reports to deliver value when it comes to the security of these same applications. What happened is eventually, you know, years passed and tides turned. Um, a lot of the world's most critical functions, um, businesses and processes embraced the new age of web applications. Um, you know, enterprise applications sold both at on premise and SAS, they took off. And if you look today, almost everything in an enterprise's attack surface is composed of some sort of web applications. Uh, and to be honest,

you've probably used a lot of these web applications in the last week, maybe realizing it, not realizing it, but I'm sure that, you know, a lot of these are just under the hood. And uh a lot of companies have to use these to build their business ultimately as an enterprise. So the the world now is you know primarily composed of web applications when you look at an external attack surface. What this led to at least as I was starting in this industry was all of the methodologies when it came to understanding an attack service they shifted. Um we had to be able to deal with uh a neverending uh growth of scope. We had to change how we looked at

scopes entirely. Even with large budgets, when you had pentest, they weren't necessarily designed to keep up with the pace of change that we were seeing uh in the enterprise world. What really changed was the whole bug bounty scene and how bug bounties paved the way of understanding an attack surface beyond a single application and actually for an entire enterprise. So the scope no longer was an individual application but rather an organization's entire attack surface uh on the external internet. And we we saw this shift. The the industry progressively shifted towards evening the playing field for both attackers and defenders cuz realistically uh attackers don't look at an organization and say I can only go after this one application. They go

after everything that's on the external internet belonging to that organization. So we saw this huge shift uh around you know 10 8 n years ago that for me at least led to the perfect storm. Uh as Kylie mentioned I presented at the the very first B sites in 2015 and I had introduced a proof of concept tool that uh you know I released on GitHub at the time which would alert you on new DNS records uh that appeared for any given domain that you were monitoring. This tool was really built from this idea of competing in the bug bounty space. As you guys know, bug bounties can be quite harsh and competitive. If you're not the first

person to find something, you're usually not going to get paid for it. It's going to be a duplicate. So, this idea that these attack surfaces were rapidly expanding. Organizations were moving to this uh you know very very fast pace with web applications made sense for understanding an attack surface as things appear on the internet. But as you combine this idea of understanding what's appearing on the internet with exposure scanning or vulnerability scanning, that's where a lot of the magic really happens. What we realized at the time was that discovery was only really the beginning. Um really the values behind asset note was that it's great to be able to discover uh what's on the external

internet that's internetf facing for an organization, but what is the outcome that most organizations are really hoping to achieve here? And the number one use case really is that people want to discover vulnerabilities on a continuous basis across this attack surface. When we started 7 and a half years ago, this didn't exist. Um everything was quite slow. It would couldn't handle the scale that we were talking about or it suffered from serious false positive issues. Most scanners were point and shoot and often they missed the whole idea and concept of considering an entire attack surface and what could affect an entire attack surface. So that's what really led to the dream uh for us of building asset note. So

after you know I I can be honest I tried uh working on asset several times as a business myself and honestly failed uh quite quite a lot. Uh it wasn't until I met my current co-ind co-founder Michael Jerarchis who was really the missing piece in terms of making it a business but we we both saw that there was this you know vision of intelligent automation that could run automatically across uh an entire attack service that could discover everything that belongs to organization and monitor it and only report exploitable vulnerabilities. And since 2018 uh we worked really really hard to make this dream come true. So, here are some photos of um us in our journey. And the one that I love the

most is the one in the middle. Uh because it it kind of shows you that building a business is not as glamorous as you might think it is. There are a lot of really late nights, a lot of McDonald's, a lot of vices like beers and cigarettes, but there's a lot that goes on in terms of making a business. uh in in my opinion and it's it's easy to romanticize this idea of building a business but really for the last 7 and 1/2 8 years both Michael and I and the whole ASET team have worked pretty relentlessly to to actually build the business and make it successful and to deliver that vision that we always had

from the beginning to to all the all the customers we have now and any future customers we may we may have. There are some really great highlights though in terms of building the business. um couldn't have found a better team, a better co-founder and a better experience and journey. And uh I'll always look back at it as some of the best years of my life. But what this really led to and what I want to get into today in this keynote is this idea of enterprise web security research without the strings attached. Little did Michael and I know, but building an attack surface management platform actually meant that we had the capacity and capability to build a

dedicated uh enterprise web security research team and that is really what I am most passionate about as well because for the last 7 and a half 8 years we've been operating this uh security research team. It was really interesting because we didn't have a typical exploit broker model where we had to hold on to our vulnerabilities as long as possible and try and keep them alive as long as possible. We had a very clean disclosure model uh where we our aim was to fix these vulnerabilities for our customers at the end of the day. We focused really on pre uh critical pre-authentication vulnerabilities in some of the largest enterprise software bundles in the world. Uh but all of this research fed

into what we were building as a product and it's always been hand inhand and that was the primary reason we did the the research and built a research team here in Australia. But that's what I want to talk a little bit more about today. How did we go about doing that? And what did that involve? What did we see? And what are our observations in the wild today? The next part I want to talk about is that that that element I I mentioned where we we built this research team here in Australia. And you know, as as Sylvia and Kylie mentioned, um you know, there's a lot of talent here in Australia. And I I kind of want to, you

know, show what we found in building a research team here as well. And really, it's about getting the right people together. Um you might be asking, how do you even find the best security researchers here in Australia? The truth is the first 3 years that we were running Asset Note, I was doing all of the security research myself uh as with some engineers joining along and we'd often bond uh on some of the vulnerabilities we found together. But it wasn't really until our third year that we were able to hire our first researcher. But being able to do the research for so long myself with our engineers, we had some pretty clear ideas of what we

needed from a researcher and a successful hire for us. We always dreamt that we'd be able to um build a research team and this was our opportunity to build one and we found that there is so much talent in Australia. Uh so definitely love being here and love the the people in Australia, the talent here. For us when we uh review uh when we when we put out an interview task for the researchers, it typically looks something like this. So we we give them a enterprise um web security product that we have already found plenty of zero days in in the past and spent weeks and weeks on and understanding exactly what the vulnerabilities are that we're

looking from them as well. We time box it to about 1 week. Uh we asked them specific things that we're looking for and we asked them to look for pre-authentication uh vulnerabilities. Um the technical interview itself involves doing what you'd be doing dayto-day in the job. these zero days that in this product they don't exist uh on the internet. You won't find any writeups on them. Uh but we we you know we we find that this is a very realistic test that we could send to our potential candidates that worked out quite well. There's a lot of really complex routing mechanisms and authentication bypasses that really let us gauge the um the skill set of whoever we were

interviewing. So, in this in this interview take-home assessment, we give a week and we give them instructions on how to set it up as well as what we're looking for in terms of the vulnerabilities. What we found was that the best responses often they discovered new and unique creative ways to compromise the target. Things that we had not even thought about which always humbled us when we saw their responses. They focus pretty relentlessly on pre-authentication vulnerabilities. And I say that because we've also had many candidates that when we give this interview uh they send us a bunch of post authentication vulnerabilities. It's just not what we're looking for. They the the best candidates this did

also discover uh the more complex and deeper routing mechanisms that really showed us that they understood the codebase to a deeper level and they provided very clear traces from um from source to sync for all the vulnerabilities. But the key thing for all of these candidates that we ended up hiring that were successful, they really enjoyed their journey, which is so important because a lot of what we do in security research, it can be quite timesensitive. It can be quite difficult. Uh there can be many roadblocks and if you don't enjoy it, then it's probably going to be quite difficult for you to to stay on. The pitfalls though in this take-home assessment that we found from a lot of

candidates was that they often treated this um take-home assessment as a a clickandshoot exercise uh reporting a lot of post authentication vulnerabilities which we we aren't really interested in and I'll explain why we have such a relentless focus on vulnerabilities that affect an attack surface without authentication later but they had a often a greater focus on client side bugs. um nothing that could really lead to compromise uh in the same way that we would we would expect. They did often miss on the complex routing elements and they often didn't consider the entire application uh holistically. There's also a bit of gaps of knowledge that we saw as well in terms of the candidates that you know didn't succeed

and that was usually to do with their uh lack of understanding of certain techniques that affect that stack. So things like JDBC related attacks or expression language evaluation but some of the submissions I can tell you uh the talent is absolutely real. So here's an example from one of our candidates who is a researcher with us today. But he was able to find an endpoint that was pre-authentication which allowed you to provide a JDBC driver a URL for that JDBC driver and a database user and password. What he found was there was a driver called the Derby embedded driver that let you in the URL provide a trace file which could be any file on the local file system and

he came up with a payload inside the database user which would perfectly fit inside the trace file in order to be executable. So you can see this database user has a bunch of comments on the left and the right and he's what he' done is he'd essentially come up with a a a a payload which would perfectly fit in that trace file to be executable. When you visited that trace file, it would ultimately lead to command execution. So there's there's often submissions like this that we'll get that will truly humble us and will make us realize that there is so much talent here in Australia. Um but yeah, we we obviously hired him immediately. But yeah, uh diversity does matter. Uh

and and when I talk about diversity, I really mean the diversity in skill sets and thought process. Uh over time, as we built this security research team, we found that a lot of the a lot of the best people to work on this research team often came from the CTF space, specifically top ranking teams and challenge creators. But the the defining factor of our security research team was not just people that participated in CTFs, but rather created challenges in CTFs themselves. And that that really has been one of the strong indicators of uh really good talent in terms of hiring for security researchers. Honestly, like we're always better at some things than others. Um myself

included. Like there's so many researchers on our team that fill the gaps that I have and collectively we're able to find a lot more uh together. Now that I've explained a little bit on how we built a research team, what goes into running a security research team and actually achieving the mission? When we first started uh the security research team, we understood that there was a clear need of some sort of structural framework when it comes to what we prioritize. So we we split it up into three major areas. uh the reactive side where we look at anything that's in the wild that's coming up. So endday exploits or you know uh reverse engineering patches that have been for

vulnerabilities that are exploited in the wild and looking at public ps and that reactive side is very important to make sure that you know none of our customers got compromised from something that's just been released out in there in the wild. the the part that I love the most and what we tend to spend a lot of time on as well is the proactive side where we often discover the the zero day vulnerabilities themselves to be able to protect a lot of our customers and these are often in really popular software which affects many of our customers at once and lastly there was an element where we had to curate everything where we had to make sure that everything we

had built so far had the correct you know metadata around it the correct uh CVS the scores and so on but this is how we split up our work as a security research team. The mission for us for for security research, what we found was, you know, we wanted to really protect enterprises from uh vulnerabilities that were released in the wild or vulnerabilities they didn't know about primarily in the software that they're using and deploying on premise or in the cloud. And earlier in our mission, like earlier in our our company's history, we would often focus on smaller products cuz it was just something that made sense at the time. But as time went on, we

realized that the the key to to a lot of the security research is focusing on the really large, really widely used popular software. Some of our projects today go on for 6 months uh for a single software product and that can be pretty intensive. But at the same time when we finally do discover something critical there it can have an an enormous impact to almost all of our customers and the broader ecosystem on the internet. But our our mission was always to protect our customers from this compromise before it happened which meant that we needed to be on top of everything that came out uh as soon as it came out as well as be on top of finding iss.

Uh but yeah, things have grown a lot and over time we've all we've gone over some of the largest products. I think if if we could start um the research team from the beginning, I would have probably uh preferred to go after the largest products from the very beginning. And I think that that goes to show that you know for us um we we don't necessarily look at these products as uh impossible. We just have to spend time and get there eventually. One of the things that um when you run a research team that you have to consider is uh you know you when you have a team of amazing researchers often I found that I needed to do as much work as

possible to make sure that I shape the targets up for them which means that I don't just throw something across to them and say hey go and hack on this. It requires a little bit of reconnaissance actually discovering the product itself actually finding this vendor software. Um there's a lot of enterprise software that's deployed across the internet and it it shocks me how many different products there are in each category that are deployed but even finding the software uh even obtaining this software and setting up this software is really important. But yeah uh setting up this software really really sucks sometimes. So I have a question for you guys. Have you ever tried to set up an Oracle

product? Spoiler, it sucks. It really really really sucks. Um, but that that is what I spend a lot of my time doing as someone that manages the security research team. Um, but yeah, enterprise software setup hell is basically for some Oracle products. You end up getting 12 GB of zip files. Some of them are corrupted for some reason. You know, they're complex and poorly documented. They require some proprietary database. and assembling this enterprise software is like honestly it feels like you're assembling a broken Lego set together or like a puzzle that's missing a couple of pieces. There's so many quirks. There's so many difficulties and even to get something to run to be able to debug it

is quite difficult. But it really is half the job uh when it comes to security research. Without having this environment, without obtaining the software, without setting it up, there's really no chance you're going to find the same sort of vulnerabilities you would if you had done that. for us the lab setups as well. And this is a question I often get as well. It's like how do you manage all of the labs and the the VMs and everything else? I'll be honest with you, we keep it quite simple. Uh we don't have any really complicated setup. Uh it's quite simple. We will often set up a um a Windows VM uh on AWS in a sandboxed

environment uh for that specific software cuz honestly setting up this software is hard enough already. or we have a Intel knuck that sits at my home that's connected to tail scale that has VMware workstation that people can connect to. If we ever do see a setup that allows for docker containers will obviously take that if possible but that's quite rare for a lot of the enterprise software we look at these days. the day-to-day in terms of managing the outcomes is quite interesting because with this research team uh what I found is that they're very capable at discovering novel techniques and novel and esoteric vulnerabilities in in different areas but it's quite important how we manage that as a as a as a

manager of a security research team. I you know I try to get involved with almost every product that's being tested uh from the research perspective and I have to make sure that none of these researchers end up um you know just sticking to themselves. What I've often found with really talented researchers is they can have an idea and spend a lot of time trying to achieve it but if they had just spoken to you know some of the other people on the team they might have realized why it may not have worked or why different things they could do. So it's quite important to do that. And when it comes to the timing of a lot of

our research engagements, I do lean heavily on the research team's feedback, which is quite different to many other research team operations where they'll just say, "You've got to work on Atlassian Jira for like 2 years straight. Good luck." So that's not really how we do things at Asenote. I think it's a it's a much more cooperative way of doing things that we have. But we we also focus really um we focus really on the crunch time. We we have very few meetings. We don't really use a ticketing system to to track everything the same way that you would for an engineering team, for example, because security research really is a creative element and it and and to add

all these different processes and structures can really defeat the purpose of what we're trying to do from a research perspective. There's a lot of different things that make up a high value target for us and um you know depending on you the complexity of the research the trade-offs that we might have and the scoping so how difficult is it to obtain the software or set it up as well as the time allocation these are all the things that you know they all make up a high value target so for example if the complexity of the research is high but you know we could set it up easily time allocation we'll see how long it takes

and trade-offs of like if I focus on this one product for 6 months is it worth it compared to focusing on all these other products that we may have as well. So what I found with a lot of highv value targets is that they are the really really large products that you see out there. The Citrixes of the world, the Palo Alto Panos's of the world, uh the service nows of the world or Jira or Confluence. These are all great examples where you know almost anywhere in an enterprise environment you see this software being run ran. So even if it takes us 6 months to find something critical there, it's often worth it. Um but yeah, it does come with

a lot of different things you have to consider, especially the fact that there are other products out there that we could be looking at at the same time. Something else that um I've been asked before often by researchers as well as uh people that are trying to do something similar is when do you find when to give up? Like how when do you know when to give up? And it's it's quite tricky because um I don't think there's a perfect answer for this. I I also don't think that it's you know purely about the talent or the target. Um it often in my opinion often when people give up and including myself and our team is when we haven't had such a

good understanding of some attack surface that we hadn't considered. What we found and a really good example is the product Tableau. Uh we spent a couple of months on this uh and what we found was um even after spending a couple of months we didn't find anything that critical. It wasn't until we took another look um about 6 months or a year down the line where we discovered some attack surface that we had never considered before or had access to before and that led to several critical vulnerabilities. So in many cases I feel that um a lot of the decisions that people make around moving on from targets can often be attributed to not understanding the target well enough

before reaching the goal. But I don't think it's the worst thing moving on from a target and coming back. There's nothing that stops us from doing that. And we actually have calendar reminders, you know, every year or 6 months to come back to targets where we think that it will eventually lead to something quite high value. So now that I've uh explained uh the journey and building a team and running a team, uh I want to talk a little bit about what we're seeing in the world today from an economics perspective. And I want to explain to everyone why why enterprise web security matters so much more than ever now uh compared to before. It's been a good 10 years, so

we've seen a lot of changes happen in that time. There are really four major um streams when it comes to the value of enterprise software Z. The first is your traditional exploit brokers which is you know selling them to them is you know they mostly focus on Microsoft Exchange and SharePoint VPNs are often the really large enterprisey products or VPNs and things like that often used for intelligence gathering or espionage. The next is platform capability which is where the company we built sits in which is where we want to discover these vulnerabilities so we can protect our customers from them. Um this is often used by you know attack service management platforms or ws or firewalls.

Uh but the major change that's happened in the last 5 years is this whole element of ransomware where now we've got ransomware affiliate programs that allow you to use this knowledge that you have of zerods in enterprise products to exploit and breach um you know enterprise networks and ultimately to deploy ransomware. This is in the last 5 years. Um, and lastly, there's bug bounties, which you can use these days in in public and private bounty programs, but your mileage may vary cuz many platforms now have specific provisions to prevent you from being able to exploit these and make money off them. But yeah, let's dig in a little bit more to the ransomware element of

this. So, this is the major change in the last 5 years. ransomware as a service pretty much has opened up this incredible new lucrative monetization strategy for exploit developers that are financially motivated. Uh and and as I said, it's it's incredibly lucrative because the highest value targets highest value targets using this enterprise software can often have a lot of sensitive data or be connected to very sensitive networks. Uh and it allows you to target many many organizations at once. For example, if you discover a zero day in a really big enterprise product, there could be thousands of organizations that are vulnerable at any given day. What we can see in the mandant reports for the last 2 years is that the the um

observed threat groups uh the financially motivated threat groups are increasing year on year. Uh at this stage, it's at about 55% with espionage only at 8%. And we're seeing that for the financially motivated uh actors, there's so many more victims than what you'd expect in the typical intelligence gathering and espionage operations. Their goal is simple. They just want to make money off the uh suffering of these organizations. And usually it leads to a lot of everyday people being affected because their PII is affected or there's a lot of data that's stolen that shouldn't have been stolen. Um but you know this is a growing trend and in the last 5 years um you know this ransomware

as a service has really made it possible for a lot of exploit developers that didn't have the means to to make this amount of money to make this amount of money by just discovering zero days in these enterprise products. This is really why it matters so much today. If we follow KOP's activities uh over the last 5 years um we can see that they've systematically found zero days across file transfer appliances starting from Excelon moving on to go anywhere MFTt move it transfer Cleo software for the Move it transfer vulnerability alone there was 2,600 affected organizations and the thing that's really interesting about this is that whoever is behind a lot of these um this exploit activity

and uh the these breaches, they're not really that much of a novice. They're they're building custom shells for these specific scenarios. So, for example, when they drop a shell for progress move it, it really only has one goal, which is to exfiltrate as much data as possible as quickly as possible without being detected. They'll often use custom APIs that only belong to these applications which really show us that they have a very deep understanding of these applications and they're not just your typical you know hacker that's dropping you know your typical shells that you see in the wild. So they are very sophisticated and they are getting a lot better and this is why enterprise

web vulnerabilities especially zero days are becoming more and more important today to protect against. So yeah, as I mentioned, there are some um you know, there are some trends here in terms of what what these uh what these ransomware affiliates are targeting and mostly they they really love the idea of being on a Windows network. Um zero days that can allow that. So any any zero day that can allow a shell on a Windows machine um is much more high value to them than than most other things. And to be specific for them to be able to access the domain uh on Windows, things like manage file transfer has been a really um really big

area to focus on from these ransomware affiliates. Uh but it doesn't really stop there. There's VPNs, firewalls, any network management and monitoring devices. Um all of these are really great targets for these ransomware affiliates and ransomware groups generally. As long as they can obtain a foothold, it can lead to some pretty disastrous effects. Uh so that that leads me into the the next part about a case study into Citrix Bleed. And I don't know how many people are familiar with this specific vulnerability, but we have a long history with this vulnerability here at at Asset Node. And I want to explain a little bit about how it came to be. Um if people aren't familiar, I'm sure

people have seen it before, may have used it, and if they haven't, if they aren't familiar, Citrix Netcaler is one of the most popular VPN appliances there is out there. um the next scale gateway specifically uh and it was probably one of the largest projects we we did at Asenote from a security research perspective. We initially started by spending like a a couple of weeks a month and then we realized no this is this is going to take a lot longer than that due to the complexity of it and it it took a long time to even just become familiar with um Citrix Netcala. Um there was a pretty heavy concentration of our customers using this software. So

it made sense for us to spend even 6 months on this. As we were researching this um this particular product, there was an advisory that was released by Citrix in um in October 2023 and they rated it a 7.5 as a sensitive information disclosure vulnerability. for us uh we we don't really trust a lot of the advisories that come from vendors uh without doing the due diligence but it was released at the start of October and there was no real urgency that we saw in the security research community when this vulnerability was released with the way that Citrix had described the vulnerability and raided the vulnerability that no one really understood how severe it really could be

and for us we really got interested in this the lack of transparency for us is just not good enough we needed to understand what was going on Yeah, but what had happened was that this vulnerability was actually being exploited in the wild since August, even though the advisory was released in October. Citrix made no mention of this in their initial advisory, but there was a lot of news that came out later that showed that this was the case. It was already being exploited in the wild by threat actors and I think a lot of people didn't understand the mechanics of the vulnerability of or what it led to from a severity perspective to even be able to protect against it at the

time. So our mission really was to prevent this in the wild exploitation. Our mission's always been to prevent in the wild exploitation of enterprise software. Um and for anyone that's you know we are really familiar with the Citrix stack but for anyone that's familiar with some of the vulnerabilities that have come out in Citrix over the last couple of years this was one of the first ones that led to the onslaught of many others that came on. But after confirmation that we after we had confirmation that there was exploitation in the wild uh from the vendor in in October 24th, we published a blog post on the mechanics of the vulnerability, how it worked and the PC

the very next day. So we we also worked with our designers to come up with a logo for Citrix Bleed. If anyone remembers heartbleleed, it's the same concept because ultimately Citrix Bleed led to so many compromises by leaking sensitive token session tokens ultimately. But yeah, we we released the PC right after we learned that the vendor had confirmed that there's in the wild exploitation. A lot of people might be asking like why would we release PC's, but the reality is the defenders can't understand what's going on without understanding how the exploit works as well. And um really I think if we don't publish this P these PCs, I think everyone's worse off from a defending defending perspective as well.

But what we found um you know over time with with Citrix Bleed is that it led to so many compromises and I think that this was a total mismanagement in terms of how the vendor categorized this vulnerability as well as the risks that it held. But as you can see here um there was even you know DP World in Australia they had to shut down their ports uh because of the Citrix bleed vulnerability. uh there's an official advisory from the ASD and you know every other agency you can think of in America also talking about how there's ransomware affiliates now actively targeting u you know companies with this vulnerability and that leads me to the next thing

about what rapid response really means to us and in general but you know understanding what it's become as well in our industry today from reversing CVS in the last seven years um you know We we've seen a lot of stuff that goes on and we understand that version based checks aren't really going to be sufficient in the long term in order to protect against things. Often version based checks will lead to a lot of false positives or they you know won't understand the underlying vulnerability. And what we found uh at least over the last 7 years of seeing CVS that get released is the industry tends to fixate on whatever media cycles pick up. Um, and sometimes, uh, media

cycles don't categorize the risk properly or they try and incite fear and uncertainty to to hopefully get you to buy their product, I guess. Um, but yeah, a lot of this uh, a lot of this work on reversing CVS for us has also made it clear that not everything is really a CVE. There are a lot of techniques out there that can't be categorized so cleanly into a CVE. Things that may affect an entire attack surface, but they don't have any CVE attached. But yeah, there are some takeaways from reversing CVS for seven years. And recently, there's been this really huge trend that we've been seeing in vulnerability marketing. And that comes from really this idea of this

misunderstanding of the true impact of a vulnerability. Um, and often it gets propagated by media. And it often is when there's some specific configuration required to exploit the vulnerability or there's some specific, you know, scenario required. But a lot of vulnerability marketing these days focuses on this aspect of inciting fear, uncertainty, and doubt. And that's often actually propagated by security vendors because it gives them a good way to, you know, plug their products at the end of the day. At the end of the day, you know, it's it often is deceptive marketing, but maybe not always. Maybe they just don't really understand the impact or maybe there's, you know, other things going on. What we see at asode at

least is this often leads to a lot of panic uh where there's internal security teams that scramble and I think that our jobs these days as working in a security team is quite difficult as it is without all the fear uncertainty and doubt but often when this fear uncertainty and doubt does happen there's actually no exploitable risks that are present in many many cases that we've seen there often flows this flow of you know there's a media article it or from a security vendor or from a news agency It goes to executives then practitioners and then there's panic at all level at all levels. It always makes us ask like how much is this act how much is this

driven by a marketing team versus the actual research team. One of the things that we found at asset note was a lot of our research we always tried very hard to keep it factual as much as possible the the risks and and everything you know really not to cause that fear uncertainty and doubt if it wasn't necessary. But this is what we see in the world. we we see like for example earlier this year there was a vulnerability for uh an Apache Tomcat rce and um it was a critical uh but if you look at the preconditions that were required to actually achieve this command execution um we we must have scanned uh you know

all of our customers assets was scanned for this continuously. We've not found a single instance of this in the wild. But you know the likelihood of this this configuration to be present in the wild in the way that you can see in an automatable fashion for exploiting this is quite low. But what you see from the vendors and what you see in the media is quite the opposite. You know people will say that you know there's there's a huge risk. Um it's a critical vulnerability. it's being actively exploited, you know, just 30 hours after the public exploits released or you'll see, you know, um posts which will neatly lead into the vendor's product offerings uh after

inciting some sort of fear to start off with. But, you know, I think that a lot of this is um is is leading to a lot of problems for many security research team security teams in general. No, vulner vulnerability marketing does not have to cause fear. It's not like every vendor is going out there and saying that this is something that you need to immediately address. On the flip side, there are some some really good resources that will explain to you that, you know, you can patch this issue, but there's no need to panic. Um, or they'll say things like, you know, we've seen exploit activity, but we've not seen any successful compromise. Pretty much for

any vulnerability that we see today that is, you know, capable of command execution, you are going to see some level of exploit activity after it's released. Whether this exploit activity actually means that there's been a successful compromise is a whole different story. And it's important to make that distinction. So that is the reality for some of these vulnerabilities we see. Uh, and something that we've noticed at least from reversing CVS for so long. there's you know exploitation from an opportunistic threat actor's perspective is not direct correlation to compromise and um you know we we have to understand the the realistic likelihood of successful exploitation now it might sound difficult to understand this for every new vulnerability that appears but

I think that there's a framework that we can use and and some questions we can ask when something comes out there there's you know in many cases we've seen a lot of vendors and just generally the security news outlets as well causing a lot fear and uncertainty and new vulnerabilities and I think that really drags a lot of people down. A lot of this panic is not really warranted. It's also not an isolated case. We've seen this across many different vulnerabilities over the last uh you know last couple of years. Things like text for shell or the Erlang OTP SSHc vulnerability. We see this time and time again in the media cycles as as new

vulnerabilities get released. But this whole idea of vulnerability marketing is just getting bigger and it's probably not a problem that's going to go away. So how do we really tell um if an emerging threat can really lead to compromise and that's where we have to do the due diligence really we have to decipher some of the specifications of a vulnerability. We need to really understand it. So whenever there is a new vulnerability that comes out there, any new P uh that gets dropped, um we will see exploit activity, uh that doesn't necessarily mean that there is compromise. And um this these intelligence feeds, while they're valuable, we need to really look into the the reporting that comes back from

real indicators of compromise that come from breaches in order to signify that a vulnerability is quite important. So here's some questions that I you know we often ask ourselves is you know what are the preconditions for a vulnerability um you know how many instances of this technology exist on the internet for example the Erlang OTP SSH RC there was so few instances on the internet but it caused so much panic in our communities does it actually lead to pre-authentication rce and um are there you know what are these preconditions likely to even exist in our environment um and are there any indicators of compromise published not only indicators of exploit activity. So these are all

things that that we really look into when whenever we assess a vulnerability that comes out in the world. That's all everyone. Thank you for my thank you for coming.