← All talks

Dormant DOMination

BSidesSF · 201731:31183 viewsPublished 2017-03Watch on YouTube ↗
Speakers
Tags
Mentioned in this talk
About this talk
JavaScript in browsers can persist across network transitions and silently enumerate internal networks without establishing outbound connections. This talk demonstrates how dormant DOM-based payloads use WebRTC, Web Workers, and XMLHttpRequest to discover air-gapped networks, scan subnets, and probe for listening ports—remaining invisible to traditional network monitoring and host-based antivirus.
Show original YouTube description
Dormant DOMination Traditional attacks to air-gapped networks have looked at vectors such as USB memory sticks (thanks Stuxnet), audio signals (thanks BadBIOS) and even cellular frequencies (thanks GSMem). But it's not entirely uncommon for portable devices (laptops, smart phones) to go from network to network, even connecting to potentially sensitive corporate networks. In fact, every day many corporate devices connect to the local coffee shop wifi on the way into the office. And it's here where things get interesting. Advanced mitigations to these vectors include things like host-health check, upon re-connecting to ‘secure’ networks. But what’s the chance that these scans will pick up on JavaScript that may be running in the DOM? Leveraging a number of existing browser technology, such as WebRTC, Web-Workers and good old fashioned XMLHttpRequest objects we have everything we need to plant a JavaScript hook and monitor the local network interface for changes in connectivity. From here, we can start scanning different local subnets looking for available hosts. Once identified, we can even determine if they have any listening ports. This presentation will discuss existing methods of subnet discovery & scanning, persistence methods and ways in which dormant JavaScript objects can periodically scan the local browser's network to discover new attack surfaces, even those that may be air-gapped. (Bloody JavaScript...)
Show transcript [en]

it's been about a week since I lost JavaScript did yeah and um I know you guys are all here because you know you have a lot of emotions and feelings towards JavaScript and I think like most worthwhile relationships it's a very complex mixture of love and hate and I appreciate that JavaScript reminds me of my wife a little bit anyway so my talk is going to be looking I guess at a passive-aggressive tale of JavaScript and I certainly am of the opinion that JavaScript is changing rapidly and I'm not too sure you guys are obviously aware of just how crazy JavaScript has been getting over the last couple of years anyone here done any work on node a few

hands so that's [ __ ] crazy because she's also writing server-side scripting in JavaScript which is blowing my mind and it's one of those things where we often have to stop and kind of think we're you know you look at something like chrome and Chrome has four buttons and like at the little burger menu thing or the three dots or whatever it is and it looks really really simple and everyone has it and you don't need a license to use it and my mom uses this you know and she seems to not get completely owned all the time but chrome is really really [ __ ] complicated and like what it's doing with JavaScript is

also really really complicated and then you think about how it's made its way into everyone's pocket and I want everyone to pull out their phone right now and open up Chrome and at the top it'll tell you how many tabs you have open and I want I want you guys to shout out like some numbers for how many tabs you have open in your mobile browser 1 4 6 we've got 10 20 going once going twice 28 um it's it's [ __ ] crazy right and people you don't I mean browser context in mobile chrome is obviously great because it puts JavaScript to sleep when it's in the background which is obviously fantastic but then if you think about your laptop

or your work laptop you probably have two or three chrome windows and if you like one of my directors you'll have like 40 tabs and they're all doing something like he opens his computer and [ __ ] is happening and there's no way he knows what is happening inside of his computer and and like JavaScript and browsers to me are super interesting I was fortunate to be invited to co-author a book on some miscellaneous JavaScript [ __ ] and um and the the primary author Wade has this really great hanging at anecdote like let's imagine that you could pull an information risk professional from from the 90s or even like the 80s into nowadays and you tried to make him do a

risk assessment of a web browser and said you know hey we've got this piece of software and we need to install it on everyone's computer and it accesses the Internet where we don't know what it's gonna access and at the same time it's accessing the sensitive resources and our intranet and it's doing things in the background and we've got a mixture of kind of code and control language in the same in the same space you know what do you think is gonna go wrong here and this poor you know 80s businessman with his big shoulder pads his head would probably explode ignoring the fact that we just time-traveled an 80s businessman into 2017 whatever um and look it's not

