Re: Transparency into private keys of Debian
On 2/1/24 10:38, Simon Josefsson wrote:
Hi
I'm exploring how to defend against an attacker who can create valid
signatures for cryptographic private keys (e.g., PGP) that users need to
trust when using an operating system such as Debian. A signature like
that can be used in a targetted attacks against one victim.
For example, apt does not have any protection against this threat
scenario, and often unprotected ftp:// or http:// transports are used,
which are easy to man-in-the-middle. Even with https:// there is a
large number of mirror sites out there that can replace content you get.
There is a risk that use of a compromised trusted apt PGP key will not
be noticed. Attackers are also in a good position to deny themselves
out of their actions if they are careful.
hello, thanks for raising this.
I've spent some time exploring this in 2022 and figured, though I don't
have the resources to do anything meaningful about this, I can still
help by making reasoning about this attack easier by implementing it. I
authored a malicious update server for multiple package managers
including apt (the contrib/ folder has a few examples, some of them
being incomplete or defunct tho, please do not make assumptions unless
you tested them, many of them have a `check:` section for automatic
integration testing):
https://github.com/kpcyrd/sh4d0wup
The name is derived from "shadow updates" that carry a valid signature
(through private key abuse) but are fed directly to an update client and
therefore never show up in Debian.
It has some features to illustrate how I would assume targeted attacks
to work (switch the Release/InRelease files based on source IP address
and/or user-agent, leading them to a different /by-hash/ url that nobody
else knows about).
From what I've learned the most interesting keys are (for each
respective release):
- Debian Archive Automatic Signing Key
- Debian Security Archive Automatic Signing Key
- Debian Stable Release Key
The DM/DD keys probably also have some value, but would leave a
permanent record in Debian which might get noticed at some (distant or
not so distant) point in the future, however when abusing release
signing keys you are almost guaranteed to get away with it.
---
Having built all of this (and also hence having proven writing the
software for this is well within reach of a single, semi-determined
rando), I then spent some time in 2023 trying to think up a system that
is as annoying as possible for sh4d0wup users and developed apt-swarm.
It's my first attempt of an autonomous p2p network and it uses the
configured public-keys for a "proof of authority", gossip-sync protocol
to attempt an eventually-consistent view of all Release/InRelease files.
However:
- I need an embedded database with specific properties for the sync
protocol (allowing fast, ordered lookups by key-prefix), I picked the
`sled` library as suggested by a debian-rust friend at FOSDEM 2023, but
I later learned sled needs to be able to fit the entire database into
RAM, so running a node currently requires ~8GB RAM (and *will* require
more in the future).
- Because of this, the entire p2p network is currently running from a
single server (that is provided to me by a friend from a local
hackerspace). You can join your own nodes at any time but so far nobody
has done so.
- Despite it's name, it doesn't know about apt and only stores opaque
signed documents, the Release/InRelease files. It does not store any
copies of any referenced package indexes (or packages), which limits the
amount of data you get to triage incidents with.
The last part is important because availability of this kind of data is
going to set the scene in case you ever need to actually investigate
something. I found that rekor from the sigstore project is a great
public resource, but will only tell you "there's a signature you don't
have any records of", but nowhere to go from there. It doesn't
complement the snapshot service and it's impossible to tell apart if
somebody generated themselves the inclusion-proof for a malicious update
or if snapshot.debian.org simply missed/lost a snapshot.
With apt-swarm you can look at the alleged `Date:` field of the release
file but you will (likely) still be missing the package index that was
fed into user's apt clients (and the code they executed) unless you
recognize the referenced hashes. Development of this project has stalled
due to the mentioned RAM usage issue, little interest for this kind of
tech (even inside the security community) and cyberpunk 2077 being a
really good game.
Throughout the year apt-swarm has collected (among others):
- 20,459 signatures from `Debian Archive Automatic Signing Key (10/buster)`
- 18,085 signatures from `Debian Archive Automatic Signing Key (9/stretch)`
- 10,463 signatures from `Debian Archive Automatic Signing Key
(11/bullseye)`
- 6,843 signatures from `Debian Security Archive Automatic Signing Key
(11/bullseye)`
- 6,623 signatures from `Debian Security Archive Automatic Signing Key
(10/buster)`
- 2,060 signatures from `DEB.SURY.ORG Automatic Signing Key`
- 420 signatures from `Rust Language (Tag and Release Signing Key)`
- 372 signatures from `deb.torproject.org archive signing key`
- 124 signatures from `Open Whisper Systems`
- 90 signatures from `Docker Release (CE deb)`
- 16 signatures from `Spotify Public Repository Signing Key`
- 10 signatures from `Valve Software LLC`
- 2 signatures from myself
Also note, PGP's subkey feature can sometimes be used to obfuscate the
trust relationships and skirt transparency logs, however `apt-key
update` has rightfully been deprecated (to my knowledge).
---
Lastly, besides apt, the Linux kernel also makes use of a private key
through CONFIG_MODULE_SIG. With no configuration it generates a random
key at build-time and then pinky-promise-deletes it, this is impossible
to prove however and also breaks reproducible builds. In Debian, the
Linux kernel is using a well-known key instead of a randomly generated
one, but even if the package is somehow made reproducible, it's still
very difficult to hold this key accountable.
---
In my local community of computer (security) enthusiasts it's "common
knowledge" a private key compromise is impossible to do anything about.
Hopefully the future proves them wrong.
anyway, cheers,
kpcyrd
Reply to: