Monday, August 24, 2015

WebRTC and Host Enumeration

Hey there everyone.  I know it has been a long time since I last updated this, but there has been a lot going on.  Between personal stuff, work craziness, the Windows 10 launch, and some other things, I have not had time to make a post.  Things are starting to die down a bit (hopefully), so my goal is to post here more often.

I was browsing /r/netsec yesterday when I stumbled across an interesting post: sonar - A Framework for Scanning and Exploiting Using Internal Hosts (link to source article).  This piqued my interest because it is a compelling way for a pen-tester (or malicious actor) to perform host enumeration inside of a network without having a presence inside of the target network.  The technique relies on the victim's browser being WebRTC enabled, so let's take a moment to talk about what WebRTC is and why we should care.  Then, we will talk about what makes Sonar interesting.  Finally, we will talk about some mitigations.

What is WebRTC?

The RTC in WebRTC stands for real-time communication.  The intent of the standard is provide a way for users to collaborate (voice, video, file sharing) without the need for anything but a browser.  No plugins are required since everything for WebRTC is built into the browser.  From a user's perspective, this probably sounds like a great thing, because they can communicate with others without having to install and configure additional software.  From a security perspective, it is intriguing on its face: no more need for Adobe Flash.  Flash has been a security nightmare, especially lately.  See here, here, and here for a few examples.  Anything that can remove one more need for Flash is a good thing.  But is it a good thing when we take a closer look?

Typically, applications designed to enhance collaboration are not designed with security in mind.  WebRTC follows the trend.  The main problem with WebRTC is that any webpage can make a request for various pieces of information, and by default these requests are granted which could compromise information about your computer and your network with very little effort required by the malicious party.  There is no popup that asks if you want to allow a website to use WebRTC, and most browsers do not have an easy to find preference (a checkbox in the options dialogs) to turn it off.

WebRTC is built into Firefox (22+), Chrome (23+), and Opera (18+) on the desktop side.  It is also supported on various Android browsers (Chrome 29+ by default, Firefox 24+, Opera 12+).  Internet Explorer and Safari do not have support built in as of this writing.  Microsoft Edge (part of Windows 10) has at least some support for WebRTC.

Why should I care about WebRTC?

It is important to understand what kinds of things are possible with WebRTC, so you can decide for yourself if the security risk associated with WebRTC makes it worth keeping it enabled.

WebRTC can help a malicious actor determine Your Local / LAN IP

In order to make connections between browsers (on a local network for example), the protocol needs to be able to figure out where your computer is so it can talk to it.  There are other webpages out there like this, but here is one example of a page that can grab your local IP.  By visiting the page, the site owner can log your external IP, so he will have that pair.  The idea is that if you can tie a local IP to a public IP, you can uniquely identify a user with a bit more information.  The concern is that if someone were using a VPN, a malicious person or unscrupulous web-advertising firm could lay down a cookie and track you.  Let's take a look at how the browser sees the request:

