EGセキュアソリューションズオフィシャルブログ

2010年5月22日土曜日

WAS Forum Conference 2010講演資料

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

ケータイ2.0が開けてしまったパンドラの箱

View more presentations from Hiroshi Tokumaru.

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アドレスによるリクエストでエラーになる状況には以下の二通りがあることになります。

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

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

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

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

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

2009年11月24日火曜日

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が必要）。

かんたんログインのDNS Rebinding攻撃

View more presentations from Hiroshi Tokumaru.

上記のようなシナリオにより、認証を突破され、個人情報の窃取、なりすまし等が行われる。攻撃対象の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アプリケーション開発のための、発注・要件・検収」といたしました。

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

PHPカンファレンス2009 - 45分で分かる安全なWebアプリケーション開発のための発注・要件・検収

View more presentations from ockeghem.

PDF形式でのダウンロード。

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

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

2008年6月22日日曜日

WASForum Conference 2008で講演します

　標記のように、WASForum Conference 2008の7/5 Developers DAY - 事件は現場で起こっている……セキュリティライフサイクルとマルプラクティスにて、「SQLインジェクション対策再考」のタイトルで講演させていただくことになりました。7月5日土曜日、東銀座時事通信ホールです。

　私の個人ブログにてSQLインジェクションについて書き溜めてきたことの総まとめをこの場でしたいと考えております。どうぞご期待ください。

2008年6月15日日曜日

安全なWebアプリケーションのために発注者がなすべきこと - 発注者のためのWebアプリケーションセキュリティ入門(1)

　このブログでの連載開始にあたり、Webアプリケーションを発注する立場でのセキュリティに対する責任や、なすべきことを説明したいと思います。

Webアプリケーション発注者に脆弱性に対する責任はあるか

　そもそも非常に基本的な前提として、Webアプリケーションの脆弱性(SQLインジェクションなど)に対する最終的な責任は誰(どの会社)にあるかを考えてみます。具体的には、インターネット上のWebサイトを運営している、あるいはWebアプリケーションョンをパッケージソフトウェアとして市販しているが、開発は外部の開発会社に委託しているケースで、セキュリティ事故などが発生してお客様(Webサイトのユーザ、パッケージソフトの購入者)に迷惑を掛けた場合、その責任は誰にあるかということです。

　結論から言えば、この責任はWebアプリケーションの発注者にあります。発注者は、Webサイトの運営者あるいはパッケージソフトの販売会社として、顧客と直接契約関係にあるわけですから、責任があるのは当然と言えます。

　これはWebアプリケーションに限らず他の分野でも同じことです。かつてマンションの耐震強度偽装が社会的に問題になった際に、強度計算を請け負った一級建築士やマンションを担当した建設会社の責任ももちろん追及はされましたが、マンションの顧客はこれらの建築士や建設会社に責任求めることはできず、マンションの販売会社に保証を求めました。それと同じで、Webアプリケーションのセキュリティ事故が発生した場合、顧客に対して責任を負うのは、Webアプリケーションの発注者であると考えられます。

　しかし、このように書くと、発注者には次のような疑問が残ると思います。我々はインターネットのことやシステムのこと、ましてやセキュリティのことは良く分からない。分からないからこそ、大金を投じて専門家に開発を委託しているのだ。専門家なのだから、セキュリティのことについても責任をとってもらってしかるべきではないか、と。

　これは心情としてはよく理解できるのですが、現実のビジネスでは通用しない理屈です。以下に、開発会社まかせでは駄目な理由を具体的に説明しましょう。

なぜ開発ベンダーまかせではだめなのか?

セキュリティに関して開発会社には法律上の義務はない

　これは食品や建設などの分野とIT分野の大きな違いです。先ほど例にあげた耐震偽装問題では建築基準法や建築士法などがあり、建設会社や建築士に対する法的な規制となっています。一方、IT分野には、これらに相当する法律はありません。製造物責任法(PL法)もソフトウェアには適用されないという解釈が一般的です。

　先の耐震偽装問題では、建設会社などの責任も問われたわけですが、それは上記の法律などに違反していたことが問題視されたわけです。一方システム開発では、このような法律がないため、開発会社に責任を求めることは非常に困難となります。

　このため、顧客からの要求が唯一の基準となります。言い換えれば顧客からの発注仕様書あるいは請負契約書などに明確に記載されていない限り、開発会社の責任にはならないのです。

