Tuesday, January 6, 2015

Hooked-Browser Meshed-Networks with WebRTC (Kiwicon 2014) - Part 1

Hi All, @xntrik here from sunny Australia. I hope you’ve all had a good New Year's and are ready to kick browser hacking into high gear for 2015. I had a thought that inspired me, and I wanted to share it here.

What if, to avoid tracking our post-exploitation communication back to our BeEF server, we were able to hook a bunch of browsers within an organisation, and make them talk to each other, instead of talking to our BeEF server? Perhaps we could keep one as the data channel (controlling peer)?

The answer is WebRTC. I recently had an amazing opportunity to present this at Kiwicon 2014, and I was keen to get the code into BeEF. This blog post provides a brief summary of WebRTC and how it works. Since there's quite a bit of ground to cover, this will be the first of a two part series.


Retaining post-exploitation communication with hooked-browsers is one of the more interesting issues with BeEF.

By default, BeEF uses XMLHttpRequest objects to poll to your BeEF server every 5 seconds. The logic is in the updater.js file of the core BeEF JavaScript client. It executes a setTimeout() function call that executes beef.updater.get_commands(), requesting the hook.js file from the BeEF server.

BeEF has options to use the WebSocket protocol as well, which shifts the comms from a polling mechanism to a more bi-directional streaming method of sending and receiving data between the server and browsers. Other more esoteric options are also being investigated, such as the use of DNS channels.

One of the issues with these methods is, all of your communication channels go back to the BeEF server. There are methods available to try and hide or obfuscate the presence of your BeEF server. But, most of these will still lead back to your BeEF Server eventually. For example, you could:

  • run multiple BeEF servers,
  • run servers with multiple interfaces, 
  • run multiple proxies pointing to your BeEF server, 
  • use reduced polling periods, 
  • use JavaScript obfuscation (which may help, but not much at the network layer), or  
  • use TLS encapsulation (similar issue, comms are still being sent to the BeEF server). 

If you're targeting a wide variety of targets, having things track back to your BeEF server may not matter so much.  If you're targeting a single organisation, though, this information is very useful to incident responders. If they detect one browser talking to your BeEF server, they'll very quickly spot the others. (This is still a big IF. As of today, no AV engines are detecting the stock-standard, un-obfuscated hook.js .. which is not altogether that surprising).

Virustotal report for stock hook.js
Thanks to those clever folks over at Google, Mozilla and Opera, we have an HTML5 technology to help us: WebRTC. WebRTC was initially intended to provide peer-to-peer communications for use-cases such as p2p video streaming. Due to bandwidth requirements, it's often better to provide video streaming between peers, instead of bouncing through servers. Another feature, apart from video streaming, is the provision of a data channel. This data channel works a little bit like WebSockets, in that it's event-driven and bi-directional. This is exactly the feature that we can use in BeEF to peer hooked browsers together.

The WebRTC Extension within BeEF is currently disabled by default. But, it's easy enough to enable. The extension provides the ability to have hooked browsers communicate with one another, using a single controlling peer as a data channel. The extension has been tested on Firefox 34.0.5 and Chrome 39.0.2171.95 (and Chrome on Android too!). In part two of this series, we’ll discuss some of the underlying JavaScript and how to use the extension.

1 comment:

  1. A good blog. Thanks for sharing the information. It is very useful for my future. keep sharing
    red ball 2 | duck life 2 | happy wheels | Red Ball | Red ball 3 | Flash Games| Tank trouble

    ReplyDelete