Offensive Javascript Techniques for Red Teamers

offensive JavaScript techniques for red teamers or anyone really awesome everyone everyone hey me with my funny rock-and-roll microphone tes tes oh cool awesome we've got a lot of material to get through in a pretty short time so we're gonna get to it thank you everyone for attending we're gonna be talking about offensive JavaScript and how we think it should be used more by offensive red teamers and bug bounty hunters so my name is Christian I've contributed to the browser exploitation framework also known as beef I've co-authored a book on bad JavaScript and presented it a couple of different conferences my name is Dylan I had the opportunity to speak here last year but an open source tool that I wrote called

truffle hog I've also spoken a number of different security conferences including torque on DEFCON and besides on a number of different apps activist MK we confer all the New Zealanders in the audience which we know there's probably at least two of you yeah so the focus of our talk is going to be on a one-legged unicorn balancing on a beach ball Wow isn't listening you gotta say it again all right hang on so it's a one-legged unicorn balancing on a beach ball while juggling pogo sticks and three tentacles [Laughter]

so we'll wait we're also going to be covering some new JavaScript features that make it a lot easier to do exploiting things and we're going to be looking at different ways that we can combine together Red Team techniques to use these JavaScript features to attack internal networks and the couple of those include the fetch API WebRTC service workers and many more sure and one of the core themes that we'll talk about is this idea in the context of web browsers that actions can be performed cross-origin despite one of the primary browser control Genesis which is the same origin policy and for those that maybe don't have too much experience with that we'll talk about these a little bit more later on

as well so like I mentioned before a lot of what we're gonna be talking about isn't very novel 2ab SEC teams and a lot of what we're gonna be talking about is it very novel to read teams but we believe the way that we were combining the two concepts is kind of unique and special and valuable to both parties and so there's gonna be a little bit of probably dry stuff but hopefully the overlaps where things get interesting so if we rewind the clock back a little bit to the mid 2000s it wasn't too difficult to find a single critical security vulnerability that could completely compromise a company you could get a sequel injection or code

execution that could allow you to completely dump a production database and just fully own an entire company at the time at attack against the client may not be that interesting because if there's systemic problems that allow you to totally dump a production database who cares if you can attack a one individual client so things obviously evolved and got more complicated over time red teams started extensively using malware frameworks to compile libraries of exploits and move laterally through environments to change many different vulnerabilities together and the thinking there is that these red teams can use these malware frameworks to move through an environment stay in environment for a long period of time and eventually again get access to that

full production database so again we're back to the same like client attacks don't really seem super interesting because with these malware frameworks it's still relatively easy to just completely dump production database so let's talk about this status quo a lot of organizations suffer from this fallacy that we have called the lobster security fallacy obviously really really hard on the outside and soft and delicious PTSD on the inside and obviously completely secure as everyone who has done a security assessment from outside of mobilization noise so a big part of this game that we mentioned with the malware frameworks is getting that first foothold and if we look through something like the Verizon breach report on how this usually

happens the really easy common ways are through either stolen credentials in a in a data breach or guest credentials or some form of social engineering like fishing and then once you get that initial first foothold into an environment like I mentioned you use your malware framework to stick around for a while and move from machine to machine leveraging more and more vulnerabilities collecting machines like you would pokemon cards until eventually you've traded up to that one that's really interesting the production database and so to put things into perspective again if it's relatively easy to get the production database it seems pretty boring to use a client attack like CSRF to attack an individual client and get one users data when you

could just get every users data now obviously someone who spent a lot of time writing and contributing to a browser exploitation framework which is meant to do exactly what you have said is boring I feel personally attacked I'll keep an open mind why don't you tell me more about that sha sha so it hands up if you've heard of beef right hands up if you've used beef as part of like an official Red Team engagement still a few hands so I every one of those people are beer self not easy um thank you obviously the idea was beef turned kind of JavaScript client attacks on their head and wrapping back to the Verizon data breach

investigation report you know in Dillon's circumstance where you were try and deliver malware 12 percent would open an attachment but a bigger percentage of people would click a link and that's an interesting point and so we asked ourselves how bad can clicking just a link bait so before we go any further by show of hands how many people have a live browser exploit that can be used to get a remote code execution on a person that clicks a link

by all means I'd be curious to hear from that half hand after but the reality is these types of exploits are becoming increasingly more difficult browsers have different containers and different security features these days that make it so that even if you have one type of vulnerability you probably don't have the whole farm flashes going away it's been end-of-life tanned it's disabled by default in a lot of major browsers these types of attacks to get remote code execution from clicking a single link not really a good option anymore and one of the things that I really like to talk about is this concept with that the modern-day operating system is in frack you know it's the browser engine

