web-dev-qa-db-ja.com

LinuxディストリビューションリポジトリのDNSスプーフィング

質問

悪意のあるWebサイトに "redirect" linux-update-repos via DNS spoofing（例：DNSキャッシュポイズニング）を実行して、有害なソフトウェア（アップデート）をインストールすることは可能ですか？ 、パケットマネージャーの更新関数（yum、apt-getなど）を実行する場合

それとも、それらのリポジトリは証明書やSSLなどで非常によく保護されているので、それは完全に非現実的ですか？

さらに、可能であれば、そのようなことから身を守る方法はありますか？

バックグラウンド

Webサーバーの自動更新をセットアップすることを検討していましたが、（これにより発生する可能性のある他の問題のほかに）攻撃者がかなり長い時間枠を持っているため、それが良い考えかどうかわかりませんでした。たとえば、午前4時から朝まで、たとえばyum-cronのデフォルト設定の場合。

linuxwebserverdnsdns-spoofingupdates
7
Levite

はい、キャッシュポイズニング攻撃を行うことは可能です。また、はい、あなた自身を保護することは可能です。

GPGでパッケージファイルに署名するというかなり標準的な方法に加えて、一部のディストリビューションはDNSSECを使用して、それらのファイルを提供するドメインをDNSスプーフィングから保護します。

以下のDNS回答の「ad」フラグに注意してください。

$ 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

デフォルトでは、debian（およびAFAIKの他のほとんどのディストリビューション）は 必要とする 一致するGPG署名。

パッケージファイルを提供するドメインでDNSSEC保護を利用したい場合は、バインド解除やバインドなどの検証キャッシングネームサーバーをローカルで実行します。

4
Joe Sniderman

短い答え

  • はいそれは可能であり、gpg-checkingを除けば、まだいくつかの攻撃の可能性があります！
  • 偽のレポの取得を防ぐために、[〜＃〜] https [〜＃〜 ]リポジトリ用に、ローカルで検証キャッシングネームサーバーを実行します（[〜＃〜] dnssec [〜＃〜]）Joe Snidermanが示唆するように（これまでに見たDNSスプーフィングに対する唯一可能な対策）
  • しかし、リポジトリ自体が危険にさらされている場合でも、攻撃の完全なリスト（長い回答を参照）は引き続き可能です。 （それらを防止する方法についての提案については、以下の「身を守る方法」の部分を参照してください）

長い答え

このトピックに関する多くの情報を提供する次のペーパーを見つけました： Package Management Security ここからの攻撃の短いリストを示します。主にyumとaptを扱います。

可能な攻撃

  • 遅い取得-DoS：攻撃者はリポジトリ通信を遅くして、パッケージマネージャーが「ハング」して、エラーになったり、パッケージの更新を取得するために他のリポジトリに連絡したりしない
  • Endless Data-DoS/Crash：悪意のあるリポジトリ（またはMITM）が無限のデータストリームを返すファイル要求に応じて
  • 古いメタデータを再生-古いパッケージ：攻撃者が正しく署名された古いメタデータを提供し、可能性につながる既知の欠陥のある履歴バージョンのインストール
  • Extraneous Dependency-Any Signed Package：攻撃者はパッケージのメタデータを変更して、依存していることを示します攻撃者が選択した1つまたは複数のパッケージ
  • すべてに依存-DoS /クラッシュ：攻撃者がパッケージのメタデータを変更して、依存していることを示しますすべてに
  • 不満足な依存関係-DoS /古いパッケージ：攻撃者は、偽造されたためにパッケージマネージャーに有効なパッケージを無視させますメタデータは満足できない依存関係を示します
  • すべてを提供します-任意の署名されたパッケージ：攻撃者はパッケージのメタデータを変更して、すべてを提供することを示しますユーザーが要求する依存関係
  • 失効したキーを使用する-任意のパッケージ：攻撃者は、失効したキーを使用して、ユーザーにパッケージをインストールさせます
  • 特権の昇格-任意のパッケージ：攻撃者は、特定のパッケージグループに署名するために信頼されたキーを侵害しますそして、ユーザーに他のパッケージの署名された悪意のあるバージョンを受け入れるようにします

