Brute-forcing a macOS user’s real name from a browser using mDNS • Hacker News Board

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

#161

Post by inferiorhuman » Fri, Jul 14, 2023, 11:03 PM UTC

rovr138 wrote: post #154

Bagged2347 wrote: post #140

Earlier quoted context omitted.

Can you elaborate on why you'd want to opt-out of DNS over HTTPS? I was under the impression that it was useful and good for privacy, but I may be misinformed.

I have a local DNS server to access servers and other resources on my network. DNS over HTTPS breaks this.

It doesn't actually break this but it does leak all of your local DNS queries to Cloudflare.

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

#162

Post by inferiorhuman » Fri, Jul 14, 2023, 11:06 PM UTC

ZiiS wrote: post #131

inferiorhuman wrote: post #90

Earlier quoted context omitted.

False dichotomy. Not only am I pretty sure Sonic isn't selling my DNS queries, I've already opted out of DNS over HTTPS. Refusing to respect the choices I've made is worse than not. Besides, unencrypted SNI means that if my ISP wanted to get the hosts I was looking at, they could.

Unencrypted SNI is fairly rare now.

Is it? The best I could find was a bit from 2021 that showed 92 of the Alexa Top 1000 site supporting ESNI. If adoption has skyrocketed since then that's great… meanwhile Firefox is showing HN negotiated a TLS 1.2 connection with no ESNI support.

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

#163

Post by cjcampbell » Sat, Jul 15, 2023, 1:18 AM UTC

Eisenstein wrote: post #150

ProllyInfamous wrote: post #123

Earlier quoted context omitted.

>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.

Are you saying that DNS resolution bypasses software firewalls?

I’d expect most firewalls to allow DNS traffic to locally configured resolvers without prompts, and I figure this is also extended to mDNS traffic, which doesn’t leave your local LAN by default.

From the mDNS side of things, you could easily block if your firewall allows you to set up port based deny rules (in this case UDP/5353). This should resolve the privacy leak from the OP, though you may find that you lose expected functionality on your host and local network depending on whether you block inbound, outbound, or both.

Unicast DNS gets a bit trickier (even without considering DoH). Depending on browser and OS configuration, you won’t be talking to more than a handful of resolvers directly. Ideally, you allow communication with these resolvers and block all other DNS traffic. You definitely don’t want to set a rule that allows you to accept each and every query, so in that sense, DNS will be bypassing the firewall.

What’s better in this case is resolver with filtering capabilities, e.g., pihole.

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

#164

Post by watersb » Sat, Jul 15, 2023, 6:04 AM UTC

ProllyInfamous wrote: post #123

watersb wrote: 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…

>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.

Ah yes, I run Pi-Hole as well.

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

#165

Post by neop1x » Sun, Jul 16, 2023, 2:14 PM UTC

jms703 wrote: post #99

Why should anyone care about this?

Because attackers can now know your super-private first name and you are losing your privacy. But no one cares about the requirement to have an apple account with bank info to use the device normally or about the requirement to have iMessage setup in order to receive SMS on iPad, about cameras with face recognition on the streets and the list can go on and on.

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

#166

Post by leoradovey1993 » Sun, Jul 16, 2023, 4:42 PM UTC

[dead]

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

#167

Post by bmacho » Mon, Jul 17, 2023, 4:19 PM UTC

jstrieb wrote: post #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/

WTH that's super creepy, how comes I've never heard about it before?

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

#168

Post by ProllyInfamous » Sun, Jul 23, 2023, 1:29 AM UTC

Eisenstein wrote: post #150

ProllyInfamous wrote: post #123

Earlier quoted context omitted.

>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.

Are you saying that DNS resolution bypasses software firewalls?

What I'm saying specifically is that LittleSnitch creates an inquiry to your DNS service (to resolve hostname to IP) before you select either option (`Deny` / `Allow`). If you have DNS that is offsite (i.e. 99% of consumer-facing accounts) then your ISP knows that you have made an inquiry to http://www.example.com [because ISP handles 99% of users' DNS resolution].