This capture is from Firefox 40 running on Windows.  This information is available by typing about:webrtc in your address bar.  Here is the interesting bit of code that figures out your IP (you can look at this by viewing the page source on the
    function grepSDP(sdp) {
        var hosts = [];
        sdp.split('\r\n').forEach(function (line) { // c.f.
            if (~line.indexOf("a=candidate")) {     //
                var parts = line.split(' '),        //
                    addr = parts[4],
                    type = parts[7];
                if (type === 'host') updateDisplay(addr);
            } else if (~line.indexOf("c=")) {       //
                var parts = line.split(' '),
                    addr = parts[2];
Essentially, the script reads the "candidate" information that is normally used for connection diagnostics which has your IP contained within it.

I am not worried as much about someone malicious figuring out my local IP and tracking me with it.  Relying on my private IP scheme to make me a harder target is security through obscurity which I am not a big fan of.  The concern I have is what the malicious person can extrapolate from the local IP.

Let's say that my local IP is  192.168.1.x is used on many consumer-grade routers as the default LAN subnet.  Many users do not change this because they have no reason to.  They plug everything in, and it just works.  If it ain't broke, don't fix it right?

This brings us back to sonar.  Sonar is a framework for discovering and exploiting common networking devices using Javascript, WebRTC, and in their example, CSRF (we will get back to CSRF in a minute).  The example that the introductory blog post uses is to change your router's DNS server to bend your traffic towards an attacker controlled server.  First, it looks to see what hosts are up by finding your internal IP (see above) and scanning the 254 hosts around it (it is assuming you are in a /24 which is common).  It guesses the model of your internal router by trying to access known elements of the router's administration webpages (like certain images).  Then, if it can fingerprint your router (assuming a fingerprint has been written for it), it will try to exploit it.  The demo exploit uses CSRF to change the DNS server on the router.  Cross Site Request Forgery (CSRF) is when an attacker makes an unauthorized request to another website (like the administration page for your router) impersonating as you.  CSRF is not Cross Site Scripting (XSS).  XSS exploits your trust in a site.  With XSS, a malicious script (typically on an external server) is called from a site that you visit (and presumably trust).  CSRF is different in that it exploits the trust that a site has in your browser.  When you authenticate to a site, the site will give your browser a cookie so that it will remember you and you can avoid re-authenticating for every request.  If a site does not protect against CSRF, an attacker can make a request from your browser by hosting code on or injecting code into (typically Javascript) a webpage that your browser renders.  Because the target site remembers you (via the cookie that is passed when the browser renders the malicious script), it will execute the command.  Let's take an example.

Let's say your router is at and that you can change the DNS server using a page on the router, like dns.php.  When you type in the DNS server you want to use (like Google's, a request like this could be generated:

The page checks your cookie, and because it is valid it makes the change.  The timeouts on these cookies are notoriously long, so even if you made the change to your router an hour ago, the cookie might still be valid.  So an attacker could set up a page that has the following in it:
<img src="">
Because the router trusts your browser from the cookie, it will  make this change. could redirect your bank website to one that looks like your bank but had an added feature of supplying the bad guy with your credentials if you type them in.

The vulnerability that CSRF exploits is akin to using a key (your credentials) to open the lock on your house (the sensitive website) and then leaving the key in the lock so that others can piggyback into your house.

This framework could apply to any vulnerable device, not just routers.  Things like VoIP phones, your Raspberry Pi, or your printer could be vulnerable.  Since many embedded devices do not have robust protections against XSS or CSRF, this could be a real concern.

So how can we mitigate something like this?

There are a couple of issues that need mitigating here: the WebRTC that allows for the host enumeration and the CSRF vulnerability in the device.  Let's look at each of them.

Mitigating WebRTC

One thing I always try to stick to when securing a system is: If you are not using something, turn it off (disable and uninstall it if possible).  The service is not providing you anything because you are not using it, and it might present an attack vector for a malicious person.  The exact method for turning off WebRTC depends on your browser:
  • Firefox: Set media.peerconnection.enabled to False in about:config.
  • Chrome: There is apparently no way to turn off WebRTC in the desktop version of Chrome.  Plugins like ScriptSafe might help mitigate WebRTC.  It appeared to prevent discovery of my local IP in Chrome, but I have not done investigation into other information leaked by WebRTC.
  • Opera: The ublock extension will block the leaking of your internal IP.
What if you need WebRTC?  There are extensions out there (like uBlock mentioned above) that will prevent this kind of information leakage.  However, that is not a cure all, and you have to decide whether or not you will accept the risk of running WebRTC if the fact that your IP can be discovered bothers you.  I think there are other steps you can take outside of disabling WebRTC to help mitigate this issue.

Mitigating CSRF Concerns

The first thing to do is to check to see if there are any firmware updates for any devices that could be vulnerable.  These are available from the manufacturer's website.

If you have devices vulnerable to CSRF, you can attempt to place web application firewalls (WAFs) in front of those devices to help mitigate things.  However, WAFs can only protect against what they know, which is defined by a rule set or behavior analysis.  If the attacker can tweak their code to do things in a slightly different way, they could bypass the WAF.

Another thing you can do is to administer your sensitive devices from a browser in its private browsing mode.  The name of this mode varies from browser to browser (Private Browsing in Firefox and Safari, Incognito in Chrome, InPrivate browsing in Internet Explorer).  The idea there is that any cookies that are created will be removed once you close the private browsing window.  Just make sure that you only visit the sensitive site (like your router's administration page) in your private browsing window and that you close it when you are done.  If there are no cookies or other authentication tokens for the CSRF technique to take advantage of, the attack described above will not work.

Playing a Trick on WebRTC Host Enumeration Tools (like sonar)

One thing I noticed when looking at sonar is that the fingerprints do not try to verify that the device they found is legit.  For instance, I could put a webserver out there at an IP that is commonly used by a router (like and put blank files where the fingerprint expects them.  If I have a sniffer running on that box, I could capture the exploit attempt and use that as a basis for mitigation and to gather techniques that attackers are using.  It is like a very specific honeypot.


WebRTC is an interesting technology that could be a good way of putting plugins like Flash and the security issues with them out to pasture, but I think it needs to bake a bit longer.  I hope that we can get to a point where security is part of the software or standard design process so that we are not scrambling after the fact to mitigate vulnerabilities.

What do you think?  I would like to hear your comments in the section below.  Thanks for reading!

No comments:

Post a Comment