セキュリティアナリストコラム
川口洋のセキュリティ・プライベート・アイズ(37)
アプリケーションサーバの脆弱性にご注意を
川口 洋
株式会社ラック
チーフエバンジェリスト
CISSP
2011/11/29
■JBossの脆弱性を突くワーム出現
こんにちは、川口です。最近、アプリケーションサーバの「JBoss」の脆弱性を突くワームが出現しているのですが、標的型攻撃のニュースに隠れてか、世間では思いのほか話題になっていないようです。
今回はJBossを狙った攻撃を取り上げ、アプリケーションサーバが狙われている理由について解説します。
| 【関連リンク】 JBossの脆弱性を突くワームが流通、パッチ適用の不備狙う http://www.itmedia.co.jp/enterprise/articles/1110/24/news011.html JBoss(Wikipedia) http://ja.wikipedia.org/wiki/JBoss |
■狙われる「JBossの設定不備」
JBossにはJMX(Java Management Extensions)コンソールという管理画面が付属しており、このJMXコンソールのアクセス制御不備が攻撃のターゲットになっています。
| 【関連記事】 社内システムのセキュリティとアクセス制御の常識(@IT Java Solution) http://www.atmarkit.co.jp/fjava/rensai4/enterprise_jboss09/02.html |
通常、このような管理画面にはアクセス制御が施されており、インターネットからアクセスできるような状態になっているはずはない……のですが、私がさらっとGoogleで検索しただけでも多数のJMXコンソールを探し出すことができました。いったいなぜでしょうか?
手元の環境にJBossをインストールしてみてください。設定ファイル/deploy/jmx-console.war/WEB-INF/web.xmlを参照すると、以下のように、設定がコメントアウトされた状態になっています(バージョンによって異なる可能性があるので注意してください)。
|
JBoss構築について解説したWeb上のドキュメントやホームページを参照したところ、上記の設定のコメントアウトを外し、JMXコンソールを含む管理画面に関する設定を行うように指示する記載がいくつか見つかりました。
もし、この設定のコメントアウトを外して管理画面を使用した場合、どのようなことが起こるのでしょうか。注目してほしいのは以下の2行です。
|
この2行があることで、GETメソッドとPOSTメソッドに対してのみ、管理画面のアクセス制御が適用されます。つまり、HEADなどの他のメソッドでアクセスすると、アクセス制御が働かず、そのまま管理画面にアクセスできてしまうのです。
JBossを運用しているならば、試しにアクセスログを確認してみてください。もし、以下の文字列で始まるHEADメソッドによるアクセスがあった場合には、あなたのサーバにもJMXコンソールを探そうとするアクセスが来ていたことが分かります。
|
■JBossに対する攻撃の流れ
JBossに対する攻撃では、アクセス制御に不備があるJMXコンソールを探しだし、それに対して以下のようなHEADリクエストが送信します。
|
この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の検知項目に入っていないことが多々あるため、注意が必要です。ぜひ、自組織の環境を確認してください。
| 【関連記事】 川口洋のセキュリティ・プライベート・アイズ(15) 狙われる甘〜いTomcat(@IT Security&Trust) http://www.atmarkit.co.jp/fsecurity/column/kawaguchi/015.html |
■高まる一方のサイバー攻撃に関する注目
| サンマの刺身の前でご満悦のHack In The Cafe Fukuoka主催者の花田さん |
最近、連日のようにサイバー攻撃に関する報道が行われていることは、皆さんもご存じでしょう。私も、最近発生しているサイバー攻撃に関する質問を受けることが多くなりました。「Hack In The Cafe Fukuoka」の方と交流するため、先日の九州出張でも、サイバー攻撃に関して熱い議論を交わしてきました。
これから年末にかけて、セミナー講師としてあちこちに出没する予定です。皆さんと議論できることを楽しみにしています。
このようなサイバー攻撃に関する議論は、国を巻き込んで盛り上がってきています。特にサイバー攻撃に関する情報共有の議論が熱く行われていますので、次回のコラムではその情報共有について取り上げることを約束して、今夜も情報共有のために飲みに行くのでした。
[an error occurred while processing this directive]| Profile |
| 川口 洋(かわぐち ひろし) 株式会社ラック チーフエバンジェリスト CISSP ラック入社後、IDSやファイアウォールなどの運用・管理業務をへて、セキュリティアナリストとして、JSOC監視サービスに従事し、日々セキュリティインシデントに対応。 アナリストリーダとして、セキュリティイベントの分析とともに、IDS/IPSに適用するJSOCオリジナルシグネチャ(JSIG)の作成、チューニングを実施し、監視サービスの技術面のコントロールを行う。 現在、JSOCチーフエバンジェリストとしてJSOC全体の技術面をコントロールし、監視報告会、セミナー講師など対外的な活動も行う。また、YouTubeのlaccotvにて、「川口洋のつぶやき」に出演中。 |
川口洋のセキュリティ・プライベート・アイズ バックナンバー
- 第1回 あの「SQLインジェクション」騒動の裏で(前編)
- 第2回 あの「SQLインジェクション」騒動の裏で(後編)
- 第3回 4月にセキュリティインシデントが急増するワケ
- 第4回 ポートスキャン、私はこう考える
- 第5回 ネガティブか、ポジティブか……それが問題だ
- 第6回 IPSは“魔法の箱”か
- 第7回 夏が来れば思い出す……
- 第8回 クッキーに隠されたSQLインジェクション、対策は?
- 第9回 レッツ、登壇――アウトプットのひとつのかたち
- 第10回 ところで、パッケージアプリのセキュリティは?
- 第11回 ○×表の真実:「検知できる」ってどういうこと?
- 第12回 急増したSQLインジェクション、McColo遮断の影響は
- 第13回 世間の認識とのギャップ――XSSは本当に危ないか?
- 第14回 表裏一体、あっちのリアルとこっちのサイバー
- 第15回 狙われる甘〜いTomcat
- 第16回 分かっちゃいるが難しいアカウント情報盗用ボット対策
- 第17回 米韓へのDoS攻撃に見る、検知と防御の考え方
- 第18回 学生の未来に期待する夏
- 第19回 狙われるphpMyAdmin、攻撃のきっかけは?
- 第20回 ECサイトソフトウェアはなぜ更新されないのか
- 第21回 BlasterやNetsky並み? 静かにはびこるGumblar
- 第22回 新春早々の「Gumblar一問一答」
- 第23回 Gumblarがあぶり出す 「空虚なセキュリティ対策」
- 第24回 Gumblar、いま注目すべきは名前ではなく“事象”
- 第25回 実録・4大データベースへの直接攻撃
- 第26回 ともだち373人できるかな――IMセキュリティ定点観測
- 第27回 不安が残る、アドビの「脆弱性直しました」
- 第28回 Webを見るだけで――ここまできたiPhoneの脅威
- 第29回 曇りのち晴れとなるか? クラウド環境のセキュリティ
- 第30回 9・18事件にみる7つの誤解
- 第31回 2010年、5つの思い出――Gumblarからキャンプまで
- 第32回 ペニーオークションのセキュリティを斬る
- 第33回 東日本大震災、そのときJSOCは
- 第34回 これが標的型攻撃の実態だ
- 第35回 スパムが吹けば薬局がもうかる
- 第36回 アナリストが抱えるIPv6、6つの悩み事
- 第37回 アプリケーションサーバの脆弱性にご注意を
| 川口洋のセキュリティ・プライベート・アイズ 連載インデックス |
- アプリケーションサーバの脆弱性にご注意を (2011/11/29)
標的型攻撃のニュースに隠れがちですが、アプリケーションサーバ「JBoss」を狙うワームが出現し、被害を及ぼしています - Undocumentedなデータ構造体を知る (2011/11/18)
アセンブリコードの解析に取りかかる前に、シェルコードがどうやってAPIのアドレスを取得し、呼び出しているかを理解しましょう - 企業を狙う標的型攻撃――その手口と抜本的な対策 (2011/11/14)
メディアをにぎわせている「標的型攻撃」。どうすればその被害を食い止めることができるのかを考察します - Androidアプリに関する話題から目が離せない! (2011/11/9)
「カレログ」に続き、Androidアプリのセキュリティやプライバシーに関する話題が目立った1カ月
|
|
キャリアアップ
スポンサーからのお知らせ
- - PR -
イベントカレンダー
- - PR -