| 日付 | 2012年03月27日（金曜日） |
| 時間 | 19時00分～20時30分 |
| 場所 | 日本橋公会堂 |
| 演題 | ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～ |
※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。
| SiteGuard | SiteGuard for Server | SiteGuard Lite | |
| 配置方式 | ネットワーク型 | ホスト型 | ホスト型 |
| 実装形態 | Proxy | Proxy | Apacheモジュール |
| シグネチャ検査 | ○ | ○ | ○ |
| ホワイトリスト検査 | ○ | ○ | |
| Cookie暗号化 | ○ | ○ | |
| セッション管理 | ○ | ○ | |
| クローキング | ○ | ○ | |
| ライセンス費用 | 178万円 | 79万円 | 約30万円 |
<?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で防御してみましょう。http://example.jp/books.php?author='+and+cast((select+id||':'||pwd+from+users+offset+0+limit+1)+as+integer)>1--以下のようにブロックされています。
仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか？プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。という箇所についてですが、XSS Cheat Sheetに出てくるimg要素によるXSSの攻撃パターンのうちの一つが以下です。
http://example.jp/books.php?author=jav%09ascript:alert('XSS');これについても、きちんとブロックしています。
SQLインジェクション対応の駄目な例として挙げられるのは、複文などの直接攻撃しか考慮していないケースです。簡単に言うと、master..execなどの直接攻撃のみ禁止しているWAFは甘く、union selectなどのunionインジェクションを考慮したWAFはまだマシであると言えます（攻撃者の観点が分かっているという意図でマシと記載しました）。マシなWAFは「union select」は考慮するが、「union/**/select」はほとんどのWAFは通り抜けるということですが、SiteGuard Liteはどうでしょうか。
このブラックリストを通り抜けるにはコメントを使用します。たとえば、union/**/selectではどうなるでしょうか? 残念ながらほとんどのWAFは通り抜けてしまいます。
author=17871+update+employee+set+number%3DREPLACE(cast(このパターンでも、SiteGuard Liteはブロックしました。
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文字連続するとブロック」というルールがあるからです。
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}"
SecRuleRemoveById 960024
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% |
| WAFなし | SiteGuard Liteあり | ModSecurityあり | |
| 秒間リクエスト数 | 365.34 | 284.85 | 127.80 |
| 相対性能 | 100% | 78.0% | 35.0% |
実運用に影響を与えない程度の控えめなブラックリストをチューニングして、それを全パラメータ共通で使用する。そうすれば、手間も掛らないし、機械化されたSQLインジェクション攻撃程度であれば十分な効力がある。それでも運用に影響が出るパラメタもある(ブログや掲示板など)が、そのパラメタだけはブラックリスト検査を除外して、その代わりしっかり脆弱性検査をして対策もアプリ側でとっておけばよい。【中略】SiteGuard Liteは、3年半に出現を予告した製品が、ようやく世の中に出てきたように私には見えましたw
また、WAFの低価格化は必須だ・・・というより、ホワイトリスト機能を使わないのであれば、安いWAFで十分だ。
| 日付 | 2011年10月14日（金曜日） |
| 時間 | 13時40分～14時20分 |
| 場所 | 東京工大大岡山キャンパス |
| 演題 | Webアプリケーションでパスワード保護はどこまでやればよいか |
| 日付 | 2011年09月10日（土曜日） |
| 時間 | 16時30分～17時10分 |
| 場所 | 大田区産業プラザ PiO |
| 演題 | 徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011 |
| 日付 | 2010年05月22日（土曜日） |
| 時間 | 10時00分～18時00分 |
| 場所 | コクヨホール |
| 演題 | ケータイ2.0が開けてしまったパンドラの箱 |
このエントリでは、ケータイ向けWebサイトがDNSリバインディング攻撃に対する防御耐性があるかどうかをチェックする方法を説明します。ケータイ向けに「かんたんログイン」機能をもつWebサイトをチェック対象とします。
基本的な前提として、検査対象のWebサイトの管理者が自ら検査することを想定しています。
検査対象の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になります。
ケータイWebアプリケーションのログイン画面のURLに対して、ホスト名を数値IPアドレスに変更したもので、携帯電話ブラウザを使用してアクセスします。上の例では、ログイン画面のURLがhttp://mobile.example.com/login?guid=ONの場合、http://115.146.17.185/login?guid=ONにアクセスすることになります。
この結果、403 Forbiddenなどのエラーでログイン処理が継続できなくなった場合はチェックを終わります（耐性あり）。画面が正常に表示された場合はステップ2に進んでください。
携帯ブラウザ上でかんたんログインボタンを押下（あるいはリンクを選択）します。
この結果、403 Forbiddenなどのエラーが表示された場合はチェックを終わります（耐性あり）。ログインが正常終了し、ログイン後の画面が表示された場合はステップ3に進んでください。
携帯ブラウザの機能を利用して、現在表示されている画面のURLをチェックします。ホスト名が数値IPアドレスのままになっている場合は、DNSリバインディング攻撃に対して脆弱です。アドバイザリを参考に対策してください。数値IPアドレスではなく、本来のホスト名に変更されている場合はステップ4に進んでください。
先ほど確認したURLに対して、ホスト名を数値IPアドレスに変更したものでコンテンツを閲覧します。コンテンツが正常に表示された場合、DNSリバインディング攻撃に対して脆弱です。エラーになった場合は、DNSリバインディング攻撃への耐性がある可能性が高いと予想されます。
以上の内容をフローチャートにまとめました。
かんたんログインのDNSリバインディング脆弱性をサイト運営者が自らチェックできる方法を説明しました。この方法はあくまで簡易検査であり、疑わしい状況である場合や、対策方法が分からない場合は専門家に問い合わせることを推奨いたします。ステップ4まで進んではじめて結果が出た場合も不確かである可能性があるため、専門家に相談されることを推奨します。HASHコンサルティングへの問い合わせはこちらから。
この情報は、読者の便宜のために、HASHコンサルティング株式会社が現状のあるがままの状態で提供するものです。この検査の引き起こす結果等について、HASHコンサルティング株式会社はいかなる保証もしません。また、この情報は事前連絡なく改定される場合があります。
また、この検査方法は、あくまで自分が管理するWebサイトについてのみ実施してください。
水無月ばけらさんのはてなブックマークコメントにて、指摘を頂戴しました。
ほとんどの場合はこれでOK。しかし、「数値だと蹴られるが、でたらめな Host: だと受け入れる」という設定が実在するので油断大敵。
ご指摘ありがとうございます。当方で確認した範囲では、ModSecurity（Apacheのモジュールとして動作するWebアプリケーションファイアウォール）を導入している場合に、「数値だと蹴られるが、でたらめな Host: だと受け入れる」設定となる事象を再現できました。以下に、ModSecurity導入状態で、数値IPアドレスによるリクエストがエラーになっている画面例を示します。
すなわち、数値IPアドレスによるリクエストでエラーになる状況には以下の二通りがあることになります。
上記1の状況であれば問題ありませんが、2の状況であれば、DNS Rebindingに対して脆弱である可能性があります。携帯電話の画面内容から、上記の区別をつけることは簡単ではない場合があるため、正確な検査を実施するには、正式なドメインとは別に検査用のドメインが必要になります。
このような検査用ドメインを用意することが難しいお客様のために、HASHコンサルティング株式会社では、無償で検査用のドメインをご提供することに致しました。お問い合わせフォームより、「検査用ドメイン希望」とご連絡ください。以下に注意事項を記述いたします。
別途キャンペーンとして告知したいと考えておりますが、サービスの提供は即日開始いたします。不明な点はお問い合わせください。
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情報をキャッシュしていないか、極めて短時間のキャッシュがなされているものと推測される。
以下の条件を満たすサイトがこの攻撃手法の影響を受ける。
また、影響を受けるユーザは、NTTドコモの2009年夏モデル以降を使用しており、かつJavaScript機能を有効にしているユーザに限られる。
この攻撃が成功した場合は、攻撃者はユーザになりすまし、そのユーザに与えられた権限での全ての操作が可能となる。具体的には以下のような脅威が発生しうる。
以下の一つあるいは両方によりこの手法を防止できる。
具体的には、以下のような実装方式が考えられる。
iモードブラウザのJavaScript機能を無効にすることで上記攻撃を防止できる。
現状iモードコンテンツでJavaScriptを活用しているものは、まだほとんどないと考えられるので、JavaScriptの無効化がもっとも現実的なユーザの予防策となる。
一般的な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による認証回避やセッションハイジャックには至らないと考えられる。
当初リリースで「FOMAカード製造番号などを用いている場合は影響を受けない」としていたが、これは誤りであり、FOMAカード製造番号などを用いている場合も影響を受ける可能性がある。FOMAカード製造番号をXMLHttpRequestにより送出する方法はないと当初考えていたが、XMLHttpRequestを用いずに別の方法で攻撃が可能であることが判明した。FOMAカード製造番号を使っている場合、利用者のブラウザ画面上に確認画面が表示されるので、そこでユーザが拒絶すれば攻撃にあわないが、巧妙な誘導などにより攻撃されれば、被害に遭うユーザも出てくると考えられる。
HASHコンサルティング 徳丸浩
http://www.hash-c.co.jp/
contact (at) hash-c.co.jp
このセキュリティ情報は予告なしに改訂される場合がある。このセキュリティ情報を適用した結果についてHASHコンサルティング株式会社は一切の責任を負わず、利用者の利益のために、あるがままの状態で公開するものである。