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.
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.
You'd think so, but the way I've set it up Little Snitch throws up a dialog box when a browser makes errant requests but otherwise remains silent. Most recently this caught Firefox trying to force DNS over HTTPS despite me having disabled it when it first became generally available. I suppose leaking DNS requests to Cloudflare isn't the worst thing in the world, but it would circumvent the ad blocking I've set up locally.
Ah so I just dug into the rules. What happened was a plugin made a DNS request to mozilla.cloudflare-dns.com. I've nothing special set up for Firefox, but basically no rules for plugin-container, so when a plugin tries to make a DNS request Little Snitch pops up an alert.
Not great I suppose, but better than nothing. Generally what I'll see for Firefox itself are requests for non 80/443 ports.
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.
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.
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.
It breaks DNS based blocking if you have it setup. Some people setup ad-blocking so that it encompasses their entire network and the way this works is that it silently drops DNS requests to ad domains on the edge of your local network.
And in some/many jurisdictions, your ISP is more regulated by your local government (also in regards to data protection) than cloudflare who has no obligation to you.
How do you even use bank apps on a jailbroken phone? Last time I was JB'd everything from McDonald's to my bank just threw up a big 'no' and refused to even work.
Also: the noscript plugin downloads every .js file first before it decides if it's not going to execute it which is a massive data leak unless you also have host file entries or firewall rules blocking access to the most common privacy abusers.
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.
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.
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].
I’ve been enjoying Windows Firewall Control from BiniSoft/Malwarebytes. It’s a sort of a (better IMHO) hybrid GUI between Windows built in host firewall, and Little Snitch’s application firewalling.
I checked that out once but the safing/SPN thing spooked me. It doesn't really explain what it is and why it is needed for a software firewall. As far as I can tell is it a peer-to-peer VPN network? I don't want that. If you have a good answer I'd love to learn it.
CTO of Safing here. I hope I can bring some clarity into this.
Portmaster is actually a privacy suite consisting of many features and modules. It is often described as an "application firewall" to give people a quick, but incomplete idea of what it is.
The SPN is one of these features. It is a blend of VPN and Tor - oversimplified - and is fully optional. In fact, it is a paid feature and won't activate without logging in with an eligible account.
I humbly suggest that you add an entry in your FAQ regarding this question. I tried (quickly) to find answers in the documentation and then moved on when I couldn't find one. Take of that what you will.
I've heard of little snitch a ton, but is it just a really smart firewall essentially? On Windows, every darn thing connects to something, its ridiculous.
Same with macOS. Install LittleSnitch in strict mode, and you won't go 5s without a pop up blocking something. You can either trust all of the lists that are available to keep LS somewhat out of your way, or you can go full tilt and approve everything. Personally, I've never found that middle ground.
Is 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.
Technically they can make the request. The server will receive and respond to the request. CORS is applied by the browser which prevents the response from being read. This is why CORS doesn't prevent a request from mutating something on a server. A CSRF token does.
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.
First of all, you could probably do a timing attack on CORS response, you'd just have to deal with how much they're cached.
Depends on the resource request. For example, <img> can be used to load remote resources without CORS, since the image data isn't shared with JS (trying to read it via a canvas marks it "tainted", and errors read requests). Meltdown/Spectre breaks this barrier down, which led to the introduction of COOP/COEP headers that require CORS on remote requests and would break this attack—except that you can ask the browser to send requests without cookies, re-introducing this timing attack.
And none of this helps you if the server in question isn't actually a HTTP server, but something else (that only ever expected to be exposed on localhost). Depending on the exact syntax it expects, it's plausible that a HTTP request (even a CORS request) might be misinterpreted to do something nefarious.
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. Cool. We need to massively improve sandboxing - of all applications - in the desktop world.
This will block all requests to .local, even from .local itself. If you want to allow foo.local to talk to itself, say because you run a webserver on it, you'll have to add additional overrides for each such domain:
@@||foo.local^$domain=foo.local,all
... or if you trust your .local entirely to allow any foo.local to talk to any bar.local, you can add one override for all of .local:
To avoid confusion, this is not about an internet server making requests to your local network, but your local web browser making those requests. Although, the javascript executed in the browser can be loaded from an internet server, of course.
Yes. Change the client. For example, I'm using one that does not auto-load resources, does not run Javascript and does not perform DNS prefetching. There is no way for the website (cf. user) to make network requests.
This experiment is of course limited to users who do not change defaults, since any MacOS user can easily change their hostname to anything they want, and that is quite easy to do, even for people who do not read HN. The "real name" might not be real if the user has changed the default. Is there any reliable way for the website to distinguish "real" from "fake" names in MacOS hostnames.
My WiFi access points allow me to configure networks so that no devices on it are allowed to make requests to the local network. I haven't done this with networks used by my PCs, though, just for televisions and IoT devices.
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.
In my tests it only recognizes the same browser. I’m a different person when using different browsers. I noticed that I can still be correctly fingerprinted after resetting the browser or using a private window.
Using Firefox (on a Linux laptop) with resistfingerpriting=true or Mull (on an Android) with its default settings, I'm able to get assigned a new fingerprint whenever I clear cookies or use a new Incognito session.
I haven't tested it, but presumably they also wouldn't be able to track me between domains, even without clearing cookies.
Doesn’t seem to be the case on iOS unfortunately which is really creepy. Still get tracked regardless of Cookie & Cache Reset/VPN/Private Browsing with Safari
Good thing I always change the name of my devices.
Apple's default naming is a privacy error. One time I was on a first date with someone in law enforcement. Being a woman alone and obviously interested in protecting herself, she'd done a background check on me and had informed several fellow community members of our whereabouts.
I, on the other hand, didn't know her last name. We joked about that. When we got in her car after dinner, the intrigue was up when her dashboard display showed that it auto-paired with her iPhone... which was named with her first and last name. I didn't point this out, and challenged her to figure out how I knew her name by the time the drive was over.
>...dashboard display showed that it auto-paired with her iPhone... which was named with her first and last name.
So many times a rental car comes with a dozen of profiles from previously paired phones along with their phone books, saved map locations, history. Not much use, of course, still, it leaks out without much thought to it.
Guess what, the hardest thing is to remind myself to clear my profile before returning the car...
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 <name>s-mac-xxxx to be a bit of an odd choice, especially considering it's from a company that advertises privacy as a huge selling point; either they don't expect you to use your real name, or this is a case where "user friendliness" took precedence. From the privacy perspective, Windows' randomly generated hostnames would be better.
> 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.
Unlike regular DNS where you're asking a single server at a single IP for a yes/no answer, mDNS is multicast, so no single server can authoritatively say no†. You can only detect that there are no records when the lookup times out because no servers have responded.
† Not technically true, a device can say no if it knows it owns that name.
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.
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.")
This allows to test wether hostnames exists on your network.
It’s maybe not an issue for a unique hostname but what about fixed hostnames or default hostnames that are common in the IoT world.
This allows a website to secretly guess if you own a given device. It’s even worse used in a targeted attack : if you know some devices of the network, you can guess that the connected user is on the targeted network.
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 fingerprint information has been captured and reported to [insert scary cyber agency here]." Even if they are seasoned veterans rather than script kiddies, it could at least give them a smile.
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
I'm now thinking how this is related to Wi-Fi sharing. I've always renamed my device to avoid leaking my name when I'm sharing Wi-Fi. Interesting stuff.
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
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.
> Both errors will be mapped into the same Failed to fetch JavaScript error, so we can’t rely on the error type, but we can perform a timing attack. Local networks are fast, so the valid mDNS hostname registered in the network will be resolved in a reasonable time frame, which is significantly faster than the default connection timeout. In the example above, the difference is four milliseconds for a valid address versus five seconds for an invalid one.
This isn't really a "timing attack." A timing attack implies exploitation of an unintended behavior by executing something at some specific time. This just sounds like a workaround for the fact that the Javascript API doesn't expose a way to detect a hostname resolution error, which really should exist.
offtopic, does the browser offer some kind of Network Service Discovery? If so we can establish WebRTC sessions without any signaling servers, like opening two different browsers on different devices in a LAN, they discover each other without any outbounding connections.
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 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.
I see this joke frequently when looking at available wifi; is this meme a reference to a particular thing (other than the FBI having surveillance vans) or did a bunch of people just converge onto it?
I like this idea, but any sophisticated attacker will ignore the Bluetooth names and just pull vendors off the MAC addresses. Though it would be interesting if you can define the Bluetooth MAC addressees in software to match your fake names :)
I used to do something similar with my router. I would run an AP called "Linksys" or something common and give it an OUI belonging to Cisco. It probably had no benefit (maybe even harmful!), but it was fun to "disguise" my OpenBSD router as a common off the shelf router.
That reminded me that almost 10 years ago ghacks [1] instructed people to add _nomap to their Wifi networks name to avoid these being harvested by Google and Mozilla. I wonder if that ever worked or still does and if companies stopped collecting that information.
Officially this is still supported. With that said, there have in past years been data sanitizing failures which get them mapped anyway. Google caught a little flack for that several years ago.
It might sound a bit silly, but I've had pretty good results just naming my devices after Pokemon. Whenever I have a new device, I open the Pokemon DB[0], choose one at random, and then add it to my .csv file of device names -> what they are and what role they perform.
Rather than choosing at random, I like to pick names that have some relation to the device in question, e.g. "Pichu" for a tiny mobile device, "Snorlax" for the big slow machine, "Articuno/Zapdos/Moltres" for three successive powerful servers, etc. What's extra fun about Pokemon, if you're familiar with the franchise, is that you can pick names based on generation, with older generations for e.g. older devices, and if you're _really_ familiar with the franchise you could even pick names based on types or other characteristics.
My company uses codenames like this for our services and it drives me insane every time I have to go look up which is which or mentally convert to the name it should have been given.
Very similar here. PCs get Pokémon region names (MacBook is Johto), non-PC Ethernet connected devices get Professor names, all other devices are Pokémon.
I do something similar but with other mobile/gacha game characters since those names are always in abundance. I also try to do some kind of correlation with the fictional settings too (groups of devices will correspond to meaningful in-domain names)
For non-mobile devices like workstations or servers, I also tend to directly give FQDN, like (name).(location).(my-personal-domain.tld)
I do the same thing but with Star Trek words! I have a somewhat logical naming scheme too. Computers are named after Star Trek ships (Yorktown), phones are named after handheld devices (Phaser), and drives are storage related things (Isolinear). And my printers are just named Replicator and Synthesizer.
I've been using chili peppers (peri, shishito, ancho, ...) for my devices for the last few years. Many years before that, I was using named swords (notung, glamdring, sting, etc).
Back in college my boss named a sun workstation lab with aleutian islands, and another after indonesian islands. (Some of those were fun to remember, there was an umnak and an unimak.) The servers were named after seas and oceans. We tried to name a new lab of windows machines after bugs, but the department nixed that.
I've historically preferred to use Culture series ship names (eg. GCU Grey Area, GCU Jaundiced Outlook, etc.), but stopped after Elon started naming his SpaceX ships like that.
I then went for Scottish Single Malt names (eg. Laphroaig, Jura, etc.).
After quitting alcohol, I've now settled on Douglas Adams names (eg. Deep Thought, Grunthos the Flatulent, etc.).
My go-to is either gods from Norse mythology, or Transformers for servers.
I set my iPhone to an emoji, and apparently it's one of the emojis that is composed of multiple emojis to render correctly. It's fun to see how every device it connects to draws the emoji or more likely boxes a little different.
I do the same, mostly because I don't like my full name showing up in every subpath of the home directory. Sometimes this leaks far beyond your local computer, too, since many build tools include some path info in the compiled binaries. You can download apps from the app store, run `strings` on them, and find the username of the developer who built the binary.
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 observers, your choice of a name like "John" suggests you're a westerner named John. So by just going with "iPhone" or "MacBook" you're in a smaller anonymity set but also not drawing attention to yourself in your local area, and not externally leaking information like your locale (although of course you could always leave a false trail by using a cyrillic hostname).
Some other leaky, 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, and WiFi SSIDs (which are visible to any application with access to the network stack, and unfortunately aren't entirely within your control - often a list of nearby SSIDs, combined with a mapping of SSID to geolocation, is enough to triangulate your location to within a meter, which is one of many reasons I disable WiFi in favor of ethernet whenever possible).
> 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.
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.
The hostname is derived from the admin user's name, which ought to also be fake. My "full name," unix username, and hostname are all a nice short "me".
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.