Jump to content




IMPORTANT
We are happy to let you know that SIRUMIUM (ex crimeclub) is back online.
If you are old vendor here you will have one month bonus on your advertise and free banner in rotation.

ADVERTISE
Sign in to follow this  
Dark

Using WebRTC ICE Servers for Port Scanning in Chrome

Recommended Posts

Dark    0

Full source: https://medium.com/tenable-techblog/using-webrtc-ice-servers-for-port-scanning-in-chrome-ce17b19dd474

Using the browser to scan a LAN isn’t a new idea. There are many implementations that use XHR requests, websockets, or plain HTML to discover and fingerprint LAN devices. But in this blog, I’ll introduce a new scanning technique using WebRTC ICE servers. This technique is fast and, unlike the other methods, bypasses the blocked ports list. Unfortunately, it only works when the victim is using Chrome.

You can skip my explanation and go straight to the code or the demo page. Otherwise, let’s start with a proof of concept video. Here I am scanning my 192.168.88.0/24 network.

https://www.youtube.com/watch?v=M6lBVhkzUmM&feature=emb_logo

 

What’s an ICE Server?

As I said, the scanning technique uses WebRTC ICE servers. An ICE server is a STUN or TURN server considered by a WebRTC RTCPeerConnection for self discovery, NAT traversal, and/or relay. A list of servers can be passed into the RTCPeerConnection’s constructor. Here’s an example constructor being provided one of Google’s public STUN servers:

Quote

var rtc = new RTCPeerConnection({ iceServers:[{“urls”:”stun:stun.l.google.com:19302”}] });

When the above RTCPeerConnection enters the ICE gathering state it will attempt to connect to the provided server.

Protocols Matter

ICE servers can be bound to either UDP or TCP ports. However, unless instructed otherwise, Chrome appears to only attempt communication over UDP. Below is a Wireshark screenshot of the packets Chrome sends to a non-existent TURN server. Everything is UDP.

 

You can force Chrome to reach out over TCP if you know something about the ICE server URLs. The URLs passed to the RTCPeerConnection’s constructor must conform to RFC 7064 (STUN) or RFC 7065 (TURN). The TURN URI scheme follows:

Most important for scanning purposes is the optional “?transport=” field. Chrome can be forced to use ICE over TCP by using a TURN URI that ends with “?transport=tcp”.

We now have a way to initiate a TCP connection with any IP and port we choose. However, since almost all the hosts we’ll scan won’t be TURN servers, how can we determine if a host is alive or not?

Determining If a Host Is Alive

The following JSFiddle generates 256 TURN URI in order to find an active address in the range of 192.168.[0–255].1

https://jsfiddle.net/49n5oLj7/

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×