all bad you're thinking to yourself okay javascript who really gives a [ __ ] okay it's not like you can get JavaScript and bad JavaScript will immediately result in arbitrary execute it like you know arbitrary RCEs on computers or bad binaries but then you have to remember that like javascript is generally the platform for most drive-by malware these days and this [ __ ] is obviously causing people a problem because they're still getting impacted by it even today and then you have some other really interesting surfaces such as you everything IOT and you're on your like globes and you're on your cameras and these things are on your home network and you're kind of like you're

not too concerned about them but then they've got a C surf boner ability that can be that can obviously make them do bad things and and C surf is like one of my favorite vulnerabilities I know PayPal and ever I mean everyone has this problem I just I just pulled out a couple of websites and I think this concept of what javascript is doing now like if we look at what it's doing right now it's already pretty pretty freakin crazy and if we project forward into way that we're shifting from this general-purpose computing platform to kind of more dedicated computing like iOS and Chrome OS and rest in peace' Firefox OS um like we're kind of shifting from being able

to run arbitrary executables on our computers but then that's left a gap and people want to do [ __ ] with their computers and so javascript is empowering them to do that with all sorts of craziness and this is just like a short list of random stuff that we are now seeing in browsers inter tab communication which to me is I haven't really gotten my head around whether or not that's bad one of my colleagues was talking about it not too long ago it's very interesting to have within the same origin tabs being able to communicate without with each other via asynchronous message passing like it's that's an interesting influence on an attack surface that we already kind of don't

know how to measure very well um WebSockets web workers web RTC like this stuff is all replacing native functionality and it's just in JavaScript like we just get it for free um web assembly is the thing that's really kind of exciting me at the moment Stephan Kraus did some research a week ago where he basically ran some computing problems the red line is natively performance on C and the yellow line is Java and he ran these I guess these processing exercises in Firefox Safari two different versions of Chrome against native computations now apparently the web assembly version in Firefox is quite fast because for some of these it was almost on par with native performance of Java and that's

today so in five years time javascript will likely be performing at speed as far as like having a binary running on your computer anyway what the [ __ ] am I talking about what's the problem I'm I think we're getting to this point where even with things like the same origin policy JavaScript running inside of your browser has the ability to reach out and it may not be able to get data back but it can determine where am I why things like web RTC so it can get an internal an IP address and obviously where it is out on the Internet and what is near me as in send a request and wait for the socket to close within a timeout

period to determine if a port is open on arm and that's still not very clear so I'm going to get to the demonstration real real soon but what I've hacked together with some with some upright duct tape is using web RTC T's web RTC real time communications to get internal IP address information XML HTTP request objects to determine servers within my proximity a rules engine to tie it all together and obviously a some duct tape and a lot of beef so there so the beef project hands up people who know about beef ok hands up people who have used beef hands up people who have used beef for work it's actually that's [ __ ]

cool you guys Rock I'm gonna bake you all lamingtons anyway so the first phase in our little exercise the first first ingredient is web real-time communications and for those that haven't heard of this the idea is that you want to be able to have real-time video chats with your friends and you don't want to leave a web browser so web RTC allows you to do this and one of the mechanisms it does one of the mechanisms that it uses to achieve this is the ability to be able to talk directly from peer to peer and for a computer to talk to its peer it has to be able to know its internal IP address so as a part of that when you establish

a peer connection even if it's not a legit peer connection it'll start throwing these on ice candidate events and ice which is the interactive connectivity establishment will basically say ok my browser is listening on these IP addresses and on these ports and so in this instance you can see you know the local IP address of this computer is one on two six-eight 0.13 so all of a sudden we've started and get a picture of the local subnet and it's listening on a particular UDP port which doesn't really matter now tying this with xml httprequest objects we can obviously kind of craft arbitrary requests and even if they go against the same origin policy they'll close within a certain

time period so so ignoring things like on port blocking that browsers have a browser can send requests to an origin and it'll fail either really fast or not so fast so you can actually determine if a port on a remote host is actually is listening with some degree of accuracy the final ingredient is obviously the engine to run this together and in the beef project a good friend of mine called Mikkel a he built this functionality about a year ago called the old auto run rule engine or a re e and a re is basically a combination of few things first you have to be able to target browsers so you have to be able

to programmatically say when these browsers are hit do stuff the second part is the chaining modes and so the training modes currently have two different modes so sequential is okay if a Chrome browser is hooked into beef then run this module then run this module and send me the results nested forward is a little bit more complicated because this is where you can start building some logic so in this instance you can't really read it but the first module is get my internal IP address and if that succeeds because the status was one take the output of this module and run it through internal network fingerprinting after we kind of mash the output from the first module to kind of

build up a subnet range so this is kind of cool but the problem is when these run they run immediately so the browser gets hooked these modules run what I have done is I've implemented a third mode called dormant forward and what happens is you get like a set up phase so the browser gets hooked if it mates the target like the targeting method within the I re set up it basically goes okay what's my internal IP address what's my external IP what's my ISPs ASN like where am I so builds up a picture of where it is in the internet and then what happens is it kind of then goes to sleep and it'll

monitor network changes from jumping ahead um one of the things that I did do to figure out where the computer was actually was in like I implemented a different service on beef that interfaces with team Kim Roos have you guys ever seen they've got like a bunch of lookup services and they implement you can do like reverse lookups and ASM lookups with Tim Camry and they also really sit over DNS which is super fast so we've got a web service that you can kind of ping an IP address against Tim Kim Roo they'll give you the ASN and from there we can pull out the ISP information so once we have the internal and external details of the browser we

kick off some timers and some event handling logic so basically go okay every what ever every five seconds am I on a different network or has the window don't navigate a dog online status changed on my online on my offline and once I've detected that we have changed Network we go are we back online or are we offline are we back on our home network or are we on a new network and as soon as we're on a new network we basically we run the internal WebRTC IP lookup we get the internal network IP information and then we feed that into arbitrary modules execute those modules and then cache the results locally and then if we ever get

back on the home network we send it out to beef so what that means is if you're hooked into beef and you cross into a different network you won't talk to beef but you'll run modules store the results locally until you potentially return to the internet which means that your corporate controls want to get up now we have some configuration settings like how stealthy we want it to be you know what happens when we return home and these are these are just sort of just different levels of how chatty we want to be on the network and also some logic to determine when we get back to our home state what do we do do we just

continue to run or do we kind of dump all our results back to the beef server and then kind of stopped running the config looks almost exactly the same so in this instance the chain mode is set to dormant forward and every single time we get on to a new Network we run a ping sweep against the subnet that we're associated with or at least a subset of IP addresses so walking through the scenario we have a mobile phone there on the Internet they get hooked into beef somehow oops but you're hooked into beef somehow and the payload gets onto that computer onto the phone and that stops right nothing else really happens at that point now if at some point later on

the phone ends up on a different network it'll try to discover internal land resources and probe for those and see if it can send requests to those and at no point will it talk back out over the internet so it's not going to be making the beef server like you know your ir guys aren't gonna see that someone's talking to a beef server so they're not going to detect that anything's going on and nine times out of ten the beef payload itself will never be detected by antivirus anyway so good [ __ ] luck anyway if we return back to the home network we basically dump our data back to beef and so this is a this is me

starting beef it's super pixel Ian and cruddy but that should be okay okay and you can sort of basically say that as soon as beef has started it's already printed out that we've loaded a rule set that's going to run two different modules we're going to run the pink sweet module and then we're going to run a separate module so the the JSON configuration file here has the port scanner module and the pink stripe module that's just a persister json configuration so obviously you can run any modules you want but for this example this is what it looks like obviously log into the beef server and for those that haven't seen beef this is what beef looks like boring-looking

website thing and to demonstrate and kind of show you verbose logging I'm plugging in my phone into USB debugging so I don't have to film a phone consistently because you can't read anything off the phone um for those doing kind of mobile JavaScript stuff the remote devices functionality inside of Chrome is awesome because you can plug it in you can turn on USB debugging and you can play around with the console on your computer as opposed to your phone so you can see here I plugged in my phone I've enabled USB debugging and so now I can control my phone from my computer and so I'll use my computer to open a new tab on my

phone to hook the phone into the beef server so I do that just by visiting a demo page just for the for the demonstration and you can see the the phone is hooked into beef that's what the default beef page and then immediately the the setup phase has begun and it goes okay what's my internal LAN IP address what's my external IP what's my ISP so I've determined that it's with t-mobile it's likely on an LTE network and the browser has showed up in beef which is as expected now if the phone drops off the network so if we go into airplane mode you'll immediately see that we're in a different state so we're now offline

we're not talking to any networks now if I join a wireless LAN network and I'm gonna also show that the browser will obviously drop out of beef so we're no longer talking between the phone and the beef server it takes a little bit for that to refresh

