Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Get your local and public IP addresses in JavaScript (github.com/diafygi)
239 points by diafygi on Jan 26, 2015 | hide | past | favorite | 89 comments



I use this exact method for fraud detection. 99% of the time, carders " " will simply load up a proxy in Firefox/Chrome (usually a socks5) and fire away. They typically don't tunnel their whole connection through the proxy, just their browser.

If their request IP doesn't match up with this IP, there's a very high chance that the order will is fraudulent.


Interesting. We check to see if Javascript timezone matches GeoIP and/or billing/shipping address. Also Canvas fingerprinting works well. Lastly measuring latency is another good one since you can't cheat the speed light.


GeoIPing billing/shipping is always a good idea, but there are plenty of use cases (particularly depending on what industry you're in) where that will throw false red-flags. e.g. corporate card, registered to corporate office, etc. Unfortunately, it's also very trivial for a carder " " to find a SOCKS that geolocates back to the card's billing address.


As much as I'm happy that you're able to detect fraudulent transactions, I am really disappointed that there's not a Content Security Policy rule to prevent WebRTC :-(


Very heard. I'm quietly pushing for this.


edns-client-subnet (if present) can catch some frauds, too.


Sh you'll ruin my startup!!!!!!!

;)


That's clever, thanks. Implemented.

Another useful heuristic is to check if the client is coming in from a public Tor exit. YMMV depending on the nature of goods being sold, but in our case not a single legit purchase came in this way and nearly all fraudulent purchases were through Tor.


If you -- or anyone reading this -- needs any help on identifying fraudulent transactions, preventing fraudulent transactions, etc., I'm always available. It's the one bright spot of having the history that I unfortunately do, is that now that I'm on the "good side", I can help companies prevent this from happening. Since I wrote the book, I can help better than, say, MaxMind can (I'm biased).


Not that i'm a expert. But i think only amateurs would be so foolish. Nearly all open proxys out there forward the clients real IP in the HTTP X-FORWARDED-FOR header.


In a former life, I was an expert.

HTTP proxy is not a SOCKS4 is not a SOCKS5. :)

What they'll do is buy from a proxy shop " " - usually someone(s) with a botnet and a lot of clients on that botnet - so the IPs are residentials. vip72.com is a popular one. They do provide a client which will allow you to tunnel your entire system through the proxy, but it's not required for use (and some people are wary of it)


    > i think only amateurs would be so foolish
When I think of people using stolen credit cards to buy goods, I'm not envisaging a `leet hacking squad... That there are highly sophisticated cyber criminals in no way implies that all - or even most - are.


not really - theres a bunch of anonymous proxies. also socks proxy dont have any control over that anyway


This can be disabled in firefox's about:config page by setting media.peerconnection.enabled to false.

The problem with disabling all these features on a case by case basis is that you contribute to a richer fingerprint this way. Browsers will become increasingly more vulnerable to fingerprinting and there doesn't seem to be a way to stop it without going back to the dark ages of the web.


There really needs to be a writeup of all the Firefox defaults to change to make your browser actually secure. That's one I didn't know about. I think that your local IP is actually going to be very unique for some people, more so than just having this "feature" disabled.


The TOR project has a fork of Firefox with lots of defaults changed to prevent user fingerprinting. They also provide patches back to Mozilla. The closest to a list of defaults to change I found is

https://www.torproject.org/projects/torbrowser/design/#Imple...


One issue is that without using Tor Browser itself, any attempts to de-fingerprint your browser end up making an extremely unique fingerprint if anyone's looking hard enough.


> to make your browser actually secure

To make it secure, disable all plugins.

To make it more private, that's another story. Poor Firefox actually tries its best not to make you identifiable in some superficial ways - e.g. lying about user agent in "obscure" OSes. My FF reports 'Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/blah Firefox/blah', and I am not on Windows. I don't remember enabling anything like this in any way so I assume it is the default behaviour. This is with "nothing" as an option for DNT btw (neither yes nor no).

Ultimately this is moot as you can't get around your font & rendering fingerprints that can be extracted from a hidden canvas element, but hey. Still better than serving it up in a platter.

> your local IP is actually going to be very unique for some people, more so than just having this "feature" disabled.

How so? It'll fall ion pretty standard ranges. I only find any use/value in it when combined with the remote IP + the rest of your env. characteristics.

