Foro de elhacker.net

He estado leyendo un post de un blog muy interesante y se trata de que utilizando el objeto webrtc de HTML5 es posible obtener las ips locales de todas tus interfaces de red:

http://hacking.ventures/local-ip-discovery-with-html5-webrtc-security-and-privacy-risk/

Acá una prueba de concepto: http://net.ipcalf.com/ al ingresar te muestra todas tus ips locales, a mi me mostró la que me asignó mi router, la del virtualbox y de una vpn local.

Acá el código fuente que han utilizado (en javascript):

// NOTE: window.RTCPeerConnection is "not a constructor" in FF22/23
var RTCPeerConnection = /*window.RTCPeerConnection ||*/ window.webkitRTCPeerConnection || window.mozRTCPeerConnection;
 
if (RTCPeerConnection) (function () {
    var rtc = new RTCPeerConnection({iceServers:[]});
    if (1 || window.mozRTCPeerConnection) {      // FF [and now Chrome!] needs a channel/stream to proceed
        rtc.createDataChannel('', {reliable:false});
    };
 
    rtc.onicecandidate = function (evt) {
        // convert the candidate to SDP so we can run it through our general parser
        // see https://twitter.com/lancestout/status/525796175425720320 for details
        if (evt.candidate) grepSDP("a="+evt.candidate.candidate);
    };
    rtc.createOffer(function (offerDesc) {
        grepSDP(offerDesc.sdp);
        rtc.setLocalDescription(offerDesc);
    }, function (e) { console.warn("offer failed", e); });
 
 
    var addrs = Object.create(null);
    addrs["0.0.0.0"] = false;
    function updateDisplay(newAddr) {
        if (newAddr in addrs) return;
        else addrs[newAddr] = true;
        var displayAddrs = Object.keys(addrs).filter(function (k) { return addrs[k]; });
        document.getElementById('list').textContent = displayAddrs.join(" or perhaps ") || "n/a";
    }
 
    function grepSDP(sdp) {
        var hosts = [];
        sdp.split('\r\n').forEach(function (line) { // c.f. http://tools.ietf.org/html/rfc4566#page-39
            if (~line.indexOf("a=candidate")) {     // http://tools.ietf.org/html/rfc4566#section-5.13
                var parts = line.split(' '),        // http://tools.ietf.org/html/rfc5245#section-15.1
                    addr = parts[4],
                    type = parts[7];
                if (type === 'host') updateDisplay(addr);
            } else if (~line.indexOf("c=")) {       // http://tools.ietf.org/html/rfc4566#section-5.7
                var parts = line.split(' '),
                    addr = parts[2];
                updateDisplay(addr);
            }
        });
    }
})(); else {
    document.getElementById('list').innerHTML = "<code>ifconfig | grep inet | grep -v inet6 | cut -d\" \" -f2 | tail -n1</code>";
    document.getElementById('list').nextSibling.textContent = "In Chrome and Firefox your IP should display automatically, by the power of WebRTCskull.";
}

---

Local IP discovery with HTML5 WebRTC: Security and privacy risk?

With the progression of HTML5 WebRTC, browsers are getting ever closer to making pluginless video conferencing a reality. One feature of WebRTC is the ability to discover the local IP addresses of the browsing machine. Does that put us at an increased risk?

Recently I stumbled across Nathan Vander Wilt’s net.ipcalf.com. When opened from a relatively new version of Chrome or Firefox, your computer’s local IP addresses should present itself.

I’ve coded up another example, which attempts to use WebRTC to find your local IPs, and then probe for other live hosts on your network(s).

Others will likely cover the usefulness of these APIs, so I will — for the sake of argument — comment on the tinfoilhat-y perspective. Bear with me.

Privacy concerns

I know for a fact that some people use multiple browsers on the same PC, in order to separate identities or browsing profiles. These people might browse Reddit’s cute-cat-picture-subreddits with Firefox and the programming subreddits with Chrome. From the web server’s perspective, both browsers will likely have the same public IP address, but their headers, tracking cookies and whatnot will clearly differ.

