 I'm Infosec AU on Twitter so feel free to reach out to me after you've watched this presentation and you have anything you want to talk about regarding enterprise application software security. So I'll just move on with the talk and the first thing I want to go through today is how we actually obtain the source code. When you look at enterprise web applications one of the biggest things about them is there's a lot of security through obscurity. The fact that you simply cannot obtain the source code is often a really good defense mechanism for not finding vulnerabilities within it. So one of the things that is something that you have to be really good at is being able to get your hands on this software and analyzing the source code from that point onwards. I'm going to be going through some of the common techniques that I've used over the last couple of years to be able to discover source to be able to obtain the source code for these enterprise applications. The first technique I'm going to be going through today is obtaining the source code through cloud marketplaces. So if you're not familiar with cloud marketplaces we have many vendors list their software on these cloud marketplaces on AWS Azure and GCP. In many cases you're able to obtain a trial license that lets you access the software that's most likely typically gated through an enterprise sales process. I think not many people enjoy talking to salespeople so this is a great way to get access to the software. This is really valuable because we can pretty much spin up enterprise software from these marketplaces and you are able to get access to source code in many different ways by either dumping the disk or getting a shell access once you spun it up. I've used this technique multiple times in order to gain access to source code I typically wouldn't be able to get. So here's an example. This is on AWS marketplace. One day I came across this asset running on fb.com which is Facebook and it was running something called PCO IP connection manager. Looking on Google and doing a little bit of slew thing I found that it was actually the software called Teradisi PCO IP connection manager and thankfully it was available on a cloud marketplace. I was able to spin up this software from the cloud marketplace obtain the source code and then find vulnerabilities within it. So this is just an example but there's many enterprise software on these cloud marketplaces and it's something that you should check first off before you give up on auditing enterprise software. The second technique that I want to go through today is container image registries. So this really includes Docker hub for the most part. So if you just go to hub.docker.com you can search for any of the images that have been put up on Docker hub. If an image is available you can simply spin up that Docker container and then you can gain shell access to the container and then obtain all the source code whether that's war files, jar files, PHP files, whatever for further analysis. This is similar to cloud marketplaces but you're most likely running random images that people have built on the internet but this is also a very successful methodology when it comes to obtaining software. So you can see here you can obtain Adobe experience cloud either by contacting sales or relying on a Docker image that's already been built and pushed to Docker hub. So it's much easier to find this software pre-built and you can even see here that it was updated two months ago. So it's not as if it's outdated and it's most likely still current enough for you to perform your security analysis. But yeah there's a lot of enterprise software on Docker hub sometimes posted inadvertently and sometimes it's not intentional but it's great for us security researchers so we can get access to the source code. The third technique is obviously contacting sales. I mean these enterprise software companies have big sales teams and this is a high friction, high reward technique. If the only possible way is to contact sales to get a copy of the software you better believe that that software hasn't had many eyes looking at it from a security perspective. While this is often the highest friction if you can convince sales to give you a trial copy it's quite likely you're going to own the crap out of it. And this is my least favorite route because Boo who wants to talk to sales but historically speaking it's had the highest rewards for me personally when it comes to finding critical vulnerabilities. Another technique is freelancing websites. So this is a little bit more creative. I'm sure a lot of you would have heard of sites like Fiverr. So if you find experts in the certain software you're auditing on these freelancing websites you can convince them to give you a copy of the source code. So this is an example of me trying to get a copy of WebSphere commerce which is a very obscure but still quite popular software deployed and I just asked someone on Fiverr who specializes in deployments of WebSphere. So this is another technique that you can use to gain access to source code. This has been successful for me in the past especially when there's really no other way to get it. Obviously another technique is GitHub. So you can just use GitHub docs to try and identify whether or not someone has put up this software on GitHub and then obtain a copy of all that software. So for example if you're using the enterprise web application and you see install CMS step one you could chuck that in as a file name and see if that's available somewhere on GitHub. This can be really effective for .NET or Java code bases by searching the correct strings on GitHub. And lastly the technique I want to go through which you know depending on the situation can be very valuable is chaining vulnerabilities. So you can you can often leverage other vulnerabilities to obtain source code for applications. Challenges often include not knowing all the file locations and potentially not allowed depending if it's a bug bounty program or a specific vendor you're targeting. But one of the more common techniques with vulnerabilities is if you have local file disclosure you can leverage that local file disclosure to disclose the source code as long as you know the location of the source code. Another one is XXE which is external entity injection that can also lead to local file disclosure and also can lead to source code disclosure. Obviously command execution will let you read the source code. But yeah on .NET systems you can often download the DLL files from the bin folder and decompile them back to C sharp source code. So this is something that I've also historically used when it comes to obtaining access to enterprise application source code often on .NET environments using some sort of local file disclosure vulnerability to download all the DLL files in the bin folder. So one of the things that I just want to preface this the rest of the presentation with is I just want to have a little bit of a reality check for what people think security research is like and what it actually is like. So what people think security research is like is something like this. They think it's magical you're going to find amazing vulnerabilities all the time you're going to be the zero day master it's going to be a lot of fun there's no hard moments. But in reality what security research is actually like is you first have hope you find no bugs you maybe find a bug the bug was a fake the understanding leads to a real bug and the bug isn't reachable on default config. So in many scenarios this whole journey and adventure of finding zero days in enterprise applications you often only see the end result which is you know command execution vulnerability or a local file disclosure or whatever but you don't see the process and the process is painful it's something that you need to have a lot of endurance for and you need to be committed to finding these vulnerabilities you cannot give up easily otherwise you will not find them in many scenarios. So now I'm going to go through a bunch of enterprise products which I've found vulnerabilities in over the last year and this is going to go through some of the successes some of the failures what I learned along the way some of the lessons but essentially we're starting off with a product called IBM web sphere portal it's now rebranded to something called HCL digital experience but you know you might be wondering what this software actually is so it's an enterprise content management system it's used by medium to large enterprises there's around four and a half thousand instances on the internet and it's often self-hosted which is great because we get to target infrastructure belonging to organizations around the world it has widespread use amongst the fortune 500 and companies that run bug bounties so it was a great target for us so the way we got started is we just pulled down a Docker image you know earlier in this presentation I was talking about all the different techniques to get access to the source code fortunately for web sphere portal there was the ability to just pull the software from Docker hub and we were able to start up a web sphere portal server so quite simple once we started the Docker server the Docker container we found all the jar files put them in a tar file and then extracted it and then decompiled all of it so these were the commands that I used I used the prosion decompiler to get all of the Java source code the next step usually that I take when I look at any enterprise web application is understanding the attack surface this is one of the most important steps because this will then lead to the rest of your discoveries and if you do a poor job at this step then you might miss a lot of really important vulnerabilities so in this scenario is quite simple we just use the grep command to look for anything that had servlet mapping or mapping now again like this does require some intimate knowledge about how this application works but over time you do become familiar with how different applications are deployed whether it's on Tomcat whether it's on some PHP web server or some Python application they all have different patterns for deployment in this scenario this was on a web sphere server but it was very similar to Tomcat where you could look at all the server mappings and mappings which are typically inside XML files and then understand the attack surface so we see here there's a lot of matches and there's a lot of attack surface to go through but in our process of doing this we ended up finding this file called proxy-config.xml and you can see here that it actually has multiple paths that let you proxy to these three URLs you can either proxy to www.ibm.com www-03 or redbooks.ibm.com now this was quite surprising because if you're not familiar with the vulnerability class of server-side request forgery that's something that can be quite critical on these on these networks and this vulnerability this potential vulnerability leads to this potential code leads to server-side request forgery it's interesting that they've allowed you to access these three websites and it's something that really caught our attention and we wanted to see whether or not we could leverage these three white listed websites to actually access any website we wanted through this server-side request forgery for those that don't know what server-side request forgery is it is essentially when you can coerce a web server to make a request on its behalf and then you can read the contents of any web request that you make on behalf of the server so if this server is on a sensitive internal network through server-side request forgery you can actually access all the internal IPs and hosts and different things on that sensitive internal network that's why something like this is potentially critical so one of the things with enterprise web applications and and and auditing them is yes we can see the mappings and the code but sometimes it's quite tricky to understand where the endpoints are on the application in this scenario it wasn't too bad everything was under the path of slash WPS so we can see in the previous slide we had proxy my proxy common proxy but that's all now just mapped at slash WPS slash but you know the config file just said that we could access IBM comm and red books that IBM comm how are we going to turn this into a full read SSRF how are we going to be able to access any hosts that we want to well what we did was we chained a Lotus domino open redirect this website red books that IBM comm runs Lotus domino to deliver content to users so if we were able to achieve a URL redirect on this website then we would be able to achieve SSRF on any arbitrary host and after researching Lotus domino I noticed some really old documentation around the sign up process basically it let you be redirected anywhere you wanted to so this was the documentation and in the documentation it said if you append app and redirect to you can redirect to any location so this was exactly what we were looking for and what we were able to do is if you went to this URL and you slapped on the end question mark logout and redirect to the server would respond with a 302 found with a location header of example com which we want to redirect to this is perfect for our use case because what we can do is we can combine all these elements together and achieve a full read SSRF so this is what the final payload look like WPS proxy and then red books that IBM comm and then you've got the redirect and you can see that the web server is rendering example com and that request is happening on the on behalf of the web server so this is you know a full read SSRF in IBM web sphere and this is pre authentication one of the things that you often do when auditing enterprise software is you go very intending and what I mean by that is once you've discovered one vulnerability in one pattern you try and find that vulnerability in pattern across the entire code base and see where else it's occurring because likely if the developers have made a mistake in one location it might be repeated in multiple other locations so when it comes to variant hunting for this vulnerability we looked for all the files that were called proxy dash config dot XML we found a number of them and actually these two in particular that are highlighted in yellow were extremely problematic so the first one was essentially proxy to any URL with the ability to use any of these methods so get head post put delete which is kind of like a super proxy and quite dangerous and it also let you use all of these headers as well so it would proxy all these headers as well with the full response returned so just by doing this exercise of variant hunting we're able to discover an even more critical vulnerability that had the same pattern as the first vulnerability we discovered in this code base so this is what it looked like basically for read SSRF as well I know that it it doesn't look that exciting with example dot com being loaded here but just imagine if it was your internal confluence wiki or something like that so with variant hunting there was a lot there was actually a lot more variants some that were quite complicated that you wouldn't be able to protect by just putting a WAF in place so you can see the one with content handler with the digest it was quite complicated to protect against this vulnerability by just using some sort of WAF rule in this one you have to use the open redirect as well and this is what it looked like and we also had more variants in the Ajax proxy and the proxy servlet just quickly running through these it's the same sort of impact and you're able to achieve server side request forgery pre authentication through these end points as well now we found server side request forgery but you know we as good hackers we don't want to stop there we we we think to ourselves how can we escalate this how can we make this more critical it's great to have server side request forgery but remote command execution is even better and initially we thought with this service I request forgery we could somehow access an internal port and exploit other functionality inside these internal services running on this web server so we found something called IBM KC which is IBM Knowledge Center and that was accessible on port nine zero four three and the web dot XML file had this little snippet which basically was slash API slash web feed now just to be frank this is a vulnerability that I'm going through the one that I'm going through now we were ultimately not successful with it but I'm sharing this information just because to walk you through the process that we went through and the effort we had to go through before realizing it wasn't possible and I think that's a valuable part of the learning process so we download the KC dot war file from our Docker image and we find that it's got this path which is slash web feed and it seems to take in a URL and do something with it it seems to pause it in some way or form as it's an RSS web feed URL if we take a look at the passing logic we can see in the passing logic it's got the XML stream reader with create reader in and it seemed like this XML stream reader had no protections against external entity injection so this was a very viable technique for us if we were able to leverage our SSRF into something more serious and unfortunately we tried on a bug bounty target and it fails it returns forbidden and at this point we're not sure what we've done wrong we think that we've got the correct endpoint we're proxying to the correct port and we are trying to provide it a URL but it's not working so we start digging a little bit further and we realize that we had an older version of WebSphere portal because that's all we could get at the time and we realize that with a newer version of WebSphere portal that request was forbidden so obviously we we grabbed the the war file we take a look at the source code and it's been deprecated which really sucked because we spent a lot of time going through WebSphere source code before we found that this was deprecated and not working on the latest versions we also had some more attempts at XXE and unfortunately we weren't successful with these either we tried encoding some XML entity injection payloads and chucking them into the resource proxy which took base 64 XML and unfortunately it responded with something along the lines of you know the entity could not be resolved we dig further into the code and we realize that the entity handlers have been nulled out so it's not possible to actually resolve any entities as a part of this endpoint but again this is another failure in the process of finding vulnerabilities in WebSphere I think it's quite valuable to talk about there was another vulnerability in WebSphere portal which allowed you to get post-auth command execution via directory traversal so once you were authenticated you were able to upload a zip file that contained HTML CSS or JavaScript the extraction of the zip file was vulnerable to directory traversal so once you went to a specific location inside WebSphere portal you had the option to import a zip file that was vulnerable to direct directory traversal but you could only upload HTML files or JS or CSS files and you might be thinking to yourself how can I make that impactful that doesn't sound that important well actually if you're able to upload files to the local system at any location if you upload a file to the ETC sysconfig network scripts location regardless of the extension that that file has on reboot it will execute the command that you have in the file this is quite an interesting technique it only works on some distributions however this is something that you could use to get post post-auth RCE on WebSphere there's a tool called Evil Arc which lets you craft zip files which have directory traversal and you could very easily use this tool to craft the malicious file you can see the command in this slide here of how I did that you might be wondering why does this work well there is this amazing full disclosure mailing list which has this message about this guy who came across this for whatever reason if you're able to write a file which starts with IFCF into that specific folder then you can execute whatever command is inside the name attribute on restart there's some references here but I'll be sharing my slides after this talk so don't worry about getting any of these down there is an exploit write-up as well for this that goes into a lot more detail about how we found these vulnerabilities what they are and if you're interested in understanding them a bit deeper the next enterprise technology that I want to go through is SolarWinds Web Helpdesk SolarWinds Web Helpdesk is a central ticket management management system for your enterprise it connects with SolarWinds Orion it's used by medium to large enterprises schools and government there's around 2,000 instances exposed to the external internet one of the lessons that I learned along the way was you know removing the stigma from huge code bases it's used by large enterprises but their code base is just huge there's spring web objects traditional surflets it's extremely complex and it can be really daunting looking at this software just as someone who's never had experience with these technologies or someone that you know may not understand how everything works but with some intelligent analysis of the sources and sinks it starts to get easier my number one advice when it comes to auditing complex software is try and map out as much of the attack surface as possible in the form of sources and sinks and then do your auditing after you understand this the first thing we came across in SolarWinds Web Helpdesk was this hard-coded credential for something called the help desk integration user this was interesting so we searched this credential in the code base in order to find the production hard-coded credentials which was even more interesting initially our questions were what are these credentials that us do why are these credentials hard-coded that does not look good so these credentials let us access a big part of the spring web app embedded in this software the most interesting controller was found in the asset report controller and surprisingly SolarWinds were exposing endpoints that let you run arbitrary hibernate queries and view any of the sequel output that came back from the database hibernate talks directly to the database based off the models explicitly defined in Java so this was the code the code was essentially an endpoint called slash raw hql and this let you provide a hibernate query and give you the result of the hibernate query we needed those hard-coded credentials to reach this endpoint so that was an important discovery if we take a look at the get string hql result you can see that it's literally just taking the hql query and creating a query and returning the result so very simple so you needed a few things in order to exploit this you needed a CSRF token you needed the hard-coded credentials in basic auth format and again the CSRF token in the cookie the content type must be text plain and then your hibernate query inside the post request so if you had all of these elements which you can obtain pre-authentication you were able to run basically any sequel query on SolarWinds web help desk and receive the full response so that that returned the email and the password in a hashed format which is pretty crazy that you can do this without any authentication what's not shown in this presentation is the hours that were spent mapping the sources and sinks and understanding the authentication flow and some of these spring routes numerous failed attempts at exploiting certain vulnerability classes the vast amount of code in this code base causing auditing fatigue and obviously shouting f yeah once you've discovered a pre-auth critical bug which is the best part of the journey the impact is you can run arbitrary sequel queries against SolarWinds web help help desks internal database this allows attackers to obtain the username and password hash from the database it's limited to hibernate queries but still quite critical because you could still like insert users or modify data within SolarWinds web help desk you can find the exploit right up here again I will be sharing slides so you will be able to click through this in the future the next product I want to go through is hacking site cores experience platform so site core is a very comprehensive CMS that's used by large enterprises governments banks fortune 500 companies you can build a lot of digital experiences through this there's around 10,000 instances of this software running on the internet and a handful of bug bounty programs were discovered at what world vulnerable when using this software one of the notes as well with source code auditing is many times when you're doing source code auditing you want to give up because of how daunting it is or because you know how hard it can seem when you're going through it and throughout my journey of auditing site core I wanted to give up like five times it was so tempting to like just walk away and not spend any more time auditing the software you've got to be really motivated but there's also some really good advice here of just taking a lot of breaks if you get fatigue while looking at source code my advice is just step away from the computer and come back when you feel better and if you do this consistently and you're persistent you will be able to find zero days in a reliable consistent manner as well so I obtained the source code of site core from a github repository and I obtained two important elements the web root of site core and also the source code after decompiling all the DLL files this was really important because there's a tax surface in both areas that you needed to map together this is something that's specific in many cases to dot net applications where you've got all the C sharp source code but you've also got files in the web route that map to the C sharp source code so when we're mapping out the attack surface we were able to look at the dot config files located in one of the folders and understand what the mapping look like there's a bunch of ASPX and ASHX files but you can see that inside the web.config file there's this line which is saying slash site core slash shell maps to the physical folder slash site core slash shell so this was an important thing to notice because this led to our discoveries later on so since we have the site core shell directory we can see that there's all these different files in there there's like these ASHX files ASPX files but the journey in mapping the attack surface is not over yet we're still not sure what's pre-authentication or post-authentication so we need to go through each one of these files and read the source code in order to understand what are the authentication requirements if there are any authentication requirements when we investigated some of the files we found this one particular file called report dot ASHX which had this code here which essentially said this is where the C sharp code is and we loaded this source code in our ID to try and understand what this file let us do and if it required authentication this might be a little bit hard to read but in this file you can see that there is a it is taking in a HTTP request it is taking in the post body and it is going to the sync report data serializer dot serialized query you will also notice in this file that there is no authentication required before it goes to the sync of the serialized query so this is very interesting and any time you see any software mentioning anything about serialization that should definitely get you very curious about how that serialization works because in most languages the serialization can be quite dangerous it can most likely lead to something like command execution once we look at report data serializer dot CS we can see that there is the sync digitalized parameters where the post input ends up at net data contract serializer dot read object now for those that aren't aware about dot net security in dot net there are a number of ways of serializing data and many of those ways are quite dangerous net data contract serializer is actually a very dangerous way of serializing data because it can lead to command execution so what we found is from source to sync the ability to potentially get command execution so to craft the payload here we used some software called why so serial dot net you can basically generate a gadget which will execute an arbitrary command and we slotted into this XML that we've crafted to end up at that sync once we've done that we can literally just send the post request to report dot ASHX with our XML payload and we have command execution which is very critical this is pre authentication and it affects a large number of site core versions there are a lot of governments that use site core a lot of enterprises a lot of fortune 500 so this bug was very critical and affected a lot of organizations it's something that I think was probably in the code base for three or four years before it was discovered so this is something where you know just the idea of enterprise web applications having vulnerabilities you know but not being found through obscurity is very much so the cases here just because no one had had looked through this before the exploit write up for this can be found here and yeah there's a bunch of information about how we did the whole thought process behind this one the last product that I want to go through today is VMware workspace one UEM which is called AirWatch. This product is used for mobile device management it's actually extremely popular it used to be called AirWatch now it's called workspace one UEM as it's owned by VMware but one of the interesting things about MDM solutions is they need to be exposed to the external internet for many reasons mobiles need to be able to contact these MDM solutions in order to be able to operate in general so almost every large enterprise has some sort of mobile device management solution and this was one that we targeted at asset note. Installing this software was actually harder than discovering the vulnerability which is in many cases what happens with complex enterprise software I think we spent around a week just trying to install the software that was before we even looked at any of the source code on the right I've got a structure of directories that were obtained from the AirWatch installation and you can see that these directories are just all deployed under different paths like slash catalog or slash AirWatch there was a presence there was the presence of some ASHX files which we focused on when initially looking at the attack surface some of these ASHX files were not protected by authentication. We found this one file called blob handler dot ASHX and this file existed under multiple virtual paths but this endpoint was accessible pre-authentication and there was no authentication logic within the code but you can see here in this piece of code it's a function called render proxy response and I know earlier in this presentation we talked about SSRF and the dangers of SSRF but this is another scenario where we may have SSRF because what's happening in this function is it's taking in an encrypted URL decrypting that URL and then basically proxying that request through the server so if we were able to provide some sort of encrypted URL we could potentially proxy to any URL we wanted but the big question was how are we going to generate an encrypted URL how does the encryption algorithm even work so that's when we started digging further and started reading into the source code and understanding how it worked. We found that this was the encryption function it got the master key and once it got the master key was able to encrypt a string and you can see this logic of get master key but essentially if the key version equals kv0 then it would return the default master key and in our scenario the key version was kv0 so it pretty much always returned the default master key and the default master key was neatly just hard coded in the source code so that was phenomenal we were able to use this passphrase and salt data in order to generate an encrypted URL but you know sometimes well we didn't really want to recreate all of the encryption algorithms that they had written in C-sharp so what we decided to do was to just hook in and rely on their own DLL files to encrypt our own strings so we could leverage the functions they had already created in order to encrypt our own strings this allowed us to specify arbitrary URLs to be encrypted which then let us proxy to any URL through blobhandler.ashx so we had this final exploit which was just a python script that you could run and you could specify any host that you wanted to request and it would generate this encrypted URL that you could use on airwatch instances to access anything the exploit write-up for this is this thing but don't worry the presentation will be available later. I do have some final tips for source code review that I want to go through before I close off this presentation for the novice code reviewers out there my the biggest takeaway you can have from this is identify your sources and syncs the sources are where data is being input and the syncs is where data is being processed ultimately spend time doing reconnaissance on the code base for example identifying all the routes through whatever mechanism that application framework has map these routes to server-side functionality and make a note of all the inputs for all these routes be thorough it's worth it and go through the server-side flow from HGDP request the source all the way down to the sync and repeat this process for the rest of the attack surface if you follow this you will be successful with source code analysis for the more experienced code reviewers understand how things interoperate within the software and really review the dependencies that are used within a project because sometimes you will find vulnerabilities within a dependency of a dependency and it could still affect them actual application don't make any assumptions even for standard libraries read through the documentation thoroughly and understand how these standard functions work to make sure that they don't have flaws in them themselves and ensure that you're covering all the attack surface often there's going to be other internal ports exposed other internal services that you may be able to access in some creative way so try and cover more attack surface as much as possible also you can start chaining vulnerabilities for impact so if there's an SSRF do not stop there try and find something more critical through that SSRF and if you gain a deep understanding about this application about an application that's stacked by reading documentation thoroughly I can not yeah I recommend you do that because I cannot stress how important this is each application and framework is different I can have its quacks that's all thanks very much for coming to my talk excellent and we have some time for questions are there any questions from the room or from the signal angel you or are you moving that slowly could happen as well no if there are no questions you will well please move to the mic the microphones are here because otherwise the people on the stream will not be able to hear the question so first of all thank you for the talk my question is why you do the code auditing how do you keep an overview I mean what kind of tools do you use so I take a lot of notes in sublime text basically while I'm doing the source code auditing however I also rely on a few other tools beyond just you know manually auditing stuff so there's a tool that I use quite a lot now called samgrep if you've heard of that before but you can essentially run your own rule sets and write your own rule sets as well so it's quite useful as I have been doing a lot more software code audits over time I've been writing a lot of samgrep rules that I can now run on any enterprise web application source code that I have but I usually take notes in sublime text or something like that okay thanks no worries yeah other question yeah also thank you for me how have your experience has been with reporting these vulnerabilities to the parties involved it's been a mixed experience so for us we have our own disclosure policy which is essentially we will disclose the vulnerabilities after 90 days or 30 days after patch however we've had some vendors that are extremely responsive and fix it within a very short period of time but other vendors that get to the point where they threaten us and things like that for finding the vulnerabilities so it's been a mixed bag however most of the time it's not a bad experience it's been pretty good thank you are there any other questions yes just following up on her question can you just move closer to the morning yeah you have a subdomain from Facebook which you hacked the enterprise software for do you then first disclose to the vendor and hope they don't patch it to report to Facebook or do you report to Facebook as well so it depends I mean back then that was maybe like five six years ago I reported that one directly to Facebook and they worked with the vendor but typically nowadays what I do is I report to the vendor first I wait until a patch is available and then I report to bug bounty programs the reason I do this is because many programs have a zero day policy and they will refuse to pay you money if it is a zero day it does depend on the program though some programs are much more willing to take zero day reports but there are other programs that aren't so keen any other no let's thank the speaker for for this great talk