chances are you have a smartphone and it's running a browser probably with a bunch of tabs also chances are if you open your laptop it's got a couple of windows and I know we have a previous hiring manager of ours who used to have thousands and thousands of tabs and I'm pretty sure he doesn't know what was on every single one of those tabs Angelou and so you know the reality is like this is a really interesting attack surface like a browser is a piece of software that roams around and it simultaneously connects to the internet it can talk to the local local loopback on your machine it potentially is able to access things over a VPN and it goes from local

network to local network so it's very very interesting and so kind of coming back to this question how bad can clicking a link be we think it's pretty bad we're going to try to free in the case to be sure one of the one of the common patterns that you would see from using something like the browser exploitation is something similar to this a user clicks a link a bad website with bad malicious you know with malicious JavaScript can get the person's internal IP address using technologies such as web real-time communications and then using that information it can perform a network sweep to find available hosts near that computer and then using that can actually find open ports with some

limitations against those servers as well the beef has a number of modules that can help with these phases from using WebRTC and during the port scanning and this picture here is actually it's a feature inside of the product where after you run these modules it'll give you a little diagram which is kind of really useful all right so it sounds like you're kind of framing the case for how some of these what are usually seen as client attacks you're using beef to actually use them to attack infrastructure exactly so if a client clicks a link then you go through that person's browser to attack some internal infrastructure that sounds pretty interesting but based on my understandings of the

limitations of browsers it sounds like there's still some challenges here like the amount of time it might take to do timing attacks and stuff like that and maybe something same-origin policy restrictions it seems like you know in theory that's a good idea but maybe in practice it doesn't work out too well sure and certainly a lot of the logic in beef that does these you know recon modules against other networks is based on trying to send a request to an IP address on an arbitral and waiting for things to fail it doesn't matter whether or not the same origin policy is going to prevent any of that talking about this though without actually discussing the same origin policy gets really

complicated so we have a couple of slides on the SOP for those that haven't spent time working on this stuff and the idea is that browsers have this control inside of them to isolate origins from each other generally this is kind of you know from like a scheme hostname and port and obviously some browsers have some nuances because Internet Explorer versions of Internet Explorer would do sop control slightly different but the idea is that if you have content running in one origin such as Facebook it can't arbitrarily send Java scripts to an origin like Google and get data back technically it's broken down into this kind of two high level buckets simple requests are standard form requests or

get requests or other kind of standard web requests that our browser may initiate across origin and then non simple requests so literally everything else so these are you know potentially requests that are generated from JavaScript for example although the fetch API can send simple requests as well this is the bit that always seemed crazy to me that if you send a post request to another origin even on another network that's allowed without asking the server's permission but if you send a put request arbitrarily you have to ask servus permission ahead of time sure and that permission chain looks like this before the client will send the request that it wants to send it first of all

sends an options request and it waits to determine if that's written you know something that it's allowed to do unfortunately what the SOP doesn't prevent is this leaking of timing information because if you know if a host is available regardless of you know from just the pure networking perspective a response will take a little bit like if a host is unavailable a response will take longer to fail and you can use that timing information to do internal network scanning and things like that and as Dylan alluded to cross-origin vulnerabilities can be performed through cross-site request forgery and other other forms as well the other topic that makes this really interesting is DNS rebinding which which can really blow

this stuff away we'll we'll talk about it a little bit but we don't have too much time to cover it in depth cross-site request forgery is a pretty well-known vulnerability that you know web application security people talk about typically these are simple requests which will include a version of state when you try and protect against these generally what you're writing is this pre-flight you're adding a version of then the pre-flight artificially by trying to ensure that there's some some value that the DES client knew ahead of time before sending the request origin wrapping back with FRA and I basically talked about you know CSRF attacks against users they're kind of not as work okay so I guess when you frame it

like that the fact that you can send post requests and get requests to every single network that a person is sitting on the loop back the VPN the internal network just if they click one external link once that sounds like you might be able to do some bad stuff with it sure and this is this is primarily what beef is about the idea is that you in the middle here are our beachhead and if you can get arbitrary JavaScript that's hooking back to something else you can then send other commands to other other networks and this could be your co-workers or other internal services cross-site scripting forms part of this as well we're not going to talk about

this too much but the idea is that if you have a vulnerability and you're a web app you can obviously run arbitrary JavaScript in that origin in that instance that that JavaScript basically emulate anything that the user can do and if you're wondering how common these types of owner these are this is the readout of hacker ones most common reported vulnerabilities these get recorded all the time cross-site scripting is still by far sitting very comfortably on top if you run a bug bounty program you probably see those all the time cross-site request forgery is not too far to follow but still very common type of vulnerability and both of these can be used to attack infrastructure this is

