2012年1月30日月曜日

ホスト型の廉価版WAFであるSiteGuard Liteを評価した

このエントリでは、株式会社ジェイピー・セキュア(以下、JP-Secureと表記)のホスト型WAFであるSiteGuard Liteβ版の評価結果を報告します。SiteGuard Liteは、ModSecurityのようにApacheにモジュールとして組み込むタイプのWAFです。

はじめに

JP-Secure社が本年2月に、廉価なホスト型WAFとしてSiteGuard Liteを販売開始すると発表しています。このβ版を入手して評価しましたので、その内容を報告します。
商用製品の紹介ですので、以下に「重要情報の告知」を示します。
  • HASHコンサルティング株式会社および徳丸浩(以下、単に徳丸浩と記述)は、SiteGuard Liteβ版の評価プログラムに申し込み、β版を無償で提供されている
  • 徳丸浩はβ版提供以外に金品その他の提供を受けていない
  • 本稿執筆時点でJP-Secure社とアフィリエイト契約はなく、その予定もない
  • 評価結果をブログに書くことはJP-Secure社の了解を受けており、執筆内容の制約は受けていない
ただし、徳丸浩はセキュリティを商売にしておりますので、製品を評価した結果がよいものであれば、その製品を販売したいと思っています。そのため、評価記事が宣伝の要素を持つことはあり得ます。できるだけ客観的な評価を心がけますが、上記前提をご了承いただいた上で読者の判断により続きをお読みいただくか、読むのをやめていただければと思います。

SiteGuard Liteとは

SiteGuard Liteは、JP-Secure社がApacheのモジュールとして提供するホスト型WAFで、今年2月から販売開始されます。JP-Secureには元々フル版のSiteGuardがありますので、SiteGuard Liteはその名の通り廉価版という位置づけなのでしょう。SiteGuardのラインナップ比較を下表に示します。

SiteGuard SiteGuard for Server SiteGuard Lite
配置方式 ネットワーク型 ホスト型 ホスト型
実装形態 Proxy Proxy Apacheモジュール
シグネチャ検査
ホワイトリスト検査
Cookie暗号化
セッション管理
クローキング
ライセンス費用 178万円 79万円 約30万円


SiteGuard Liteはシグネチャ検査に特化することで価格を下げた廉価版と言うことになります。

インストール

SiteGuard Liteは商用製品ですのでバイナリでの提供となります。Red Hat Enterprise Linux 4/5/6あるいはCentOS 4/5/6が動作可能ディストリビューションとなっています。筆者としてはUbuntu上でも動作確認してもらえるとありがたいと思いましたので、JP-Secure社にはそう要望しています。
rpmによるインストールは基本的には以下の3コマンドです。

# rpm -Uvh siteguardlite-1.00-beta.i386.rpm
# cd /opt/jp-secure/siteguardlite/
# ./setup.sh

最後のsetup.shはApacheの各種パスなどを指定するものです。その他、SE Linux用のポリシーを必要に応じて適用します。
今回の検証では、Centos6.2を用いました。apacheをyumでインストールした環境では、上記setup.shの実行は、リターンキーを何回か押すだけで終わりました。

使ってみる

それでは、さっそくSiteGuard Liteを用いて各種の攻撃を防御してみましょう。防御対象には、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」(以下、徳丸本)の脆弱なサンプル44-001.php(同書P120)を用いました。ファイル名はbooks.phpとしました。ソースの冒頭を以下に引用します。
<?php
  session_start();
  header('Content-Type: text/html; charset=UTF-8');
  $author = $_GET['author'];
  $con = pg_connect("host=localhost dbname=wasbook user=postgres password=wasbook");
  $sql = "SELECT * FROM books WHERE author ='$author' ORDER BY id";
  $rs = pg_query($con, $sql);
?>
// 以下略
このスクリプトにはSQLインジェクション脆弱性があります。それをSiteGuard Liteで防御してみましょう。
以下は、徳丸本のP121に登場する「個人情報を盗み出す」攻撃です。
http://example.jp/books.php?author='+and+cast((select+id||':'||pwd+from+users+offset+0+limit+1)+as+integer)>1--
以下のようにブロックされています。


