web-dev-qa-db-ja.com

サーバーがShellshock bashバグに対して安全かどうかをテストする短いコマンドはありますか？

やった apt-get update; apt-get upgrade -y実行しているすべてのシステムで。私の/etc/apt/sources.listは、これらすべてのシステムで十分です。理想的には1行のシェルコマンドを使用して、各システムをもう一度すばやく確認したいと思います。

このような1行のシェルコマンドは存在しますか？存在する場合、それは何ですか？

この質問は主にCVE-2014-6271に関するものです。

shellshockbash
76
kqw

私のbashは脆弱ですか？

この単純なコマンドは、bashのバージョンが脆弱かどうかを確認するのに十分なテストです。

_x='() { :;}; echo VULNERABLE' bash -c :
_

パッチを適用したバージョンのbashは、開始環境の変数にパッチを適用した脆弱性の悪用コードが含まれている場合に警告を報告するため、コマンドが実際に実行されたことを示すために追加のテキストを印刷する必要はありません。

脆弱なシステム：

_$ x='() { :;}; echo VULNERABLE' bash -c :
VULNERABLE
_

パッチが適用されたシステム：

_$ x='() { :;}; echo VULNERABLE' bash -c :
bash: warning: x: ignoring function definition attempt
bash: error importing function definition for `x'
_

これが何をテストし、何をテストしないか、およびその理由の詳細な説明については、以下の「その他の関数解析のバグ」を参照してください。

私のシステムは脆弱ですか？

Bashに脆弱性がなければ、システムに脆弱性はありません。

Bashが脆弱である場合、CGIスクリプト、DHCPクライアント、制限されたSSHアカウントなどの攻撃ベクトルに沿ってbashを使用しているため、システムは脆弱です。 _/bin/sh_がbashか他のシェルかを確認します。この脆弱性はbash固有の機能にあり、ダッシュやkshなどの他のシェルは影響を受けません。 shの代わりにbashを使用して上記と同じテストを実行することにより、デフォルトのシェルをテストできます。

_x='() { :;}; echo VULNERABLE' sh -c :
_
  • エラーメッセージが表示された場合、システムにはパッチが適用されたbashがあり、脆弱性はありません。
  • VULNERABLEが表示された場合、システムのデフォルトのシェルはbashであり、すべての攻撃経路が問題になります。
  • 出力が表示されない場合、システムのデフォルトのシェルはbashではなく、bashを使用するシステムの一部のみが脆弱です。確認する：
    • CGIから、またはDHCPクライアントがbash（_#!/bin/bash_ではなく_#!/bin/sh_で始まる）によって実行されるスクリプト。
    • シェルがbashである制限付きSSHアカウント。

このテストのしくみ

コマンド_bash -c :_をリテラルテキスト_() { :;}; echo VULNERABLE_を環境変数xの値として設定して実行します。

  • _:_ビルトインはアクションを実行しません ;ここでは、空でないコマンドが必要な場合に使用されます。

  • _bash -c :_は、_:_を実行して終了するbashのインスタンスを作成します。

    これでも、脆弱性をトリガーするのに十分です。 bashが1つのコマンドのみを実行するために呼び出されている（そのコマンドは何もしない）場合でも、bashはその環境を読み取り、内容が_() {_で始まる各変数を関数（少なくとも名前が有効な関数名）を実行し、関数を定義します。

    このbashの動作の背後にある意図は、関数定義のみを実行することです。これにより、関数を使用できるようになりますが、実際にはその内部のコードは実行されません。

  • _() { :;}_は、呼び出されてもアクションを実行しない関数の定義です。 _{_が個別のトークンとして解析されるように、_{_の後にスペースが必要です。正しい構文として受け入れられるようにするには、_;_の前に_}_または newline が必要です。

    Bashでシェル関数を定義する構文の詳細については、 Bashリファレンスマニュアル の .3シェル関数 を参照してください。ただし、bashによって使用される（および認識される）構文は、定義が実行される有効なエクスポートされたシェル関数としてより制限されていることに注意してください。

    1. 正確な文字列_() {_で始まり、_)_と_{_の間に1つのスペースが必要です。
    2. また、シェル関数の複合ステートメントが_( )_ではなく_{ }_で囲まれていることもありますが、それらは_{ }_構文内でエクスポートされます。内容が_() (_ではなく_() {_で始まる変数は、脆弱性のテストやトリガーを行いません。

  • bashshould終了後、コードの実行を停止_}_。しかし、（パッチが適用されない限り）そうではありません！ これは、CVE-2014-6271（「シェルショック」）を構成する誤った動作です。

    _;_は、関数を定義するステートメントを終了し、後続のテキストを読み取って別のコマンドとして実行できるようにします。また、_;_の後のテキストは、別の関数定義である必要はありません。何でもかまいません。

  • このテストでは、_;_の後のコマンドは_echo VULNERABLE_です。 echoの前の先行スペースは何もせず、単に読みやすくするために存在しています。 echoコマンドは、テキストを 標準出力 に書き込みます。 echoの完全な動作は実際には多少複雑ですが、ここでは重要ではありません。_echo VULNERABLE_は単純です。テキストVULNERABLEが表示されます。

    _echo VULNERABLE_は、bashがパッチされておらず、環境変数の関数定義の後にコードを実行している場合にのみ実行されるため、これ（およびそれに類似する他の多くのテスト）は、インストールされているbashがCVE-2014-6271に対して脆弱です。

その他の関数解析のバグ（そしてなぜそのテストとそのようなものはそれらをチェックしないのか）

これを書いている時点でリリースされているパッチと、脆弱性をチェックするために上記で説明および説明されているコマンドは、CVE-2014-6271と呼ばれる非常に深刻なバグに適用されます。このパッチも、脆弱性をチェックするための上記のコマンドも、関連するバグCVE-2014-7169には適用されません（まだ発見または開示されていない可能性のある他のバグに適用されるとは想定されていません）。

バグ CVE-2014-6271 は、2つの問題の組み合わせから発生しました。

  1. bashは、およびの任意の環境変数で関数定義を受け入れます
  2. その間、bashは、関数定義の右中括弧（_}_）の後に存在するコードの実行を継続します。

これを書いている時点で、リリースされている（そして多くのダウンストリームベンダーによって公開されている）CVE-2014-6271の既存の修正、つまり、システムを更新するか、既存のパッチを手動で適用することで得られる修正です。 -は2の修正です。

しかし、bashのコードにotherミスがある場合、-1は多くの追加のソースになる可能性がありますバグの解析。そして、私たちは知っています少なくとも1つの他のそのようなバグが存在します-具体的には CVE-2014-7169 。

この回答に示されているコマンドは、インストールされているbashにCVE-2014-6271の既存の（つまり、最初の公式の）修正がパッチされているかどうかをテストします。 その特定の解析バグ に対する脆弱性をテストします：「GNU Bash 4.3までは、環境変数の値の関数定義の後に続く文字列を処理します[...]」

その特定のバグは非常に深刻であり、利用可能なパッチはそれを修正しますが、CVE-2014-7169はそれほど深刻ではないように見えますが、依然として懸念の原因です。

StéphaneChazelas （ Shellshockバグの発見者 ）が 最近説明された ---の回答に Shellshockはいつだったか（CVE-2014 -6271）バグが導入されました。それを完全に修正するパッチは何ですか？ on nix.SE ：

bashがそこにある関数定義以外を解釈しないようにするパッチがあります（ https://lists.gnu.org/archive/html/bug-bash/2014-09/msg00081 .html ）、そしてそれはさまざまなLinuxディストリビューションからのすべてのセキュリティアップデートに適用されたものです。

ただし、bashはそこにあるコードを引き続き解釈するため、インタープリターのバグが悪用される可能性があります。そのようなバグの1つ すでに検出されています （CVE-2014-7169）ですが、その影響ははるかに小さくなっています。そのため、近日中に別のパッチが提供される予定です。

しかし、それが悪用のように見える場合...

何人かの人々は、ここや他の場所で、なぜx='() { :;}; echo VULNERABLE' bash -c :印刷VULNERABLE（または類似の）が警告と見なされるべきかを尋ねてきました。そして最近私は誤解が広まっているのを見てきましたその特定のコマンドを入力してEnterを押すには対話型のシェルアクセスがすでに必要なので、Shellshockはどういうわけか深刻な脆弱性ではないはずです。

私が聞いた感情の一部は、慌てる必要はないことを表明しましたが、NATルーターの背後にあるデスクトップユーザーは、ソースコードからbashを構築するために生活を保留にすべきではありません- -非常に正確で混乱しやすい脆弱性自体特定のコマンドを実行してテストする機能（ここに示すコマンドなど）は深刻な間違いです。

この投稿で与えられたコマンドは、「サーバーがShellshock bashバグに対して安全かどうかをテストするための短いコマンドはありますか？」という質問への回答です。それはではありません「実際の攻撃者が私に使用したShellshockはどのように見えるのですか？」そしてこれは「このバグを悪用するために誰かが何をしなければならないか？」という質問への回答ではありません]（そしてそれはまたではありません「個人的にリスクが高い場合、すべての技術的および社会的要因から推測する簡単なコマンドはありますか？」

このコマンドはテストであり、bashが特定の方法で任意の環境変数で記述されたコードを実行するかどうかを確認します。 Shellshockの脆弱性はx='() { :;}; echo VULNERABLE' bash -c :ではありません。代わりに、そのコマンド（およびその他のコマンド）はdiagnosticであり、Shellshockの影響を受けているかどうかを判断するのに役立ちます。

  • Shellshockは、リモートからアクセス可能なネットワークサーバーを実行していないデスクトップユーザーのリスクがほぼ確実に低くなるものの、幅広い結果をもたらします。 （現時点では、私たちが知らないと思うことはどれほど少ないかです。）
  • 対照的に、thecommandx='() { :;}; echo VULNERABLE' bash -c :は、Shellshock（特にCVE-のテスト）に役立つ場合を除いて、まったく重要ではありません。 2014-6271）。

興味のある方のために、なぜこのバグが深刻であると考えられるのか、そして特にネットワークサーバー上の環境変数に、バグを悪用して害を及ぼす可能性のある信頼できないデータが含まれているのかについての情報を含むリソースをいくつか示します。

ここで概念的な違いをさらに説明するために、2つの仮説を考えます。

  1. テストとしてx='() { :;}; echo VULNERABLE' bash -c :を提案する代わりに、テストとして_bash --version_を提案したと想像してください。 （OSベンダーはしばしばセキュリティパッチを古いバージョンのソフトウェアにバックポートするため、これは実際には特に適切ではありません。プログラムが提供するバージョン情報は、一部のシステムでは、実際に脆弱であると思われるプログラムに見えるようにすることができますパッチを適用しました。）

    _bash --version_を実行してテストすることが提案されていたとしても、「攻撃者は自分のコンピューターの前に座って_bash --version_と入力することはできないので、大丈夫です！」これは、テストとテスト対象の問題の違いです。

  2. エアバッグの故障や衝突による炎上爆発など、車に安全上の問題がある可能性があり、工場でのデモがストリーミングされていることを示唆するアドバイザリが発行された場合を想像してみてください。 「しかし、私が誤って車を900マイルも工場まで運転したり牽引したりして、高価なクラッシュダミーを積み込んでコンクリートの壁にぶつけたことはありません。だから私は元気でいる必要があります。」これは、テストとテスト対象の問題の違いです。

123
Eliah Kagan

多くのシステムではBashとなるデフォルトのシェルで次の行を実行して、脆弱かどうかを確認できます。 「busted」という単語が表示された場合は、危険にさらされています。 2番目のコマンドのみが「無効」と出力する場合、bashは脆弱ですが、この脆弱性は、デフォルトのシェル（sh）を実行する部分ではなく、bashを明示的に呼び出すシステムの部分にのみ影響します。どちらのコマンドも「無効」と表示されない場合は、システムにパッチが適用されています。

env X="() { :;} ; echo busted" /bin/sh -c "echo completed"
env X="() { :;} ; echo busted" bash -c "echo completed"

ソース

パッチを適用しても、システムはまだ脆弱である可能性があります。

env X='() { (a)=>\' bash -c "echo echo vuln"; [[ "$(cat echo)" == "vuln" ]] && echo "still vulnerable :("

ソース および 別のソース

12
BadSkillz

同じサブネット上にある複数のサーバーを一度に確認する方法が必要な場合は、Masscanを使用してすべてのサーバーにリクエストを送信できます。 https://github.com/robertdavidgraham/masscan

設定ファイルの例は http://blog.erratasec.com/2014/09/bash-Shellshock-scan-of-internet.html にあります：

target = 0.0.0.0/0 //CHANGE THIS TO THE PROPER SUBNET
port = 80
banners = true
http-user-agent = Shellshock-scan (http://blog.erratasec.com/2014/09/bash-Shellshock-scan-of-internet.html)
http-header[Cookie] = () { :; }; ping -c 3 209.126.230.74
http-header[Host] = () { :; }; ping -c 3 209.126.230.74
http-header[Referer] = () { :; }; ping -c 3 209.126.230.74
//change the above 3 Ip addresses to the IP of the machine you send it from.

脆弱なマシンは、pingを送り返します。著者によるフォローアップのブログ投稿によると、いくつかの構成が必要になる可能性があります。

11
Nzall

次のようにCGIスクリプトをチェックできるCLIユーティリティである ShellShocker を試すことができます。

python shellshocker.py http://example.com/cgi-bin/possibly-vulnerable-cgi.cgi
0
Liam Marshall

次のオンラインテストにCGI URLを送信するサーバーを確認できます。

http://Shellshock.iecra.org

0
Roger

「脆弱」または「脆弱ではない」のいずれかを出力する簡単なテストを作成しました。

env x='() { :;}; echo vulnerable; exit;' bash -c 'echo not vulnerable' 2>/dev/null

また、bashのバージョンが脆弱である場合、スクリプトの一部として使用する場合は、終了コード2で戻ります。

0
colevk