<< 業務システム、またはSoRとSoEについて | main |

スポンサーサイト

一定期間更新がないため広告を表示しています

| - | - | - |

Apache Struts2脆弱性事件のこと(S2-045, S2-046)

事象

3/6に脆弱性S2-045 (CVE-2017-5638)が公表されて以来、3/10に公表されたGMOペイメントゲートウェイ (GMOPG)を皮切りに、複数の企業・団体で、情報漏洩が発覚した。

日本語情報として、以下が掲載されたのが3/8〜3/9で、GMOPGが調査を開始して、Web Application Firewall (WAF)での不正リクエストの遮断および、システムを全停止してネットワーク未接続状態にあったバックアップシステムへの切替えを行ったのは、3/9夜から3/10未明とのことなので、対応は極めて迅速だったと思われるだけに、被害が出てしまったことは残念に思われる。

他の企業・団体では、概ね一週間程度で対策完了した様子である(LAC)。比較的速やかに対策が進んだのは、以下の事情があったためと思われる。

GMOPGが、速やかにセキュリティインシデント発生を外部に公開したことは、被害の拡大防止に大きな効果があったことだと思う。しかし、対策着手から実施までに数週間掛かってしまい、事故を起こしてしまった事例(JINS)もあったことから、いかに早急に本番適用できるかが重要であったかがわかる。

脆弱性S2-045とStruts2について

この事象S2-045は、リモートコード実行(RCE)に分類される脆弱性で、リクエストヘッダの'Content-Type'に仕込まれたコードがそのまま実行されてしまうというものだ。その後、'Content-Dispostion' / 'Content-Length'でも同様の事象が発生することが報告された(S2-046)。通常、Javaの場合はコンパイル型言語なので、この手の脆弱性が顕在化することは少ないのだが、Strutsの場合は、Object-Graph Navigation Language (OGNL)という式言語が導入されており、インタープリタ型言語のように記述されたコードを動的に実行できて、これが脆弱性の温床になっているらしい。

そもそも、Struts2は、J2EE時代にデファクトスタンダード的な位置づけであったStrutsが古びてきたことから、最新のJavaEE仕様を活用して、生産性を高めることを目的として開発しなおされたものであるが、以下のような理由で、Struts 1.x系ほどには普及しなかった。

  • Struts 1.x系と互換性が無かったこと
  • JavaEE自身がフレームワークとして充実してきたこと
  • Spring MVCをはじめとしたモダンなフレームワークが多く登場したこと
  • 脆弱性が多かったこと

上記のようなことから、2017年現在では、システム開発に当たってStruts 2.x系を敢えて選択することはまず無いと思われるが、2007年2月のStruts 2.x系初版GA以降、2013年4月にStruts 1.x系がサポート終了(EOL)する前後の時期までに開発されたシステムでは、Strutsの名前を継承したフレームワークであったこともあり、採用されることがそれなりにあった。

この事件の教訓

適切な技術・製品を選択すること

結果だけ見ると、当時、Struts2を選択したことは、最良の判断ではなかったと言って良いと思う。もちろん、それは結果論・後知恵であるし、Struts2に限らず、なんの製品・技術についても、そして誰しもが遭遇し得ることである。

しかし、なるべくこのようなことにならないように、何らかの技術・製品を採用するときには、機能要件を満たすかどうかだけではなく、「製品ドキュメンテーション・サポートは十分か」、「十分に枯れていて安定しているか」、「ユーザーグループは活発か」、「業界トレンドに沿っているか」、といった評価・判断が必要であると云える。

セキュリティ・インシデント発生時に速やかに対応するための能力

そして、何を選択するにしても、脆弱性は日々発見されているわけであるから、今回の、脆弱性情報の公開から最初の大規模被害が報じられるまでの時間の短さを鑑みるに、少なくともインターネットに公開されたシステムを持つ企業では、以下の能力が必要だと云える。

  1. 自システムを知っていること
    • 各システムで使われている製品・バージョンを把握しておくこと
    • 各システム・各製品のサポート担当者を明確にしておくこと
  2. 脆弱性情報をタイムリーに知れること
    • 当該製品の脆弱性情報をタイムリーに入手できること
    • 脆弱性情報の深刻度・優先度を正しく判断できること
  3. 脆弱性情報に対して、該当するかどうかの調査・判断を迅速に行えること
  4. 暫定対応策を速やかに本番適用できること
    • コードの変更・ビルド・リリースを迅速に行えること
    • 変更後のテストを迅速に行えること
  5. 最悪の場合は、システムを停止する判断を迅速に行えること

速やかに対応するために必要なこと

上記の能力を実現するためには、「システム部に必要な能力を持つ要員を必要な量だけアサインすること」、「システム変更・システム停止を含む判断を迅速に行える権限を与えること」が必要になる。

特に権限については重要で、通常の、「書類を作って、エビデンスを添付して、承認印を回して、会議して」、といったプロセスを何週間も経ているようでは間に合わない。できるだけシステム稼働させたいユーザ部と、情報漏洩するくらいならシステム停止したい経営側との要求が競合するため、システム部が板挟みになって機能不全に陥らないように、必要な権限を与える必要がある。システム部としては、重責を負うことになるので、組織的に速やかな判断を下せるように、セキュリティインシデント発生時に適用する緊急プロセスを設ける必要がある。

速やかな本番適用を実現するためには、システム的な機能として、以下のようなものが必要になる。

  • コードリポジトリ変更、ビルド、リリース・デプロイを迅速に行うDevOps環境
  • システムのリグレッションテストを迅速に行うテストツール実行環境
  • 論理障害・改竄後の復旧に備えたシステムバックアップ
  • できれば、サービス提供を代行可能なバックアップシステム

「脆弱性が多い・評判が悪い製品は他の製品へ変更する」、「セキュリティパッチをタイムリーに適用する」、「外部からの入力文字列を複雑な処理系へサイニタイズ・妥当性検証せずに渡さない」、「アプリケーションサーバ起動ユーザの実行権限を絞る」、「データは階層化して必要な場所に適切な権限で必要な期間しか保存しない」、「WAF・FW・IPS・IDSといったソリューションを適用して検知・防御する」、といった基本的な取り組みは重要であるし、教育、施錠管理・入退室管理、監査ログの取得と保護、データや通信経路の暗号化といったベタなものと合わせて実施するべきである。

しかし、今般のような緊急性が高い事象については、上記のような基本的なお作法・ガイドラインへの準拠に加えて、「緊急性が高いことを認識する能力」と、「最低限度の暫定対応策を迅速に実現する能力」が求められる。

(参考)基本的な取り組みについてのガイドライン

| 日記 | comments(0) | trackbacks(0) |

スポンサーサイト

| - | - | - |
コメント



この記事のトラックバックURL
http://msugai.jugem.jp/trackback/1086
トラックバック
CALENDAR
Sun M T W T F Sat
      1
2345678
9101112131415
16171819202122
23242526272829
3031     
<< July 2017 >>
WATCH
SEARCH THIS BLOG
LATEST ENTRIES
CATEGORIES
SELECTED ENTRIES
RECENT COMMENTS
RECENT TRACKBACKS
Twitter
MY WEB SITES
PROFILE
ADMIN
MOBILE
qrcode
ARCHIVES
SPONSORED LINKS