exposed local server information and local ips
Categories
(Core :: Security, defect)
Tracking
()
People
(Reporter: forwarding4, Unassigned)
Details
Attachments
(1 file)
|
21.50 KB,
image/png
|
Details |
demo_output.png
User Agent: Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.98 Safari/537.36
Steps to reproduce:
Visit this demonstration https://flngerprlnt.github.io/star_echo
or this http-link http://jsfiddle.net/flngerprlnt/1qjukmve without Mixed Content
Test case:
- local router favicon
- FRITZ!Box image
- XAMPP default favicon (windows)
- Default SABnzbd installation favicon
- Default NZBGet installation favicon
With more test cases it is possible to fingerprint the visitor based on running software, by loading local resources.
This works in Firefox, Chrome, ...
Actual results:
Output in my test case is:
Your router is available via 192.168.178.1
Your router is : FRITZ!Box
Your are running XAMPP with default configuration
NZBGet is running on port 6789.
NZBGet is running on port 6789.
Screenshot of my demo output is attached.
Expected results:
Resources should habe been blocked by default
|
||
Comment 1•6 years ago
|
||
Not sure what is your point here?
192.168.178.1 is a private ip address, most of the time won't exist.
Could you explain more what is your point? Thanks
|
Reporter | |
Comment 2•6 years ago
|
||
(In reply to Sylvestre Ledru [:sylvestre] from comment #1)
Not sure what is your point here?
192.168.178.1 is a private ip address, most of the time won't exist.
Could you explain more what is your point? Thanks
This can be used for browser fingerprinting (just an example).
Building and testing an exhaustive list exposes software used on the client system and network.
The motivation why a website may wants to know which software a user is currently using or connected to depends on the application and goal of the website.
It is not limited to 192.168.178.1. That was just an example.
|
|
||
Comment 3•6 years ago
|
||
Sure, there are a lot of ways to do fingerprinting.
However, I am not sure to see how your bug is actionable ?!
|
||
Comment 4•6 years ago
|
||
This would be actionable if you disallow linking to private address ranges (10/8,172.16/12,192.168/16) like it's already done with file:// urls on the protocol level.
I'm sure that this would create problems at larger organizations.
|
||
Comment 5•5 years ago
|
||
Steven, could you help triage this bug? Thanks!
|
||
Comment 6•5 years ago
|
||
Thank you for the report! This is a known issue discussed in Bug 959893. I think we can resolve this as a duplicate of that bug since there doesn't appear to be any new information here.
Tom, does that sound right?
|
||
Comment 7•5 years ago
|
||
This isn't actually about the WebRTC local IP thing, this is about looking for specific resources on RFC 1918 IP addresses and using it to learn about the private machine/network. There is a draft spec to do something about that, but I don't think there's been much movement on it. But you are correct it is a dupe/example of why that work is valuable.
|
|
Reporter | |
Comment 8•5 years ago
|
||
I am aware of Bug 959893.
This Bug is not a technical dupe, since it is unrelated to WebRTC.
If you inspect the source code you can see that no WebRTC-code is used.
In terms of privacy there should be a browser setting, so that the browser user can choose to block this kind of leakage at will,
instead of using custom block workarounds.
Description
•