an interesting quote from hacker one where they basically say generally speaking stored cross-site scripting are more impactful than reflected cross-site scripting I think what we want to do here today is kind of flip that on its head and the reason why is if I want to get some reflected cross-site scripting on an internal application I trigger it through a victim that clicks a link I can do that but if it's a store across side scripting I would need some way to store the payload ahead of time I wouldn't be able to get that data in and then get them to render it and the only way to make that happen as additional vulnerabilities where as reflected

cross-site scripting we can immediately start attacking infrastructure and so to take a step back and look at what the bigger picture is here let's say I knew that internally a company is using Jenkins a lot and I can force a person to send HTTP requests to their internal network if they click my link and then I get a reflected cross-site scripting in Jenkins because Jenkins lets you run code through the web UI and because JavaScript gives you full access to the web UI this reflected cross-site scripting gives me remote code execution and Jenkins and the stored cross-site scripting in this context isn't really that helpful so if somebody clicks my link I can use the

reflected cross-site scripting to trigger remote code execution internally at a company so kind of bringing it all back we mentioned one of the challenges here might be same origin policy and we talked about some ways to get around that but it still seems like if we're attacking an internal network it's gonna take a long time to go through all that and we're relying heavily on timing to do that yeah there's gonna be some major limitations to using these definitely and that's I'm not gonna argue that obviously the window of time where you get JavaScript to run to do like a full network sweep and find all the internal hosts and find all their IP address is

obviously tricky happens if the victim closes their tabs you know the premise that we're talking about is trying to get to arbitrary command injection on internal hosts through potentially a single victim who may close their tab pretty fast so I think this is where we really take the idea of some red teaming techniques and we combine them ahead of time to do a whole bunch of recon on a company using a wide variety of methods to get everything we need to know about their internal environment ahead of time so that by the time somebody clicks a link we already know exactly what we're targeting with our payload queued up and immediately we just start attacking them

there are a ton of different rate contexts and I will not go into all of them mostly for time reasons but I will cover two of the ones up here just to kind of get the point for us the way certificate transparency works basically all SSL certificates from a real certificate authority will be logged in a public ledger called certificate transparency even internal hosts and so if you have SSL on your applications the host name for those applications is very likely being leaked through certificate transparency and another example of things you can use recon virustotal is a service that advertises itself as free virus scanning for malware samples that you upload to it and they do that

they will scan it with a whole bunch of different antivirus software well they don't advertise as much though is if you pay virustotal a bunch of money they actually allow anyone to download those samples that people have uploaded so if you upload some weird internal thing that's got internal host names anybody can download that if they pay virustotal enough and if you don't want to pay virus total if you want to just use their free api as it turns out they make available to them all the host names that they've found from all the samples that have been uploaded so it's pretty easy to get a whole list of host names through virustotal of a company because

chances are over a long course of time folks at that company have uploaded various samples to virustotal including internal host names i'm not gonna go through the rest but you got the picture at this point now we're going to at this point for no arbitrary reason pick on Netflix so we've asked ahead of time from one of our friends over at Netflix that we can do this and they've given us a thumbs up we don't know anything about networks Netflix is internal environment we've never worked there before we do have some friends over there that we refuse to apologize to um but the idea here is we're just gonna perform recon on Netflix to see

what it looks like so we're gonna start with second-level domains what this means is like if it's something calm or something or etc we want to see as many of those domains that we could possibly can that are owned by Netflix so there are a lot of different tools that we can use to do this one of them is a tool called passive total that will show us in this example on the Left there's a Whois certificate or sorry the Whois record it's got some information like the email address organization in the street and the city those are all relatively unique to Netflix and passive total will actually allow you to do a reverse search on those fields so we can

see all the other domains that also share those attributes and use them to put together Netflix's portfolio of domains you can just click the button which is my form of hacking it's yep so on the right side we've got the SSL certificate and it's the same exact idea you notice the location is los gatos how many companies are in los gatos i've looked it's not that many most of the los gatos certificates actually belong to netflix and so when we put this together with say crawling there github looking for host names going through their mobile app looking for host names we end up with more than 500 second-level domains too many to list here and I will not dig into each

and every one of these four subdomains for the sake of time and said we were only going to look at subdomains of one of these second-level domains but you can imagine like all of them could have subdomains that correspond to internal host names so we're just gonna pick Netflix comm and we're going to get to work on finding subdomains we used a bunch of different recon techniques to do this and by the end of it what we end up with is thousands of subdomains we have a small list of them here you as you can see like some of them look pretty interesting from an attacker standpoint that's our confluence of Puppets server their JIRA their artifactory