セキュリティ要件は発注仕様として見積もりと直結する

　しかしこういう疑問も出てくるとと思います。法的な根拠がなくとも、これだけセキュリティ事件が多発している現状であれば、プロの良心として、要求がなくてもセキュリティには万全の備えをしてくれてよいではないか、と。そのような良心的なベンダーもないわけではありません。しかし、現実の商談の現場では、「良心的なベンダー」にも以下のような葛藤があります。

　それは、開発者会社の選定は、通常、相見積もり(コンペ)で行われているため、受注をとるためには、できる限り安い見積もりを出す必要があります。これは発注者にとって結構なことなのですが、開発ベンダーの心理としては見積もりを安くするためには顧客から要求されていない要件はできるだけ省略したいという心理が発生します。

　このため、開発会社側としても、仮にセキュリティが重要だと分かっていても、顧客の要求事項にない、あるいは要求が非常にあいまいな場合は、できるだけセキュリティ要件を省いて、見積もり金額を安く抑えようという心理が働くのです。

開発ベンダーも実はよく分かっていない

　これを書くと身も蓋もないのですが、開発会社もよく分かっていないところがまだまだ多いのが実情です。このため、「おまかせ」とか「よきにはからえ」ではうまくいかないのです。

発注者は何をすればよいか?

このため、発注者側の自衛として、(1)開発会社選定の際にセキュリティについてもよく考慮する、(2)発注時にセキュリティ要件を明確にするということが重要となります。とりわけ、セキュリティ要件の明確化は重要です。

　下図はソフトウェアを発注・開発する際の流れを非常に大雑把に示したものです。図に示すように、ソフトウェア開発プロセスの中で発注者が関与できる箇所は、「要求仕様」と「検収」のタイミングしかありません。しかも、検収は「要求仕様どおりにできているかを確認する」ものですから、セキュリティ要件が要求仕様になければ、検収のタイミングで指摘することは困難です。

　このため、全ては要求仕様の段階で決まってしまうのです。これは、機能要件や性能要件についても同じことであって、セキュリティだけが特別ではない、ということに過ぎません。

まとめ

　Webアプリケーションを外部に委託して開発してもらう場合、セキュリティ上の責任は最終的には発注者側にあります。発注者は開発会社に「安全なシステムを開発させる責務」があることになります。このためには、とくに重要なことが、発注時のセキュリティ要件を明確にすることです。

　前述のように、システム開発では要求仕様にない項目は盛り込んでくれないと考えるべきです。発注時にすべてが決まると言っても過言ではありません。

HASHコンサルティングからの提案

　HASHコンサルティング株式会社では、発注者の立場で使用するのに適したセキュリティ・ガイドラインの策定や、開発会社選定から納品・検収までの一連の開発プロセスにおける相談を承っております。どうぞお気軽にご連絡ください。

2008年6月11日水曜日

セキュアなWebアプリケーション開発のためのノウハウを提供します

　こんにちは。HASHコンサルティング株式会社の徳丸浩です。私はこれまで二種類のブログを運営してきましたが、いずれも技術的な内容にフォーカスした内容でした。このブログでは、安全なWebアプリケーションをベンダーに開発してもらうためのRFPの書き方、発注仕様に盛り込むべきガイドラインのあり方、契約書、検収など、非技術的な内容を中心に、役立つノウハウを提供していこうと思っております。

　Webアプリケーションのセキュリティを担保するためには、ベンダーまかせ、開発者まかせでは決してうまくいきません。そのような方法は、技量の高い開発者に「当たれば」よいものができるかもしれませんが、あまりセキュリティに詳しくない開発者がたまたま担当した場合には、非常に多くのセキュリティ・ホールが残ったままになっているかもしれません。私は長年開発の現場にいて、そのような状況をつぶさに経験しておりました。

　このような状況の中で、安全なWebアプリケーションをいかにコストや納期に影響を与えないで開発するかは、現在大きな課題と言えます。そのためには、発注者やプロジェクトの責任者がセキュリティにも関心を払い、それぞれの立場でWebサイトの安全性について責任を果たすことが重要です。

　このブログでは、そのような取り組みに向けた実践的な方法論を紹介してまいります。どうぞご期待ください。

HASHコンサルティング株式会社
代表取締役　徳丸浩

登録: 投稿 (Atom)