ネットエージェント株式会社 オフィシャルブログ

bashにおける脆弱性「Shellshock」について

LinuxやMac OS XなどのUNIX系OSで広く使用されているbashに見つかった脆弱性(Shellshockと呼ばれています)が先日から話題になっています。
弊社でもこのbashの脆弱性について調査を行いました。

■概要
環境変数に特定の文字列を設定するだけでその環境変数内の文字列をシェルが関数として実行してしまいます。
シェルを通じてコマンド等を実行する幅広い環境で影響がありますが、特に顕著に影響を受けるのはCGI等のWebアプリケーション環境です。
CGIをはじめとするWebアプリケーションではWebブラウザからのHTTPリクエストヘッダなどに含まれる各種の情報を環境変数を通じて取得するため、攻撃にも応用しやすいからです。

今回の脆弱性は、攻撃者にとっては非常に簡単な方法で攻撃が可能であり、現在すでにこの脆弱性を利用した攻撃が広く観測されているため、早急に対応が必要となります。
特に、CentOSではデフォルトで/bin/shがbashへのシンボリックリンクとなっており、影響を受けやすいため注意が必要です。

■脆弱性のあるbashかどうかの確認方法
コマンドライン上で
$ X='() { :;}; echo vuln' bash -c 'echo'
を実行します。このとき、画面に vuln の文字列が表示されるようであればお使いのbashは脆弱性のあるバージョンとなります。

※vuln の文字列が表示されない場合であっても、脆弱性に対応するために現在リリースされているパッチでは修正が不十分という可能性もありますので、ベンダの情報やJPCERT/CCによる緩和策等を参考にしてください。

参考: GNU bash の脆弱性に関する注意喚起(JPCERT/CC)

