 All right, we've got Dylan back joining us on the stage again talking about getting shells from java scripts So please welcome them to the tour camp stage Thanks for the kind intro So like I kind of mentioned this in the first talk I gave but I This is my first time attending tour camp and I didn't quite nail the motif On some of my talks. So this is a little on the technical side and I'm going to try to do my best to decode a lot of that but There's no the crème brûlée involved to this this talk So that being said I'll go ahead and get into it basically the premise of this talk is kind of just like highlighting some stuff that's already kind of I think well known by the security community, but The way I kind of tie it together and some of the bug bounties that I've submitted to I think can kind of paint Some of this in in a new light So most or a lot of people may be familiar with like the beef browser exploitation framework that that takes basically cross-site scripting to like the next level of like getting an implant and like surveying internal networks a little bit Really my intent is to is to kind of push that one step further of like basically highlighting how crazy the idea of like a web browser is in the first place like let's go to Untrusted websites and take code from them and run it in a sandbox way And then allow that code to make arbitrary network requests on every single network that I'm sitting on like if you Laid that out to somebody in the 80s That would sound insane But this is kind of the way we've rolled with it and we're kind of at that point now and I just want to show a couple of Ways that you can take advantage of specifically that of sitting on Privilege networks and going to the internet and running code and then being able to affect the privileged network that you're on But to get there I need to go through some kind of dry web appy stuff So hopefully everybody can bear with me for that So there's there's kind of like this this fallacy that I'm sure everybody in the room knows is like if we have Like a really hardened outside then like we can we can have the inside like really soft and gooey It's like a company can it's been a lot of time like hardening The exterior but like all of the interior assets Maybe they'll leave that a little more soft, and I say it's a fallacy because like the reality is like Whatever your mechanism is for breaking in whether it's fishing or through a You know browser exploit or a USB stick in the parking lot It's it's it's relatively easy to do and really hard to Secure that out external perimeter, and if your inside is gooey, then then you can just move around Really easily and and this talk is basically just showing another way of Getting that first implant that doesn't involve fishing or a USB stick in the parking lot So like I had this idea in my head of when I was like first Entering this industry of like how much damage can really be done if you click a link? like Most people don't have browser exploits most of the malicious links that are sent around Probably don't have a zero-day in Chrome Flashes on its way out like They've are I think they've already announced the end of life date They've there's tons and tons of exploits still left in flash, but Chrome disable is it by default So that's that's not really a vector as much anymore And in general folks are weary about downloading files So if you send them to a malicious link and it and it forces an exe download I think like most people at this point know not to run that So I you know that was a question that I had kind of like sat on for a while like you click a link But like so what like how much damage to could be done So, you know to get into the weeds here, I have to sort of in-depth go over Cross-site request for tree and cross-site scripting and then it's gonna be dry for like the next three four slides But then we'll get to the more interesting stuff after after we get through it So hopefully everybody can bear with me for that Basically at a high level the same origin policy is like the fundamental browser security mechanism like you visit Facebook comm and you want to be confident that Facebook comm cannot steal any data from Google and it cannot affect any change on Your Google account so we have the sandbox that separates the two origins and the the rules which allow you to Get data are dictated by the same origin policy and it's sort of self-describing it Limits you to only be able to do those within the origin that you're on with a couple of exceptions And those exceptions are kind of interesting. We'll talk about some of them So basically You take this with a grain of salt This is the way the rules should be now bracer browsers were often break this when they come out with new features and stuff like that But fundamentally there are two different types of HTTP requests in a browser There's the simple kind and then there's the non-simple kind and I didn't define that terminology that was defined by specification a simple request is One that is either get post or head and any of the content types you see on the left And you can't have any custom headers It has to be a very vanilla request one that you might get from a web form a typical request a website makes would fall into a simple request a Non-simple request is the type of request you start seeing in single-page apps and more complicated websites Where maybe they set the content type to application JSON or maybe they set a custom header Maybe they use a method. That's not get post and head. Maybe they're using like a rest framework as they use put and delete those types of requests are defined as non-simple and The difference between those two with regards to the same origin policy is a simple request from Facebook If you visit facebook.com and they send you JavaScript That JavaScript can force your browser to make a request to Google if it's simple and that request is credentialed It'll include your credential if you're currently logged into Google Which doesn't sound great, but that's just the way we've architected the internet And non-simple requests require some validation ahead of time to make sure that you're actually allowed to make that request So a request is made ahead of time By the browser under the hood with a method called options That basically goes to the website and question and says am I allowed to make this request and then the server Responds either yes or no or nothing at all and if it doesn't explicitly say yes, then that request can't be made So these kind of dictate the rules which allow you to make requests from one origin to another And so this is the complicated flow the pre-flighted flow first You want to make a request you ask the server permission. Do I have permission and then the server responds back? Yes, you have permission to make a request with these methods to this origin With credentials or without credentials and then the browser goes ahead and makes the request That seems like the flow that all requests should follow, but there's kind of this caveat of an older time Where you can make simple requests without having to ask permission Facebook can force you to make a request to Google a Credential request on your behalf And so that's that's what that looks like. It's just an immediate request And then the server responds at that point allowing your browser Either to view the content of that response or not to view the content of the response So you're allowed to make the request, but then the server can set some rules around whether or not the JavaScript can read the response And like I mentioned before this is kind of super dry, but it'll get more interesting in a minute So this is kind of like the traditional way that you'll Imagine cross-site quest for a tree working you Visit evil.com evil.com can then force you to send credential requests to Google and if there's a state changing operation that Google has available They can potentially force you to change state on your Google account Which is is crazy. It's insecure by default and we have to engineer these really wacky solutions to make that Harder to do and I'll get into that a little bit Basically the way we've fixed that is Outside of the browser we've hacked this artificial pre-flight on top of all of our requests They basically say Before you make this request make another request that fetches a token from Google and then on the state changing Request include that token to prove that you've been able to successfully read this response of a previous simple request and That whole flow sounds crazy insecure by default and stupid Because it is But this is kind of just the way we've architected the internet So like the conventional way of thinking about cross-site request forgery is like it's an attack on a user I Can force a user to do a state changing attack or to do a state changing action on their account If they're logged into Facebook and Facebook doesn't implement this wacky pre-flighting thing into their application I can force them to change their status or I can force them to add me as a friend I can't view the response from that because Facebook is never going to grant me permission to view the data that comes back But if they don't implement all that weird token stuff Then I can I can do things on their behalf if they visit my website That's the classical way of thinking about cross-site request forgery and it is by far the most convoluted complicated web attack that I know of Just the way we built this and the reason it's insecure by default and it's non-intuitive and I have to like explain all this And really boring way for people to understand it It kind of just sucks But really what I want to focus on on this talk is it's kind of what I highlighted a little bit earlier You visit a website on the internet, but your web browser it sits on a lot of different networks It sits on local host it sits on your corporate network, right? And if you're not Google and you're not running a weird beyond-corp situation Your browser can talk to your co-workers so you may visit evil calm and Evil calm then has the ability to make requests to your co-worker or to an internal server And that's pretty scary and So like that's that's kind of the way I I Am trying to push people to think about cross-site request forgery that it's not just an attack on users It can also be an attack on your infrastructure but if you visit a link and That link has malicious JavaScript that JavaScript can make arbitrary requests to your internal network And that can be really scary and I'll give some examples What makes this worse is recently browsers implemented this like peer-to-peer Way for two browsers to talk to on each other Without a server involved and I am not a network engineer And I'm not going to pretend to know all the nuances of how or why this works the way it does But one byproduct of it is it exposes your internal IP address to any website So you go to a random website that website Has the ability to pull the IP address of your local network, not just your public IP address And from that information they can then guess what IP addresses your co-workers are guess what IP addresses servers on your infrastructure are and That's that's just the way it is and different browsers do this differently some browsers will give like one Internal IP address other browsers will give every single internal IP address that you're sitting on Which can include the IP address of the network if you're on a VPN I think Firefox usually gives a lot more information And that kind of sucks And so, you know if folks are familiar with Metasploit It's a malware framework, and it's an archive of exploits and there is a section of Metasploit of HTTP Exploits after you've compromised a host usually this is when it's it's it's used you compromise a host And then you want to move to other hosts within the environment These are all the HTTP exploits that are available like basically if an internal host is running Jenkins or something like that It'll fall into the HTTP modules and Metasploit, and if you compromise one host and your co-workers running Jenkins you can move from your host to their host with this HTTP exploit But what was interesting is when I went through this list of exploits Not only like so it's a big list of remote code execution over HTTP But the vast majority of these had no built-in protection against cross-site request forgery Which means like you don't just have to think of it as a means of like I've already compromised a host And now I'm going to move laterally from that host to another host Instead you have to think of this as what if I just visit a malicious web page? And then they get information about my internal subnet through WebRTC And now all of a sudden they can start slamming my internal network with all of these cross-origin requests because the browser allows it and Their remote code executions that are all of a sudden phoning home to the attacker So some some big ones I threw up on here Jenkins, Jboss, Struts, PHP, MyAdmin The list is really really long But these are all HTTP exploits that are also Vulnerable to cross-site request forgery and I'll caveat that by saying Jenkins has a Feature that you can turn on to protect against cross-site request forgery But you can also turn that option off And again if you're dealing with a large company and law of large numbers and the attackers literally just sweeping your entire subnet There's a good chance at least one person will have it turned on or to have the feature turned off. I should say So at a high-level overview a user clicks a link the Malicious web page loads JavaScript on the page It obtains that user's internal IP address even though they've clicked a link to a website on the internet That page can now get information about the internal subnet handed to them by the browser and Now they can just sweep the entire internal subnet with whatever exploit payloads they want Maybe pulled out of the Metasploit library or maybe exploits that people haven't found yet And I'm going to show how easy those are to find on some of these internal assets in a bit But basically, you know, you just click to link and then all of a sudden your coworker your internal servers your printers They're all owned and phoning home even though like there was never a browser exploit that the initial victim wasn't actually compromised well, they sort of were but they're No shell command was ever ran on their host. No malware implant was ever installed on their on their computer And so like how long that takes well, it took me about 30 seconds with a really rudimentary try to sweep a Slash 24 so here you can see my internal IP address on the bottom there and It took a particular exploit that I built out for one of the ones that I showed previously slammed it in slur slash 24 all 255 hosts And did it in about 30 seconds So it could be pretty quick and I think this can actually be made faster with web workers and other hacks So it could potentially be even faster than that So So far I've talked about a relatively blind way of doing this somebody clicks a link and then you sort of just spray and pray But there's a way to do this a lot more targeted and I think recon in general has sort of become a lot more sophisticated in the last couple of years a Means to figure out what internal hosts are running at a company Has just become really really easy to do and that's through a number of different means You could crawl through github and look through their open source repositories go through all of their old Commits and just see references to internal hosts. I've used truffle hog to do that before You could view certificate transparency logs Which is a log of every public certificate issued by a certificate authority So if they have TLS and their internal hosts you can figure out what their internal hosts are by this public log You can search virus total basically if you upload any file to virus total virus total will parse out all the links And then make them available to everyone You could do good old-fashioned Google dorking you could do good old-fashioned brute-forcing with tools like fierce You can use passive DNS. There's companies with DNS probes That'll just watch everything fly past it and it'll make every host that it sees available to anyone who asks for it Long story short. It's really really easy to get a list of every internal host name And I've done this with a company that I was supposed to blur out but then forgot to so Pretend that you can't see which company that is and Basically you can see I was able to find you know 48 sub-demands that were sorry 48 Yes sub-demands of the company that were definitely internal sub-demands. It was using their internal schema And then I was able to find 97 that Were partially public and partially internal It's really really easy to get the internal Topology of a network this way And then if you sort of start to combine that with what I talked about earlier Let's let's pick one. So it here's a random sub-demand from that list before It's it's a piece of code that I've never heard of Gocd Dot DevOps company network. So I googled gocd and it was this open-source thing So I was able to pull down the source code and standard up locally Which you see here and by default there's no authentication on the system You can add authentication to it But the default of just running it out of the box doesn't have off and that's a pretty good start And then when I sort of did some digging it didn't take long for me to find a cross-site request forgery exploit on this system and What's interesting here is if you think about a classical cross-site request forgery exploit the ability to set a status The ability to send an email like that's Relatively benign in the grand scope of attacking a company But if you're targeting one of these internal tools the scope just all of a sudden explodes. So this tool Has the ability to build environments. It has the ability to stand up hosts And as it turns out One of those endpoints the ability to build an environment doesn't have cross-site request forgery protection Which means I can now take this company's name. I can build a payload Such that when a person visits an evil link I'm specifically targeting that host and that piece of software which I found a specific exploit on And if that link gets clicked I can build an environment in their ecosystem That's pretty bad and It's really really easy to find these types of exploits these internal tools these open-source ones are usually not audited They don't go through the same scrutiny that say a public bug bounty website may go through They don't have intense security code reviews on them They're usually really vulnerable and they're usually in a position that can do a lot of nasty state-changing things in your environment So you know a summary of everything I've talked about so far Basically, you know if your internal services aren't locked down, right and you click a dangerous link Through a phishing email through a watering hole attack through whatever vector that origin Can move laterally from your browser To another host in the environment which can be blind or it can be targeted and then that host can get a malware implant phone home Without a browser exploit So I'm going to talk about another type of vulnerability here one that folks are probably more familiar with cross-site scripting basically the idea behind cross-site scripting is if you Visit a page and the page takes input from a user say from the URL and that input gets reflected back into the page in an unsafe way that can lead to a malicious user running arbitrary JavaScript on that page so if you think about it like if Facebook had a cross-site scripting vulnerability and you send somebody a link to this thing And then you render the Facebook's page. They'd have the ability to set statuses to Delete friends to do anything on your behalf because JavaScript has pretty much full control over the origin for which it runs So Some examples of things you can do with cross-site scripting Anything the user can do all of a sudden you have that ability you can steal data You can change state on their account You can create backdoors by exfilling session tokens or installing an app on their account Maybe you install like a Facebook app because you're running code on their behalf but these are all again sort of Peer-to-peer attacks not an attack on infrastructure If we look about how common cross-site scripting is as a vulnerability These are like the hacker ones most common vulnerabilities and you see it's like way on the list All the way at the top by a large margin So cross-site scriptings are really really common and people are really really used to seeing them in bug bounties And that kind of normalizes us to them to an extent which is kind of it kind of sucks because it is a pretty severe Class of vulnerability within the scope of the origin that it runs on There are a couple different types of cross-site scripting I won't spend too much time going into them Or all of them I should say but I will focus on the first two a Reflected cross-site scripting is you go to an origin with some kind of parameter in the URL So a link can be sent to you and that parameter then injects JavaScript on the page a stored cross-site scripting is basically Some other user on the system stuck some data in a database somewhere and then that got rendered out in another context And so at the bottom here you sort of see this quote from hacker one that like a reflected Cross-site scripting vulnerability is probably less severe than a stored cross-site scripting vulnerability I want to challenge that and specifically I want to challenge that with regards to what I've talked to so talked about so far So basically if if you if you think about Sort of what I've talked about if you've got an internal Jenkins host and the internal Jenkins host is Building stuff in the environment and it has the ability to Spin up new hosts or to run code on other hosts in the environment A cross-site scripting on that origin Reflected or or stored could potentially mean compromising your entire environment but a stored cross-site scripting would depend on a Previous request being successful Storing something in the database and then a second request to fetch that back out and rendered it Whereas a reflected cross-site scripting is more dry fi you click one link and then it runs So in this context in a context where the attacker doesn't have access to the host in the first place But they get some kind of reflected cross-site scripting on this weird open-source thing that they're running internally Tomcat Jenkins or something else I've never heard of The reflected cross-site scripting can be a lot worse than stored cross-site scripting You're not going to get stored cross-site scripting on a lot of those things But you probably could find a reflected one if you look hard enough and even if you did find a stored one You wouldn't be able to store it because you'd need to be on that network But you can trigger the reflected one by getting somebody to click a link who is on that network And If you were to find a stored cross-site scripting you would need a cross-site request for a tree bug to go with it To allow a state-changing request to happen so that you could send that subsequent second request So it's it's it's less likely it's more complex and the reflected cross-site scripting I would argue is a lot more deadly in this particular situation of targeting internal applications So sort of again the old way of thinking about this is like you attack a user you steal a user's data But I want to kind of shift that paradigm and sort of And I know like other other people in the industry like beef for example have started to shift that I want to shift it even More to make people more aware of the fact that these like dangerous web browsers Sit on internal environments that that can make network requests any network that you're on and you can use these Webby attacks that seem harmless to attack infrastructure and to cause some real damage in an environment and so This is one example of one that I submitted to a bud bounty review board is an open-source tool for Performing code reviews you hook review board up to github it has the ability to pull projects from github and Anyone with access to review board can perform a code review I found that review board had no cross-site request for drew protection and There were several cross-site scripting vulnerabilities that I was able to find and so when you think about that I have the host name already because I've enumerated it passively and then I can build a payload That targets that host name that I've clicked by an employee would trigger one of these vulnerabilities and the impact of that would be I now have the ability to run code on somebody's browser and that Browser can make a request to an internal host and that host can Access all the source code in your company and then I can steal it all So end-to-end you click a link and all of a sudden I've stolen all your company's source code That's it's a pretty severe thing to do from something that we typically think is benign cross-site scripting And I guarantee you review board has not gone through an intense vetting process There's probably more vulnerabilities like that in it So the impact here is just way more severe than what we typically think of when we think of cross-site scripting We're targeting an internal host and if somebody clicks a link it causes irreparable damage to the company basically and So like that's the you know the kill chain here is like because it was a stored cross-site scripting I found you have to make one request to set the cross-site scripting Which you can do because there's no cross-site request for drew protection and then a second request to activate the cross-site scripting Which then exfiltrates all the data from the origin Which in this case would be all the source code or whatever source code you wanted to target So you can see here review board fixed this cross-site scripting vulnerability and gave me credit for it And then the bug bounty I submitted this to which was unrelated to review board also triaged this and they upgraded their version So another example is there was another company that I was doing a bug bounty against and And I love doing these bug bounties because it's I'm finding exploits on open-source software stacks So I could talk about them like it's not locked down. I can you know, it's it's open source I'm free to be more open about it So I'm doing some bug bounty on some company and they're running something global site company calm a Google global site I find out it's an open source piece of software and I just I tear it apart. I find so many vulnerabilities in this thing I found many cross-site scripting instance instances and I found a remote code execution Which was only triggerable if a user was logged in but if we combine these two things together if a user is currently logged in I can use the cross-site scripting to trigger the remote code execution and I can build this end-to-end link that if clicked by a user at this company is currently logged in all of a sudden their browser Targets this internal host and that host phones home So that kind of goes over what I just said you install the web shell via the user making one request You activate the web shell by making a second request and then that makes the host phone home And you can see they paid me out pretty well for that nine grand for all of the issues They recognize this is a really severe issue But this was just one host in their environment an open-source host Which their security team had never heard of never audited and they had a ton of other hosts that I haven't looked at yet And most companies do of just weird open-source stack running internally. You can target externally via these links So I want to spend a little bit of time talking about service workers Which is another new JavaScript feature that allows you to do these attacks in a more interesting way a Service workers intent is basically to function as a fake server in the case internet goes down so you make a web request and a service worker kind of pretends to be the server and Can service you in the event that there's no connectivity to the server? That's what it's designed for but what it allows you to do is kind of weird First it allows you to run JavaScript for five minutes after the user closes the tab Now if you remember I said 30 seconds is how long it takes me to sweep an internal subnet For five minutes is how long I get to sit on that after the user has closed the tab That's kind of scary It only runs on TLS hosts. So if you were just sweeping their internal subnet You probably wouldn't have much luck unless there's some crazy internal TLS tooling at that company But there is an exception to that and I'll get to that in a bit They're slightly sandboxed. So you don't have full JavaScript Execution abilities within a service worker, but you can make cross-origin requests Which means you can install cross-site request forgery attacks and you can trigger cross-site scripting attacks So, you know when I think of a service worker This is what happened when I opened up an incognito window and viewed how many service workers were currently installed Google had already installed one. They're kind of like malware. They're little bits of code that can continue to run after I Forget about the browsing context that I'm on And I personally don't want that like I you know, I use a VPN sometimes for some websites that I visit I don't like the idea that they can figure out who I am if I turn the VPN off four minutes after I visit the website But the additional thing that they allow you to do is send all these requests to all these internal hosts So if you find a bunch of internal hosts that are using TLS You can have your service worker just go to town for five minutes on those things could set up some command and control hook with beef And you can just continue to slam those hosts for five minutes after the person closes the tab There's kind of that thought when you have a cross-site scripting attack that it only runs for the short amount of time The person visits the page and if they just close the page immediately like you may be out of luck But these give you five definite guaranteed minutes And here's that exception that I talked about before it doesn't always have to be over TLS There is one exception and that's if you load a service worker over local host And you might be wondering like when can an attacker ever get somebody to load a service worker over local host on somebody's work station? And I've kind of come up with a kill chain here that is a little outlandish, but it works basically if you submit a file via bug bounty and Claim it some exploit an HTML file The person triaging the bug is probably gonna run that on local host and they're probably gonna do it on a privileged network Which means you could install a service worker on their machine on local host That can run for five minutes after they close the tab and now it can make insecure Requests to their network sweep the slash 24 that they're sitting on and Anybody running Jenkins or whatever else you're targeting those hosts can phone home It'll still run for five minutes, and it'll just allow you to make insecure requests Yeah, so Yeah, I'll speak to that a little bit so basically the Person in the front said like if you just open the HTML file It won't be running on local host and we're running on the file origin, which is correct However, there are different ways that you could coerce people to run it on local host For example if you included a bunch of HTML files and you wanted those HTML files to be able to reference each other Then you can say just spin up a Python HTTP server to make this work and chances are the person triaging the bug is gonna do it But that is a good point There are some other downsides to running things using the file origin There are some security implications to doing that And we could talk more about them later, but it is a good point. Thank you for bringing it up But that's that's basically the idea that that you can target these internal hosts Through the web browser you can do it in a very targeted fashion The recon and all the information that you can learn about an internal network has gotten really really sophisticated in the last couple of years and You can also figure out into a person's internal IP address because of a browser feature So that's basically That's basically What what I have for you. I'm hopefully bringing some visibility and bringing a new light into viewing these classical vulnerabilities I realized that a lot of that was like super technical But hopefully like bring it back up the overall idea of like how much damage can happen if I click a link I Just want to demonstrate that the answer is a lot Does anybody have any questions? Question the back Yeah, so if I understand the question you're asking How do I install a service worker on an origin basically? For a server that's up. Yeah, so just rolling it back a little bit a service worker Can be installed on an origin that you have control over so if you have control over an origin you can install a service worker for that origin and It's designed to be like a well I'm gonna install this just in case in case I go down then the service worker will kick in But the service worker has the ability to also run while the server is up it can run all the time Yeah Control the origin is So the way you install a service worker you visit a web page a web page can run JavaScript on your page and that JavaScript installs the service worker and Then it points to another file being hosted on the origin and that file itself is or is the service worker So you can't quite install a service worker if you get a cross-site scripting on an origin for example But if you have full control over the origin like evil calm and somebody visits evil calm You could just install a service worker on that origin no problem and then use that service worker to make requests to the internal network Yes That's a great question the question was like can you write a browser plug in to just kill all service workers? I can do one better. You can actually disable service workers as a feature You can just in chrome turn them off, but you might find it breaks some functionality on certain websites You use Facebook Google they all install service workers, and they all do stuff with regards to their origin It might end up breaking stuff unintended question up front So the question is if you visit a web page can that web page install a service worker I'm just repeating the question so that everyone can hear it basically the question is if you visit a web page Can the web page install a service worker and then close the main page? It can certainly redirect you to another website I'm not sure if you have the ability to close a tab my gut is that you do And then what was your second question? Can a service worker open a new tab? Probably not is what I would think service workers are somewhat locked down and in the JavaScript that they can run one of those things that they can do is make requests to other origins, but my guess is that Included in that subset of things is not the ability to open a tab, but I am not a hundred percent on that There's a question in the back First of all really great talk Yeah, so I don't remember exactly, but I'll give you a scenario that's perfectly plausible I went to their certificate transparency I Went to a certificate transparency log. I searched for their top-level domain found all the sub-domain And one of the sub-domains was global site.company.com and then from that a Google global site found out was an open-source stack Spiked on it submitted the bug then they found this thing running that they weren't aware of and it went from there Yes On the client side Yeah, so the question was like from like a blue team perspective, what sort of behavior could you potentially? Fingerprint to identify this type of lateral movement. It's tough like Making HTTP requests internally is something that people do normally So being able to identify this. I mean you can write Signatures for the Metasploit library, but you don't know what you don't know about so if I have an exploit on global site and I Build out a payload for that You know, it's gonna be tough to to write a fingerprint for for that when you don't even know a global site is you don't know That it's in your environment What you could do is probably build some sort of heuristic on like if an internal host All of a sudden sweeps an entire network But then you're kind of getting into like behavioral stuff, which is a lot harder to write rules for and to scale and to keep up with So it's tough and I think that's another really good point that like This type of implant is a lot Trickier to get attribution and to figure out what happened and to trace back the story of like well This host got malware on it all of a sudden but like where did that come from like that host? You know they themselves didn't click a malicious link. They didn't even know about the guy on the other side of the company that did So it's hard and I'm not an expert in blue team by any means, but Yeah, I've got to answer your question But from the client side watching like what's that since if you're not like you go stealthy You already know what your target in the network. You're not gonna try and do it in network integration. You just go in and try it Target specific host hit it with your specific Like you describe in your in your talk and then you know So like you're asking basically what kind of endpoint detection can we put on the host of the person clicking the link? Are these I Think that would be tough to do I think like we're using the browser the way it's intended to be used It's possible that you could maybe write some sort of plug-in that detected If you visited an external host and then that external host is trying to do internal things That seems like something that you could probably alert on But So the origin header was introduced by browsers to be a method of limiting cross-site requests If you look at the OASC CSRF cheat sheet both origin and refer checks are listed as So that's a good point basically the person in the front mentioned that if you cross reference The origin header with the host header you can potentially tell that this network traffic was done cross-origin I think the problem you're gonna have is a lot of these hosts are target Well global site for example review board for example these were targeted against TLS endpoints and so you'd need some sort of TLS introspection to be able to see that and Then you're gonna have all the problems that go with full TLS introspection But it is a good point and we could possibly build some sort of browser plug-in like the other gentlemen mentioned to be able to detect that kind of thing Totally except for the case where I mentioned of like somebody runs something a local host And then you're just sweeping that internal sub to mate that that could be all unencrypted that you could that could you do Other question Yes The point brought up was basically like It falls back to what I said originally that that fallacy of like having a hard security shell and outside a soft security shell is a good security model I mean, that's a fallacy right. It's not true. We all know it's not true, but like Pointing some of this out that this definitely I think brings more visibility to that and like Google's beyond-corp model Of like let's just kill the internal network entirely. I think that is in my mind the only like ironclad like solution to this Beyond-corp and I apologize if I bastardize this definition, but the best of my knowledge beyond-corp is basically You have the ability to talk to the cloud. We're gonna view an access point. That's it You can't talk to your coworkers. You can't talk to printers like you have no internal network Okay, thank you And for all the bug bounty enthusiasts in the room I strongly encourage you to try this out It's really really easy to find these bugs. It's really really easy to find these open-source stacks ran and Like you're finding bugs on open-source things that are ran all across the community So you're giving back in a way that really gives back more than just a traditional bug bounty But you might find pushback which I did find at review board. They were like we didn't write this so we're not gonna pay you So that that side of it kind of sucks, but the upside is you get CBE's you can talk about it And you're giving back to the community in a better way in my opinion Yep So the question is like how do you do timing if you find a bug in an open-source stack do you first reach out to the Like hacker one platform or whatever or do you reach out to the vendor? Historically I am not a copyright expert, but the way I've treated this is when I disclose something to hacker one I am giving them intellectual property. I am giving them an exploit and that belongs to them at that point I'm not sure if that's I haven't read the terms and conditions I don't actually know if that's the way it works, but that's the way I've treated it and then I've said okay Well, I'm disclosing this to you. I'm giving you this exploit What would you like me to do next and nine times out of ten? Probably ten times out of ten. They're like, okay go to go immediately disclose that to the vendor and then CCS And then we'll stay in the loop Some other pushback you may get is like a company may say Well, you're just like spraying this across every single company you can find like that's not fair. You shouldn't be paid Five times for the same bug and so I try to do it on a one-by-one basis of like this belongs to you I'm not disclosing it to anyone else like whatever you want to do. That's that's what we're gonna do Other questions cool. Thanks everyone