This is a well-written, interesting article. I especially like the non-alarmist tone to it ("Considering the inherent weaknesses and numerous limitations, this attack isn't practical.")
Brute-forcing a macOS user’s real name from a browser using mDNS
121–130 of 168 posts
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#122Is there a way to prevent websites from the broader Internet from making network requests to my local network? I can't imagine why this should be allowed by default. (Not to suggest bringing back IE's Local Intranet Zone permission...)
They generally can't, because of CORS. The only reason this "hack" works is because the timing of the rejection is different between non-resolving domain request and resolving-but-rejected request. But if you run something on https://192.168.2.1 it can't be accessed from a web app running on https://my-own-domain.com unless the service running at 192.168.2.1 allows the "Origin" my-own-domain.com.
But you could DDoS something on the internal network.
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#123On my macOS box, I run Little Snitch, a nice UI that can be set to ask local user for explicit permission before allowing a network request. https://www.obdev.at/products/littlesnitch/index.html I’ve occasionally stumbled on it during remote logins, usually when an SSH session wants to download something new, like NPM requesting NodeJS bits. The text terminal SSH download will block; if I figure out it’s the Little S…
>Little Snitch
Just FYI, DNS-resolutions do still occur BEFORE THE POPUP DIALOGUE TO CONFIRM/DENY CONNECTION (i.e. www.example.com gets resolved to 1.1.1.1 , but no connection is made to 1.1.1.1 until `Confirm` is selected).
Add a PiHole to your network, you will not regret this time/$$$/investment.
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#124Is there a way to prevent websites from the broader Internet from making network requests to my local network? I can't imagine why this should be allowed by default. (Not to suggest bringing back IE's Local Intranet Zone permission...)
A common abuser of this is the Discord desktop app, which listens on a local port. When your browser navigates to a Discord channel's join page, it sends a request to localhost via this port and sends the channel ID to the client. This lets the app pop open a native 'Join Channel' experience. I discovered this when I noticed how this behavior worked even in incognito mode and my browser was signed out of Discord. Not…
Why in the world have people flagged this comment?
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#125Earlier quoted context omitted.
Ideally you'd use the most common name, in order to maximize the size of your anonymity set. So you could go with "John Appleseed" to get a "john" home directory and a "John's MacBook Pro" hostname. But in a small community, to local observers seeing your device on bluetooth screens, you might get weird looks ("there is no John here, why is this sus?") whereas "iPhone" looks like a default. And for non-local observer…
> seemingly private identifiers are SSH pubkeys (I always delete the comment trailer), which are sent to every server you SSH to and also published to places like GitHub I use this in my .ssh/config file: Host * IdentitiesOnly = yes ... then you'll only send keys that are specified per-host in .ssh/config with 'IdentityFile' or with a command-line argument. More discussion: https://news.ycombinator.com/item?id=100046…
I've always wondered if there was any downside to having my default private keyfile being shared whenever I fail to use the "-i" option to specify the correct keyfile when authenticating against a new server.
Thanks for linking to the previous HN discussion!
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#126This is a well-written, interesting article. I especially like the non-alarmist tone to it ("Considering the inherent weaknesses and numerous limitations, this attack isn't practical.")
In another universe, this would be "FINGERBleed", along with a snazzy website and logo.
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#127Windows will also be using mDNS in future.
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#128This is a well-written, interesting article. I especially like the non-alarmist tone to it ("Considering the inherent weaknesses and numerous limitations, this attack isn't practical.")
In another universe, this would be "FINGERBleed", along with a snazzy website and logo.
Reminds me of https://www.hertzbleed.com/
There still hasn’t been any known reported case where this would be possible or used. Very impractical.
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#129Earlier quoted context omitted.
Little Snitch is amazing. Any windows comparable?
I used to use tinywall on Windows. https://tinywall.pados.hu/
tinywall is great, however it does not block requests to microsoft and other essential windoze functions which one may either consider good or bad.
Re: Brute-forcing a macOS user’s real name from a browser using mDNS
#130Is there a way to prevent websites from the broader Internet from making network requests to my local network? I can't imagine why this should be allowed by default. (Not to suggest bringing back IE's Local Intranet Zone permission...)
A common abuser of this is the Discord desktop app, which listens on a local port. When your browser navigates to a Discord channel's join page, it sends a request to localhost via this port and sends the channel ID to the client. This lets the app pop open a native 'Join Channel' experience. I discovered this when I noticed how this behavior worked even in incognito mode and my browser was signed out of Discord. Not…
Why is this such a big deal? Have it as an option to disable, sure, but it makes handling auth between the desktop and browser so much easier.