Apache Struts2の脆弱性から、システム開発・運用の現場は何を学ぶべきか？

近年のStruts2の動向

エンタープライズ・システム部でITアーキテクトをしている藤本です。

Apache Struts2でリモートから任意のOSコマンドを実行できてしまう脆弱性（S2-045、S2-046）が立て続けに公表され、問題になっています。読者のみなさまは2013年4月にもStruts1およびStruts2に立て続けに重大な脆弱性が見つかったことを覚えているでしょうか？

• Apache Struts 2の脆弱性が、サポート終了のApache Struts 1にも影響
  ～国内でいまだ大量稼働するStruts 1利用企業に、直ちに緩和策を～

あれから4年、今またStruts2（S2-045、S2-046）への攻撃が猛威を振るっています。

• Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について
• 【続報】Apache Struts 2における脆弱性 (S2-045、CVE-2017-5638)の被害拡大について

Struts2（2.3.x系）は、2014年4月から2017年3月までの36か月の間に、14回のリリースが行われました。およそ2.6か月に一回の頻度でバージョンアップを実施したことになります。そのうち、セキュリティ関係のアップデートとして、26件の脆弱性の修正がありました。

Version Notes 2.3.x

• Version Notes 2.3.32
• Version Notes 2.3.31
• Version Notes 2.3.30
• Version Notes 2.3.29
• Version Notes 2.3.28.1
• Version Notes 2.3.28
• Version Notes 2.3.24.3
• Version Notes 2.3.24.1
• Version Notes 2.3.24
• Version Notes 2.3.20.3
• Version Notes 2.3.20.1
• Version Notes 2.3.20
• Version Notes 2.3.16.3
• Version Notes 2.3.16.2

参照元：Migration Guide

Security Bulletins

• S2-021- Improves excluded params in ParametersInterceptor and CookieInterceptor to avoid ClassLoader manipulation
• S2-022- Extends excluded params in CookieInterceptor to avoid manipulation of Struts' internals
• S2-023- Generated value of token can be predictable
• S2-024- Wrong excludeParams overrides those defined in DefaultExcludedPatternsChecker
• S2-025- Cross-Site Scripting Vulnerability in Debug Mode and in exposed JSP files
• S2-026- Special top object can be used to access Struts' internals
• S2-027- TextParseUtil.translateVariables does not filter malicious OGNL expressions
• S2-028- Use of a JRE with broken URLDecoder implementation may lead to XSS vulnerability in Struts 2 based web applications.
• S2-029- Forced double OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution.
• S2-030- Possible XSS vulnerability in I18NInterceptor
• S2-031- XSLTResult can be used to parse arbitrary stylesheet
• S2-032- Remote Code Execution can be performed via method: prefix when Dynamic Method Invocation is enabled.
• S2-033- Remote Code Execution can be performed when using REST Plugin with ! operator when Dynamic Method Invocation is enabled.
• S2-034- OGNL cache poisoning can lead to DoS vulnerability
• S2-035- Action name clean up is error prone
• S2-036- Forced double OGNL evaluation, when evaluated on raw user input in tag attributes, may lead to remote code execution (similar to S2-029)
• S2-037- Remote Code Execution can be performed when using REST Plugin.
• S2-038- It is possible to bypass token validation and perform a CSRF attack
• S2-039- Getter as action method leads to security bypass
• S2-040- Input validation bypass using existing default action method.
• S2-041- Possible DoS attack when using URLValidator
• S2-042- Possible path traversal in the Convention plugin
• S2-043- Using the Config Browser plugin in production
• S2-044- Possible DoS attack when using URLValidator
• S2-045- Possible Remote Code Execution when performing file upload based on Jakarta Multipart parser.
• S2-046- Possible RCE when performing file upload based on Jakarta Multipart parser (similar to S2-045)

参照元：Security Bulletins

この数字は個人的な意見としては、多くもなく、少なくもない。というのが実感です。世の中には、頻繁に使用されているOSSでもっと多くの脆弱性が公表されたものもあるからです。

しかし、Strutsプロジェクトの脆弱性に対するこれまでの対応は、付け焼刃的な印象がぬぐえません。Security Bulletinsの2013年4月以前の対応に目を向けてみても、S2-005の際に悪意のあるパラメータを除外するためにParameter Interceptorの初期パラメータ(excludeParams)にNGワードを追加するという軽減策が提示されました。その後、S2-20の際にはさらにNGワードを追加するという提示がなされています。この対応をみていると、どうしてS2-005の修正の際に全体を見渡したうえで、最適な修正を行うことが出来なかったのだろうかと思ってしまいます。

なぜ、Apache Struts2の脆弱性が見つかると狙われるのか

他のOSSフレームワークでも脆弱性は公表されているのに、なぜこれほどStrutsの脆弱性が話題になるのでしょうか。多数のWebシステムでStrutsが使われているというのも事実ですが、それ以外にも私は次のように考えます。

1. Strutsを使用していることがわかりやすい

