web-dev-qa-db-ja.com

Sudoと.profile / .bashrcは簡単な権限昇格を可能にしますか？

まず、現在のLinuxデスクトップディストリビューション（Debian、Fedoraなど）によってセットアップされた構成を想定していることを述べておきます。実装した場合、ここで説明する問題を軽減する方法があると確信しています。私が興味を持っているのは、「すぐに使える」セキュリティです。

シェルが~/.profileや~/.bashrcのようなファイルを実行するという事実は、ユーザーの実行環境の完全な操作を可能にし、ユーザーが所有するため、Sudoは安全に実行できます。問題は、ユーザーとして実行されている悪意のあるプログラムがこれらのファイルを編集して、たとえばPATH環境変数を変更して、PATH="$HOME/.evil:$PATH"などの偽のSudo実行可能ファイルを含めることができることです。悪意のあるプログラムも$HOME/.evil/Sudoファイルを作成しました。次に、ユーザーが次にシェルでSudoと入力すると、代わりに偽のSudoが実行され、入力したパスワードを記録できます。したがって、偽のSudoは、元の悪意のあるプログラムがユーザー特権しか持っていなくても、root特権を取得できます。

実際、Ubuntuのインストールによって作成されたデフォルトの.profileファイルには、次の行が含まれています。

# set PATH so it includes user's private bin if it exists
if [ -d "$HOME/bin" ] ; then
    PATH="$HOME/bin:$PATH"
fi

そのため、.profileを変更する必要さえありません。$HOME/bin/Sudoを作成するだけで、PATHが最初になります。

私の要点は、任意の悪意のあるコードが実行された時点ではすでに「遅すぎる」ことではなく、この攻撃はユーザーに気付かれる可能性があるということではありません（フィッシング攻撃に似ていると思います）。ユーザーとして実行されている悪意のあるプログラムは、ユーザーができることなら何でもできると思います。しかし、私が期待できないのは、そのユーザーよりもmoreができることです（root特権）。

私の質問は、本質的には：

  1. システムSudo実行可能ファイルがこの方法で回避できるというのは本当ですか？
  2. デフォルトで、デスクトップLinuxシステムがデフォルトで、このように簡単に利用できる方法でセットアップされているのはなぜですか？ Sudoを呼び出すデフォルトの方法は、それが実際にシステムによって提供される実行可能ファイルであることを確認してはなりません（毎回/usr/bin/Sudoを入力する予定はありません）。 Sudoはシステムクリティカルなセキュリティ操作を実行するので、PATH変数を使用してその場所をシャドウする可能性は、大きな利益をもたらすことなく多くのリスクをもたらすようです。このような環境では、Sudoの使用は基本的に安全ではないようです。rootとしてのログインを有効にし、別のTTYにログインすることをお勧めします。
linuxprivilege-escalationbashsudopath-injection
6
Socob

侵害されたアカウントで実行できることはすべて、攻撃者も実行できます。

基本的に、これはLinuxプロバイダーがユーザー間で分離しているためです同じユーザーとして実行している個々のプロセス間ではありません。特定のユーザーとして実行されているプロセスは、そのユーザーの下で実行されている他のプロセスと同等の機能を持つと見なされます。

システムのSudo実行可能ファイルをこの方法で回避できるのは本当ですか？

はい、他の方法でも同様です。侵害された非特権アカウントでrootに特権を昇格すると、rootが侵害されます。 suを使用してrootから特権を非特権アカウントに落とすと、 ルートも侵害 ！信頼されていないアカウントの特権を安全に昇格することはできません。 PATHを使用してシステムを悪用することは可能ですが、bashプロセス自体をハイジャックしてキー入力を盗聴することも可能です。インタープリター（bash、python、Perlなど）は引き続き実行されるため、noexecを使用して実行を無効にすることはさらに役に立ちません。 noexecオプションは、定期的に販売されているにもかかわらず、セキュリティ機能として設計されたことはありません。

攻撃者がSudoまたはsuをハイジャックする方法の不完全なリスト：

  • 親プロセスでの_LD_PRELOAD_変数の使用（例：bash）。

  • 親プロセスをptrace()またはprocess_vm_writev()でフックします。

  • X11プロトコルを使用して、端末エミュレータにキーストロークをスニッフィングまたは挿入します。

  • 実際のSudo実行可能ファイルをラップするエイリアスまたは関数を作成します。

私はこれらについて 別の質問に対する私の回答 で詳しく説明しました。

デフォルトで、デスクトップLinuxシステムがデフォルトで、このように簡単に利用できる方法でセットアップされているのはなぜですか？

