テレビCM
SKYSEA Client Viewコラム
第1回では、「脆弱性」とは何であるのかということから、脆弱性ハンドリングでは何をするべきなのかを確認してきました。しかし、具体的にどのように対応を進めていけばいいのかを想像することは難しかったのではないでしょうか。そこで今号と次号の2回にわたり、実際の脆弱性を取り上げながら、対応例を示していきます。
まずは昨年大きな話題となった、Bash（オープンソースプログラム）の脆弱性（通称:Shellshock）を取り上げます。ここからは、UNIX環境を含むサーバー群を監督する「システム管理者」として、“どのように対応したらいいか？”を一緒に考えながらご覧ください。
出典１脆弱性情報：GNU bash における任意のコードを実行される脆弱性
JVN iPedia 脆弱性対策情報データベース
| 項 目 | 内容 |
|---|---|
| 脆弱性番号 | JVNDB-2014-004410 CVE-2014-7169 |
| 概要 | GNU bashは、環境変数の値の関数定義の後で末尾の文字列を処理するため、任意のコードを実行される脆弱性が存在します。 |
| CVSS基本値 | 10.0 |
| 影響を受けるシステム | GNU bash 4.3まで |
| 対策 | ベンダより正式な対策が公開されています。ベンダ情報を参照して適切な対策を実施してください。 ・Red Hat Security Advisory : RHSA-2014:1293 |
| 参考情報（link） | IPA:bashの脆弱性対策について（CVE-2014-6271 等） |
※この情報は、説明のため一部を改変・省略しています。
新しい脆弱性情報に触れたときは、連載第1回のように手順を追って情報をさばいていくのが有効です。まずはその脆弱性が自分の管理する資産に含まれていないかを確認しなければならないことを思い出して、脆弱性情報データベースの「影響を受けるシステム」で指定されている「GNU Bash 4.3以下」が自社の資産リストに存在していないかを検索しましょう。すると、「Red Hat Linux」を使用して運用している外部公開用Webサーバーが、まさに「GNU Bash 4.3」を利用していることを発見してしまったのです！
ここで見つかったサーバーは、脆弱性の影響を受けている可能性が高いといえます。そこで、あなたは脆弱性情報をさらに読み解いて分析し、リスク評価や対策方法の検討を始めることにしました。
まずは「概要」を読んで大まかな脆弱性の特徴をつかんでおきます。ここには「任意のコードを実行される」と書かれており、攻撃者が何らかの“プログラムを実行できてしまう”らしいことが読み取れます。次に「CVSS基本値」の項目を見てみると、最高値の10.0が付けられています（出典１）。
今度はCVSS基本値をさらによく見ていきます（出典２）。すると、ネットワーク越しに簡単に攻撃され、しかも機密性・完全性・可用性のすべてに全面的な影響があることがわかりました。
出典２CVSS基本値の各項目（CVE-2014-7169）
| 項 目 | 評 価 | 項 目 | 評 価 |
|---|---|---|---|
| 攻撃元区分 | ネットワーク | 機密性への影響 | 全面的 |
| 攻撃条件の複雑さ | 低い | 完全性への影響 | 全面的 |
| 攻撃前の認証要否 | 不要 | 可用性への影響 | 全面的 |
ここまでの情報で「ネットワーク越しに任意のコードを実行され、機密性・完全性・可用性に重大な影響がある」、かなり深刻な問題だということが理解できてきました。そこで、より詳細に内容を知るために、IPAの「bashの脆弱性対策について」を確認してみることにします。参考情報に示されている「bashの脆弱性対策について」のリンクからページを開くと、この脆弱性がどのようなメカニズムで攻撃されるのかを知ることができました（図１）。さらに、すでにこの脆弱性を使った攻撃が観測されていることもわかります。
図１脆弱性を悪用した攻撃のイメージ
続けて、「攻撃を受ける可能性があるアプリケーション（製品）」の章を読んでみると、自分の環境に一致するであろう条件が書いてあります（出典３）。
出典３攻撃を受ける可能性があるアプリケーション（製品）
ウェブアプリケーション
ウェブアプリケーションが CGI から OS のコマンドを実行している場合、攻撃の影響を受ける可能性があります。
IPA：bash の脆弱性対策について
この脆弱性に該当している資産は、外部に公開中のWebサーバーですから、攻撃を受けてしまう可能性があるようです。さらに大きな被害も予想されることから、高い優先度で脆弱性への対応を行う必要があると判断しました。
ここからは、脆弱性のあるサーバーにパッチを当てて、脆弱性をふさぐ作業へ進んでいきます。どのように対応したらいいのかについては、脆弱性情報データベースの「対策」（出典１）の項目を確認すればよいのでした。ここには、「ベンダ情報を参照して適切な対策を実施してください。」と記載されています。
ベンダー情報を参照し指示を確認すると、パッケージマネージャを利用してBashに関する指定のパッケージをアップデートすることで対策可能だと書かれていました。あなたは該当サーバーの関係各所と調整して、アップデートを行い、サーバーを無事に攻撃から守ることができました。
ここまでで「Bash」の脆弱性を例にとったストーリーはおしまいです。今回取り上げた脆弱性は特に危険性が高かったことから、「Shellshock」というコードネームとともに大きな話題になっています。多くのメディアで取り上げられ、真贋のはっきりしないさまざまな情報が飛び交う中で、一時は業界全体が混乱状態に陥ってしまいました。こういうときに頼りになるのも、脆弱性を理解するための吟味された情報から対策方法へのリファレンスまでがまとめられている“脆弱性情報データベース”です。幅広い情報収集も重要ですが、まずはここを軸に分析・対策を進めることで、今回のストーリーのように落ち着いて対応することができるはずです。
まとめ
今回は、実際にBashで見つかった脆弱性を例にとりながら、ストーリー仕立てで脆弱性ハンドリングの一例を示しました。脆弱性情報データベースで入手した情報からリスクを評価し、実際の対応につなげていけることを実感していただけたのではないでしょうか。大きな話題になるような脆弱性でも、正確な情報さえ持っていれば、このように落ち着いて対応していくことができます。
次回は、さらに複雑な脆弱性ハンドリングを紹介いたします。