悪意のあるソフトウェアパッケージを単に配信する次の攻撃を追加したいと思います。

  • Chosen-prefix衝突攻撃-すべてのパッケージ（！）：攻撃者は悪意のあるパッケージを配信し、元のパッケージと同じ署名を提供します（作成に非常に費用がかかります;非常に効果的です;以前に発生しました。 Flame maleware を参照）またはK-Yoの答えへのコメント）

  • 盗まれた開発者キー-Any Package：元の開発者キーは悪意のあるパッケージに署名するために使用されます。 （SteveDLが言ったように、これは衝突攻撃よりも簡単に達成でき、同じ結果があり、以前にも発生しました）

  • 愚かなユーザー-任意のパッケージ：実際には攻撃ではありませんが、たとえば、非固有のパッケージにインストールされている場合、上記の攻撃は必要ありません。攻撃者は、余計な手間をかけることなく、システムにほとんど何でもインストールすることができます。

この記事には、（通常は）署名されていないパッケージメタデータ、依存関係リゾルバーに対する攻撃、リポジトリにSSL接続を使用していない場合のMITM攻撃（ポイズニングされたDNSキャッシュと同様の結果になる可能性があります）など、興味深い点がたくさんあります。上記の可能性のある攻撃の詳細な説明（3.2章）。

論文のすべての部分を説明することはできませんが、以下は、セキュリティを確保するための提案のリストですAPT/YUM：

自分を守る方法

多くの攻撃の有効性を軽減するいくつかの単純なアクションがあります。

  1. リポジトリ通信を検証します。 APTおよびYUMは、ファイルサイズとデータレートが妥当であることを確認することにより、無限のデータと低速の検索攻撃の効果を制限する可能性があります。
  2. 追跡署名時間。 APT（およびメタデータ署名を追加する場合はYUM）は、古いバージョンの署名済みデータの受け入れを拒否する必要があります。これにより、古いメタデータのリプレイ攻撃の効果が制限されます。
  3. HTTPSを使用します。 HTTPSを使用すると、中間にいる男性がリポジトリを装うのが難しくなるため、攻撃者が攻撃を開始することが困難になります。
  4. ガードミラー。ディストリビューションに対するミラーの制御の委任は、細心の注意を払って処理する必要があります。これにより、攻撃者がリポジトリを偽装する機能を取得することが困難になるため、ほとんどの攻撃を防ぐことができます。
  5. メタデータとパッケージに署名します。メタデータとパッケージの両方に署名すると、攻撃者がほとんどのタイプの攻撃を開始することが困難になります。
  6. メタデータが正しいことを確認してください。 APTまたはYUMがパッケージのインストールを決定すると、パッケージをダウンロードしてその署名を検証し、メタデータがリポジトリによって提供されたメタデータと一致することを確認する必要があります。これにより、攻撃者は、攻撃者がパッケージに正しく署名できない場合の攻撃に依存します。

これらの対策は、多くのタイプの攻撃を開始することの困難さを増加させます。ただし、APTおよびYUMのアーキテクチャ内では、key revocation、escalation of privilege、はすべてを提供します、不満足な依存関係攻撃。これは、APTとYUMは基本的にこれらの問題に対処するには不十分です。

この投稿を自由に編集/強化してください！

3
Levite

あなたの質問に答えるために、更新サーバーのDNSを偽装することが可能です。次に、パケットマネージャは署名のないパケットをインストールするべきではありません。攻撃者が不正なデータを送信する可能性がありますが、それを受け入れることはできません。

ほとんどのディストリビューションは、更新に署名するために OpenPGP を使用します。

Fedora と Debian は、例えばそうします。

自動化されたオプションが有効なキーに対して更新を検証することを確認する必要があります（すべてではないにしても、ほとんどの場合のデフォルトの動作です）。

2
K-Yo