not all of these are necessarily still live but a lot of them probably are and what we can do is we can use these subdomains to look for things that look like they're open-source sounding names so what we can do once we find one like for example if we were to find Jenkins that Netflix com not to say that exists basically this would allow us to build a payload against that host specifically and target it internally so it's fair to also assume that if we find a name that's something Netflix comm there's probably a whole bunch of devs running that thing locally as well so if we find Jenkins that Netflix comm it's probably fair to assume a whole

bunch of devs are running Jenkins locally so what uh what if we again put this together not to pick on Netflix and not to pick on Jenkins but if we look at the list of cross-site scripting that have been reported to Jenkins over the last couple of years they're pretty common and typically for one reason or another they're filed as low severity we want to again frame the case that if you were to get a reflected cross-site scripting in something like Jenkins it could be game over even if it's internal and one of the really interesting things that that happens in this instance as well as the kind of tunes the bug bounty from being assessment to being

effectively a white box assessment it's a view download you can software yourself look at the code it's a really good point so yeah usually you're from a from an attackers point of view if you're attacking something that's external you don't have the source code for it but if you're attacking an open source thing that runs internally you could just rip the source code run it locally proc do whatever you need to do so potentially bug finding is a little easier so this is just a small piece of JavaScript to see what that could look like if we had such an exploit like a cross-site request forgery against Jenkins or something like that to sweep a slash 24 so 255 hosts this takes about

30 seconds so it's pretty quick so if we knew ahead of time that there's something than running internally we had an exploit queued up and ready to go we could potentially spray their entire internal network after 60 seconds this actually is what unlocks some more deadly attacks we mentioned DNS rebinding earlier we won't have time to go into all the specifics of DNS rebinding but the basic idea is that the definition of an origin does not include an IP address and so if a DNS server responds with a public IP address the first time and a private IP address the second time the browser will think that it's talking to the same origin even though it's talking to a

different server so we can serve our malicious JavaScript under a public IP address and then using that malicious JavaScript have it make requests to its own origin and then the second time the browser does a dns lookup the shortest CTL of browser sports is 60 seconds we can actually respond with an RFC 1819 IP address and have them make that request to an internal host now the caveat here is that HTTPS won't really work because certificates common names won't match up because your external host name isn't gonna be the same as your internal host name but everything non SSL we can basically completely get rid of the same origin policy and just fully make requests of your response to hosts

without relying across that request forgery bugs and what about only expensive firewalls that we have that's a great question because the person clicking the link is already sitting on the network behind the firewall we've already bypassed that and so the user their browser can make full requests to loop back to internal hosts to VPNs they're already sitting behind the firewall and so we're pretty much able to completely blow past that pretty much everything on the internal network that does not use SSL or that's running locally basically becomes external and the attacker can fully make requests and view responses as if there were no restrictions to the entire internal network just by holding somebody on a

page for 60 seconds NCC has put out a framework called singularity and we met with those folks and talked with them they're building out capabilities in singularity that will basically allow you to you click a malicious link and then singularity will rebind to your entire internal network it'll look at the responses coming back log all of them and if it matches a signature of something it knows it's vulnerable it'll auto upload exploits to it and you'll be able to hook in interpreters and stuff like that so this DNS rebinding stuff is really dangerous and I wish we cover it more but we've got to keep covering other other techniques as well so obviously in these

examples we're talking about rebonding to IP addresses but during the recon we didn't get up here dresses we got see names like does that can we do that yes so during our recon we were able to get a portfolio of potential DNS records that that a company is running internally you're absolutely right that when we do our DNS rebinding we don't have to point to an IP address we could just point to a cname and because we already have thousands of posts so we know are probably already internal we don't have to do any guesswork at all we can just completely do our DNS rebinding to all the hosts that we already know are there and then immediately start

exfiltrating data so no we're gonna cover a bunch of real-world examples that i've used in bug bounties that are unrelated to Netflix or Jenkins or anything that we've talked about so far what I want to show here is that this process is actually relatively easy to do and I've done it a couple of times so basically there is some company that was running a piece of software called review board they're running it at review were about Capcom that I was able to find through recon this company ran a bug bounty program and so I looked up review board I saw what it was it was a code review tool I pulled it down and ran it locally I had access to the