local-network

With the WebRTC local IP discovery technique, those interested in tracking you, be that ad agencies or some spy organization, will be able to do make connections between browsers based on a combination of public and local IP. If they for whatever reason can tie an identity to one browser, they will probably assume that the same person is hiding behind the second one.

There’s also a risk that the local IP info can aid in identification between public IPs. Let’s say that you use some VPN service, or Tor, whenever you surf cute cat pictures, but you use the same browser. EFF’s Panopticlick tells the story of how each browser is pretty much unique, based on HTTP header fingerprinting and so forth. Add local IP addresses, or even subnets to circumvent DHCP lease times, and your browser / PC is even more unique. And by unique, I mean trackable.

Security concerns

Consider some evil page which, based on the local IP returned from the WebRTC technique, starts scanning devices on your LAN. Let’s say your IP is 10.0.8.13, then the evil javascript could start out by guessing that your router is at 10.0.8.1. Then let’s move on to assume that your router, which probably hasn’t had it’s firmware upgraded for a while, has some half-assed web interface, which is accessible from your LAN.

The chance of this router being remote exploitable — that is from your public IP — isn’t huge. It has happened, but it doesn’t happen that often. The chance of there still being some obscure XSS flaw hidden in there somewhere, however, is much greater. So what if this evil page, which has now identified that your router is on 10.0.8.1, and figured out which software it runs, then goes on to exploit one of the XSS vulnerabilities — and adds some evil person as remote admin?

Now this doesn’t have to be your router. It would be fairly trivial for a javascript to discover which hosts are up on your local network — I’ve had great luck doing timed HTTPS-request against non-HTTPS ports on IPs to do just that. With this information, the evil page can go on to test the discovered hosts for a plethora of vulnerabilities, based on simple fingerprinting. That could do all kinds of damage.

I just put this to the test on an office network I am part of, which happens to house an old Canon printer. I’m pretty sure it predates the pyramids — but at the very least the dawn of security bugs, because it will do pretty much exactly what a rogue javascript tells it to do.

So, yeah, your printer is now part of a botnet, and is routinely DDoS-ing powerplants in Iran. Congratulations.

But what does it all mean?

So there are privacy concerns, and the feature can at least make local exploitation easier for an attacker.

On the other hand, there are bigger privacy concerns around today (yes I’m talking to you, NSA), and from a security perspective not yielding the ip is arguably security through obscurity.

So I’ll let you lot make up your own minds. My tinfoil hat stays on.

@WHK, interesante post, pero hagamos algo mas profundo si es posible listar las infterfaces observando las lineas de codigo:


por que no crear un powersell para escanear red Local y/o simplemente explotar una Windows (cliente) observando el HTTML5 creaando un C&C hacia internet, mmm posteamos algunos PoC....

-berz3k.

https://github.com/diracdeltas/sniffly

 :P

Nopues, eso hace cuando falla xD te deja ese mensaje para que lo hagas manual

El que te resuelve las ip es la función en javascript :



Muy ingenioso, ya lo había probado en otras ocasiones pero jamas me había resultado, de hecho lo había intentado usando las imágenes del apache que vienen por defecto también pero jamas me había funcionado :-/

Lo último que he estado viendo es tratar de explotar una ejecucion de un js fuera del origen del sitio desde donde se comenzó a ejecutar y es por un bug en firefox pero aun no lo logro explotar xD me restringe todo, ni si quiera un alert puedo ejecutar y es porque queda como en una especie de sanbox adicional.

"Hello! This is a demo of Sniffly, a practical timing attack to sniff browser history using HSTS in Chrome and Firefox"

@EFEX@WHK aun probando en browsers inferiores no me rula bien este bug...

-berz3k.

En firefox si me anda, ese bug ya tiene su CVE id asignado asi que probablemente en algunas versiones de algunos navegadores ya lo esten parchando.

Si como dijo WHK, ahora otro mas https://mathiasbynens.github.io/rel-noopener/