しかし、これは典型的な攻撃だから当然のようにブロックするでしょうね。以下、いくつかのトピックスを見てみましょう。

(1)ApacheKillerとhashdosはデフォルトで防御
ApacheKillerhashdosのexploitをかけてみたところ、デフォルト設定でブロックしました。


(2)「完璧なWAF」はどうか
一頃、WAF業界で話題になった「完璧なWAF」に出てくる攻撃についても評価しました。
仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか?プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。
という箇所についてですが、XSS Cheat Sheetに出てくるimg要素によるXSSの攻撃パターンのうちの一つが以下です。
http://example.jp/books.php?author=jav%09ascript:alert('XSS');
これについても、きちんとブロックしています。
次に、SQLインジェクションについてはどうでしょうか。「完璧なWAF」からunion selectに関するくだりを引用します。
SQLインジェクション対応の駄目な例として挙げられるのは、複文などの直接攻撃しか考慮していないケースです。簡単に言うと、master..execなどの直接攻撃のみ禁止しているWAFは甘く、union selectなどのunionインジェクションを考慮したWAFはまだマシであると言えます(攻撃者の観点が分かっているという意図でマシと記載しました)。
このブラックリストを通り抜けるにはコメントを使用します。たとえば、union/**/selectではどうなるでしょうか? 残念ながらほとんどのWAFは通り抜けてしまいます。
マシなWAFは「union select」は考慮するが、「union/**/select」はほとんどのWAFは通り抜けるということですが、SiteGuard Liteはどうでしょうか。
試してみると、
  • union select       … 通り抜ける
  • union/**/select   … ブロックする
あれあれ、「完璧なWAF」とは逆の結果となりました。でも、この方がいいですね。「union select」は普通の英文にも出てきそうなのでブロックすることは不適切で、一方「union/**/select」は通常の英文にはまず出てこないと思われ、攻撃目的である可能性が高いからです。


