Shellshockは、30年前から存在するコマンドラインインターフェイスシェルBashのバグで、2014年に重要な脅威として発見されました。 現在でもShellshockは企業にとって脅威であることに変わりはありません。
発見された年に比べれば、確かに脅威のリスクは低くなっています。 しかし、混沌とした状況に対応するためにセキュリティの優先順位が再調整されたこの年に、この脅威と、これらの攻撃を今日まで存続させている根本的な要因を振り返るのは良い機会だと思います。
Why is Shellshock Relevant in 2020?
Shellshockは、攻撃者に与えられた特権が昇格し、システムを自由に侵害できるようになることから、重要な脆弱性であると言えます。 ShellShockの脆弱性であるCVE-2014-6271は2014年に発見されましたが、現在でも世界中の多くのサーバーに存在することが知られています。 この脆弱性は直後に更新（CVE-2014-7169）され、2018年に至るまで修正されています。
Shellshockがいまだに利用されている主な理由は、衝撃的なものではありません。 この脆弱性は、悪質な行為者が何も知らないターゲットに対して展開できる、シンプルで安価な攻撃です。 CVE エントリ以来パッチが提供されていますが、適切なパッチ管理システムを導入していない組織はまだ脆弱である可能性があります。
Shellshock は 2017 年にまだ顕著でした。 攻撃者に必要なのは、基本的なプログラミングスキル、サーバー、マルウェアへのアクセスだけとなれば、当然といえば当然です。 しかも、攻撃を実行するためのコストは、月々数ドルもかからないのです。 計算上は、攻撃者に有利なのです。 最小限の知識、わずかな労力、低コストが、1 つの簡単なハッキング戦略に相当します。
サイバーセキュリティに関するメディア報道が盛んで、国土安全保障省の警告さえ出ているにもかかわらず、一部のシステムにはパッチが適用されていないままになっています。 ある例では、Center for Election Systems の職員がパッチを適用しなかったために、ジョージア州の選挙システムに危険が生じました。
平たく言えば、Shellshock は、脆弱なバージョンの Bash を含むシステムが、より高い特権でコマンドを実行するために悪用される脆弱性です。 このため、攻撃者は潜在的にそのシステムを乗っ取ることができます。
技術的に深く掘り下げると、Shellshock は Bash シェル (GNU Bash バージョン 4.3 まで) のセキュリティ・バグで、Bash が環境変数から意図しない bash コマンドを実行するようになります。 この脆弱性を悪用する脅威者は、ターゲットとなるホスト上でリモートでコマンドを発行することができます。 Bash は本来インターネットに接続するものではありませんが、Web サーバーなどの多くの内部および外部サービスでは、サーバーのオペレーティングシステムと通信するために環境変数を使用します。
これらのデータ入力が実行前にサニタイズされない場合 (コードが入力の一部でないことを保証するコーディング標準プロセス)、攻撃者は Bash シェル経由で実行される HTTP リクエスト コマンドを起動することができます。 BASH を使用して OS と通信する電子メール サーバーや DNS サーバーも影響を受ける可能性があります。 BASH は通常、Unix ベースのシステムで見つかりますが、Windows ベースのシステムを使用している組織も無縁ではありません。 これらの企業は、おそらく脆弱性のあるアプライアンスやハードウェアを利用しているのでしょう。 BASH は、家庭用ルーター、多くの IoT デバイス、および組み込みシステムの一部であることを忘れないでください。
Shellshock は、サービス拒否 (DOS) 攻撃を行うために使用することもできます。
ここにコードの行があります (Bash 関数宣言の後にセミコロンを付け、「sleep」コマンドを 3 つの可能なパスから実行して、確実に実行されるようにします)。
new_function() { :;} ; /bin/sleep 20 /sbin/sleep 20 | /usr/bin/sleep 20
この “sleep” コマンドは、サーバーが返信する前に 20 秒間待機することを強制します。 そうすることで、マシンは20秒間何もできなくなるため、マシン上のリソースは本質的に人質になります。
1つのsleepコマンドは無害かもしれませんが、攻撃者はこれを悪意のあるコードに置き換えることができるかもしれません。 その後、そのコードは、サーバーまたはリソースに手錠をかけ、いかなるリクエストも処理できなくします。
有害なインターネット ユーザーが、自分の好きなコマンドをリモートで実行できるようにするリスクは高いのです。 オープニングを使用することで、悪質な行為者はシステム上でプログラムを起動し、自分のシステムへのアウトバウンド接続を作成し、悪質なソフトウェアを実行することができます。
おそらく最も重大なのは、この脆弱性を利用して、クレジットカードの詳細、パスワード、個人を特定できる情報 (PII) など、システムに保存されている機密データおよび情報を盗むことができることです。
Is Shellshock Still Rampant?
Shellshockは2014年に発見された時ほど普及していないようです。 自社の脆弱なサーバー（しかも、当時はたくさんあった）すべてにパッチを当てなければならない大変さを想像してみてください。
とはいえ、Shellshockが問題であることに変わりはありません。
たとえば、「Sea Turtle」と呼ばれる、DNS レコードを利用して機密システムにアクセスするサイバー脅威および脆弱性キャンペーンが進行しています。 この攻撃を成功させるには、一般的なハードウェアおよびソフトウェアの脆弱性がいくつか必要で、Shellshock はそのうちの 1 つです。
以前ほどではないが、すべての企業は、すべてのハードウェアとソフトウェアにパッチが適用され、最新の状態になっていることを確認する必要があります。 そのうちのいくつかは無料で入手できます。 そのうちの1つである bashcheck は、Github を使ってダウンロードすることができます。
技術者の方は、Bash プロンプトで簡単なコマンドを入力しても効果があります:
env X=”() { :;} ; echo Bash is Infected” /bin/sh -c “echo completed”
env X=”() { :;} ; echo Bash is Infected” `which bash` -c “echo completed”
env VAR='() { :;} ; echo Bash is Infected’ bash -c “echo completed”
もしプロンプトが「Bash is Infected」を返したら更新と修正の時期が来たと言えるでしょう。 出力が「Bash is Infected」を返さない場合、次のような応答があります:
bash: warning: VAR: ignoring function definition attempt
bash: error importing function definition for `VAR’
Bash Test
ウェブサイトや特定の CGI スクリプトに対する脆弱性をテストしたい場合、以下のツールが役に立ちます。 ‘ShellShock’ Bash 脆弱性 CVE-2014-6271 テストツール。 2 つの入力フィールドのいずれかに、テストしたい Web サイトまたは CGI スクリプトの URL を入力し、青いボタンをクリックします。
What We can Learn About Cybersecurity Threats
ここで企業にとって最大の教訓は、繰り返しになりますが、システムをパッチすることです。 パッチ管理をセキュリティよりも IT の責任と考える企業もありますが、パッチ管理は企業のセキュリティ態勢にとって重要であるため、セキュリティ部門にとって常に最優先事項でなければなりません。
システムが今日も脆弱である場合、おそらく対処すべき根本的な運用上の問題があると思われます。 Shellshock は非常に古い脆弱性で、ほとんどすべてのシステムでパッチが利用可能です。 この種の脆弱性から身を守る最善の方法は、システムを最新の状態に保ち、この悪用に対してリリースされたすべての修正を適用することです。
資産にパッチを当てる場合、通常は単純なプロセスですが、戦略的アプローチを採用する必要があります。 システムがすぐにパッチを適用できない場合、脆弱性の潜在的なリスクとビジネスへの影響を比較検討する必要があります。
Shellshock は、企業が対処しなければならない脆弱性の長いリストの中の 1 つに過ぎません。 無限に続くように見える脆弱性を管理することは、サイバーセキュリティを支える重要な戦略であり、今後もそうあり続けるでしょう。
安全な組織のためのチェックリスト
脆弱性管理を成功させるには、企業は以下の 3 つの領域で成功する能力を備えていなければなりません：
- 潜在的に影響を与える脆弱性を迅速に特定する。 ここでは、スピードがすべてです。 しっかりとした計画で全員が同じページに立つことで、より迅速な対応が可能になります。
- 脆弱性の深刻度レベルを決定する。 組織のリスクに対する許容度を知ることは、脆弱性がどの程度深刻であるかを決定する上で大きな助けとなります。 ネットワーク・インフラストラクチャによって、ある脆弱性は他の脆弱性よりも有害です。
- セキュリティの緊急性と本番環境への影響の可能性のバランスを考慮した行動計画を持つこと。 独立系セキュリティ研究者の Rod Soto 氏にとって、Shellshock から学んだ最大の教訓は、インターネットは多くの脆弱なアプリケーションに基づいており、そのセグメントの大部分を侵害する可能性を常にはらんでいるということです。 「そのため、このような広範で重大な脆弱性が見つかった場合、影響を受けるすべての関係者間の調整により、影響を受けるシステムにパッチを適用したり、軽減したりすることができます」
あなたの会社が Shellshock やその他の脆弱性に対するリスクの軽減に成功した場合でも、その対応策が完璧であるとは考えられません。 対応計画は生きた文書であるべきで、脅威に対して組織が迅速に対応できるように頻繁に見直す必要があります。
最後に、攻撃後のシナリオと同様に、計画の各段階を見直す際に尋ねるべき質問があります。
- 計画のどの部分が成功したのか、
- 計画のどの部分が失敗したのか、
- 我々が今行う必要があると認識していることで行わなかったことは何なのか。
- 次にやってくる脆弱性に対してより準備するために、私たちは何を学びましたか？
Shellshockは古い攻撃かもしれませんが、攻撃者にとっては、適切なセキュリティ衛生を欠いている犠牲者を悪用するためのすべてのボックスを満たすものです。