ホワイトリストとブラックリストの議論はFirewallの利用が一般的になる過程で十分に議論され、90年代に議論され尽くした、と思っていました。しかし、解説の余地はまだまだあるようです。ネットワークFirewallによるセキュリティ対策を簡単に振り返り、セキュアコーディングの現状を考察したいと思います。
追記：このエントリはネットワークFirewallのポートフィルタリングについて議論しています。ホワイトリストで対策すべきはアプリケーション自体です。ネットワークFiewallはホワイトリスト型セキュリティで対策しますが、WAFなどのアプリケーションFirewallはブラックリスト方式で対策するのが現実的です。ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
先週末、まっちゃ445というセキュリティ勉強会にお呼び頂きました。未修正のPHP4/5の脆弱性やパネルディスカッションのパネラーとして話をさせて頂きました。関係者の皆様、いろいろ参考になりました。ありがとうございました。
この勉強会の主題の一つがWeb Application Firewall(WAF)でした。パネルディスカッションのテーマもWAFでした。進行役にはサイバー大学の園田さん、パネラーにはサーボーズラボの竹迫さん、HASHコンサルティングの徳丸さん、そして私の4人でパネルディスカッションを行いました。
3人ともWAFの効用や限界に意見の相違はなかったのですが、私と徳丸さんにはシステム開発に於けるブラックリストとホワイトリストの使い方には意見の相違があったと思います。うまく議論をまとめられなかったのでブログに書きます。
追記：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
(さらに…)
Stefan Esser氏のブログでmt_srandとそれほどランダムでない乱数（mt_srand and not so random numbers)というエントリが8/17に掲載されています。気になっていたのでPythonの実装も調べてみました。
大規模なWebサイト構築を行っている方ならF5にお世話になっている方も多いでしょう。F5のブログで私と全く同じ意見のブログ – Why it’s so hard to secure JavaScriptを見つけたので紹介します。
(さらに…)
【注意喚起】ワンクリック不正請求に関する相談急増！
http://www.ipa.go.jp/security/topics/alert20080909.html
これによるとワンクリック詐欺が増えているらしい。少なくとも相談件数は増えている。
IPAの資料によるとユーザがアプリケーションを実行してしまう事が原因と解説されています。
相談の主な内容は、動画を見ようとして、[再生]ボタンなどをクリックした結果、請求書を表示するウィンドウ（図2）がデスクトップ画面に貼り付いて、画面から削除しても繰り返し表示されてしまうというものです。
この現象は、動画を見るつもりでクリックをし続けた結果、請求書を繰り返し表示するウイルスプログラムを取り込んでしまったことにより起こっています。
取り込む際には、Windows の警告画面が出ていたはずですが、被害者は、皆、その警告を無視してクリックをし続けて自らウイルスを取り込んでしまっています。
アプリケーションまで実行してしまうユーザも数多くいるようです。
これはWeb開発者にとってもかなりの脅威です。Webブラウザにユーザ名とパスワードを保存している利用者も多いと思います。私は全てのサイトで異なるパスワードを利用しています。とても覚えきれないのでブラウザにパスワードを保存しています。当然ですがマスターパスワードを設定しています。
しかし、一般のユーザはどれだけこれらのファイルを暗号化して保護しているでしょうか? Yahooオークションでユーザが知らない内に不正に出品される事件が発生しているそうですが、この原因には
などが考えられるのでは無いでしょうか? Yahooオークションで不正出品が大量に行われている問題は、Yahoo自体の問題より、他のサイトのセキュリティ脆弱性やユーザの誤ったネットワーク利用の問題の方がより重大な問題ではないかと思います。
Yahooオークションにも不正な出品を防ぐシステム作りをする責任がありますが、ユーザ自身もコンピュータを利用するリスクを正しく知る努力が必要だと思います。
最低限、これくらいは注意を払ってもらわないと、いくらWeb開発者が安全なWebサイト作りに留意しても安全にWebサイトを利用できません。
ブラウザ開発者も保存されたパスワードやクッキーはデフォルトで暗号化すべきだと思います。そろそろ利便性より安全性を重視したデフォルトにする時期だと思います。
悪意のあるページからブラウザを保護する為のフィルタリングツールにはクライアントにインストールするタイプ、プロキシタイプなどある。これらのツールは本当にクライアントを保護できているのだろうか?
最近の攻撃は悪意のあるサイトにアクセスしなくても、広告から悪意のあるサイトに誘導されたり、SQLインジェクションやネットワークレベルの攻撃で悪意のあるページへのiframeを挿入される事例が多い。
個人的にはこれらのフィルタリングツールを使用した事はないが、これらのツールの有用性には疑問が多い。JavaScriptの難読化には多くの手段がある。例えば、.replaceを利用する方法がある。
start();
function z_sa(o,p,v){ o.setAttribute(p,v); }
function start(){
var z = document.createElement(‘object’); z_sa(z,’id’,’z’);
z_sa(z,’classid’,”cjlWsTiWdI:HBWDH9T6jCT5T5H6T-T6I5IAj3j-”
“W1W1IDH0I-W9H8W3HAT-I0T0WCH0W4jFICW2T9TEI3T6T”.replace(/[WHjIT]/g, ”));
replace(/[WHjIT]/g, ”)
によって
clsid:BD96C556-65A3-11D0-983A-00C04FC29E36
と変換され、RDS.Dataspaceの脆弱性 MS06-014を攻撃するためコードなる。
出典：http://dvlabs.tippingpoint.com/blog/2008/08/14/threatlinq-javascript-bad-juju
他にもJavaScriptの難読化やURLの動的生成など、単純なブラックリスト方式の防御を無効化する手法はいろいろあります。
一般ユーザは本当にWebを利用する危険性を理解しているのか心配になります。
「プログラミングはホワイトリスティングが基本」にブラックリストもホワイトリストもどちらも同じ事を言っていて違いが分からない、とコメントを頂きました。
追記：ブラックリストとホワイトリストの違いが解らない方は、恐らくホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることを理解していないのだと思われます。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
http://pfrb.blog114.fc2.com/blog-entry-5.html
ホワイトリストとブラックリストは単純な場合は分かりやすいコンセプトですが、ちょっと複雑になると分かりやすいようで境界が分かり辛いコンセプトです。
メールを例にホワイトリストとブラックリストの違いと境界の分かり辛さを解説します。
(さらに…)
このエントリは何年も前（日付を見たら2008年８月）に書きかけで放置していたエントリです。最近書いた、セッションアダプション脆弱性をPHPのモジュールレベルで修正するパッチについての議論の参考になると思うので公開します。私は補助的な意味合いを持つ追加のセキュリティ対策は無意味であるとは全く考えていません。対策の限界を知って、有効に利用する。それで良いのでは無いでしょうか？以下、書きかけで未公開だったエントリです。
関連エントリ： セッションフィクセイションはアダプション脆弱性修正で防御可能 （特にコメント欄）
WAFは有用なセキュリティ対策です。これに異論は無いでしょう。ゼロデイ対策にはWAFは非常に有効であり、可能であれば導入すべきだ、とセミナーでも繰り返し説明しています。しかし、WAFは万能ではありません。導入すれば安全性が簡単かつ飛躍的に向上するシステムでもありません。説明を省略しているので説明不足な部分もありますが、疑問がある場合はコメントをください。 (さらに…)
「ホワイトリスト方式の優位は神話」と題するエントリに私のブログホワイトリストはどう作る? が引用されている事を教えていただきました。
ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。
誤解されないように書こうとすると、どうしても長文になります。暇な方だけお付き合いください。
参考： セキュリティを論理的に構築する方法 （こちらは科学的なセキュリティの基本構造の作り方の話です。ぜひどうぞ） (さらに…)
Googleがクラウドコンピューティングの言語としてPythonを採用したのでセキュリティ研究家が脆弱性を調査し、今年はPythonの脆弱性が多く報告されるはず、とこのブログで予想しています。また新たな脆弱性が報告されているので書いておきます。
今回は整数オーバーフローが多いので、整数オーバーフローを中心に調査したのだと思われます。
Python 2.5.3以上でないと穴だらけと言えますが….
http://python.org/download/
と言った状況のようです。
しかし、予想通りとはいえ数が多いですね。
CVE-2008-3144
Multiple integer overflows in the PyOS_vsnprintf function in Python/mysnprintf.c in Python 2.5.2 and earlier allow context-dependent attackers to cause a denial of service (memory corruption) or have unspecified other impact via crafted input to string formatting operations. NOTE: the handling of certain integer values is also affected by related integer underflows and an off-by-one error.
CVE-2008-3143
Multiple integer overflows in Python before 2.5.2 might allow context-dependent attackers to have an unknown impact via vectors related to (1) Include/pymem.h; (2) _csv.c, (3) _struct.c, (4) arraymodule.c, (5) audioop.c, (6) binascii.c, (7) cPickle.c, (8) cStringIO.c, (9) cjkcodecs/multibytecodec.c, (10) datetimemodule.c, (11) md5.c, (12) rgbimgmodule.c, and (13) stropmodule.c in Modules/; (14) bufferobject.c, (15) listobject.c, and (16) obmalloc.c in Objects/; (17) Parser/node.c; and (18) as…
CVE-2008-3142
Multiple buffer overflows in Python 2.5.2 and earlier on 32bit platforms allow context-dependent attackers to cause a denial of service (crash) or have unspecified other impact via a long string that leads to incorrect memory allocation during Unicode string processing, related to the unicode_resize function and the PyMem_RESIZE macro.
CVE-2008-2316
Integer overflow in _hashopenssl.c in the hashlib module in Python 2.5.2 and earlier might allow context-dependent attackers to defeat cryptographic digests, related to “partial hashlib hashing of data exceeding 4GB.”
CVE-2008-2315
Multiple integer overflows in Python 2.5.2 and earlier allow context-dependent attackers to have an unknown impact via vectors related to the (1) stringobject, (2) unicodeobject, (3) bufferobject, (4) longobject, (5) tupleobject, (6) stropmodule, (7) gcmodule, and (8) mmapmodule modules.
桝形さんから
http://blog.ohgaki.net/php-5-2-strict-session
で公開したパッチのPHP4.4.8版を送っていただきました。私のWikiにも添付ファイルとして掲載させていただきました。
http://d.hatena.ne.jp/masugata/20080714#p2
に掲載されているパッチと同じパッチです。
私は全てのPHPユーザがStrict Sessionパッチ適用すべきと考えています。詳しくはWikiをご覧ください。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
桝形さん、パッチありがとうございました。
随分前からバージョンアップしたパッチ公開しないと、と思いつつ遅れていました。PHP 5.2.6用の厳格なセッション管理を行うパッチを公開しました。詳しくはWikiをご覧下さい。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
他のネットワークからパッチをダウンロードしようとして、セキュリティ強化の為にPukiwikiのattachモジュールのカスタマイズで添付ファイルのダウンロードが出来なくなっていました。これも修正しました。
このパッチを摘要するとmake testのsession関連のテストがエラーになりますが、気にする必要はありません。テストの内容をみるとこれらのテストは本来失敗すべきであることが分かります。
Flash Playerのバージョンアップがなかなか進まないようです。
先月末にあったSymantec社の0Day攻撃の誤報のおかげでかなりバージョンアップが進んだのですが、残念ながらまだまだのようです。例えば、先週1週間のこのブログへのアクセス集計では既知の脆弱性が無い9.0.124を利用していたのはたったの40%です。
バージョンアップが進まない原因にはAdobeのサポート方針にも大きな原因があると言えます。
(さらに…)
中国でのソフト開発が進められています。例えば、
「NEC、中国のソフト開発体制を強化−5000人にトレーニング開始」
http://enterprise.watch.impress.co.jp/cda/topic/2008/06/11/13158.html
人件費が圧倒的に安い中国ですがセキュリティの問題も考えなければなりません。中国政府の機関が直接関与していると考えられるセキュリティ上の問題は海外メディアやブログではかなり頻繁に報道されています。
A New Cold War?
http://www.spinhunters.org/blog/a-new-cold-war/
にはアメリカの通商代表が中国訪問中にコンピュータから情報を盗まれた可能性があり、捜査中だとしています。
随分前になりますが国防相のメールが中国のサイバー攻撃により読み取られた、とする報道も記憶に新しいです。アメリカ軍が利用しているルータや兵器部品でさえ中国製の偽物が多数発見されるような状態です。まさに「何でもあり」の無法状態です。
セキュリティは意識しなくてもよいシステム開発案件なら良いですが、中国での開発はさらにリスクが高いと考えるべきでしょう。システム開発にもチャイナリスクを十分に考慮しなければならない時代がやってきたようです。
追記：この件、どうも0dayでなく既知の脆弱性の問題だったということで決着しているようです。情報ありがとうございます。ただ、このブログにアクセスしている方でもgoogle analyticsによると脆弱性の無いバージョンだと分かるFlashを利用している方がたったの16.6%です。前のバージョン(9.0.115)の利用者は31.78%です。残りのユーザもほとんどが危険なFlash Playerを利用していると思われます。かなり有効な攻撃であることには変わりないようです。Flash Playerは時々アップデートがある、と教えてくれますがあまり役立たないので自分で脆弱性情報を収集してバージョンチェックする方が良いです。
とりあえず9.0.124.0であれば大丈夫なようです。
http://www.adobe.com/jp/support/flashplayer/ts/documents/tn_15507.htm
いろいろ困る事もあるのですがFirefox+NoScriptを利用するとこの種の攻撃のリスクを大幅に低下させられます。
追記2:
Flash attack may as well have been zero-day
http://blogs.zdnet.com/security/?p=1236
結果的には0dayでなかったが同じくらい効果的に攻撃されているではないか、という意見です。私も同じ意見です。このブログでも時々Flashの自動更新は役立たずであり、その結果危険なFlashを使い続けているユーザが多い事を書いています。
Flashのバージョンチェックや設定チェックはお世辞にも分かり易いとは言えないのでWikiにリンク集も作っています。
http://wiki.ohgaki.net/index.php?Flash%E3%83%90%E3%83%BC%E3%82%B8%E3%83%A7%E3%83%B3%E3%83%81%E3%82%A7%E3%83%83%E3%82%AF
FlashやQuickTime等のプラグインはエンドユーザにとっては最大の脅威といっても良いくらいですが、あまりその事実は理解されていないと思います。このブログをご覧の方で最新版のFlash Playerに更新されている方はバージョンアップが進み、最新版を利用されている方の割合が17%から30%に向上しています。しかし、向上したと言ってもたったの3割で残りのほとんどは危険なFlash Playerを使い続けています。