(3)ライザムーン(LizaMoon)攻撃は防げるか
次に、これも一頃話題になった「新しいタイプのSQLインジェクション攻撃」であるライザムーン攻撃ではどうでしょうか。ライザムーンの特徴である(1)数値型項目に対するシングルクォートを用いない攻撃、(2)MS SQL Serverに対するセミコロンのない複文の特徴を持つ以下のパラメータで試しました。
author=17871+update+employee+set+number%3DREPLACE(cast(
このパターンでも、SiteGuard Liteはブロックしました。

ModSecurityとの比較

ここで、SiteGuard LiteのライバルとなるであろうModSecurityとの比較を試みます。ModSecurityの最新版2.6.3とCore Rule Set(CRS)2.2.3の組み合わせと比べてみました。
実は、今まで挙げてきた攻撃パターンは、ModSecurity(+CRS)もすべてブロックします。こう書くと、「では、無償のModSecurityでもよいのではないか」と思いそうですが、そうではありません。ModSecurityは「止めるべきでない」リクエストも止めてしまいます。つまり、過剰検知(False Positive)が多いのです。
たとえば、ModSecurityは「union select」という並びが入力にあるとブロックしますが、それだけでなく、「unionselect」や「unionAAAselect」もブロックします。すなわち、unionという単語の後のどこかにselectがあると、ブロックされます。
そのような例としてGoogle検索で適当に探した文を以下に示します。以下を入力として与えても、ModSecurityはブロックします。
Providing a credit union is a valuable benefit, and at Southern Select CCU, it will not cost your company a thing.
出展: http://www.southernselectccu.com/JoinUs.aspx (won'tをwill notに変更)
次に、ライザムーン攻撃についてもModSecurityはブロックしますが、以下の単純なパターンでもModSecurityはブロックしてしまいます。
author=17871+update
極めつきとして、ModSecurityは以下もブロックします。
author=夏目漱石
CRSには標準で「英数字以外が4文字連続するとブロック」というルールがあるからです。
さすがにこれでは使えないので、ModSecurityのチューニングとして、過剰検知のルールを無効化してみましょう。
まず、上記をブロックしているルールをModSecurityの監査ログから探します。以下が該当します。

SecRule "ARGS" "@rx \\W{4,}" "phase:2,log,capture,t:none,t:urlDecodeUni,block,id:960024,rev:2.2.3,msg:'SQL Character Anomaly Detection Alert - Repetative Non-Word Characters',logdata:%{tx.0},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:tx.msg=%{rule.msg},setvar:tx.%{rule.id}-WEB_ATTACK/RESTRICTED_SQL_CHARS-%{matched_var_name}=%{tx.0}"
このルールをコメントアウトしてもいいですが、別の方法として、id=960024を無効にすると言うルールを追加しましょう。この方が、ルールのメンテナンス性が良くなります。


SecRuleRemoveById 960024
このチューニングは、後述の性能評価のために必要でした。
一方、SiteGuard Liteでも同様のチューニングが必要になるケースはあり得ます。その場合、WebのGUIからログを確認して、対応するルールの無効化や監視のみへの変更も、Web GUIから可能です。今回の評価では、SiteGuard Liteのチューニングはせず、デフォルト設定で使用しています。

さて、前述のように、ModSecurityとCRSの組み合わせは防御能力は高いように見えるものの、過剰検知が多いのでチューニングなしには使えないのです。過剰検知が多いのはModSecurity本体というよりはCRSの問題ですが、さりとて、CRSを使わないとなるとルールを買ってくるか、自分で作ることになります。すなわち、ModSecurityは無償とはいえ、導入には手間が掛かるということです。


一方、ModSecurityのメリットはなんでしょうか。ことカスタマイズに関しては、ModSecurityの方が優れています。ModSecurity自体はWAFを作るための開発ツールととらえることができます。たとえば、アカウントロック機能をModSecurityで実現することも可能です。しかし、ModSecurity上の複雑なルール作成は大変ですし、ModSecurity本体のバージョンアップに伴い従来動いていたルールが動かなくなる可能性もあります。そのようなModSecurityのバージョンアップの大変さについては、IPAが公開している「WAF読本」のP70~P71にも記載されています。
ということで、ルールの自由度という点ではModSecurityが優れていますが、その自由度を使いこなすのは中々大変であると考えます。

性能評価

次に、性能の評価をしてみました。サーバーマシンのスペックを以下に示します。4年前に19,800円で購入した格安サーバーです。

DELL PowerEdge/SC440
CPU:Pentium Dual-Core 2GHz
メモリ 3.6Gバイトを割り当て
VMware Server上で評価

負荷テストにはApache Benchを用い、以下のコマンドラインを用いました(同時接続=50、リクエスト数=1000)。WAFに負荷をかけるために、余分なパラメータを追加しています。
ab -c 50 -n 1000 "http://example.jp/books.php?author=Shakespeare&zip=113-8663&addr=%E6%9D%B1%E4%BA%AC%E9%83%BD%E6%96%87%E4%BA%AC%E5%8C%BA%E6%9C%AC%E9%A7%92%E8%BE%BC2-28-8&tel=03-1234-5678"
結果を以下に示します。

WAFなし SiteGuard Liteあり ModSecurityあり
秒間リクエスト数 30.05 29.94 27.56
相対性能 100% 99.6% 91.7%

ModSecurityが少し遅いものの、あまり差はありません。その理由は、アプリケーションが遅いため、相対的にWAFの遅延が見だたなくなっているからと予想されます。
そこで、先のスクリプトをチューニングすることにします。ボトルネックは、DB接続をコネクションプールしていないことと予想されるため、pg_connectpg_pconnectに変更してabをかけました。
結果を以下に示します。高速化されたため、リクエスト数を1万にしています。

WAFなし SiteGuard Liteあり ModSecurityあり
秒間リクエスト数 365.34 284.85 127.80
相対性能 100% 78.0% 35.0%

スクリプトが10倍以上高速になったことにより、WAFのオーバーヘッドが目立ち始めましたが、それでも2割ちょっと遅くなるだけで済むというのは、許容できる範囲ではないかなと思いました。4年前の2万円弱のサーバーで280リクエスト/秒出せるのであれば、通常の応用には十分ですし、アプリ側が遅い場合は、1番目の例で見たようにWAFのオーバーヘッドはさらに目立たなくなるからです。ModSecurityはCRSを全部有効にしているために遅いとも考えられるため、性能という観点からもルールのチューニングが有効でしょう。ただし、Webサーバーの性能に余裕がある場合には、上記性能劣化は許容できると思います。

他のWAFとの使い分けの考察

SiteGuard Liteの購入を検討する際にもっとも比較されるのは、SaaS型のWAFサービスでしょう。
単純に価格だけ見れば、SiteGuard Liteの方が安く見えます。SaaS型のWAFサービスの相場は、初期設定10万円程度、月額3万~という感じだと思いますが、初年度で元が取れそう…というのは錯覚で、SaaSの方は導入費と運用費が込みですので、単純に比較するわけにはいきません。
また、SaaS型WAFサービスだと応答の遅延を気にされるユーザが多いようですが、SiteGuard Liteのようなホスト型のWAFは、遅延の影響はもっとも受けにくい形態になります。
このように、性能上の特徴とトータルコストを勘案して、導入するWAF製品・サービスを選定することになります。

守るべきWebサーバーの数が非常に多い場合は、複数台のWebサーバーを一台のWAFで守れるならば、SiteGuard Liteではなく、ネットワーク型のSiteGuard(フル版)の方が安くなる可能性があります。

感想

私は3年半前に「三重苦を乗り越えてWAFが普及するための条件とは」という記事を書いて、以下のように結論づけました。
実運用に影響を与えない程度の控えめなブラックリストをチューニングして、それを全パラメータ共通で使用する。そうすれば、手間も掛らないし、機械化されたSQLインジェクション攻撃程度であれば十分な効力がある。それでも運用に影響が出るパラメタもある(ブログや掲示板など)が、そのパラメタだけはブラックリスト検査を除外して、その代わりしっかり脆弱性検査をして対策もアプリ側でとっておけばよい。【中略】
また、WAFの低価格化は必須だ・・・というより、ホワイトリスト機能を使わないのであれば、安いWAFで十分だ。
SiteGuard Liteは、3年半に出現を予告した製品が、ようやく世の中に出てきたように私には見えましたw

そんな訳で、弊社(HASHコンサルティング株式会社)は今までセキュリティ製品の販売は手がけていませんでしたが、SiteGuard Liteは初めて「この製品なら売りたい」と思いました。


まとめ

SiteGuard Liteのβ版について評価しました。
SiteGuard Liteはシグネチャ検査に機能を絞った廉価版WAFですが、XSSやSQLインジェクションについては十分な防御性能と速度を持ちます。
インターネットがとても物騒な状況にある今、とくにSQLインジェクション対策としてWAFの導入は有効であり、その有力な選択肢としてSiteGuard Liteが挙げられると考えます。


[PR]
WAFの選定・導入に関する相談はHASHコンサルティング株式会社まで。
安全なWebアプリケーションの作り方DRMフリーのPDFによる電子版もあります。

2011年10月16日日曜日

10月14日YAPC::ASIA Tokyo2011でトークしました

YAPC::ASIA Tokyo2011トーク資料

日付2011年10月14日(金曜日)
時間13時40分~14時20分
場所東京工大大岡山キャンパス
演題Webアプリケーションでパスワード保護はどこまでやればよいか



YAPC::ASIA Tokyo2011のベストトーク賞3位を頂戴しました。ありがとうございました。

2011年9月11日日曜日

9月10日PHPカンファレンス2011で講演しました

PHPカンファレンス2011講演資料

日付2011年09月10日(土曜日)
時間16時30分~17時10分
場所大田区産業プラザ PiO
演題徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011

徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
View more presentations from Hiroshi Tokumaru.




PDF形式のダウンロード
USTREAMによる講演録画


※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。

2010年5月22日土曜日

WAS Forum Conference 2010講演資料

WAS Forum Conference 2010講演資料

日付2010年05月22日(土曜日)
時間10時00分~18時00分
場所コクヨホール
演題ケータイ2.0が開けてしまったパンドラの箱

2010年3月19日金曜日

「かんたんログイン」DNSリバインディング耐性のチェック方法

このエントリでは、ケータイ向けWebサイトがDNSリバインディング攻撃に対する防御耐性があるかどうかをチェックする方法を説明します。ケータイ向けに「かんたんログイン」機能をもつWebサイトをチェック対象とします。

基本的な前提として、検査対象のWebサイトの管理者が自ら検査することを想定しています。

用意するもの

  • チェック対象のWebアプリケーション(かんたんログイン機能あり)
  • 携帯電話(かんたんログイン可能なもの)
  • インターネット接続されたパソコン

ステップ0:IPアドレスの調査

検査対象のWebサーバーのIPアドレスを調べます。一例として、検査対象サーバーのホスト名が mobile.example.com の場合、以下のコマンドでIPアドレスを調べることができます。

C:>nslookup mobile.example.com
サーバー:  ns.example.com
Address:  192.0.2.1

権限のない回答:
名前:    mobile.example.com
Address:  115.146.17.185
C:>

上記の例では、WebサイトのIPアドレスは、115.146.17.185になります。

ステップ1:数値IPアドレスでログイン画面を閲覧

ケータイWebアプリケーションのログイン画面のURLに対して、ホスト名を数値IPアドレスに変更したもので、携帯電話ブラウザを使用してアクセスします。上の例では、ログイン画面のURLがhttp://mobile.example.com/login?guid=ONの場合、http://115.146.17.185/login?guid=ONにアクセスすることになります。

この結果、403 Forbiddenなどのエラーでログイン処理が継続できなくなった場合はチェックを終わります(耐性あり)。画面が正常に表示された場合はステップ2に進んでください。

ステップ2:かんたんログインの実行

携帯ブラウザ上でかんたんログインボタンを押下(あるいはリンクを選択)します。

この結果、403 Forbiddenなどのエラーが表示された場合はチェックを終わります(耐性あり)。ログインが正常終了し、ログイン後の画面が表示された場合はステップ3に進んでください。

ステップ3:URLのチェック

携帯ブラウザの機能を利用して、現在表示されている画面のURLをチェックします。ホスト名が数値IPアドレスのままになっている場合は、DNSリバインディング攻撃に対して脆弱です。アドバイザリを参考に対策してください。数値IPアドレスではなく、本来のホスト名に変更されている場合はステップ4に進んでください。

ステップ4:数値IPアドレスでのコンテンツ閲覧

先ほど確認したURLに対して、ホスト名を数値IPアドレスに変更したものでコンテンツを閲覧します。コンテンツが正常に表示された場合、DNSリバインディング攻撃に対して脆弱です。エラーになった場合は、DNSリバインディング攻撃への耐性がある可能性が高いと予想されます。

以上の内容をフローチャートにまとめました。


まとめ・注意事項

かんたんログインのDNSリバインディング脆弱性をサイト運営者が自らチェックできる方法を説明しました。この方法はあくまで簡易検査であり、疑わしい状況である場合や、対策方法が分からない場合は専門家に問い合わせることを推奨いたします。ステップ4まで進んではじめて結果が出た場合も不確かである可能性があるため、専門家に相談されることを推奨します。HASHコンサルティングへの問い合わせはこちらから。

免責

この情報は、読者の便宜のために、HASHコンサルティング株式会社が現状のあるがままの状態で提供するものです。この検査の引き起こす結果等について、HASHコンサルティング株式会社はいかなる保証もしません。また、この情報は事前連絡なく改定される場合があります。

また、この検査方法は、あくまで自分が管理するWebサイトについてのみ実施してください。

追記(2010/03/21)

水無月ばけらさんのはてなブックマークコメントにて、指摘を頂戴しました。

ほとんどの場合はこれでOK。しかし、「数値だと蹴られるが、でたらめな Host: だと受け入れる」という設定が実在するので油断大敵。

ご指摘ありがとうございます。当方で確認した範囲では、ModSecurity(Apacheのモジュールとして動作するWebアプリケーションファイアウォール)を導入している場合に、「数値だと蹴られるが、でたらめな Host: だと受け入れる」設定となる事象を再現できました。以下に、ModSecurity導入状態で、数値IPアドレスによるリクエストがエラーになっている画面例を示します。


すなわち、数値IPアドレスによるリクエストでエラーになる状況には以下の二通りがあることになります。

  1. ホスト名が本来のものでないことによるエラー
  2. 数値IPアドレスをエラーにしている

上記1の状況であれば問題ありませんが、2の状況であれば、DNS Rebindingに対して脆弱である可能性があります。携帯電話の画面内容から、上記の区別をつけることは簡単ではない場合があるため、正確な検査を実施するには、正式なドメインとは別に検査用のドメインが必要になります。

このような検査用ドメインを用意することが難しいお客様のために、HASHコンサルティング株式会社では、無償で検査用のドメインをご提供することに致しました。お問い合わせフォームより、「検査用ドメイン希望」とご連絡ください。以下に注意事項を記述いたします。

  • 検査対象サイトのホスト名(FQDN)をお知らせください
  • 弊社が所有する検査ドメインのサブドメインに、検査対象サイトのIPアドレスをセットしてお伝えします
  • ドメインの所有権を譲渡するわけではありません。
  • IPアドレスは固定です。DNS Rebindingそのものの再現はできませんが、脆弱性の簡易検査用途には十分です
  • 検査対象サイトの正当な管理者であることをメールアドレスのドメインなどを元に確認させて頂きます
  • 検査作業は上記手順によりお客様にて実施頂くことを原則としますが、お客様合意の元に、弊社からも簡単な検査を実施させて頂く場合があります
  • 検査作業や結果の判定、脆弱性の詳しい解説などをご希望される場合は別途ご提案させて頂きます
  • 検査用ドメインの提供は、原則として1社につき1サイトとさせていただきます。多数のサイトを検査希望される場合は別途ご提案させていただきますので、その旨ご連絡ください
  • 本サービスは予告なく応募を締め切る場合があります

別途キャンペーンとして告知したいと考えておりますが、サービスの提供は即日開始いたします。不明な点はお問い合わせください。

2009年11月24日火曜日

iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性

iモードIDを用いた「かんたんログイン」のDNS Rebinding脆弱性

HASHコンサルティング株式会社
公開日:2009年11月24日
追記日:2010年1月21日
転載:2013年12月5日

概要

iモードブラウザ2.0のJavaScriptとDNS Rebinding(DNSリバインディング)問題の組み合わせにより、iモードIDを利用した認証機能(以下かんたんログイン)に対する不正アクセスが可能となる場合があることを確認したので報告する。危険度の高い攻撃手法であるので、サイト運営者には至急の対策を推奨する。

背景

携帯電話のかんたんログインとは、ケータイブラウザ(たとえばiモードブラウザ)に用意された契約者固有IDを利用した簡易的な認証であり、ユーザがIDやパスワードを入力しなくても認証が可能となる。iモードIDは、NTTドコモの提供する契約者固有IDの一種で、URLにguid=ONというクエリストリングを含めることにより、端末固有の7桁のIDがWebサーバに送出される。現在、iモードIDは、ケータイWebアプリケーションに広く利用されている。

2009年5月より、NTTドコモの携帯電話ブラウザ(iモードブラウザ2.0)ではJavaScriptが利用できる。ケータイJavaScript機能は、その後いったん機能停止されたが、10月末より順次再開されている。

DNS Rebindingとは、DNSを利用した攻撃手法の一種で、DNSが返すIPアドレスを短時間の間に変更する。典型的な攻撃手法としては、被害者となるユーザにインターネット上のコンテンツ(A)を閲覧させた後、当該Webサーバーのホスト名に対するIPアドレスを変更し、その後コンテンツ(A)から同じホスト名に対して、JavaScriptなどにより同じホスト名に対してアクセスする。よく知られた攻撃手法は、第二のIPアドレスとしてローカルネットワークのアドレスを返して、被害者ユーザに対してローカルネットワークをアクセスさせ、その結果を攻撃者に戻すようなスクリプトを実行させる。

発見された問題

DNS RebindingとケータイJavaScriptを利用して、かんたんログインに対する攻撃が可能になるシナリオを説明する。

想定環境の説明

以下のような環境を想定して説明する。ホスト名やIPアドレスは架空のものである。

攻撃対象のWebサーバー www.hash-c.co.jp(IP:115.146.17.185)
攻撃対象ページのURL http://www.hash-c.co.jp/userinfo.php?guid=ON
ワナのWebサーバー evil.example.jp (IP:192.0.2.2)

evil.example.jpのDNS設定は、TTLが5秒に設定されているとする。
攻撃対象のURLは、かんたんログインにより、閲覧者の個人情報を表示するものとする。

攻撃シナリオ

攻撃シナリオは以下の通りである。

(0)攻撃者は、http://evil.example.jp/rebind.html を用意し、ユーザを誘導する
(1)ユーザがhttp://evil.example.jp/rebind.htmlを閲覧する
(2)rebind.htmlにアクセスした後、攻撃者はDNSを操作し、evil.example.jpのIPアドレスを115.146.171.185(攻撃対象サーバのIPアドレス)に変更する
(3)rebind.htmlは表示されてから10秒後に、JavaScriptのXMLHttpRequestにて、http://evil.example.jp/userinfo.php?guid=ONにアクセスする
(3-1)evil.example.jpのTTL(5秒)を既に経過しているので、evil.example.jpのIPアドレスを問い合わせる
(3-2)DNSサーバーは115.146.17.185を返す
(3-3)http://evil.example.jp/userinfo.php?guid=ONにアクセスしようとするが、IPアドレスが変更されているので、実体としてはhttp://www.hash-c.co.jp/userinfo.php?guid=ONにアクセスしている
(3-4)この際、iモードIDもユーザの正規のものが送出されている
(4)www.hash-c.co.jp側ではかんたんログイン認証され、個人情報を返す
(5)スクリプトは受け取った個人情報をワナサーバー(192.0.2.2)に返す

上記のシナリオを以下に図示した(Flash Playerが必要)。

上記のようなシナリオにより、認証を突破され、個人情報の窃取、なりすまし等が行われる。攻撃対象のWebサーバーに複数回アクセスして、あらかじめ取り決めた画面遷移をたどることも可能である。

実証実験の内容

NTTドコモの2009年夏モデルP-07Aを用いて、上記シナリオを実機検証し、シナリオ通りの動作を確認した。

ただし、DNSのTTL設定は動作に影響しないようで、TTL=86400(有効期間一日)に設定した場合でも、10秒後のアクセスでDNSの引き直しが行われている模様である。この事実から、NTTドコモのゲートウェイ設備では、DNS情報をキャッシュしていないか、極めて短時間のキャッシュがなされているものと推測される。

影響範囲

以下の条件を満たすサイトがこの攻撃手法の影響を受ける。

  • iモードIDなど個体識別情報によるかんたんログイン、あるいはセッション管理を行っている
    (FOMAカード製造番号などを用いている場合は影響を受けない)
  • HTTPリクエストヘッダのHOSTフィールドをチェックしていない

また、影響を受けるユーザは、NTTドコモの2009年夏モデル以降を使用しており、かつJavaScript機能を有効にしているユーザに限られる。

発生しうる脅威

この攻撃が成功した場合は、攻撃者はユーザになりすまし、そのユーザに与えられた権限での全ての操作が可能となる。具体的には以下のような脅威が発生しうる。

  • ユーザの秘密情報の窃取(個人情報、Webメール、企業情報など)
  • ユーザ権限でのサービスの悪用(物品購入、不正な送金など)
  • ユーザ権限でのデータベースの更新など(不適切な内容の投稿、設定の変更など)

解決策・回避策

Webサイト提供者

以下の一つあるいは両方によりこの手法を防止できる。

  • iモードIDなど個体識別情報をかんたんログインおよびセッション管理に使用しない
  • HTTPリクエストヘッダのHOSTフィールドの正当性をチェックする
    iモードブラウザ2.0のXMLHttpRequestではHTTPヘッダの書き換えができないのでこの方式で対策になる(ケータイゲートウェイとのみ通信を許可している前提)

具体的には、以下のような実装方式が考えられる。

  • 認証には、パスワード認証(推奨)あるいはFOMAカード製造番号によるかんたんログインを使用する
  • セッションIDをURL埋め込みあるいはCookieに保持するセッション管理方式を用いる
  • HTTPリクエストヘッダのHOSTフィールドの正当性をチェックする。具体的には、名前ベースのバーチャルホストを使用する。

iモードのユーザ

iモードブラウザのJavaScript機能を無効にすることで上記攻撃を防止できる。

現状iモードコンテンツでJavaScriptを活用しているものは、まだほとんどないと考えられるので、JavaScriptの無効化がもっとも現実的なユーザの予防策となる。

携帯電話事業者(NTTドコモ)

一般的なDNS Rebinding対策としては、DNS Pinningが知られている。これは、ブラウザ側でDNSの検索結果を一定時間保持するものだが、携帯電話ブラウザはキャリアのゲートウェイ(PROXY)経由でのアクセスであるので、ブラウザ側ではDNSによるIPアドレス解決を行っていないと考えられる。このため、DNS Pinningを実装できない。

一方、前述のように、NTTドコモのゲートウェイ設備では、DNSのキャッシュを全くあるいはほとんど保持していないと考えられることから、一定時間以上DNSの結果をキャッシュすることで、予防的な対策となる。例えば、TTLの指定に関わらず最低1時間以上キャッシュを保持することで、DNS Rebinding攻撃が成功する確率をかなり低下させることができる。

技術メモ

DNS RebindingはPC用ブラウザでも成立するが、今回報告したような認証回避には悪用できない。その理由は、PC向けWebアプリケーションは、iモードIDのような固定の識別子を用いて認証していないためである。また、セッション管理に通常用いられるCookieはドメイン名により送出先サーバを特定しているので、上記シナリオのように別ドメインを指定している場合は、送出されない。

このため、パスワード認証やCookieによるセッション管理など、PC用Webアプリケーションで一般的に用いられる開発手法に従っていれば、DNS Rebindingによる認証回避やセッションハイジャックには至らないと考えられる。

訂正(2010年1月21日)

当初リリースで「FOMAカード製造番号などを用いている場合は影響を受けない」としていたが、これは誤りであり、FOMAカード製造番号などを用いている場合も影響を受ける可能性がある。FOMAカード製造番号をXMLHttpRequestにより送出する方法はないと当初考えていたが、XMLHttpRequestを用いずに別の方法で攻撃が可能であることが判明した。FOMAカード製造番号を使っている場合、利用者のブラウザ画面上に確認画面が表示されるので、そこでユーザが拒絶すれば攻撃にあわないが、巧妙な誘導などにより攻撃されれば、被害に遭うユーザも出てくると考えられる。

発見者

HASHコンサルティング 徳丸浩
http://www.hash-c.co.jp/
contact (at) hash-c.co.jp

免責

このセキュリティ情報は予告なしに改訂される場合がある。このセキュリティ情報を適用した結果についてHASHコンサルティング株式会社は一切の責任を負わず、利用者の利益のために、あるがままの状態で公開するものである。

2009年9月6日日曜日

9月4日 PHPカンファレンス2009 ビジネスデイで発表しました

こちらの日記はずいぶん後沙汰しておりますが、標記のように、PHPカンファレンス2009 ビジネスデイにて発表する機会をいただきました。関係者のみなさまありがとうございました。

主催者からのリクエストが、「発注側として気をつけるべきセキュリティ」ということでしたので、今さらXSSやSQLインジェクションの話をしてもしょうがないと思い、発注者視点での話をこの機会にまとめてみようと思いました。そのため、タイトルは「45分で分かる、安全なWebアプリケーション開発のための、発注・要件・検収」といたしました。

発表の中でも述べましたが、発注者がセキュリティに関与できる場面は、発注と検収の場面しかなく、検収は発注仕様に沿っているかどうかを確認するものですので、発注と要件(発注仕様)が極めて重要ということになります。しかし、従来、このセキュリティ要件をどのように書けばよいかは、実はよく検討されていなかったのです。 詳しくは、講演資料をご覧下さい。

PDF形式でのダウンロード

ビジネスデイとはいえ、技術的テーマに関心の強いであろう人たち相手に、発注とか検収の話をして興味を持っていただけるか不安だったのですが、ブログやtwitterの反応を見る限り好意的なものもあり、ほっとしているところです。

このテーマは今後も検討を進めて、さまざまな機会で発表することを予定しております。現在決まっているのは、11月14日の第2回東北情報セキュリティ勉強会ですが、それ以外でも発表の機会を持つ予定です。その際には、このブログなどで告知いたしますので、よろしくお願いいたします。

フォロワー