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

In Part 1, we introduced you to BeEF's WebRTC extension as a solution for avoiding tracking of post-exploitation communication back to our BeEF server. In this post, we'll talk more about how this can be used during penetration testing. This will include further information about the extension and usage details for the console and RESTful API.

One of the pre-requisites of WebRTC is the ability for peers to share Session Description Protocol (SDP) signaling messages between each other. This nominates what TCP/UDP ports are available to receive data, video and audio channels. The WebRTC spec does NOT dictate how these signaling messages are passed between peers. So, we've implemented a signaling channel within BeEF - hence, you have to hook the browsers at least once.

Once signaling has been established, and the peers (1 to 1) are established, there are new JavaScript methods available to send messages to each other. If the peers are on the same subnet, they will in fact be sending DTLS (Datagram TLS) messages between each other directly over either TCP or UDP. If they're separated by Firewalls/NAT devices, there are methods available to WebRTC to get around this too.

A quick example. If browser 1 and 2 are peered, the following JavaScript will send a data channel message from browser 1 to browser 2:

beefrtcs[2].sendPeerMsg('Hi!');

Within beef.webrtc are event handlers for these messages. The following logic is currently in place:

• If a peer receives a message of '!gostealth' - It will STOP talking to BeEF, and instead start polling back to its peer with a heartbeat. At this point, the browser will cease sending HTTP GET requests to the BeEF server, although is still peer-connected to another hooked-browser.
• If a peer receives a message of '!endstealth' - It will come out of stealth, and start talking to BeEF again, but will still maintain the peer channel.
• If a peer receives a message of '%<JavaScript>' - It will execute the JavaScript - sending any return values back to its peer (Not to BeEF directly), once this message is received it will then be sent back to BeEF.
• If a peer is STEALTHED and receives any other message, it will simply replay the text back to the peer that stealthed made it go into stealth. Otherwise, it will send the message back to BeEF.

If you enable the WebRTC extension in BeEF, this functionality is available through the interactive console, and the RESTful API. 

Console usage:

BeEF> rtcgo 1 2

Will connect online browser 1 to 2. After connection, you will see event messages in the log (particularly if you started beef with -v)

BeEF> rtcgo 1 2 true

As above, but will print verbose messages in the clients' consoles

BeEF> rtcstatus 1

Will check the RTC statuses of the browser and its peers

BeEF> rtcmsg 1 2 "Hi browser 2 .. from browser 1"

Will tell browser 1 to send a datachannel message to browser 2

This will simply send a text message from 1 to 2, when 2 receives the message, it will send it back to BeEF and display in the log. 

There are a few custom datachannel message commands that are implemented within the client-side JS

BeEF> rtcmsg 1 2 !gostealth

This will tell browser 1 to command browser 2 to go into a stealth mode, which will make it stop talking to beef but remain connected to each other via WebRTC. Browser 2 will occasionally send a heartbeat back to browser 1 - which will be displayed in the beef log.

BeEF> rtcmsg 1 2 "%return window.prompt(\"test\");"

This will tell browser 1 to command browser 2 to execute the JavaScript, and return the value back to browser 1, who will then send it back to the beef log. This is especially useful in stealth mode, as you can still control the browser even though it's not talking to beef.

BeEF> rtcmsg 1 2 !endstealth

Will make browser 1 command browser 2 to come out of stealth, and will start talking to beef again.

While a browser is stealthed, it can't be seen from beef, and can't be used as the source of RTC messages (because these are passed to the browser via the hook.js polling process).

The RESTful API calls are similar and examples exist within extensions/webrtc/rest/webrtc.rb file. Functions include:

GET /api/webrtc/status/:id

POST /api/webrtc/go {"from":1,"to":2}

POST /api/webrtc/msg {"from":1,"to":2,"message":"hiya!"}

You can see the presentation http://www.slideshare.net/xntrik/kiwicon-2014-hookedbrowser-meshnetworks-with-webrtc:

Kiwicon 2014 - Hooked-browser Mesh-Networks with WebRTC from Christian Frichot

And the video demo is available https://www.youtube.com/watch?v=pLC3hbUvhoE:

I'll be capturing some of this information within the Wiki soon as well - https://github.com/beefproject/beef/wiki/WebRTC-Extension

Thanks for all your help and inspiration browser-peeps!

-@xntrik