【Struts脆弱性】サルでも分かるStrutsのClassloader脆弱性(CVE-2014-0094)(CVE-2014-0112)

2019/07/05追記:
7payの件はStrutsの脆弱性全く関係ありません。

　対象読者

セキュリティがよく分からない。簡単に説明してほしい人。

どう対処すれば良いか分からない人。

事情がよくわからないプロマネとかチームリーダーの人。

　前提

Strutsに脆弱性が発見されました。


IPA - Apache Struts2 の脆弱性対策について(CVE-2014-0094)(CVE-2014-0112)


簡単に言うと（対処せずに使用すると）Struts2系とStruts1系はやばい。SAStrutsはOK。S2Strutsはアウト。
その他にもリクエストパラメーターをリフレクションではめ込むようなFWは全て懸念される事象です。


何が一番やばいかといったらStruts１系。


2014年４月ですでにサポートが終了している事から、今後脆弱性が発生した時に助け舟が無い訳ですね。
これは、今回の脆弱性に限った話ではないです。ずーっと付いて回る問題。
そういった意味でStruts１系は別の問題をはらんでる訳です。


Strutsベースの社内オレオレFWとかも、もちろん該当します。
独自FWや、OSSのFWなんかも一度確認する方が良いかもしれません。
おそらく、各サイトから情報が公開されるのではないかと思います。
FWとは直接の関係はないですが、NTTデータとか本気出すらしいですね。

サポート切れ企業に脅威、システム構築ソフト「ストラッツ１」、自社対策へ。



Struts１系のソースを軽く確認しましたが、リクエストパラメーターをほぼ全部BeanUtils.populateでシュバババーンとはめ込んでるわけですね。
（大雑把に、ActionServlet#doGetーActionServlet#processーRequestProcessor#processーRequestUtils#populateーBeanUtils#populateという流れでした）
そのプロセスが危ない。別にBeanUtils単体としては何も問題ない。
（ちょっとクセのある）優秀なヤツだと思います。

　詳しい内容

分かりやすい記事を載せておきます。
正直、この内容が理解出来るのであれば、本エントリは読む必要はありません。


piyologさん-Strutsの脆弱性CVE-2014-0094について改めてまとめてみた
WAF Tech Blog - 例えば、Strutsを避ける

あと、ひがやすをさん（Seasarつくったすごい人）のエントリも載せた方が良いですね
ひがやすを blog - StrutsのClassLoader脆弱性はSAStrutsに影響しません

さて、いかがでしょう。これから僕の出来る限り噛み砕いて説明しようと思います。

　難しいので、すんごく噛み砕く

　　どのFWが対応しないとヤバい？

Struts2系とStruts1系

S2Struts

Strutsをラッピングした自社製FW

それ以外にもリクエストパラメーターを全てリフレクションで自動でセットするFW（もしかすると）

　　何がヤバい？

リクエストパラメータの書き換えによってAPサーバーの設定を外部から変更出来る（CSRFとかその類い）

つまり、ブラウザでURLのところいじってしまえば好き勝手される

勝手にアプリケーションに悪質なページを追加して、悪意のあるユーザーに機密情報の吸い出しなどされる可能性がある

リモートアクセスされてOSコマンドを実行される可能性あり（OSコマンドインジェクション）

　　例えば、どういう操作？

URLバーの「http://XXXXX:8080/XXXXAction.do?」の後に「class.classloader.何かのプロパティ=危ない接続先」という風に書き換えられる

cookieからとか怪しいページに飛ばされて、そこからリクエストをスクリプトで飛ばされる等も考えられる

　　apache財団は何もしてくれないの？

Struts２系については対応する。でも１系、お前は別だ

対応の仕方はなんというか付け焼き刃。脆弱性が見つかる度にいたちごっこになる予感

　行うべきセキュリティ対策

「classloader」という文字列を含むリクエストパラメータを防ぐ必要があります。
Struts1系なら、サーブレットフィルター等が良いでしょう。正規表現で一致する場合は
不正なリクエストと判断すべきです。
正規表現はpiyologさんのエントリから引用します。

正規表現	公開元	影響緩和の有効性
(^|\W)[cC]lass\W*9	MBSD・LAC	有効
(.*\.|^|.*|\[('|"))(c|C)lass(\.|('|")]|\[).*	Apache Software Foundation	有効

実装するとしたらこんな感じかな？(動作確認してません。ごめんなさい)

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;


public class RequestCheckFilter implements Filter {

  public void init(FilterConfig conf) throws ServletException {}

  
  public void doFilter(ServletRequest req, 
              ServletResponse res, FilterChain chain) 
              throws ServletException, IOException {

    // 正規表現パターンを生成
    Pattern p = Pattern.compile("(^|\W)[cC]lass\W*9");
    // リクエストパラメータ でループ
    Enumeration e = request.getParameterNames();
    while ( e.hasMoreElements() ) {
        String target = (String) e.nextElement();
        Matcher m = p.matcher(target);
        // パラメータに不正な文字列があった場合例外をthrow
        if (m.find()){
            throw new Exception("不正なリクエストパラメータです")
        }
    }
    
    
    // 後続実行
    chain.doFilter(req, res);

  }

  public void destroy() {
  }
}

Struts2系ではapache財団よりtruts-default.xml内のexcludeparamsタグの内容を変更して、
エスケープしてはじく方法が提示されています。

<param name="excludeParams">^class\..*,^dojo\..*,^struts\..*,^session\..*,^request\..*,^application\..*,^servlet(Request|Response)\..*,^parameters\..*,^action:.*,^method:.*</param>

　まとめ

今回の問題はリクエストパラメータをはじくという対処で解決するものではあります。
しかし、今後もこういった脆弱性が発見され続けるでしょう。


プロジェクトとしては、脆弱性が発見された時に
対応するフローというのをしっかりと確立しておく必要があります。
特にStruts1系に関しては、前述の通り、今後サポートされません。
今から新規にシステムを作成する場合はセキュリティ観点からすると、Strutsは厄介かもしれません。


ただ、日本のJavaを用いたSIにおいては
Strutsのノウハウの蓄積が多く、現行システムに関しても
Strutsで動いているものが多いと思います。
枯れたフレームワークと言われているStrutsばかりでなく、
他のフレームワークを利用するノウハウの蓄積と技術者の習熟が課題となるのではないかと思います。