so now if the phone jumps from LTE to a wireless LAN you'll immediately see like the console spit out a bunch of stuff because it'll determine that it's on a different network and it'll immediately start to run the module and the first module is the ping sweep and the ping sweep immediately identifies that there's a server listening there's a server available on one and two one six zero two one one nine and because it's found an active server it'll also then kick off the port scanner so it'll try and determine if there are any ports listening on that server as well and at no time is there talking to beef so this is just on my wireless LAN so the port

scanning capability kind of you can see here it's failing on FTP requests so it's using XML HTTP request objects to send FTP protocol requests to arbitrary ports and then tracking how long it takes to fail or not fail obviously we jump back offline by turning off the Wi-Fi and jump back onto LTE and what you'll see is the phone will basically go okay I've checked why am I appear to be back home I'm gonna push all my data back to beef and you'll kind of see a whole bunch of these data requests start to go to beef and then if you jump back in the beef command and control server you'll see in the logs that it ran a

bunch of modules and we now have the results from that and they show up in the network tab so we get like a little pretty network diagram the phone has discovered some other computer and for that particular host it's listening on two ports twenty-two and eight eight eight eight so when we ran the port scan module I think we were testing for a 2284 four three eight eight eight and nine thousand so we found two of whatever six ports that we were scanning now let's say we want to queue up a different module so that if the phone gets back on to that network at some point it's gonna run commands against that webserver we can obviously pull up

another config file to do like a COS request against one or two one six eight zero to one one nine against port eight eight eight eight and then using the api of beef which we have an api which is interesting we can obviously lift existing rules we can add new rules to the system so here i'm doing a post request send this particular JSON rule file into the system and then we can trigger it so we've loaded a new rule which is ID number two and then we trigger a rule number two and that'll trigger and then you'll immediately see in the browser it goes through that setup phase again so the browser will go I'm you know this is

what my IP address currently is this is the ISP that I'm on so we go into airplane mode go back onto the wireless LAN just to see if we can send a request to this arbitrary port on a server on a different network and if the phone when the phone rejoins back to the wireless LAN network you'll see at the top it actually you can see the network request to this server so you can see up here it sent a request and because this status is 200 for those who have been paying along paying attention it may indicate that perhaps someone's misconfigured cause on our web application and you know because it's on an internal network

maybe they don't care so anyway obviously you know we returned back to LTE and then we dumped that data back out to the beef server and then we jump back into the beef server and then you'll see in the log that obviously it ransom as soon as i refresh the log you'll see that it ran some more modules and you can see the results of the the COS request

and what's interesting here is it's given back an open cause policy on a website that seems to be some sort of form to send a ping message and obviously you know if you do penetration testing and you see an application that takes in an IP address into like a form field you're probably thinking well is it just going to take an IP address or are you gonna try and put something else in there as well so let's say at this point we want to try and send a different request to that web server if the phone ever gets back onto that network so we basically load up a second a third module that will try and send a

get request against that end point but this time it's gonna prepend an IP address with a semicolon arbitrary system command just to demonstrate whether or not we can get further information or data out of there we have to do the little dance load the module we then trigger the module and then you know we got to get the phone back on that first Network

javascript is pretty cool and pretty terrible once again you'll see like the browser will send another request to that port so you can see the ping command you'll notice that it takes a little bit to resolve because maybe it takes a little bit to ping and then once again we kind of return the phone obviously the phone is still offline so we're not communicate communicate in with the beef server it's kind of invisible as far as the Internet is concerned and then obviously if we kind of jump back to the home network that data will be dumped back up to the beef server it'll push the results back up to beef and we'll see if we jump back into

that command module we'll see that it's been run a second time and we've got a second like more result system

[Music] and you can see this what appears to be a ping response and at the end of it a username yeah Java scripts pretty cool um so you talk to IR guides about this sort of stuff and WebRTC and other JavaScript technologies and it gets pretty hairy with regards to what you can do to defend against this I think really this this really underpins things like zero trust network I know like five to ten years ago we were able to kind of pretend that an internal land was relatively safe from bad actors either from you know staff or bad things happening on their computers I think that day is over and one of the things I

really like about looking at these things from JavaScript perspective is in general no IVs is doing JavaScript at all I know the default beef hook payload it hardly ever gets detected by anything on virustotal occasionally semantics will flare up but then we change like the copyright header to a different year and then it wouldn't detect it again and also it's also kind of cool because I know the Australian signals Directorate they kind of push out their top 35 control recommendations so this is you know these guys do assessments for a lot of government organizations and they're always like if you do the top four of these 35 so you reduce the likelihood of being compromised by like 80 to 90 percent and

