Live data from Hacker News

Brute-forcing a macOS user’s real name from a browser using mDNS

fingerprint.com

51–60 of 168 posts

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#51

Earlier quoted context omitted.

I do the opposite: one of my laptops is named "Peter's iPhone" (hint: my name is not Peter, nor do I own an iPhone) and I've also set all my Bluetooth to random Bluetooth headset or mouse models.

My hotspot on my phone is "FBI van 4"

In the early days of insecure WiFi, in apartment buildings you would see network names like "Don't steal our WiFi Room 238!"

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#52

In the example above, the difference is four milliseconds for a valid address versus five seconds for an invalid one. This is surprising --- I'd expect a DNS lookup failure to be much faster than a default connection timeout which comes after a successful DNS lookup. That said, I've always found the s-mac-xxxx to be a bit of an odd choice, especially considering it's from a company that advertises privacy as a huge s…

The reason users' real names are in the hostnames is possibly because of AirDrop. The system appears to use the hostname for things like Personal Hotspot and AirDrop, and other types of names would probably lead to widespread confusion when it came time to share a file.

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#53
post #2

As part of my standard (and pretty lame) OPSEC I always change the default names that apple gives its devices (like "Joiqj's iPhone") to a more generic name (like "iPhone"). Nice to see that it was good practice.

I do that too. So if we’re on the same network and conflict, it’ll become “iPhone (1)”, etc.

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#54

This is interesting, well written up and even has a nice proof of concept. Nicely done! A fun countermeasure would be to change the device hostname to something like atemptingurl.local that entices the attacker to try visiting that website where a webpage is carefully crafted to run the exact same technique on them and return: "Hi [hacker's device name]! Your machine information, IP address, geolocation and other fin…

You would need to be running a http server with CORS allow all. You would then also reduce your own security as you are now exposed to all the bugs in the chosen http server

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#55
A similar type of timing attack can be used to port scan your local machine (and other devices on your local network) from your browser.

https://github.com/Flu1dTeam/PortScanner

A while ago, eBay got caught doing this.

https://blog.nem.ec/2020/05/24/ebay-port-scanning/

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#56
Could browsers mask this by turning connection refused to a 5 second timeout in JavaScript but still show the actual error in the console (which JavaScript cannot read).

This should only trigger when when JavaScript is making a request where CORS would kick in AND connection is refused

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#57
On 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 Snitch then I have to walk all the way to my desk downstairs, wiggle the mouse to wake up the monitor and unlock the screen saver, and click “Allow” on the Little Snitch dialog box.

Works as intended.

BUT by default it’s common to set such things to silently allow local network requests, so I don’t know if such shenanigans in the OP would work in my case.

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#58
post #57

On 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…

In my case, I couldn't imagine configuring LittleSnitch to only allow certain hostnames from my browser. It has a "allow all traffic to 53/80/443" rule, otherwise most websites would flood me with hundreds of new LittleSnitch popups.

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#59
The more time passes, the more comfortable I feel about mostly interacting with the internet from a Qubes box, in a disposable Whonix/Tor VM, with Javascript disabled...

This is just gross. I mean, not surprising. But appalling in so many ways that it's even possible.

If you're not familiar with fingerprint.com, they do "deep user profiling" - think "maintaining a constant user ID across computers, browsers, OSes, etc." They have a demo on the main page that's a little bit creepy in how good it is.

Re: Brute-forcing a macOS user’s real name from a browser using mDNS

#60
post #35
post #25

Earlier quoted context omitted.

Is that true? There’s a preflight request that checks with the server as to what’s allowed and then the browser issues the original request if it’s ok, right?

"Simple" requests are sent without a OPTIONS preflight check. It's because old style forms could always do a cross-origin request, so you have to protect against it anyway. For the full definition of what is a "simple" request: https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simpl... EDIT: Lol @ jakear making an almost identical response with the same Mozilla link.

Not only forms, img and link tags supported cross origin sources too, with no user action required.
Post reply on HN