source code and I started looking for web bugs and of course it's a web application and it's a web application that not a lot of security researchers are looking at so it was filled with web bugs ahead cross-site scripting and cross-site request forgery and because it was white box they were relatively easy to find so when we kind of combined all this together what we end up with is a link that if somebody this company clicks we can use cross-site crypt scripting and cross-site request forgery to completely steal all the source code at this company so we have a link that if somebody clicks immediately I just get all the source code we see here when

I disclose through you bored there great about it they fixed it really quick and then when we top stack again and move back to the bug bounty the response was kind of interesting they said well we're running this internally and we appreciate you reaching out to reviewer and getting this fixed but we didn't really write this code and it doesn't really Drive well with our scope so we're not gonna pay you but thanks for submitting Wow again this pattern is gonna get a little repetitive but there was another company running a tool called geo CD DevOps grumpy Network I had no idea what Geo CD was so I googled it I found it was an

open source thing pulled down that source code I run it locally and by default it has no authentication so that's off to a good start I'm able to proxy requests and with enough poking at it I find that it's got a particular endpoint that is not validating CSRF tokens the application was generally good about CSRF but there was this one endpoint that just wasn't validating the token and this endpoint was to build an environment not important and so when we put all this together what we end up with is if somebody clicks a link then we can build an environment internally at this company by geo CDs definition of what an environment is not super great

what happened here is I used somebody that was working at this company and I reached out to them and I explained this whole thing to them and I said I know you have a bug bounty like I had a bad experience before should I bother submitting this and he said you know like I understand where the other company was coming from like this this really you know isn't gonna be in scope and we didn't write that code so don't bother submitting but thank you for finding this and so I didn't one more time same exact process we find some company running some open-source thing in this case the thing is actually relatively older piece of software the

source code is on SourceForge global site company comm and again we're gonna pull the source code down we're gonna run it locally and we're gonna pen test it and hear what we actually find are some worst types of vulnerabilities we find cross-site scripting cross-site request forgery we also find remote code execution through the file upload and some other serious bugs so when we put all this together what we have end to end is someone clicks a link and then we use the cross side scripting just directly install a web shell and figure the web shell and now at this point we've got somebody who clicks a link and immediately I have a shell in their internal company this is obviously

pretty severe impact and when I presented this to the company they definitely got the the picture and the scope of impact and they compensated pretty well so the results from submitting these types of bugs to bug bounties has been kind of varied and we could talk about that more in a bit but in this particular case the company was appreciative of the finding but hopefully I've gotten the point across that this is really easy to do if you want to target a company and you want to get a foothold into an environment and you want to constrain yourself to the foothold is only a person clicking a link it's not that much effort to be

able to do what I showed so um you know obviously going back to to this same problem though we do have still some challenges with this limited time window and there are other options that we have available to us such as service workers similarly we don't have time to go into this in depth of service workers is a relatively new browser capability that actually allows you to run JavaScript after the tabs have closed typically you only get about a window of five minutes but some great researchers Emanuel law from Google and claudio from Zedeck security out of New Zealand they've figured out how you can do it for 30 minutes and running 30 minutes of

JavaScript after the window has closed is obviously petrifying and they allow certain degrees of you know cross-origin requests so you know in this instance it can only run I have a TLS and it can't do mixed content or no blocking requests it's funny because the DNS rebinding is only over non TLS and the servers workers are only over TLS so we have a nice portfolio of attacks so using these you know we can do things like we can potentially spray all the HTTP hosts that we know about from our recon we can potentially spray the loop back as well because quite often people will run applications and they actually listen on the local local loopback I'm not too

sure how many people realize that T marks a local loopback for Windows it does we should also mention that there is an exception to the TOS rule and that is loopback service workers do allow you to make non TLS requests that cool I'm so like enclosing really quick you know just reframing these problems browsers obviously have access to multiple contexts and if you're using you know if you're doing a readiness assessment we have a pretty open scope you should definitely be using this as part of your assessment recon really really helps and quite often this is like a different way to exploit recon because red teamers are generally doing this but now you've actually got ways to be able to send

requests to internal hosts new browser features are obviously really interesting webassembly and a bunch of other things are coming down a pipeline so take the time to research those things and and I think one point that I really want to drive home here is if you're running a bunch of open source in your internal network like we really consider either putting it in scope for the bug bounty or putting some effort specifically into improving the security of that open source software submit your patch upstream and get other companies to be more secure as a result a lot of people just blindly run open source stuff internally without thinking about it too much but the reality is those

projects don't have the funding or the resources to secure them awesome thank you everyone and thanks to these people um if you want to come and talk to us for questions where the booth called it's a cruise booth we'll be outside for a bit as well thanks everyone [Applause]