8

Question(s)

Is it possible to "redirect" linux-update-repos via DNS spoofing (e.g. DNS cache poisoning) to a malicious website, so that harmful software (updates) will be installed, when running the packet manager's update function (yum, apt-get, etc.)?

Or is that completely unrealistic, since those repos are very well protected via certificates, ssl, etc.?

Furthermore if possible, are there ways to protect yourself against something like that?

Background

I was considering to set up automated updates for my webserver, and (besides other problems that might arise from this) I was not sure if it is a good idea, since an attacker would have a pretty big time window. For example from 4 am til morning, in case of the default settings of yum-cron for example.

Community
  • 1
Levite
  • 819
  • 1
  • 6
  • 14
  • 2
    I believe (but have not checked) that all distributions offering online updates via a packet manager do this with strong cryptographic signatures, so in theory your plan should be sound (save system compromise at the organization in charge of the update packages or some serious bug in a crypto library or packet manager). In practice: Do you really want to commit to _always_ installing every update not only without testing it first, but also whilst you may be asleep and unavailable to at least start solving any instant hickup? –  Jul 28 '14 at 14:02
  • @pyramids: Well I am at least considering it. The longer back-story is, that this is for a company I will "soon" be leaving, and I am not sure that they would apply any updates at all, after that point. So at least if something breaks through an automatic update, they will notice & try to fix it. Otherwise the machine will (most likely) be left without updates from that point on, which seems more dangerous to me - but this is an entirely different story ^^ - I am still looking for other possibilities though! But you have some really good points there (+1)!! – Levite Jul 28 '14 at 14:41
  • 2
    Debian/*Buntu/Mint: Aptitude/Apt-get would require confirmation before you install an unsigned packet, so the update manager would wait on you. Arch: Pacman would not allow unsigned packages and yaourt would require manual updates that indicate the packets are unsupported and you're doing things at your own risk. – Steve Dodier-Lazaro Jul 28 '14 at 15:14
  • Only apply security update repository automatically, which reduces the chance of defects. And why dont you schedule your manager to operate during business hours? This allows you to leave your employer with *reasonable* security and limited risk profiles if they dont have active patch management. You can also send your employer a official warning that these servers require active patch management, and without that they are likely to have stability and security issues, just to cover your liability. – Andrew Russell Jul 29 '14 at 08:34
  • @AndrewRussell: Many nice ideas thx! The official email will most likely be the best way to cover my liability. (Of course I would still like to know, that the system is kept safe as well.) Changing the update schedule is definately also a good thought! – Levite Jul 29 '14 at 09:30

4 Answers4

4

Yes it is possible to do a cache poisoning attack, and yes it is possible to protect yourself.

In addition to the rather standard practice of signing the package files with GPG, some distros use DNSSEC to protect the domains that serve those files against DNS spoofing.

Notice the 'ad' flag in the dns answer below:

$ dig +dnssec security.debian.org.

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> +dnssec security.debian.org.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 23375
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 9, AUTHORITY: 4, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 4096
;; QUESTION SECTION:
;security.debian.org.           IN      A

;; ANSWER SECTION:
security.debian.org.    300     IN      A       212.211.132.250
security.debian.org.    300     IN      A       128.31.0.36
security.debian.org.    300     IN      A       128.61.240.73
security.debian.org.    300     IN      A       128.101.240.212
security.debian.org.    300     IN      A       149.20.20.6
security.debian.org.    300     IN      A       195.20.242.89
security.debian.org.    300     IN      A       200.17.202.197
security.debian.org.    300     IN      A       212.211.132.32
security.debian.org.    300     IN      RRSIG   A 8 3 300 20140827233402 20140728233402 28626 security.debian.org. AF84GPGaVSMwLsTWP0vVJpW6E9r7PL1Pi/LTxGXPUt5x1AxeW8UKJ+wh OiB6tPy91sBRA5GfNofq+P3AhsWt2JGSR/iiN9qq6p6ryU6G5gQeZbYY MYVGDzf3j2z+kUMbsB902L/fPeJzLDxyaJzHPLU8alzs+4bvvKfd4SeA +MyGrckpFkr0Csi2LtRKGA5hJPrxFcHOFeWsY+n/mjAxy8g6SSdYrKVZ 3kk5G9sR1kKSiyHwxFVaIQXR0j1skl9/

;; AUTHORITY SECTION:
security.debian.org.    28800   IN      NS      geo1.debian.org.
security.debian.org.    28800   IN      NS      geo2.debian.org.
security.debian.org.    28800   IN      NS      geo3.debian.org.
security.debian.org.    28800   IN      RRSIG   NS 8 3 28800 20140827233402 20140728233402 28626 security.debian.org. TpTt53QAgOwwH38oqkfbm4F07j78VthQCzcHezN+N0+fPu0vXiatFMAI 1CBAFkYj/rkYNfv+xhM7OfvNgWMcRoMn9v7UOtMdxUOsjO2lQCVdjMsx TRz9OITY/NZWVD0/hkNXvpBVbsFW+y0JRzEb0xegHdGYHS1A9PVwRlCT 2DJLgkL6mS+RrOfteEDZD80HZZiiQcDLf1CgG6K2s5wNUIwsAzZdFEWC XnCXAguK3PVusvvnHz1i09B9qducyd+8

;; Query time: 2370 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Tue Jul 29 04:00:11 2014
;; MSG SIZE  rcvd: 719

By default, debian (and AFAIK most other distros) will require the GPG signature to match.

If you want to take advantage of the DNSSEC protection on the domains that serve the package files, run a validating caching nameserver locally, such as unbound or bind.

Joe Sniderman
  • 531
  • 4
  • 7
3

Short answer

  • Yes it is possible and aside from gpg-checking there are still several possible attacks!
  • To prevent getting a fake repo, I would make sure to use HTTPS for my repos, and run a validating caching nameserver locally (DNSSEC) like Joe Sniderman suggests (the only available measure against DNS spoofing I have seen so far)
  • But if the repository itself is compromised, the full list of attacks (see long answer) is still possible! (See the "How to protect yourself" part below, for suggestions as to how to try to prevent those)

Long answer

I found following paper which supplies a lot of information on the topic: Package Management Security Here is a short list of attacks from it. It mainly deals with yum and apt though.

Possible Attacks

  • Slow Retrieval - DoS: An attacker slows repository communication so that package managers will “hang” and will not error out or contact other repositories to retrieve package updates
  • Endless Data - DoS / Crash: A malicious repository (or MITM) returns an endless stream of data in response to any file request
  • Replay Old Metadata - Outdated Package: An attacker provides old metadata that is correctly signed, leading to possible installation of known defective historic version
  • Extraneous Dependency - Any Signed Package: An attacker changes the metadata for a package to indicate it depends on a package or packages of the attacker’s choice
  • Depends on Everything - DoS / Crash: An attacker changes the metadata for a package to indicate it depends on everything
  • Unsatisfiable Dependencies - DoS / Outdated Package: An attacker causes a package manager to ignore valid packages because forged meta-data indicates unsatisfiable dependencies
  • Provides Everything - Any Signed Package: An attacker changes the metadata for a package to indicate it provides any dependency the user requests
  • Use Revoked Keys - Arbitrary Package: An attacker uses a revoked key to get users to install packages
  • Escalation of Privilege - Arbitrary Package: An attacker compromises a key trusted for signing a specific group of packages and then gets users to accept signed malicious versions of other packages

I would like to add following attacks which simply deliver a malicious software package:

  • Chosen-prefix collision attack - Any Package (!): An attacker delivers a malicious package, which provides the same signature as the original package (extremely expensive to create; highly effective; has happened before, see Flame maleware or the comments to K-Yo's answer)

  • Stolen developer key - Any Package: The original developers key is used to sign a malicious package. (As SteveDL said, this might be easier to accomplish than a collision attack, has the same outcome, and has also happened before)

  • Stupid user - Any Package: Not really an attack, but if for example you allow unsigend packages to be installed, none of the attacks above are necessary. An attacker will be able to install pretty much anything on your system without too much effort.

There are a lot of interesting points in the article, starting with (usually) unsigned package metadata, attacks against the dependency resolver, MITM attacks when not using SSL connections for repos (which could have a similar outcome as a poisoned DNS cache), as well as detailed descriptions to the possible attacks listed above (Chapter 3.2).

I can't go through the every part of the paper, but following is a list of suggestions to secure APT / YUM:

How to protect yourself

There are several simple actions that will mitigate the effectiveness of many of the attacks:

  1. Validate repository communication. By checking that file sizes and data rates are reasonable, APT and YUM could limit the effectiveness of endless data and slow retrieval attacks.
  2. Track signature times. APT (and YUM if it adds metadata signing) should refuse to accept older versions of signed data. This would limit the effectiveness of the replay old metadata attack.
  3. Use HTTPS. HTTPS makes it more difficult for an attacker to launch any of the attacks because a man in the middle will have a harder time masquerading as the repository.
  4. Guard mirrors. Delegating control of a mirror for a distribution should be treated with utmost caution. This will help to prevent most of the attacks because it will be harder for an attacker to obtain the ability to impersonate the repository.
  5. Sign metadata and packages. Signing both metadata and packages makes it more difficult for an attacker to launch most types of attacks.
  6. Check metadata is correct. Once APT or YUM has decided to install a package, it should download the package and verify its signature and that the metadata matches the metadata provided by the repository. This will help to prevent the depends on everything attack and extraneous depends attacks when the attacker cannot correctly sign the package.

These measures will increase the difficulty in launching many types of attacks. However, within the architectures of APT and YUM there is no way to fix key revocation, escalation of privilege, provides everything, and unsatisfiable dependencies attacks. This means that the security architectures of APT and YUM are fundamentally inadequate to address these issues.

Please feel free to edit/enhance this post!

Levite
  • 819
  • 1
  • 6
  • 14
2

To answer your question, it is possible to spoof the update servers DNS; then, your packet manager should not install unsigned packets, an attacker could send you bad data, but you wouldn't accept it.

Most distributions use OpenPGP to sign their updates.

Fedora and Debian do for example.

You just have to make sure that your automated option validates updates against valid keys (which is the default behavior in most – if not all – cases).

K-Yo
  • 258
  • 1
  • 4
  • 2
    Very good point! To elaborate, there have been precedents of collision attacks on packet signing for Windows drivers, in the case of the [Flame malware](https://en.wikipedia.org/wiki/Flame_(malware)) but that's more elaborate than most adversaries can afford. It'd be simpler to steal a developer's key and sign malware with it (I seem to recall it's also how other APT malware get their malicious drivers signed). – Steve Dodier-Lazaro Jul 28 '14 at 15:13
  • ... I don't think any use PGP. GPG might make more sense. – pacifist Jul 29 '14 at 04:58
  • @SteveDL: Great reference to Flame concerning the **chosen-prefix collision attack**!! You are probably right that (right now) most attackers don't have the resources to implement something like this, but I am rather certain that we will be seeing more of it (don't know if towards linux systems though ^^). But a collision has to be found only once, to do several attacks with it (still amazing to me to find *one*). Or does the GPG signing used by the packet managers by far surpass windows driver signing, rendering an collision attack highly unlikely? – Levite Jul 29 '14 at 07:47
  • @K-Yo: I think (hate it when I have to start a sentence this way) the general behavior is, that the packet manager's update functions will refuse unsigned packets by default (at least when updating over the net). Unless of course you specify something like `--nogpgcheck` (e.g. for `yum`). But you are right, one should make sure! *Edit: Just saw that SteveDL posted about this in a comment to the question: for debian based systems, it requires user confirmation!* – Levite Jul 29 '14 at 08:17
  • 1
    @Levit I have no clue! I think most distros will be hit by something else than collision attacks though. Apple and Microsoft have orders of magnitude more resources into managing how much third-parties are entrusted with. On Linux it's just a matter of being willing to get things done, and it's unlikely the people who review and sign packages can verify the sources and package scripts in details every other month for tens of thousands of packages. – Steve Dodier-Lazaro Jul 29 '14 at 12:10
  • @pacifist: GPG is the implementation of OpenPGP made by the FSF. OpenPGP is the standard compatible with PGP but without the licencing issues PGP had. – K-Yo Jul 29 '14 at 14:12
  • @K-Yo: like it or not you originally stated PGP - the commercial product which didn't make sense in your answer and would probably add confusion to an unfamiliar reader's problems. Your edit to claim you meant OpenPGP-standard-compatible is barely an improvement. – pacifist Jul 30 '14 at 00:03
-1

It really depends on your threat model. If you are hosting some Wikileaks-grade document, that might be a very real threat. If it's just a casual server on the Internet, you'll just want to update as often as possible way before worrying about this kind of attack.

Dillinur
  • 468
  • 3
  • 7