When you have to delve into about:config to disable it, 99.99% of people will have it enabled. This + your remote IP would pretty much identify you just fine.

${witty_double-edged_sword_quote}


The user agent string is just a convoluted mess because websites started displaying content based on that string so newer browsers had to fake it so they would still work with these websites. User agents don't mean much nowadays because of this.


> Ultimately this is moot as you can't get around your font & rendering fingerprints that can be extracted from a hidden canvas element, but hey. Still better than serving it up in a platter.

This has some work to be done still, but it's a start in regard to blocking hidden canvas elements: https://addons.mozilla.org/en-US/firefox/addon/canvasblocker


I am not sure FF hides the real OS in user agents. Check about:config for general.useragent.override and if its value exists, then at some point you or a plugin specified an override.


Huh, you're right. It's user-set. Go figure.


I think that your local IP is actually going to be very unique for some people

I'm willing to bet that almost everyone who has a single "home router"/NAT is going to be 192.168.1.2 or 192.168.1.3. There will be the exceptions on 10/8 or 173.16/12 but the majority of home networks will be 192.168/16.


I found this project recently and ended up using most of it: https://github.com/pyllyukko/user.js


That's been on my todo list for a long, long time...


If you'd like an easier way to toggle this setting. https://addons.mozilla.org/en-US/firefox/addon/happy-bonobo-...

I wish Chrome would provide this setting too.


You can use WebRTC Block on the chrome store


I just disable JS by default and whitelist the (very few, currently) sites that absolutely need it.

That probably means I share the same fingerprint as everyone else using the same browser with JS disabled.


User-Agent still changes, and since people enable it for various sites, you can try to load it from different domains and see what is blocked/loaded.


Yeah, but that Adobe Acrobat version is quite old, and that's an interesting Wacom tablet you got there...


That approach used to work but so many sites now are utterly reliant on jquery and other bulk.

The new trend is not only needed javascript but localstorage.

I cannot believe the sheer number of sites I have to use now that will not function without localstorage enabled.


> very few, currently

I've tried disabling JS and all sites were completely broken and resulted in a horrible experience. I guess though if you set your bar very low few sites really need it.


Easy enough to check - https://panopticlick.eff.org/


CSS media queries reveal your fonts and screen dimensions. Maybe someone could tie that in with lazily loaded images with unique IDs, thereby tracking you. It would be nice if people could disable media queries, as they're annoying anyway sometimes. You can disable fonts, at least in firefox.


> I share the same fingerprint as everyone else using the same browser with JS disabled

That's not a lot of people who have JS disabled.


Privacy at the browser level is hopeless! The answer is to compartmentalize. This VM and its convoluted Internet connectivity are pure Mirimir. I care not that the browser has been fingerprinted, that my IP has been logged, that evercookies have been placed, etc, etc, etc.


How do you manage your VMs? Are you using Qubes[1] or something like it? Can you easily force all traffic from a specific VM through a VPN/proxy?

[1] https://qubes-os.org/


I have used Qubes, and I highly recommend it. But mostly I use VirtualBox in Debian. If you search my handle, you'll find how-to guides and articles. Basically, I use local networks of gateway VMs to route traffic through nested chains of VPNs, JonDonym and Tor. I mostly use pfSense VMs, because they're so easy to secure. But Whonix is the best solution for using Tor.

One could do the same in Qubes, more elegantly. And indeed, I got the idea of workspace and gateway VMs from Joanna Rutkowska's early posts about the Qubes project.


Do you have a how-to of your current setup?


Check out the link in my profile. There are a couple background articles on risk assessment and anonymity systems, and a series of eight how-to guides. I also write a lot on Wilders, and have at times on Tor.SE.

I use various nested VPN chains, with three VPNs minimum. I also use a bunch of Whonix instances, connecting via VPN chains. And sometimes I play with JonDonym.


I've read some of your guides, and I don't really understand what the chained anonymity is getting you. Could you give some examples where complex chains are useful?

I can see limited circumstances where VPN/proxy->Tor, Tor->VPN/proxy, and VPN/proxy->Tor->VPN/proxy make sense, but no need for anything more complex than that.


If you use Chrome and a Tor SOCKS proxy, get ready for a big surprise.

Edit: owfffjaqvllmh4zi.onion reveals true IP addresses when using Chrome through Privoxy and Tor chain.


That is an important piece of information, but viewers be advised: that page has a non-work-safe background and is NOT exactly a copy of the GitHub demo page (and has other obfuscated JavaScript running on it).


This was already shown January 7th by:

http://jsfiddle.net/alokmenghrajani/0qo4kq7x/


There are some interesting comments in the hackernews thread I started: https://news.ycombinator.com/item?id=8859350


yeah it comes up regularly on HN actually.. ive seen it 3 or 4 times by now (different url/authors)


"Additionally, these STUN requests are made outside of the normal XMLHttpRequest procedure, so they are not visible in the developer console or able to be blocked by plugins such as AdBlockPlus or Ghostery. This makes these types of requests available for online tracking [...]"

So the extra effort to get around adblockers?


You can see it in: chrome://webrtc-internals/


Its particularly interesting in that it gets ALL my local ip addresses. This seems quite dangerous. Could they just start probing around my local network or does cross domain stuff kick in?


I don't see how. WebRTC may leak your local IP, but that doesn't mean someone outside your local network can interact with it (without compromising a machine on said network).


If your router is vulnerable to XSS or something like it, an attacker can probably guess its IP pretty easily (x.x.x.1).

Edit: I realized I didn't take this to its full conclusion. Guess the router's IP, exploit XSS to open ports on the router to your machine (JS knows your local IP already), carry on escalating from there.


Given that ten IP values will cover 99% of routers, could as easily cycle through them all...


You don't even need xss for this. You can simply bruteforce the password and try to get some fingerprint of the router and enable remote management. I did this some years back. Back then I also needed to find out the routers IP. Did this via iframes and the js onload event.


That's a great point. You're 100% correct. Can you recommend any good reading on offensive security?


You could have a look at Samy Kamkars talk "How I met your girlfriend" at Blackhat 2010: https://www.youtube.com/watch?v=O5xRRF5GfQs&ab_channel=killa...


Holy cow. Browser devs seem to become crazier by the minute. Combine this with the lack of a same-origin policy in the JavaScript websocket API and you can really poke around in the local network.


Well, for websockets it's up to the server to check if the connection should be accepted or not. Same as in CORS whnere the server sais who is allowed to access the resources, not the browser.


There's no SOP in the JS websocket API because websockets are a newly-designed protocol specifically for the use case of being called from JS. If you have websocket servers on your local network (... although, why?) they know they should be checking origin.


If you have websocket servers on your local network...

Maybe those aren't common, but it's very common to have something that looks just like one (speaks HTTP on port 80), which is called a web server. That might be embedded in your router or other device, or it may be a configuration interface for your POS, or it might be hiding in some other dark and unpatched corner that was formerly hidden behind a firewall. Of course it would be nice if the server simply doesn't respond (while writing alarms to the log) when it sees an Upgrade: websocket header, but can we be sure that all our hidden servers are so well-behaved?


The intention of the WebSocket protocol is that the handshake is sufficiently unlike HTTP that nobody could make a meaningful response to it by mistake.

As for non-meaningful responses, isn't this equivalent to using <img src="http://192.168.1.1/admin?action=evil"> to send an HTTP request? That's also not restricted by same-origin, and never has been and never will be. You get the same result -- you cause an HTTP request to be sent somewhere, and the response isn't useful to you nor is the contents of the response visible to you, but the request and its side effects still happen.

I'm not super well-versed in websocket design, so I'm happy to be convinced I'm wrong, but that's my understanding of why it works the way it does.


Ahhh, you're right. I guess this just ends up being another way of "fingerprinting" the hosts on the local network, which really is kind of minor.


This is the bug from goole about a year ago saying it is by design. https://code.google.com/p/chromium/issues/detail?id=333752


The demo reported 192.168.56.1 as a local IP. Now they know I have VirtualBox installed. I wonder what other IPs can leak information about common apps and network configs.


The concept is useful, but the API with its need for all these asynchronous callbacks, really sucks donkey balls.


This is pretty good timing. I got an email from Braintreepayments this week that I needed to implement some code changes for fraud detection and paypal before march. Upon integrating this code I noticed some odd data being sent back: https://www.braintreepayments.com/docs/ruby/general/fraud_to...

It turns out that this script must employ this techinque. After inspecting the requests in chrome Dev tools it appears all my private ips were being collected and sent over the wire back to Braintree (or whatever company is hosting their fraud detection).


Does not work on Firefox Developer edition 37.0a2

media.peerconnection.enabled is set to true

EDIT: hbbio's jsfiddle works


What is in in the about:config for "media.peerconnection.default_iceservers"? They could have removed the default STUN server.


This error message in the console looks like it indicates the problem: TypeError: Not enough arguments to mozRTCPeerConnection.setLocalDescription. webrtc-ips:72:20

According to the docs, the error callback is not optional.


Is there a specific reason stun.services.mozilla.com cannot be pinged successfully? Is this by design?

Edit: Apparently it is by design; ICMP ECHOs are blocked by default on AWS instances, on which stun.services.mozilla.com [54.172.47.69] is running. http://aws.amazon.com/articles/1145?_encoding=UTF8&jiveRedir...


Let's have a quick survey:

1. Are you currently using WebRTC in any projects?

2. Are you planning on using WebRTC in the future?

3. Do you think that WebRTC should be enabled by default in browsers?


1. No / 2. No / 3. Yes, with explicit permission and warnings every time.


1. Yes, see https://github.com/daGrevis/hndrx

2. Obviously,

3. With explicit permit from user each time it's needed (like it's for webcam);


Fails in Firefox nightly with the following errors:

    This site makes use of a SHA-1 Certificate; it's recommended you use certificates with signature algorithms that use hash functions stronger than SHA-1.[Learn More] webrtc-ips
    TypeError: Not enough arguments to mozRTCPeerConnection.setLocalDescription.
Here's me hoping they're addressing these concerns already.


I've been using it for almost a year on sharedrop.io (p2p file transfer app) to distinguish peers in the same local network. The code I'm using for finding local IP comes from http://net.ipcalf.com. The app even allows you to select your local IP in case you got more than one, e.g. because of VPN.


Wow, seems like a big privacy issue. Does this mean that VPNs soon won't be effective for masking your IP?


No. Your public IP has always been available to a Javascript developer who knows enough to write a one-line PHP script that prints $_SERVER['REMOTE_ADDR'] (as an example). This just makes it available via another protocol.

The new bit is that you can now get local IPs. But that doesn't help someone trying to figure out if you're using a VPN.


> Your public IP has always been available to a Javascript developer who knows enough to write a one-line PHP script that prints $_SERVER['REMOTE_ADDR'] (as an example).

The demo shows both my USA VPN IP address and my China Telecom IP address under "public addresses" (I strongly doubt this was possible before WebRTC). This means that Hulu, YouTube, Netflix etc. can now start blocking me even when I'm behind a VPN.


I set up http://ip.nfriedly.com/json?callback=foo a while ago - it's available if anyone is interested in a simpler version that also works for older browsers.


When you're on the command line:

    curl ifconfig.me


Nice! I didn't mention that http://ip.nfriedly.com/text works too, but I like the ipconfig.me domain name.


Doesn't work for me, thankfully. The funny thing is, I have enough different privacy and security addons that I don't even know which one is protecting me here (best bet is possibly NoScript, even though I allowed scripts on that page).


I hope webrtc isn't authorized by default by browsers.I want to give explicit consent.It should even have been that way for ajax requests.


You might be interested in NoScript. With this addon, JavaScript can be blocked by default, and allowed on pages of your choosing.


What makes AJAX requests dangerous?


Some people just want to know about any data their browser is sending server side. In the old days, your browser would not do anything without you making a conscious action. Widespread AJAX use changed that so your browser could be sending information to a server without any oversight. That lack of oversight isn't inherently dangerous, but certainly has potential for exploitation.


You could always send information using javascript by loading images, hidden iframes etc. (You would not get a meaningful response though). This applies to dark old days even before JS..


Great point. Lately we have been reconsidering the request manager matrix shown in gngr. It was inspired by HTTPSwitchBoard's matrix, that has a separate column for XHR.

However, like you pointed out, there are other ways than XHR to leak data if JS is enabled.

If JS is not enabled, the kinds of data that can be leaked is fewer (perhaps screen resolution and size).

Would welcome expert comments on our issue tracker: https://github.com/UprootLabs/gngr/issues/90


Why do I have two public IP addresses?


It assumes anything other than 10.* and 192.168.* are public.

https://github.com/diafygi/webrtc-ips/blob/master/index.html...




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: