12

On Linux, the /etc/ssl/certs folder includes all the necessary public keys for Certificate Authorities. If I have not misunderstood something, this makes it possible to verify public keys received from other servers over the internet.

But an adversary, e.g. a program with root privileges, or even a security agency collaborating with developers of a Linux distro, can "plant" its' own certificates or modify the existing ones. This would enable MiTM attacks by making the adversary's fake certificates used for such attacks seem legitimate and signed by a Certificate Authority.

Is there any technique that prevents this, or a way to verify that those keys have not been modified after installation?

Improve this question
5
  • 51
    If the attacker gains root privileges, you have a lot more to worry about than certificate trust. An attacker with root doesn't need help from a MITM to compromise your connections terminating on that node, and can downgrade encryption without having to fake certificates.
    – Ben Voigt
    Commented Nov 21, 2022 at 17:37
  • 21
    The trust chain must end at some point. You trust Ubuntu's certificates because you trust Canonical and that you obtained your copy of Ubuntu via secure means. If you do not trust Canonical or the way in which you obtained a distro then don't use it. Decide who you trust and follow that.
    – Bakuriu
    Commented Nov 21, 2022 at 20:11
  • 1
    You can check the fingerprints of the certificates. See this answer.
    – John Wu
    Commented Nov 22, 2022 at 6:07
  • This isn't enough to be its own answer, but consider: The Kerbleckian Evil Dictatorship could collaborate with Canonical to sneak their KED-owned certificate into Ubuntu. But though Canonical alone can control what goes into their OS, they can't stop other people from noticing. We know that because this kind of attack has happened, but even more subtly: The CA itself was legally pressured, and forced to give the KED valid certificates for popular websites. If they'd done something as obvious as put a fake CA on disk, it'd be much faster.
    – anon
    Commented Nov 23, 2022 at 1:59
  • @BenVoigt: although in practice, corporate SSL interception often does work by planting a root certificate and then MITM your traffic at the local network edge, rather than running any interception code on your machine. Go on, ask me how much of my time has been wasted by this fact. At least the certificate is named "Steve's Employer's SSL Interception", not "Just a Regular CA Root".
    – Steve Jessop
    Commented Nov 24, 2022 at 12:49

3 Answers 3

Reset to default
46

If an adversary or attacker has root level access to your system (and therefore, the ability to plant its own certificates in your system's trust store), then that means your system has been compromised. If your system has been compromised, that it's game-over irrespectively.

Once your system has been compromised, and the attacker has root level access, the attacker then has complete control of your system. He or she can access your files, install its own programs, monitor what you do on the system, and monitor your communications - without even needing to plant certificates in your trust store.

Improve this answer
4
  • 2
    But planting certificates might be a simple and un-obvious way of compromising communications, without having to replace many things.
    – Paŭlo Ebermann
    Commented Nov 22, 2022 at 0:22
  • 4
    Although this answer is, in principle, correct, it does not address the verification part of the question. Integrity checking is an established way to find out whether any file has been modified; best practices suggest that the integrity check program and baseline db are not stored on the target box and that the verification takes place offline - this cannot be changed by an adversary that has gained root access to the target box
    – user284677
    Commented Nov 22, 2022 at 6:17
  • Too small an edit => "that it's game over" should be "then it's game over".
    – Matthieu M.
    Commented Nov 23, 2022 at 8:37
  • Strictly speaking, it is possible to protect a Linux system even against an adversary with root-level access, for example using SELinux and ensuring lockdown is set to integrity mode.
    – forest
    Commented Nov 24, 2022 at 2:45
18

Trusting the "pre-installed" certificate authorities requires a level of trust on your part for the OS/App you're installing. Trusting that no one has installed an illegitimate root certificate post-installation requires tooling like a file integrity monitor (FIM) to alert if files are added.

From CISA:

When you trust a certificate, you are essentially trusting the certificate authority to verify the organization's identity for you. However, it is important to realize that certificate authorities vary in how strict they are about validating all of the information in the requests and about making sure that their data is secure. By default, your browser contains a list of more than 100 trusted certificate authorities. That means that, by extension, you are trusting all of those certificate authorities to properly verify and validate the information. Before submitting any personal information, you may want to look at the certificate.

File integrity monitors should alert you when a file has been added or deleted, and when files are modified. When properly configured this would alert you to a certificate chain being added to your server.

References
Understanding Web Certificates
What is File Integrity Monitoring

Improve this answer
3

Is there any technique that prevents this,[...]

In principle, you cannot prevent someone from gaining privileged access to your OS and altering files; it's considered just a matter of time and effort. All you can do is make it as difficult as possible and establish detection and recovery procedures for when the intrusion takes place.

[...] or a way to verify that those keys have not been modified after installation?

It can usually be done by using file integrity monitoring tools (FIM - e.g. aide) or full blown host-based intrusion detection systems (HIDS - e.g. samhain)

However, the use of a FIM (or HIDS, for that matter) requires three things:

  1. establish your integrity baseline immediately after your OS installation
  2. establish an SOP to follow when OS updates take place
  3. be serious about safeguarding the integrity baseline produced in step one (and amended with every update)

else you may find yourself in the position to trust something that you shouldn't.

As a side note, /etc/ssl/ is the location used by the openssl software to store its global configuration file, along with its trusted certs and private keys.

It is the default place to look for certs and private keys when a program uses openssl as a linked library, but it's not the default for every program you may execute in your box, for example:

  • openssh uses the /etc/ssh directory for the openssh server's public/private keys and the ~/.ssh/ directory for the client's trusted public keys
  • mozila firefox trusts its own CA list
  • java installations have their own CA trust stores (e.g. for openjdk it's inside /etc/ssl/certs/java)

etc.

This is important to understand, because you don't need to gain admin level privileges in order to modify some of the CA lists. For example, you may leave your computer unattended for a minute, someone can launch your browser (let's say firefox for this example), import her own CA certificate and then be able to mitm you at will.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .