https://lapcatsoftware.com/articles/2023/3/4.html
Previous: What Apple doesn't get about Feedback
Articles index Jeff Johnson (My apps, PayPal.Me, Mastodon)
Little Snitch "denied" connections leak your IP address
March 29 2023
Little Snitch is a macOS app and network filter extension made by
Objective Development Software. I purchased Little Snitch years ago,
continue to use it, and will continue to use it. I've also done a lot
to promote Little Snitch on my blog and even in the news media.
However, this blog post raises a privacy issue with Little Snitch
that bothers me, and I believe the public has the right to know about
it. My hope is that highlighting this issue will prompt some
improvements in Little Snitch to ameliorate it.
Here's Objective Development's advertisement for the Alert Mode of
Little Snitch:
Whenever an app attempts to connect to a server on the Internet,
Little Snitch shows a connection alert, allowing you to decide
whether to allow or deny the connection. No data is transmitted
without your consent. Your decision will be remembered and
applied automatically in the future.
When you look at the implementation of Little Snitch, the
interpretation of the word "data" becomes crucial. Technically,
unless you allow the connection, Little Snitch does indeed prevent
HTTP data from getting sent. Nonetheless, Little Snitch does not
prevent TCP (Transmission Control Protocol) data from getting sent.
This TCP data includes your IP address, which can often be used to
personally identify you. The server knows that you, i.e., your IP
address, tried to connect to the server, even when Little Snitch
"denies" the connection.
The background to this blog post is that I was testing whether Little
Snitch exempts its own connections to the developer's server from
getting blocked by Little Snitch. I already knew that Little Snitch
could block its own software update, but I wanted to see whether
there was anything else, ironically in order to assuage someone
else's fear about the app. The good news is that Little Snitch
doesn't exempt its own connections, as far as I can tell. I tested
this on one of my Macs that didn't yet have Little Snitch installed.
I disconnected the Mac from the internet, installed Little Snitch,
and went through the entire setup process. Below is a minimal set of
rules that you can use for testing. It blocks everything except
configd, which is required to connect to your router, and
mDNSResponder, which is required to perform DNS queries. (By the way,
the "Information from Objective Development" in the screenshot below
was available without an internet connection, so it appears to be
bundled with Little Snitch.)
Little Snitch All Rules
I ran the tcpdump command in Terminal to record a packet trace, and
then I reconnected my Mac to the internet to see what happens.
In the packet trace, I found no connections to Objective Development.
Disturbingly, though, there was some unusual TCP activity, for
example to Apple! (The IP addresses were in Apple's allocated
17.0.0.0/8 IPv4 range.) At first I suspected that Apple had exempted
itself from network extension filtering again. However, when I
emailed Objective Development, I learned the truth: Little Snitch
allows some TCP packets to be sent. Objective Development told me
that Little Snitch uses deep packet inspection to try to get a name
for the connection. I assume they meant for example the HTTP Host
header, the HTTP/2 :authority pseudo-header, or the TLS Server Name
Indication. The IP address alone would not necessarily provide a
unique domain name, because multiple domains can use the same IP
address.
An HTTP connection over TCP has to initiate a 3-step "handshake"
before any actual data--such as HTTP headers--can be sent over the
connection. Every TCP packet, including any packet involved in the
handshake, contains the IP addresses of the sender and the receiver.
Thus, before Little Snitch can perform deep packet inspection, the IP
address of your Mac may have already been sent to the remote server!
You can test the Little Snitch IP address leak yourself. Just run the
following command from Terminal app. (See man tcpdump for a
description of the options.)
sudo tcpdump --interface=all -n --no-promiscuous-mode
The information leak appears to occur for every TCP connection, as
far as I can tell.
While researching my blog post, I discovered a blog post from 2021 by
Rhino Security labs titled Bypassing Little Snitch Firewall with
Empty TCP Packets. For some reason, their blog post didn't seem to
attract any public attention at the time; I certainly wasn't aware of
it back then. The blog post described a technique, along with a proof
of concept, to connect to a server without triggering a Little Snitch
alert dialog. The author discovered the same unsettling fact that
I've now discovered:
Despite what it might seem, Little Snitch alerting doesn't
trigger at the first TCP packet, but rather waits until
application data is sent before interrupting the connection and
alerting the user. This is to support its domain-to-IP connection
features.
The author also provided a disclosure timeline, listing email
exchanges with Objective Development:
Nov 3, 2021 - Objective Development responded with a detailed
email on why this behavior is necessary for Little Snitch and why
it cannot be fixed.
I haven't tested whether the proof of concept, which has both client
and server components, still works on the latest version of Little
Snitch. Strangely, the author never mentioned the privacy
implications of Little Snitch's behavior, the fact that TCP packets
with your IP address are allowed to be sent to the server without
your consent. Perhaps the author was focused exclusively on the
possibility of a malicious app bypassing the Little Snitch alert
dialog, whereas my concern is simply personal privacy.
I understand that Objective Development is in a difficult position
here, because the Little Snitch feature of allowing or denying
connections by domain name may sometimes require deep packet
inspection. The issue, in my opinion, is that Little Snitch seems to
always require deep packet inspection. I don't understand why it's
required when a rule for a particular process is specified to "Deny
any outgoing connection". The domain name doesn't matter in this
case. I have a lot of Little Snitch rules like that, denying all
connections for a process that I don't want to connect to the
internet at all.
I'd like to see an explicit option in Little Snitch rules to enable
or disable deep packet inspection. I should be able to opt out of the
behavior. As an alternative, Little Snitch could use the DNS cache to
correlate the IP address with the domain. After all, any domain-based
connection by necessity has already queried DNS to find the IP
address of the server. In many cases, this correlation between IP
address and domain will be unique. And if there happen to be multiple
domains in the DNS cache with the same IP address, then Little Snitch
could show its alert and ask me whether to allow or deny the
connection, without allowing my IP address to be leaked to the
server.
At the very least, I'd like to see Objective Development publicly
acknowledge this issue, not just privately in emails to the
technically sophisticated who happen to discover it on their own.
Until now, I've trusted Little Snitch to protect my privacy, but my
trust has been a bit shaken. Although Little Snitch is still an
extremely useful tool, there's an important gap between what I
believed it did and what it actually does. Objective Development knew
all along, while their customers, myself included, were largely
oblivious.
Addendum: What about LuLu?
LuLu is an open source firewall for outgoing network connections,
made by security researcher Patrick Wardle. I decided to test it
briefly, and I found the same kind of IP address leak as Little
Snitch, perhaps for the same reason. However, I'm not 100% confident
in my results, because as a Little Snitch user, I'm much less
familiar with LuLu and how it works. Moreover, the feature set and
user interface of LuLu seem, let's just say, primitive compared to
Little Snitch.
Jeff Johnson (My apps, PayPal.Me, Mastodon) Articles index
Previous: What Apple doesn't get about Feedback