特殊なエンコーディングには気をつけよう　Apache Tapestryにおける“注意すべき仕様”　

登壇者の自己紹介

諌山貴由氏：始めたいと思います。最初に自己紹介です。私は、諌山貴由といいます。三井物産セキュアディレクションに所属しています。2008年ぐらいからセキュリティに関わる仕事を行っていまして、趣味は旅行です。

私はふだんWebアプリケーション診断を行っています。今回はその中で見つかった特殊な事例を紹介したいと思います。MBSD（三井物産セキュアディレクション）では定期的にライトニングトークを開催していて、日々の業務などで得た知見をチーム内に共有するという取り組みを行っています。今回の内容は、その一部となっています。

セッションにおける注意点

この内容は、以前MBSDのセキュリティ勉強会で実施した内容と同一になっています。注意点として、今回の内容には不正アクセス禁止法などに抵触する可能性のあるものが含まれていますが、犯罪行為を助長するものではないという点をご理解ください。

また、資料に一部、攻撃コードなどが含まれていますが、自分の管理下にないサーバーで実施すると、逮捕されることも考えられますのでご注意ください。

今回の内容は、実際の案件を基に作成していまして、案件の特定を避けるためにリクエストやレスポンスを書き換えています。この関係で矛盾した状態になっている可能性がありますが、あらかじめご了承ください。

Webアプリケーションにおける脆弱性診断

一般的にWebアプリケーション脆弱性診断ですが、基本的にURLエンコードのように、アプリケーションが解釈できる形式で送信する必要があります。

そのほかにも、エンコードとしてJSONやXMLなどがあると思いますが、これに沿わないような形式で送った場合、脆弱性を検出できない可能性があります。

オープンリダイレクト脆弱性を発見

きっかけは、このサイトにて変わったURLがありました。「$N」という、ちょっと変わったパスが含まれていました。「これ、何だろうな？」と気になっていました。

（スライドを示して）このサイト、ログインの前に「redirect」というパラメーターがあったので、その値でオープンリダイレクトがいけないかと思ってURLを書き換えてアクセスしてログインを行うと、リダイレクトされました。

このログインするタイミングで、特殊なエンコードがされていて、その値が「$002f」。「2f」はスラッシュ(/)の値と等価の値なのですが、そのスラッシュ(/)が「$002f」という値に変換されていました。「これ、何だろうな？」と気になりました。

普通に、URLエンコードだとダメなのか？　という疑問があって、まずは「%2f」に変換してリクエストを送ったのですが、これだとオープンリダイレクトが成功しない状態でした。

要は、「$hhhh」というHEXでエンコードした形式にしないと見つけられない脆弱性があると推測ができました。ただし、まだログインだけの問題の可能性があるので、さらに調査してみました。

Apache Tapestryの仕様であることがわかった

システム全体の問題であれば、パスやそれ以外のパラメーターのところで、この$の形式を解釈するだろうということで、探してみたところ、パスのところで「mbsd」という値を送っていました。その「d」の値をHEXにして「$0064」にして送ったところ、同じ挙動を示しました。これによって、システム全体の問題だろうなという推測が立ちました。

このサイトですが、レスポンスから「Apache Tapestry」ということがわかっていました。ただこれが、フレームワークの仕様なのかどうかまでは確信を持てていなかったです。

また、このサイトは、デバッグ機能が有効になっていて、とあるURLにアクセスすることでスタックトレースが取れる状態になっていました。

パラメーターにフレームワークが解釈できない値を指定した後、スタックトレースを見てみました。そうすると「org.apache.tapestry5」のパッケージ名が出力されていたので、Apache Tapestryの問題だろうなと考えました。

データベース内の情報も取れるだろうと確信

アプリケーション全体の仕様がある程度わかったので、パラメーターに片っ端から記号や不正な値を入れていきました。すると、シングルクォート($0027)を入れたところでスタックトレースに「PostgreSQL」のExceptionが出て、これ、SQLインジェクションの脆弱性が疑われるということでめちゃめちゃ怪しい状態でした。

念のため関数なども動くかを確認したところ、動くことが確認できて、データベース内の情報も取れるだろうなというのが推測されました。

普通だとブラインドSQLインジェクションでデータを抜くことができるかと思いますが、今回の場合、スタックトレースが出ているので、castを利用したバージョン取得方法を利用できるので、そちらを利用して、バージョン取得に至りました。

Tapestryソースコードから特殊なエンコードの仕様を調査

この特殊なエンコードですが、ソースコードから調査してみました。調査を行ってみたところ、（スライドを示して）ここに記載の大文字、数字、あと一部の記号以外はUnicodeのエンコードがされていることがわかりました。

それ以外にも特殊な値がありました。（スライドを示して）HEX($hhhh)はUnicodeでエンコードですね。その下が、「$N」で、これはJavaのnull文字を表しています。そのほかに「$B」でブランク（空文字）ですね。「$$」で「$」のエスケープです。

話の最初に「$N」というのがあったと思いますが、その「$N」がnullだったということが、ここで判明しました。

Apache Tapestryのフレームワークであるかどうかを意識しよう

特殊なURLエンコードですが、これは特殊な仕様なので、社内のツールだとSQLインジェクションの検出ができませんでした。これは当然ほかのツールでも同様だと考えられます。これによって脆弱性を見過ごす可能性がありますよね、という話になります。

当然SQLインジェクション以外のディレクトリトラバーサルとか、クロスサイトスクリプティング、先ほどあったオープンリダイレクトの脆弱性についても可能性があり、基本として、Apache Tapestryのフレームワークであるかを意識しましょうということになります。

Apache Tapestryは、レスポンスにバージョンが含まれていなくても判別がある程度可能です。具体的には、Apache Tapestryは「t:formdata」というちょっと特殊なパラメーターを含んでいます。

この値はなんなのかというと、中にJavaのシリアライズのデータが含まれていて、このパラメーターが含まれていると、Apache Tapestryと判断してよいと思います。

私が報告した脆弱性ではありませんが、過去にMBSDが、このパラメーターでデシリアライズの脆弱性を報告しています。現在はHMACによる改ざんチェックが入っているので、これは対策されているとみなしていいかと思います。

「YaguraExtender」という「Burp suite」の拡張ツールを作成

「Burp suite」が、日本語のエンコーディングを解釈しないのを、みなさんよくご存じだと思いますが、私はそれを解決するため「YaguraExtender」というツールを作成しています。今回、先ほどの特殊なエンコードに対応しました。

特殊なエンコード以外にも変換する時の文字コードを指定して、URLエンコードやBase64などのエンコードを行ってくれるという機能を作っています。こういうちょっと便利なものを実装しています。

まとめ

最後に、まとめです。「気になるものはフレームワークまで調査を広げてみよう」ということ、「Tapestryに限らず、特殊なエンコーディングだと感じた時は注意しよう」ということです。以上で終わりです。

（会場拍手）