in there they always put application whitelisting and you know your web browser will always be application whitelisted like they're never gonna not application whitelist your web browser so good luck spotting it that way I think I think it really does highlight you know kind of the small vulnerabilities that people kind of don't give a [ __ ] about any more like cross-site scripting in cross-site request forgery are super important to like not lose sight of how important these vulnerabilities are I know Ryan from slack he also he's got a Chrome extension that basically kills off his old tabs have been idle you know maybe that's maybe we should be looking at for desktop Chrome the ability to basically

put background JavaScript asleep when you're not looking at those tabs I mean maybe that's something that we actually need to put into defensive strategies for browsers um obviously there's a whole bunch of stuff that I need to do to tidy up the a s lookup service is super handy but potentially it's a leak for an ir person to see because we are sending a request back to the beef server but it's easy enough to spin out on to a different server I was looking I was using some third parties to do is P lookups based on your IP address but it kept on they kept on blocking me at some point so it's not not super reliable and

I'm sure there's more stuff that I can't remember anyway I just wanted to say thank you everyone I hope you guys had a great 'besides stay around for the happy hour I'm happy to feel questions and otherwise I'll be I'll be hanging out and having a beer so uh thank you [Applause] does anyone have any questions yes so um the home is based on I do like partial matching on your internet IP and then I do like a fuzzy match on your ISP ASN it's obviously not super accurate but for some circumstances it'll be okay um fuzzy matching in JavaScript is also pretty interesting I mean I didn't not like I've done a lot of testing in that

but it seemed to work quite well between my t-mobile LTE and my Comcast wireless LAN

yeah yes so so the question was okay so what happens if I guess if the browser was hooked when I was actually on a control network yeah so I think um I mean this is certainly like us like it's it's as fairly staged approach so you've seen obviously the phone has changed stayed a couple of times and you're running kind of some awareness around where it is if you hook someone and you immediately saw that their requests like that first hook was coming out from a corporate network and maybe this is not what you need to do because if at the point that you're seeing beef communicating out of like a corporate network you've already got a fairly high

foothold so you probably wouldn't use things like this uh maybe that's a great enhancement as in like I only want to activate when I know that I seem to be in someone's personal Network but as soon as I drop in somewhere different like actually different as in like a corporate ASN or like an ASM without a name maybe I should start doing things um the the rules engine is pretty cool because it's quite dynamic as far as how you make things hang together and mostly it's just terribly hacked together JavaScript so you could definitely put that logic in there phew that was interesting oh and it's really not a bad idea so shoot me a Twitter message and

I'll put on a list somewhere um yes yeah so the quest

yep so the question was how accurate is tracing the timeouts for XML HTTP requests to determine if a port is open or closed um so we've got a couple of modules that do this functionality right now and beef over time some of them have proven to be more effective than others and some of the Dov's we still talk about it quite a bit because it's not it's like it's reliable but then occasionally it's not that reliable the the time out failing though whether or not they would ever implement in the browser versus if you'd implement it out on the server I mean whether or not you're catering for this attack you know I mean whether or not this would fall

into the risk assessment where you actually be wanting to try and hide from this sort of thing I mean it sounds like it would be a good idea but I just don't see them doing it and also because you might have like web services which are on random ports anyway and obviously chrome is not going to start tampering with how long that they take to respond like I don't I don't see them doing that or Firefox or anyone but yeah that bit is a hit and miss um for the scanning that I was doing I was I was getting on my so from my LTE network to my wireless LAN and then I was hitting a virtual machine and nine times

out of ten er would detect that particular server and the particular ports on that server but then occasionally just wouldn't and I don't know if that's just my virtual machine just been terrible or not yeah it's not a sigh it's not not a great science people do work on er there's been quite a bit of research as far as like I guess doing those asynchronous requests and kind of making assumptions around the timing of the data because the problem is the same-origin policy doesn't doesn't cater for the timing of how long things take to can't likely fail because they want to give you that when something something fails and they don't want to give you the HTTP status or the

result but they can't they're not masking their timing information I mean maybe they will if they see a legitimate threat I don't know did anyone else have any other questions awesome enjoy the happy hour folks thank you very much thanks Christian always always entertaining on behalf of besides SF San Francisco and Fitbit like to give you a Fitbit and again there is a happy hour down at DNA also there's food back there it's going to go to waste so feel free to grab as many as you would like all right any other treats back there and then for those who asked questions we have some of these electronic badges if you're interested so thank you guys

be safe [Music]