アプリケーションサーバの脆弱性にご注意を：川口洋のセキュリティ・プライベート・アイズ（37）

JBossの脆弱性を突くワーム出現

　こんにちは、川口です。最近、アプリケーションサーバの「JBoss」の脆弱性を突くワームが出現しているのですが、標的型攻撃のニュースに隠れてか、世間では思いのほか話題になっていないようです。

　今回はJBossを狙った攻撃を取り上げ、アプリケーションサーバが狙われている理由について解説します。

狙われる「JBossの設定不備」

　JBossにはJMX（Java Management Extensions）コンソールという管理画面が付属しており、このJMXコンソールのアクセス制御不備が攻撃のターゲットになっています。

　通常、このような管理画面にはアクセス制御が施されており、インターネットからアクセスできるような状態になっているはずはない……のですが、私がさらっとGoogleで検索しただけでも多数のJMXコンソールを探し出すことができました。いったいなぜでしょうか？

　手元の環境にJBossをインストールしてみてください。設定ファイル/deploy/jmx-console.war/WEB-INF/web.xmlを参照すると、以下のように、設定がコメントアウトされた状態になっています（バージョンによって異なる可能性があるので注意してください）。

<!--<security-constraint>-->
<!--<web-resource-collection>-->
<!--<web-resource-name>HtmlAdaptor</web-resource-name>-->
<!--<description> An example security config that only allows users with-->
<!--the role JBossAdmin to access the embedded console web-->
<!--application </description>-->
<!--<url-pattern>/*</url-pattern>-->
<!--<http-method>GET</http-method>-->
<!--<http-method>POST</http-method>-->
<!--</web-resource-collection>-->
<!--<auth-constraint>-->
<!--<role-name>JBossAdmin</role-name>-->
<!--</auth-constraint>-->
<!--</security-constraint>-->

　JBoss構築について解説したWeb上のドキュメントやホームページを参照したところ、上記の設定のコメントアウトを外し、JMXコンソールを含む管理画面に関する設定を行うように指示する記載がいくつか見つかりました。

　もし、この設定のコメントアウトを外して管理画面を使用した場合、どのようなことが起こるのでしょうか。注目してほしいのは以下の2行です。

<!--<http-method>GET</http-method>-->
<!--<http-method>POST</http-method>-->

　この2行があることで、GETメソッドとPOSTメソッドに対してのみ、管理画面のアクセス制御が適用されます。つまり、HEADなどの他のメソッドでアクセスすると、アクセス制御が働かず、そのまま管理画面にアクセスできてしまうのです。

　JBossを運用しているならば、試しにアクセスログを確認してみてください。もし、以下の文字列で始まるHEADメソッドによるアクセスがあった場合には、あなたのサーバにもJMXコンソールを探そうとするアクセスが来ていたことが分かります。

HEAD /jmx-console/（以下、文字列が続く）

JBossに対する攻撃の流れ

　JBossに対する攻撃では、アクセス制御に不備があるJMXコンソールを探しだし、それに対して以下のようなHEADリクエストが送信します。

HEAD /jmx-console/HtmlAdaptor?action=invokeOpByName&（以下、文字列が続く）

　このHEADリクエストが成功すると、サーバに以下のようなバックドアファイルが作成されます。

画面1　バックドアの画像（クリックすると拡大します）

　このバックドアファイルの動きは非常にシンプルです。GETリクエストのパラメータに指定されたコマンドをWebサーバに引き渡し、そのままコマンドを実行することができます。攻撃者はこのWebバックドアを操作して、さらなる攻撃ツールを外部のサーバからダウンロードして、攻撃を繰り返します。

　この攻撃への対策は簡単です。以下の項目を確認してください。

• JBossを使っているか確認する
• 使用しているJBossのバージョンを確認し、CVE-2010-0738の問題に対策済みのものであるか確認する
• JBossの設定を確認し、JMXコンソールのアクセス制御が、特定のメソッドのみに適用されている状態になっていないか確認する
• アクセスログの中からJMXコンソールに対するアクセスを確認する

アプリケーションサーバが狙われる

　今回の攻撃は、アプリケーションサーバのJBossの設定不備を狙ったものでした。

　中には、「JBossを使っていないから関係ない」と思った方もいらっしゃるでしょう。しかし、そんな方こそ注意が必要です。実はここ数年、アプリケーションサーバの脆弱性や設定不備を狙った攻撃が深刻なセキュリティインシデントにつながっているケースが多く発生しているのです。

　例えば、今年4月に発生した大規模な情報漏えい事件の攻撃は「アプリケーションサーバ」の「既知」の脆弱性に対して行われたものといわれています。

　では、既知の脆弱性であったならば、なぜ防ぐことができなかったのでしょうか。ここに、アプリケーションサーバならではの対策の難しさが潜んでいるのです。

　まず、アプリケーションサーバは基幹システムと連携して使われることが多く、ビジネスのIT基盤に密接に関わっているため、脆弱性の存在を認知していても、容易にアップデートできない場合が少なくありません。運用管理に携わった経験のある方ならば、脆弱性の存在を知りつつも、即日アップデート対応ができないITシステムが多くあることは容易に想像できることでしょう。

図1　アプリケーションサーバのセキュリティを取り巻く現状

　一般に脆弱性を把握するためには、脆弱性診断を実施し、既知の脆弱性が存在していないかを確認します。しかしアプリケーションサーバは、システムにおいて黒子的な存在（しかも停止できない存在）になるため、一般的な脆弱性診断の項目に入っていないことも多いのです。

　弊社の情報セキュリティ事故の救済部門「サイバー救急センター」が対応した侵入事件の中には、攻撃に悪用された脆弱性が、脆弱性診断ツールなどの一般的な脆弱性診断の項目に含まれていないケースが何件もありました。簡易的な脆弱性診断だけでは発見できない脆弱性があることを認識してほしいと実感しています。

　もう1つ、アプリケーションサーバに対する攻撃を検知するIDS/IPSシグネチャが、メーカーからリリースされていないことが多々あることも知ってほしいのです。

　サイバー救急センターでサーバ侵入事件の原因を調査した結果、アプリケーションサーバの脆弱性を突かれて侵入されており、それを防ぐIDS／IPSシグネチャも存在しないというケースが、ここ数年何件も発生していました。JSOCではそのたびに、そうした攻撃をセキュリティ監視で検知できるように、オリジナルのIDS／IPSシグネチャ「JSIG（ジェイシグ）」を作成し、対応しています。

　Tomcat、Struts、JBossなどのアプリケーションサーバは、多くの環境で利用されている割に、セキュリティ診断項目やIDS／IPSの検知項目に入っていないことが多々あるため、注意が必要です。ぜひ、自組織の環境を確認してください。

高まる一方のサイバー攻撃に関する注目

サンマの刺身の前でご満悦のHack In The Cafe Fukuoka主催者の花田さん

　最近、連日のようにサイバー攻撃に関する報道が行われていることは、皆さんもご存じでしょう。私も、最近発生しているサイバー攻撃に関する質問を受けることが多くなりました。「Hack In The Cafe Fukuoka」の方と交流するため、先日の九州出張でも、サイバー攻撃に関して熱い議論を交わしてきました。

　これから年末にかけて、セミナー講師としてあちこちに出没する予定です。皆さんと議論できることを楽しみにしています。

　このようなサイバー攻撃に関する議論は、国を巻き込んで盛り上がってきています。特にサイバー攻撃に関する情報共有の議論が熱く行われていますので、次回のコラムではその情報共有について取り上げることを約束して、今夜も情報共有のために飲みに行くのでした。