覚書：Struts・Apache Common FileUploaderの脆弱性の確認方法について

初めに一言言っておく。
悪用スンナ。
軽い気持ちで試すな。重い気持ちでも試すな。
自前のシステムだけでのみ試すようにしろ。

この攻撃をしたら迷惑を被る人たちがいることを忘れるな。

あと、Webシステム管理者は未対策なら早く対策しろ。手前の安心をさっさと確保しとけ。

（１）Apache Struts において ClassLoader が操作可能な脆弱性

Strutsの仕組みを利用してJavaのObjectクラスgetClassLoaderメソッドを呼び出すことにより、Actionクラスのインスタンスに対して操作ができてしまう。んで、getter・setterに任意にアクセスできる。
Struts2は対策モジュール有り。Struts1は対策モジュールはないが対策方法有り。
パラメタを、以下のように書くと

/action.do?class.classLoader.xxx=123

Actionクラスに対して、getClass().getClassLoader().setXxx(123);と実行されてしまう。getterも同じく。任意の値を書き込んだり、見えてはいけない情報を取得することが可能となる。

getter・setterの名前が分からなければ、実行しようがないと思われるかもしれないけれど、穴があればいつかはこじ開けられる可能性はある。そんなリスクはほっておくべきではない。

対処方法はいくつかあるけど、パラメタ名がclassならはじくというのは同じ。

Struts1の対処方法でstruts-config.xmlでパラメタではじく方法は、以下のアクセスに対応できないとか。

/action.do?aaa.class.classLoader.xxx=123

Listenerクラスを用意してパラメタ名classがあったら例外発生するようにしておいて、WEB-INF/web.xmlの<listener>にListenerクラスを呼び出すようにすることで対処OK。

再現方法は、上記にあるようなパラメタを設定したURLをWebサーバ（StrutsだからAPサーバというべきか）に食わせること。
getter・setterがないならclass.classLoaderでも入れとき。

（２）Apache Commons FileUpload および Apache Tomcat の脆弱性

HTTPヘッダにあるboundaryの文字列が4092バイト以上だと、無限ループに入ってCPU使用率が100%に張り付く問題。
再現方法は、Burp Suiteなどのツールを使って、FileUploadするときにWebサーバに投げる内容を横取りしてBoundaryの文字列を4092バイト以上に書き換える。

Burp Suiteについては、Security Baseさんの「Burp Suiteの導入」が詳しい。

対処方法は、commons-fileupload.jarを対策版に入れ替え。commons-io.jarも必要になるかも。

最後に念を押すが、くれぐれも試すなよ。
サーバを落とすことによって、お客さんから怒られたWebサーバ管理者がお前の居場所を突き止めて訴えるってこともありうるからな。
サーバのログを見ていけば、突き止められる可能性は0ではないぞ。