Remember Heartbleed? 今日の誇大広告を信じるなら、Shellshock はそのレベルにあり、クールなロゴはないものの、同様に素晴らしい名前を持っています (これらの脆弱性のマーケティング部門の誰かがそれに取り組む必要があります)。 しかし、真面目な話、これは大問題になる可能性があり、Heartbleed で行ったように、私がこの状況を把握するため、そして他の人が誇大広告を真の根本的リスクから切り離すために、決定的な何かをまとめたいと思いました。
target = 0.0.0.0/0port = 80banners = truehttp-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.74http-header = Host:() { :; }; ping -c 3 209.126.230.74http-header = Referer:() { :; }; ping -c 3 209.126.230.74
この HTTP リクエストを脆弱な IP アドレスの範囲に対して発行すると、次のような結果になります。 本当に心配なのは、彼が効果的にこれらのマシンに任意のコマンドを発行させたことであり (かなり良質の ping であるにもかかわらず)、非常に深刻な可能性の全世界を開くことになります。
Bash とは何か、なぜそれが必要なのか。
古いニュースであれば読み飛ばしてください。 Bash は *nix シェル、言い換えれば、Unix や Linux システム上でコマンドを実行するためのインタープリターです。 また、ApacheのようなWebサーバ上のCGIスクリプトのパーサーとしても動作します。 80年代後半から存在し、以前のシェル実装から発展し（名前はボーンシェルに由来）、非常に人気があります。 Unix系には他のシェルもありますが、BashはLinuxとMac OS Xのデフォルトシェルであり、非常に普及しているオペレーティングシステムであることは明らかです。 Bash は「あらゆる Linux システムに最もインストールされているユーティリティの 1 つ」として説明されています。
Netcraft の最新の Web サーバー統計を見てみると、Bash のフットプリントの感覚がわかります。 同じ Netcraft の記事では、私たちはちょうど 10 億の Web サイトを超えたところであり、それらの多くが同じホストを共有している一方で、これはまだ全体の多くの Bash インストールであると報告しています。 これは Web サーバーだけであり、Linux を実行している他の多くのサーバーがあることを忘れてはいけません。 当然ながら、これは世界に公開されることを意図した機能ではなく、理論的には、認証されたユーザーが実行することを許可されたコマンドを実行することについて話しています。 理論的には、
バグは何か？
NIST 脆弱性データベースからの CVE から始めましょう。OpenSSH sshd の ForceCommand 機能、Apache HTTP Server の mod_cgi および mod_cgid モジュール、不特定の DHCP クライアントが実行するスクリプト、および Bash 実行から権限境界を越えて環境設定が行われるその他の状況に関連するベクターによって示されるように、リモート攻撃者が細工した環境を介して任意のコードを実行できるようになります。
They は、深刻度について「10 段階中 10」、言い換えれば「最悪」であると評価しています。 これは、攻撃を実行するのが簡単であること (アクセスの複雑さは低い)、そしておそらく最も重要なことは、CGI スクリプト経由で Bash を悪用する際に認証が不要であることです。 上記の要約は少し複雑なので、バグの仕組みに絞って説明します。
リスクの中心は、関数定義を指定する環境変数を Bash シェル内で任意に定義する機能です。 問題は、Bash が関数定義の後にシェル コマンドを処理し続けると、「コード インジェクション攻撃」として分類されるものが発生することです。 Robert の例をもう一度見て、この行を取り上げます。 これがBashシェルのコンテキスト内で処理されると、任意のコマンドが実行されます。 Webの文脈では、これはCGIスクリプトのようなメカニズムを経由することを意味し、必ずしもリクエストヘッダとして実行されるとは限りません。 seclists.org の勧告では、パスとクエリ文字列が潜在的な攻撃ベクトルである可能性があることを含め、より詳細に説明されているので、一読する価値があります。 しかし、多くの場合、それは深刻な破壊的変更となり、少なくとも、多くの場合、Web サイトですぐに問題が発生しないことを確認するために、いくつかの広範なテストを必要とすることになります。 Telnet や SSH、そして明らかに DHCP も含めると、範囲が劇的に広がるので、決してここで Web アプリケーション サーバーの悪用についてだけ話しているのではありません。 (明らかに、リスクは認証後の SSH にのみ存在しますが、公開の初期段階では、必然的に他の攻撃ベクトルがまだ現れるでしょう。)
また、潜在的な被害の範囲は、ロバートの例のように任意のアドレスへの ping をはるかに超えて広がるということを覚えておく必要があります。 問題はここからです。 攻撃者が脆弱なマシン上で好きなシェル コマンドを実行できる場合、どのような損害を与えることができるでしょうか。
どのような影響が考えられるでしょうか。
その可能性は非常に大きく、ターゲット環境を制御できるため、攻撃者にとって「シェル取得」は常に大きな勝利となります。 内部データへのアクセス、環境の再構成、独自の悪質なコードの公開など。 ほぼ無限の可能性があり、また容易に自動化することができます。
残念ながら、インターネット上の最大半分の Web サイトでシェルによる任意のコード実行となると、その可能性はかなり広くなります。 明らかな (そして特に厄介な) ものの 1 つは、一般に取得できるように内部ファイルをダンプすることです。 パスワード ファイルやクレデンシャルを含む設定ファイルは明白なものですが、考えられるのは、システム上の他のすべてのファイルに拡張できることです。
同様に、同じアプローチをシステムへのファイルの書き込みに適用することも可能です。 これは、マルウェアを配布する非常に簡単な方法であることは言うまでもありませんが、これまで見た中で最も簡単な Web サイト改ざんのベクトルである可能性があります
あるいは、次のように考えてはいかがでしょうか。 たとえば、Samy の MySpace XSS ワームでは、慎重に作成された JavaScript が、1 日も経たないうちに 100 万人の犠牲者のページを「感染」させるという、非常に効果的な実装が見られました。 理論的には、感染したマシンが他のターゲットをスキャンし、そのターゲットに攻撃を伝播させるという形を取ることができます。 これは、決して一般に公開されているマシンに限ったことではなく、企業のファイアウォールの背後にあるため、限界に近いものがあります。 これは、パッチを当てるために奔走する人々と攻撃するために奔走する人々の間の軍拡競争が過熱しているため、初期の段階から非常に興味深いものとなっています。
Bash のどのバージョンが影響を受けるのか
見出しでは 4.3 まで、言い換えれば約 25 年分の Bash バージョンすべてが記載されています。 誰もがこれを Heartbleed と比較し続けることを考えると、影響を受ける OpenSSL のバージョンはわずか 2 年間であり、Shellshock に比べれば大海の一滴にすぎないと考えてください。 人々はバージョンをアップグレードしますが、一貫してそれを行うわけではありませんし、いずれにせよ、危険にさらされるマシンの幅は、Heartbleed のときよりも Shellshock のほうがはるかに大きくなるでしょう。 すでに、パッチが完全に有効でないという報告を目にしていますが、パッチの展開速度を考えると、それは驚くことではありません。
私たちが最初にこのことを知ったのはいつですか、そしていつから危険にさらされていたのでしょうか。私が公共の電波で見つけた最初の言及は、水曜日の 14:00 GMT （オーストラリアの東端にいる私たちにとっては今朝の真夜中） に行われた seclists.org の非常に短い要約でした。 詳細はその1時間後に発表された勧告によると、ヨーロッパでは水曜日の昼下がり、アメリカでは朝方になっているようです。 これは、通常の報道機関による憶測やチキン リトル的な予測など、まだ非常に新しいニュースです。実際のところ、広範な悪用を観察するには時期尚早ですが、リスクがその潜在能力を発揮すれば、それもすぐにやってきます。 とはいえ、このバグに関するアカマイの投稿では、このバグが「長期間」存在していたことが語られており、もちろん脆弱なバージョンの Bash は過去 20 年半も前に遡ることができます。 Heartbleed と同様、問題は、悪意のあるアクターがこのことを以前から認識していたかどうか、そして実際に積極的に悪用していたかどうかです。
私たちの「もの」は影響を受けるか
ここが興味深いところです。 もちろん、この用語を使用する場合、「モノのインターネット」 (IoT) を指します。これは、カトラリーからドアロック、ライトグローブまで、あらゆるものに IP アドレスとワイヤレス アダプタを割り当てることがますます普及していることです。 たとえば、LIFX ライトグローブは、ほんの数カ月前に無線 LAN 認証情報を漏えいしていることが判明しています。 Shellshock のような Bash 脆弱性ではないものの、私たちのモノを接続することにより、以前は決して危険にさらされなかった場所で、まったく新しい脆弱性の世界に入り込んでいることがわかります。 これを実行しているデバイスは、Shellshock の危険にさらされていないように見えます。 消費者にとって難しいのは、自分のデバイスで何が実行されているかわからないということであり、それはルーターのようなより伝統的な「もの」も含みます。 このバグの長い歴史は、さまざまな組み込み OS のさまざまな進化を経た数十年以上のデバイスを意味し、現在では、長い期間に渡る非常に多様なマシンとシェルが存在します。 また、このソフトウェアが搭載されているデバイスの寿命や、実際にアクティブにメンテナンスされているかどうかも考慮する必要があります。 数年前の脆弱なTrendnetカメラのようなケースでは、膨大な数のカメラがまだウェブ上に残っていることは間違いありません。なぜなら、パッチの適用という点では、それらはほとんど「セット＆フェザー」の提案であるからです。 実際、このようなケースでは、脆弱なバージョンの所有者を疑うことなく撮影した画像を放送することに専念しているTwitterアカウントが存在します。 これは、簡単には解決できない大きな問題であり、非常に長い間、私たちを苦しめることになるでしょう。
しかし、Bash シェルは、一般的にインターネットに接続されているホーム ルーターなど、より一般的なデバイスにも存在しています。 最後にルーターのファームウェアにパッチを当てたのはいつだったか覚えていますか？ もしあなたがこれを読んでいるなら、あなたは実際にルーターにパッチを当てるタイプの技術者かもしれませんが、平均的な消費者の立場に立って、もう一度自問してみてください。 そのとおりです。
私たちの製品はすべて Microsoft のスタック上にありますが、私たちは危険にさらされているのでしょうか
短い答えは「いいえ」、長い答えは「はい」です。 Bash は Windows にネイティブに存在せず、Windows 用の Bash の実装はありますが、一般的ではなく、消費者の PC で見つかることはないでしょう。 また、win-bash のような製品が、そもそも Shellshock に対して実際に脆弱であるかどうかは明らかではありません。
長い答えは、主に Microsoft 中心の環境で動作しているからといって、その環境内の他の個別の目的を果たすマシン上で Bash を実行していないとは限らないということです。 Heartbleed について書いたとき、私は Nick Craver の Stack Overflow の SSL への移行に関する投稿を参照し、彼らのインフラストラクチャのこの図を参照しました：
Microsoft アプリケーション スタックの前には、非 Microsoft のコンポーネントがあり、Web サーバーを叩く前に通過する必要のあるコンポーネントがあります。 これらは、ファイアウォールの内側で昇格した特権を持つ可能性のあるコンポーネントでもあります。 Shellshock は、他のマシンのより広いエコシステムに存在する場合、リスクのある Bash の実装だけでなく、資産にも影響を与える可能性があるのです。
env X="() { :;} ; echo busted" /bin/sh -c "echo stuff"env X="() { :;} ; echo busted" 'which bash' -c "echo completed"
あなたは「busted」エコーを返され、バグの悪用に成功します。
もちろん、ここでの優先事項は、リスクのあるシステムに対するパッチ適用で、パッチは本質的には、Bash 関数の終了後にコードを実行できないようにすることに尽きます。 Red Hat などの Linux ディストリビューションは、リスクへのパッチ適用に関するガイダンスをリリースしているので、優先事項としてそれに飛びつくことです。
必然的に、侵入検知システムに関する定義も見られることになり、ここで探すべき共通のパターンがあることは確かです。 特に、リスクのあるシステムにパッチを展開する前に厳しいテスト要件がある場合は、多くの組織ですぐに実施できることが証明されるかもしれません。 Qualys は、かなり迅速に攻撃を検出する定義を持つことを目指しており、必然的に他の IDS プロバイダーも 24 時間体制でこれに取り組んでいます。
Bash を別のシェル実装に置き換える、またはリスクのあるシステムを封鎖するなど、より思い切ったオプションもありますが、いずれも広範囲にわたって影響を及ぼす可能性があり、軽々に決断できるものではありせん。 しかし、これはおそらく多くの人々にとってこのバグの本質であり、潜在的により重大な影響を避けるために、明白なビジネス上の影響を与える可能性のある難しい決断を迫られることになるでしょう。 攻撃ベクトルのログがない場合 (HTTP リクエスト ヘッダーまたは POST ボディで渡される場合は、しばしばありません)、これを判断するのは困難ですが、完全な pcap がない場合、ハートビート ペイロードは通常どこにもログされないので、Heartbleed の場合よりも捕まる確率は高くなります。 しかし、「Shellshock を通して攻撃されたか」に対する最も一般的な回答は、次のようなものです。
残念ながら、これは「いいえ、侵害がなかったという証拠があります」ではなく、「この脆弱性の寿命に及ぶ証拠がありません」です。 このため、システム所有者は、もし侵害があったとしても、何が起こったのかわからないという不愉快な立場に置かれます。
NSA がこれに関与していたかどうかについての推測を始めましょう。 Shellshock は Mac に影響を与えるので、もし OS X を使っているなら、現段階では OS X が危険にさらされているように見えますが、一方では、かなり実証済みのアップデート機構（つまり、Apple がマシンにリモートでアップデートをかける）により、簡単に（そしてできれば迅速に）修復されることになります。
Mac を使用している場合、この Stack Exchange の回答で説明されているように、リスクは簡単にテストできます。
Bash の再コンパイルを含む提案された修正に、平均的 Mac ユーザーが気軽に踏み込めるとは思いませんけど、これは簡単にテストできます。 メーカーの Web サイトで更新されたファームウェアをチェックインすることはできませんが、これを解読するのは本当に難しいことです。 ISPが提供するルーターは、消費者がランダムに設定やファームウェアを変更しないようにロックされていることが多く、リモートアップグレードパスを起動できるとは限りません。 さらに、膨大な数のデバイスと年齢層が存在するため、特に厄介な問題です。 もちろん、平均的な消費者が自分自身で行うのは容易なことではありません。
要するに、消費者へのアドバイスとしては、特に OS X でのセキュリティ アップデートに注意すること、が挙げられます。 また、ISP や、組み込みソフトウェアを実行するデバイスのプロバイダーからのアドバイスにも目を向けてください。 このような場合、消費者の不安を煽るフィッシング攻撃が行われることが多いのです。 現在、iPhone を電子レンジに入れるというデマが流れているので、Shellshock の「修正」として電子メールで送られてきたランダムなソフトウェアを実行しないとは一瞬でも思わないでください！
Summary
おそらく、この脆弱性の広がりを理解し始めることさえできなかったのでしょう。 もちろん、Heartbleed と比較されることは多くありますが、この演習から学んだことは数多くあります。 ひとつは、私たちがどの程度OpenSSLに依存しているのかを理解するのに少し時間がかかったことです。 もう 1 つは、これは非常に長い尾を引くということで、攻撃の数カ月後には、まだ何十万もの既知のホストが脆弱なままでした。
しかし、ある意味では、Heartbleed との比較は公平ではありません。 Heartbleed では、影響を受けるマシンのメモリ内の少量のデータへのリモート アクセスが可能でした。 Shellshockは、認証前の任意のコマンドのリモートコードインジェクションを可能にしており、潜在的にははるかに悲惨です。 この点で、私は Robert に同意しなければなりません。
これはまだ非常に、非常に早い時期で、執筆時点では、最初に電波にのってからまだ半日しか経っておらず、今のところ、まだこれから起こることの表面を削っているだけではないかと思います。