信頼されていないアカウントの特権の昇格は、想定されていることではありません。言うまでもなく、デスクトップLinuxは、一般的な* nixアーキテクチャのグランドスキームにおける後付けです。これは、Linux自体のセキュリティアーキテクチャの障害ではなく、同じ悪いアドバイスを絶え間なく繰り返すセキュリティシアターの障害です。多くの新規ユーザーが代わりにすべてをrootとして実行するため、rootとしてSudoを使用することを繰り返し言われます。この場合、Sudoを使用することをお勧めします。ユーザーがすでにすべてにrootを使用しないほど賢い場合、それは有害です。

Sudoは高度に構成可能であり、特定のコマンドのみを許可するように設計できることに注意してください。これは本当に素晴らしいところです。 Sudoを設定して、_apt-get update_をrootとして（パスワードの有無にかかわらず）実行することのみを許可し、その他すべてを拒否することができます。これにより、攻撃者はソフトウェアの更新以外の操作を制限できます。

ルートとして特定のコマンドの実行のみを許可するように構成した場合でも、信頼されていないユーザーを介してルートとして実行するように設計されていないプログラムをホワイトリストに登録すると、足を踏みにじることができることに注意してください。私はこの方法でVeraCryptを実行しようとしている誰かの実際の例を見ました それが安全でない理由を説明した 。 VeraCryptはrootとして安全に実行できるという考えでした。そのため、Sudoを使用して、信頼されていない特権のないユーザーとしてrootに昇格しても安全です。アイデアには欠陥があり、些細な特権の昇格が可能であることがわかりました！

Sudoを起動するデフォルトの方法は、それが実際にシステムによって提供される実行可能ファイルであることを確認するべきではありませんか（毎回/ usr/bin/Sudoと入力する予定はありません）？

完全なパスを入力しても保護されません！先頭の_/_を含む関数を簡単に作成でき、実際の実行可能ファイルをオーバーライドします。実行可能ファイルが本物であることを確認し、スニッフィングを無効にしようとした場合でも、悪意のあるプロセスがbashプロセスをハイジャックし、Sudoとは無関係にキーストロークをスニッフィングし、そのポイントから検出することができなくなります。ビューの。

 $ function/usr/bin/Sudo {echo 'hijacked！'; } 
 $/usr/bin/Sudo id 
 hijacked！

このような環境では、Sudoの使用は基本的に安全ではないようです。rootとしてログインを有効にし、別のTTYにログインすることをお勧めします。

これは常にの場合です。別のTTYにログインしても、完全に安全ではないことに注意してください。セキュアアテンションキーの組み合わせである [〜＃〜] sak [〜＃〜] を使用して、本物のログインセッション（agettyまたはlogindなど）。 SAKは、カーネルがリッスンする（したがって、ユーザー空間で抑制できない）キーの組み合わせです。検出すると、現在のTTY内のすべてのプロセスが強制終了され、ログインプロンプトが表示されます。正規の妥協のないTTYに切り替えた場合は、プロンプトが消えて再表示されるだけです。ハイジャックされたTTYを使用している場合、悪意のあるプロセスが強制終了され、正規のログインプロンプトが表示されます。

5
forest

まず、_.profile_を変更しても、特権の昇格は自動的には行われません。影響を受けるユーザーは、すでにSudo権限を持っている必要があります。

1-Sudoは回避されていません。あなたはそれの代わりに何か他のものを走らせています。 _.profile_を変更して_alias Sudo=~/.evilsudo_を追加し、同じことを実現できます。

2-Sudoを構成する遅延方法について考えます。デスクトップ環境ではそうなりますが、サーバー環境ではそうではありません。サーバー環境では、_/etc/sudoers_は、ユーザーにタスクを実行するために実行する必要があるコマンドのみを許可する必要があります。 Oracle管理者は_Sudo service Oracle_を実行することを期待しているため、sudoersで実行されます。たとえば、oradmin ALL=(ALL:ALL) ALLではありません。

そして、誰かがあなたのアカウントでコードを実行するのはすでに遅すぎます。 .profileを変更すると、別のシェルが起動してすべてのキー入力をキャプチャし、パスワードだけでなく、入力した他のすべてを失う可能性があります。リモートsshパスワード、データベースパスワード、ftpパスワードなど。 .profileが侵害された場合、それはゲームオーバーです。

これからユーザーを本当に保護したい場合は、ユーザーが書き込み可能なすべてのディレクトリをnoexecとしてマウントします。このようにして、_~/bin_または_/tmp_などは、何かを実行する権限を持ちません。セキュリティをわずかに高め、利便性を大幅に低下させます。

0
ThoriumBR