2014/04/27 このエントリーをはてなブックマークに追加 はてなブックマーク - 【Struts脆弱性】サルでも分かるStrutsのClassloader脆弱性(CVE-2014-0094)(CVE-2014-0112)

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

カテゴリ: ,


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




strutsののClassLoader脆弱性



  • セキュリティがよく分からない。簡単に説明してほしい人。
  • どう対処すれば良いか分からない人。
  • 事情がよくわからないプロマネとかチームリーダーの人。




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


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


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


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


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


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

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



    Struts1系のソースを軽く確認しましたが、リクエストパラメーターをほぼ全部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財団は何もしてくれないの?


  • Struts2系については対応する。でも1系、お前は別だ
  • 対応の仕方はなんというか付け焼き刃。脆弱性が見つかる度にいたちごっこになる予感



  • 「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ばかりでなく、
    他のフレームワークを利用するノウハウの蓄積と技術者の習熟が課題となるのではないかと思います。











    5 件のコメント:

    匿名 さんのコメント...

    なるほど。
    これが原因でみんなてんてこ舞いになっていたのか。
    いたちごっこは永遠に不滅ですね笑
    XSSも発行出来るサイトもまだまだあるしな~

    匿名 さんのコメント...

    わかりやすい解説ありがとうございます。
    すばらしい。

    yy_yank(やんく) さんのコメント...

    >匿名さん(2014年5月1日 22:19)
    やっぱり色んなところで話題になっているみたいですねー。
    そうですね、不滅ですね笑
    コメントありがとうございます!

    yy_yank(やんく) さんのコメント...

    >匿名さん(2014年5月3日 9:13)
    褒めていただき、恐縮です、、、汗
    引用とかがほとんどですし、たいした事書けてないですが。。
    コメントありがとうございます!

    師子乃 さんのコメント...

    初めまして。

    脆弱性未対応のシステムは大変ですね。

    コメントを投稿

    GA