■攻撃有無の簡易的な確認
Webサーバのアクセスログから「() {」という文字列を含むリクエストが存在していないかを調べます。
[root@www httpd]# grep '() {' access_log
2xx.1xx.2xx.7x - - [25/Sep/2014:07:15:16 +0900] "GET / HTTP/1.0" 200 2217 "() { :; }; ping -c 11 2xx.xxx.xxx.7x" "shellshock-scan (http://blog.*********.com/2014/09/bash-shellshock-scan-of-internet.html)"
2xx.1xx.2xx.7x - - [25/Sep/2014:13:41:18 +0900] "GET / HTTP/1.0" 200 2217 "() { :; }; ping -c 11 2xx.xxx.xxx.7x" "shellshock-scan (http://blog.*********.com/2014/09/bash-shellshock-scan-of-internet.html)"


これは脆弱性がある場合には攻撃者の用意したサイトへpingを発行するという攻撃の準備のためのコードをリファラに仕込んでいたときのログで、研究を目的としたスキャンのようです。
ただし、このログによる確認方法は簡易的なものであり、User-Agentやリファラ以外の例えばAccept-Encodingやその他のカスタムリクエストヘッダなどに攻撃用コードを仕込んでいた場合には一般的にはログに記録されないため、この確認方法では攻撃の有無を把握することはできません。

そのため、攻撃を確実に把握するためにはすべてのHTTPの通信を記録しておくことが望ましいと言えます。弊社 PacketBlackHole を用いるとHTTPをはじめとする通信の記録、確認が容易に行えます。

■影響の範囲
Webサーバをはじめとし、bashがインストールされているLinuxやUNIX環境すべてが対象となりますが、その脆弱性を利用して外部から実際に攻撃、侵入ができるかどうかについては設定や使用しているプログラムによるところが大きく、すべてのサーバが即座に侵入可能というわけではありません。

脆弱性のあるbashが存在するWebサーバに対しては、攻撃者がHTTPリクエストヘッダに脆弱性を利用した攻撃コードを含めてHTTPリクエストを発行し、それに対してWebアプリケーション攻撃が応答するだけで攻撃が成立してしまいます。

Webアプリケーションが影響を受けるのは、シェルを経由して外部コマンドを起動する部分となります。各言語において外部コマンドを起動するための関数や命令は異なっており、それぞれがシェルを経由するか否かはWebアプリケーション開発者にとっても把握が難しいため注意が必要です。

以下、代表的な事例としてPHPおよびPerlにおける影響点を記載しておきます。

○PHP

PHPではCGIモードで起動させた場合にbashの脆弱性を利用した攻撃が非常に容易に行えることを確認しています。
execやshell_exec、sysytem、proc_open といった明示的に外部コマンドを起動する関数の呼び出しだけでなく、メール送信のために広く利用されている mail 関数や mb_send_mail 関数も内部的にシェルを起動しているため、今回のbashの脆弱性の影響を受けます。これらを利用しているPHPスクリプトの動作環境では早急に対応が必要となります。

○Perl
system、exec、``、open など外部コマンドを利用している場合に影響を受ける可能性があります。特に、open( FH, "| nkf -j | sendmail" ) のように多段にパイプを介している場合にはシェルを起動してのコマンド実行となるため確実に影響を受けることになります。

また、外からみた場合には明示的にWebアプリケーションに見えない、静的なHTMLファイルであったとしても、内部でSSI(Server Side Include)を使用している場合には <!--#exec cgi=... --> などの機能により外部コマンドを呼び出している場合があり、これらもbashの脆弱性の影響を受けるため注意が必要です。


企業内、ファイアウォール内のサーバやBASIC認証等で保護されているサーバなど、攻撃者が直接的にアクセスできない場合であっても、そのサーバ上の攻撃可能なCGIなどのURLが攻撃者にとって既知である場合には、攻撃者はわなページ上のJavaScriptからXMLHttpRequestによって攻撃用のコードをを該当CGIへ送信することで任意コードの実行が可能となります。

以上、bashの脆弱性についての調査結果となります。繰り返しになりますが、現在提供されているパッチでは脆弱性への対応が不十分という話もあるため、パッチの適用に加え、万が一の場合に備えた対策を合わせてとっておくことが大切であり、弊社によるネットワークの監視カメラ「PacketBlackHole」のような製品が重要となります。
また、弊社でもサポートするSaaS型のWeb Application Firewallである「Scutum」ではすでに本攻撃に対するシグネイチャの対応を終えており、導入することにより本脆弱性を利用した攻撃からWebアプリケーションを守ることができます。



情報漏洩を発見し、証拠をつかむネット版防犯カメラ

大きな情報漏洩事件があったので、多くのシステム担当者の方々が同じような事件が起こらないような対策を模索していると思う。今回は情報漏洩対策の概要を紹介しよう。


情報漏洩対策を本格的に行うには、以下の3段階それぞれが必要である。

1. 情報が漏れないようにするクライアント用の対策ソフト
2. 情報が漏れたときに発見し記録できるシステム
3. 情報漏洩対策の専門家によるコンサルティングや検査

真に情報漏洩対策を行うには、これら3段階全てを揃えて行う必要があるが、まず最初に必要なのは当然ながらクライアント上からの漏洩を防止するための1.の対策ソフトである。しかし、これらのソフトにはソフトの種類によってそれぞれ得意な点と不得意な点があり、それらの特性を理解して利用しなければならない。漏洩を引き起こそうとしている者がその不得意な点を熟知している場合や、対策ソフトの想定外の運用が行われている場合には、漏洩を防ぎきることができないこともあり得る。

例えば、「USBメモリの使用を制限します」と謳っている情報漏洩対策ソフトの一部では、最近のスマートフォンやデジタルカメラ等のUSBメモリとは異なった方式でファイルをやり取るするデバイスについては、制限の対象外となっているものもある。

none_usbmemory
Fig.1 USBメモリの使用を制限するソフトウェアで制限の対象外となるデバイスの例

そのため、情報漏洩対策ソフトに頼りきるのではなく、データの流れを監視する仕組みを用意することで、情報漏洩を発生時点で検知し万が一漏洩が発生した場合でもその証拠を残すためのシステムというものが重要となってくる。監視における証拠の残し方としては、アプリケーション自身のログやハードディスク上に残る様々なフォレンジック用途の痕跡、通信の記録といったディジタル面だけでなく、入退室管理や防犯カメラなど従来からのアナログな手法と組み合わせて死角の発生しにくいあるいは回避するためにはコストの高くなる仕組みがふさわしい。

また、万が一何か問題が発生した場合の原因追究に、アプリケーションやOSのログといった一般的な痕跡だけに頼ろうとすると、必要な情報が十分に記録されていなかったり、あるいは必要以上に大量のログに重要な証拠が埋もれてしまって多くの時間や能力を消耗するといったことも起こり得る。
そのため、監視システムとしては単に精細にログを記録するだけではなく、ログを調査する個々人の能力に頼らずに、誰でも容易に発生した事象を短時間で解析できる機能が要求されている。
さらに、漏洩のようにひとたび発生してしまうと事後では取り返しがつかず、発生から発見、その対策までの期間を最小に抑える必要のある問題に対応するためには、監視によって日々の通信を確認し、早い段階で異常を検出できなければならない。とはいえ、すべての通信を単純にチェックすることは現実的には不可能であるため、監視システムには効率的に重要な通信だけを抽出して確認できる機能も必要とされている。

そのような社会的要請のなかで、例えば弊社のPacketBlackHoleでは、これまでに多くの実績を積み重ね、管理者が日常的に使いやすい監視システムを実現している。

pbh_link
Fig.2 通信記録とそれから情報漏洩を発見できる製品の代表PacketBlackHole

例えば、これまでの様々な漏洩事件に対する対策への知見を踏まえ、過去の事件の手法や専門家による経験を学習させたパターンを内部に持っており、個人情報や社内機密情報の外部への送信といった典型的な通信パターンだけでなく、過去の同種の事件や犯人の行動パターンなどをもとに危険性のある通信に対して早期に警告を発することが可能となっている。

found_kojinjouhou
Fig.3 過去の情報漏洩事件のパターンを元に、個人情報の外部送信を検知したイベント

また、効率的な確認のために重要な通信だけを自動的に抽出する機能も備えている。

kojin_risk_calender
Fig.4 個人の高リスク行動カレンダー

監視していて万が一情報漏洩を発見した場合には、すぐにアクションをとる必要がある。誰に連絡するか、自宅に持ち帰った可能性がある場合はどうするのか。証拠のパソコンを抑えるための手順、自宅のパソコンや私物の記憶媒体を抑えるための同意書など、あらかじめ準備を整えておく必要がある。

■ 持ち込み管理と検査

実際の運用においては、情報漏洩を発見した際には速やかにアクションを取る必要がある。どのような連絡体制となっているのか、誰が指揮を執るのか、自宅に持ち帰った場合はどうするのか、社外第三者の手に渡っている場合にはどのように対応するのか。証拠となるPCやデバイスをどのように保全するのかの手順、自宅のPCや私物の記録媒体であればそれらを抑えるための同意書など、あらかじめ具体的な漏洩のシナリオを立て、それにそった準備を整えておく必要がある。

情報漏洩対策の専門家であれば、情報漏洩に対する様々な漏洩の手法と対策を合わせて持っており、各システムの長所だけでなく短所についても理解している。これはもちろん、常に「対策の抜け道」を考えておかなければそれを上回る対策を行うことができないからである。
とはいえ、「どのような場合であっても情報漏洩を完全に防ぐ」ということはコストや運用の手間を考えると現実的には不可能に近く、どこかで妥協点を見出すことが必要である。情報漏洩対策とは正解のない道であり、唯一言えることは「結果として漏洩しない」ということが最重要であるという点であろう。我々は情報漏洩対策の専門家として、漏洩におけるリスク、対策の手法やそこにかけるべきコスト、万が一漏洩が発生したときの体制など、様々な面からみなさんのお手伝いができればと考えている。

技術を駆使して侵入せよ!

新入社員が入社して1週間がたちました。
弊社では研修の一環として、弊社サービス「ゲームセキュリティ診断サービス」に関連したチャレンジを実施いたしました。

弊社で製作したゲーム上で、「アチーブメント(実績)」を多く回収できるよう自身の技術を駆使してもらう、という内容です。

「アチーブメント(実績)」とは、例えば「ゲームで100ポイント獲得した」などのように、なんらかの条件をクリアすることにより得られる「証(あか)し」のことをいいます。

(参考:アチーブメント とは - コトバンク)
今回このチャレンジ用に用意したゲーム内にも、アチーブメント(実績)を用意し、アチーブメント(実績)回収までの時間と、アチーブメント(実績)毎に割り当てられている点数の総得点によって、チャレンジの結果を評価します。

このアチーブメント(実績)は、普通にゲームをプレイしてしまうと、時間が大変かかってしまったり、通常の操作では獲得できないものもあるため、「チート行為」と呼ばれるゲームシステムの弱点をつき通常では行えない行為を行って、いかに効率よくアチーブメント(実績)を回収していけるかが鍵になります。

このチャレンジによって、弊社で提供しております「ゲームセキュリティ診断サービス」において必要な、攻撃者によって狙われる可能性のあるゲームの弱点さがしができるかどうかが分かるのです。

チャレンジの流れは、
1日目:個人でチャレンジ
2日目:力を合わせて、英知を結集しみんなでチャレンジ
終了後:結果を元に、講師から解説
という流れで行いました。


新入社員に、チャレンジの感想を聞いてみました!

【Q】チャレンジは、どのように進めていきましたか?
【A】オリジナルのゲームだったので、まずそのゲームがどのような内容なのか、どう進行していくものなのか、などを調査し、クリア方法を考えました。
その調査・考案に半日くらいかかり、その後にミッションであるアチーブメントの回収を行いました。
そもそもアチーブメントってなんだろうというところからスタートだったので、四苦八苦しました。

【Q】2人での共同チャレンジはどうでしたか
【A】お互いの進め方、気づく点が違ったので、それぞれのアイディアや方針を組み合わせることによって効率よく進めることが出来ました。
人と一緒に作業することによって、自分が気づけない点を知ることが出来るのでよかったです。

【Q】チャレンジに挑戦してみてどうでしたか?
【A】試験ということでプレッシャーを感じながらの作業でしたが、とても楽しかったです。今回は、あと一息のところでクリアできなかったので、ぜひ再チャレンジしたいです。

新入社員諸君、取材回答ありがとうございました。そして研修お疲れ様でした。

その他、おまけエピソードとして、只今試験中
この記事に載せているイラストは、今回のチャレンジ中ということを社内に伝えるために用意しました。ゲームシステムに侵入する試験、ということで、どこかに侵入しようとしているネコさんのイラストです。

大変ありがたい事に多数のお申し込みをいただいていて、6月までお待ちいただくこととなってしまっている「ゲームセキュリティ診断サービス」ですが、優秀な新入社員も入社して、さらに皆様にお役立ちできるサービスとして展開してまいりますので、今後ともよろしくお願いいたします。
当ブログはあくまで各個人の視点で書かれており、
記事の内容についてはネットエージェント株式会社の公式見解とは異なる場合があります。
記事検索
月別アーカイブ
QRコード
QRコード