先週、Qualys社は、 （）に関するセキュリティアドバイザリ（ ）を公開し、OpenSSHクライアントのバージョン 5.4 から7.1に存在する脆弱性（CVE-2016–0777 および0778）を明らかにしました。 これらの脆弱性が悪用されると、秘密鍵情報が盗まれる恐れがあります。 この脆弱性を解消するには、管理者はOpenSSHをバージョン 7.1p2 に更新するか、既存のSSHクライアントの設定を変更して、悪用可能な機能を無効にする必要があります。
OpenSSHのようなソフトウェアの脆弱性のあるバージョンを、規模の大小を問わず企業内で発見することは、大きな問題となります。というのも、ほとんどの企業には、自社ネットワーク内のすべてのエンドポイントを把握するという基本的な能力が欠けているからです。 プロセスの終了、システムの隔離、パッチの適用など、単一のシステムに対して行いたい操作を、すべてのエンドポイントに一斉に実施するのは困難な場合がありますが、これがTaniumが優れたツールである理由の一つです。
初期の研究
Qualysの発表を読んだ後、回避策に関するさらなる情報を、できればパッチを提供している関係者から入手しようと試みました。 この分野の権威であるテオ・デ・ラート氏（ ）は、 に記載された、このバグの発生を防ぐ未文書化の設定ディレクティブ UseRoaming no について投稿しました。 一見したところ、この回避策は簡単なもののように思えました。つまり、設定ファイルにエントリを追加するシェルスクリプトをさっと作成すればよいだけでした。 これに関連する の議論 において、設定ファイルにホストパターンが定義されている場合、その設定を構成ファイルに追加しようとすると失敗する可能性があることが的確に指摘されていました。 したがって、スクリプトでは、すべてのホストの設定を追加する必要があります：
脆弱性のあるマシンへのスクリプトの迅速な展開
稼働中の設定ファイルを一括で変更することは、常識ある管理者なら誰しも不安に感じるはずです。 これは、ある程度の注意を払い、万一の時の備えをしておかないと、安易に行うべきことではありません。 ファイルを変更した場合、1台またはすべてのシステムで、その変更を素早く元に戻すにはどうすればよいでしょうか？ まず、既存の設定を新しいファイルにバックアップし、その後、ssh_config に以下の修正を適用しました： UseRoaming no
初期のテストにおいて、echo の -e フラグがすべてのシステムで利用できるわけではないことが判明したため、移植性を確保するために $’’ という構文を使用することにしました。 そこで、このコマンドを次のように改良しました：
単一のシステムで再度テストを行いました。 以下は、元のファイルの最後の数行、コマンドラインから手動で修正を実行した様子、および修正後の設定ファイルの最後の数行を示す画像です：
設定ファイルにこの修正を複数回追加するというエッジケースをテストしたところ、重複があってもSSHクライアントは正常に動作し続けることが確認されました。 運用面では、これは有効な安全策ですが、開発の後半で修正すべき点として記録しておきました。
フェイルセーフ
最も簡単な方法は、バックアップファイルを設定ファイルの上に上書きすることです。 理想を言えば、このような措置を講じる必要はまったくないのですが、これは「一オンスの予防が大きな利益をもたらす」というものであり、企業全体で迅速に是正措置を進める上で、さらなる安心感をもたらすものとなるでしょう。
スクリプトの内容は基本的なものです：
OpenSSHの脆弱性の影響範囲を特定する
修正を適用したり解除したりするためのスクリプトが揃いましたので、次は適用可否を判断するためのスクリプトを作成しましょう。 このスクリプトをTaniumセンサーに組み込み、エンドポイントのネットワーク全体でクエリを実行できるようにします。 複数のテストの結果、この回避策が好影響をもたらすことが確認されたため、私たちにとって最も簡単な方法は、ssh_config に修正によって意図された出力が含まれているかを確認することです。
移植性を考慮し、実装方法としてawkのワンライナーを採用しました。これは、ファイル内の特定の正規表現に一致する行の間に存在する行を出力するものです：
これは、3行からなる修正シーケンス全体がファイルに書き込まれている場合のみ一致します。 当社のソリューションはOpenSSHのバージョンに依存せずに動作するため、「Vulnerable」ではなく「Potentially Vulnerable」という文字列を返すようにしました。 バージョンに依存せず、より広範囲を対象とすることで、研究者がOpenSSHの同じ「Roaming」機能に関してさらなる脆弱性を発見し続けたとしても、コードを更新する必要がなくなります。 （ローミング機能は実際にはほとんど役に立たないため、設定によって無効化することで、運用に悪影響を与えることなくセキュリティを強化できます。） や Shellshock を覚えている方もいらっしゃるかもしれません。これらは、コミュニティがすべてを適切に解決するまでに、何度か試行錯誤とソフトウェアの更新が必要でした。 当社のアプローチにより、SSHクライアントにおいて同様の事態が再発することに対する耐性を確保しています。
デフォルトの ssh_config ファイルに対して行ったテストの結果は以下の通りです：
さて、先ほど倒したばかりの相手と対戦することになりました：
これは良さそうですね！ その後、これらのスクリプトを「SSHキー漏洩の回避策のステータス」と名付けるTaniumセンサーに組み込みました。
ユーザーごとのSSH設定と内容の仕上げ
調査を行ったところ、ユーザーが独自の ~/.ssh_config ファイルを定義している可能性のあるマシンについて、コミュニティ内で議論されている事例はあまり見当たりませんでした。 これらの設定はグローバル設定よりも優先されるため、この脆弱性を解消するには、ここで修正を適用する必要があります。 これをきっかけに、ホームディレクトリも対象に含めるよう、コンテンツのさらなる機能強化を行いました。 プラットフォームの違いにより、OS Xと*nix系を同等にサポートするために、スクリプトを2つの異なるバージョン用意することになりました。
さらに、以前のスクリプトで修正を適用していたロジックを改善し、修正が複数回適用されて設定ファイルが肥大化しないようにしました。 ブログ記事にすっきりと収まるには長すぎますが、それでもコードとコメントを合わせても 40 行強にとどまっています。
その結果、*nixおよびOS Xシステムにおいて、「潜在的な脆弱性がある」と判定されるシステムを数秒で特定できるソリューションが完成しました。 もし、各システムに保存されているSSH設定ファイルに、企業のセキュリティを確保するための対策が含まれていない場合、ユーザーはわずか数分で、企業内の任意のシステムまたはすべてのシステムに対して、その修正を適用したり、元に戻したりすることができます。
プラットフォーム「Tanium」
Taniumは、マシンの台数にかかわらず、すべてのエンドポイントの状態を業界で唯一リアルタイムに可視化できるため、OpenSSHの脆弱性への対応を容易にします。 このプラットフォームは、本記事で説明したアプローチを実装するための、最も迅速かつ簡単な方法です。信頼できる情報源からのデータを用いて開始し、スクリプトを開発し、テストを拡大・精緻化し、最終的にはプラットフォームの新たな機能として完全に展開することになります。
ご意見がございましたらお知らせください。また、ご自身の環境にて本コンテンツを実行することにご興味がおありの場合は、担当のテクニカルアカウントマネージャーまでご連絡ください。 Taniumについてご存じない方で、詳細をお知りになりたい場合は、 までご連絡いただき、デモをご依頼ください。
ロリー・プレンダーガスト、シニア・ディレクター
ピーター・エルシュレーガー、シニア・ディレクター
Taniumの実際の動作をご覧になりませんか？ の個別デモをご予約いただくか、毎週開催されているウェビナーにご参加ください。 「 」の今後のイベント（）にて、当社のTaniumエキスパートにご相談ください。