Strutsには、Struts1系とStruts2系があります。Struts1はすでにEoL(End Of Life)を迎えています。よく誤解されますが、Struts1とStruts2は全くの別物です。Struts1からStruts2に移行するには単純にフレームワークをバージョンアップすれば良いというわけにはいきません。しかしながら、Struts1とStruts2には共通点があります。URLを確認することで、Strutsを利用している事がわかってしまう、という点です。具体的には、Struts1の場合はURLの一部に「.do」が、Struts2には、「.action」が使われます。Googleなどの検索サイトでURLのパターンを検索ワードとして検索することで、Strutsを使用しているWebサイトを簡単に検索することができます。これでは、自らStrutsを使っていますよと公表しているようなものです。

2. 任意のコードを実行される類似の脆弱性が多い

Struts2は上述の通りこの間に8件の「任意のコードを実行される脆弱性」が発見されています。またその大半はOGNLによるもので、攻撃コードが類似しており流用が可能です。
任意のコードが実行できるということは、サーバ上にバックドアを仕込んだり、バックドアユーザを作成するなどありとあらゆる攻撃が可能になるため攻撃者にとっても旨みがあります。

参照元：Apache Struts2 の脆弱性対策情報一覧

Strutsを使うために何を準備しておく必要があるのか

Strutsを導入するメリットの一つに、費用（導入費、開発費）を抑えることがあるでしょう。 また、ひと昔前は、JavaのフレームワークといえばStrutsがデファクトスタンダードな時代がありました。フレームワークの選定にあたり、ひと昔前の状況だけで判断し、「これを選択しておけば間違いないだろう」という意識をお持ちではないでしょうか。

StrutsのようなOSSは、ソフトウェアを利用したことにより発生する損害などは、なんら責任を負わないとライセンス上に定めています。そのことを十分に理解し、使用していくことが今、改めて求められているのではないでしょうか。

では、どのような準備ができていればよかったのでしょうか？私は、以下の点が非常に大事だと思います。

1. Struts2のリリース情報および脆弱性の情報を適切に入手する

どのくらいのシステム運営者や開発者が、使用しているライブラリの提供サイトを定期的に訪問し、機能拡張の情報や脆弱性情報を収集しているでしょうか。情報の入手が遅れるとその分、（当たり前の話ですが）対応も後手になります。システムを作って終わりではなく、利用しているライブラリの種類やバージョンの管理、リリース情報や脆弱性情報の入手を適切にできる仕組みと体制の構築が必要だと思います。

2. Struts2のリリースに合わせてシステムに適用を実施する

上述した通りStruts2は、比較的短い期間でバージョンをアップしています。そのバージョンアップの際に適切にバージョンを上げていかないと、今回のような重大な脆弱性が見つかった場合、システムに与えるインパクトが大きくなり適用が難しくなります。よく聞くのが、軽微なリリースの場合にはバージョンアップせず、ある程度まとめてバージョンアップを行う、という運用です。いくら軽微だからと言って長期間放置してしまうと、いざと言うときに適用できなくて困ってしまいます。
こまめに修正バージョンを適用しておくことが、重大な脆弱性が見つかった場合に即時対応できるかどうかの試金石の一つになります。

3. テストの自動化に取り組む

こまめにバージョンを適用する必要があることは、わかっていても難しいのではないでしょうか。それは、ライブラリをバージョンアップする毎に、再度テストをやり直す必要があるからです。これには当然、コストも期間もかかります。
これらを解決するには、テストの自動化が必須になります。テストを自動化しておけば、頻繁にバージョンアップしたとしても、すぐにテストを実施し短期間、低コストで最新版の提供が可能になります。

4. セキュリティ対策機器の導入・監視をする

セキュリティ対策機器の導入の目的は、「事前/事後」対策の二面あります。事前対策は、攻撃によるセキュリティ事故を減らすのが目的です。一方、事後対策はセキュリティ事故が起きた際の被害を最小限に抑えたり、アプリケーションをバージョンアップするまでの間の軽減策として用いたりします。もしもの時に備えておくことが大事になります。

5. サイトを止めることも準備しておく

どのようなフレームワークでもソフトウエアである以上、潜在的な不具合があり、新たな脆弱性が公表されることは否定できません。やはり、事前にどのような状況になったら、システムを止めるのかなどのセキュリティ事故発生時の対応基準を明確にしておくことが必要です。いざというときに、システムを止める基準がなく、だらだらとシステムを運営した結果、被害が広がりお客様により大きな迷惑をかけてしまうケースが多く見受けられます。

最後に

Struts2の脆弱性が話題に上がると、必ずStruts1への影響は？という話を耳にします。Struts1は、すでにEoLを迎えています。影響があるのか、ないのかはEoLなので公式な情報など出るはずがありません。これからずっと、びくびくしながら使い続けますか。

正しい認識をもってStrutsならびにOSSを使っていただければと思います。そして認識が間違っていたり、状況が変化したのであれば、勇気をもって意見具申する責務がシステム開発や運用に携わっているエンジニアにはあるのではないでしょうか。