(matcha445)まっちゃ445勉強会#14

第14回 まっちゃ445勉強会
今回もメモレベルですが、ざっと書き記してみたいと思います。

[Session1：「パスワードの話」春山さん](PDF版の資料はココからダウンロードできます)
(はじめに)
パスワード情報が万が一漏れてしまった時、破られにくくする方法
勿論「パスワードが漏れないようにする事」「ユーザが強いパスワードを付ける事」が前提条件だが

Saltを付けてHash化←常識(?)
元ねたは「UNIXのパスワード保存方法」

(UNIX的パスワード保存)
GNU/Linuxの場合、/etc/shadowにパスワード情報を保存

(Hashとは)
一方向性、衝突耐性を持っている事

(Saltとは)
Hash化の時にパスワードと共に与えられる文字列
ユーザ毎に異なる値が必要←対レインボーテーブル(Ophcrackとかは有名)

(ここでFree Rainbow Tableのデモ)

(なぜユーザ毎にSaltが必要?)
共通のSalt→同じパスワードを利用する→同じ情報が生成される
ユーザ毎に異なれば良い、ランダムでなくても良い

(Saltの大きさ)
昔12bit、今96bit

(実際の処理)
cryptography engineering p304の方法
どれもHashを繰り返し利用している(ストレッチング:Stretching)

(ストレッチングとは?)
ハッシュを繰り返し利用→ハッシュ値を求めるのに必要な時間を増大
⇒攻撃に時間がかかる、実質的なパスワード文字数を増やす
MD5→1000回
SHA-256,512→5000回

(効果)
1日3456億回(昨年のPCレベル、1コアだけ使用)計算可能とする
無し→6文字で0.2日、7文字で13日
1000回ストレッチ→5文字で3日、6文字で199日

強度→回数×計算にかかる時間で設定

(方式の保存)
今は問題なくても、将来は問題が出るかも
・Hash関数自体
・Hash化の方法
・ストレッチの回数
をそれぞれ保存しておく事

(なぜUnixはこの方式?)
可逆な暗号化ではない←鍵を管理するのが難しい
バックアップデータ、脆弱性などからも漏れるかもしれない

(Unix的なパスワードのまとめ)
・パスワードはHash化、その時saltとストレッチングを利用する事
・ストレッチで強度を高める事はできるが、解読までの時間引き延ばしでしかない点である事も注意

(Webシステムは?)
・パスワード情報と鍵情報を分離して管理できる
・鍵を適切に管理し、攻撃者が鍵を入手できない場合「鍵の強度＝パスワード情報の強度」となる
・ただし鍵管理のためのコストは無視できない(漏洩、改ざん、紛失...)

(Webシステムにおけるパスワード漏洩のリスク)
・攻撃による漏洩
・バックアップデータ、廃棄データからの漏洩
・開発者からの漏洩 ...etc

(鍵を用いる場合の方法)
・共通鍵暗号(パスワード情報を暗号化する場合に使う) ... 鍵が漏れなければ弱いパスワードもパスワード情報だけで破られないし、復元もできないが、鍵の管理が必要
・鍵付きHash ... ちゃんとしたアルゴリズムなら良いが、当然鍵管理重要


[Session2:「SQL Injection 小ネタ集」佐名木さん]
(なぜ今更SQL Injection?)
心の故郷w

1998年にWebApp経由でDBを攻撃する手法が紹介
2001年に日経オープンシステムで記事掲載
2003年にブラインドSQL Injectionが登場
...(以降ご存知かと思うので省略)

(SQL Injectionの対策)
・エスケープとバリデーション(ちゃんとDBMSの仕様、マニュアルを熟読すること)
●プリペアードステートメントなどの準備済みSQL文、パラメータ変数などのライブラリの使用(オススメ ... 勿論ライブラリに脆弱性がない事が前提条件)
・アクセス制御(SELECTとそれ以外で分離、管理者ロールの封印)

(デモ)
---SQL Injectionの見つけ方---
・検索にて、文字列は'を入れてエラーならほぼ確定
　・''でエラーじゃないなら十中八九確定
→これは「文字列は'～'で囲むという」「データ中の'は''と表現する」に起因する、つまり'でエラー、''でエラーでないなら、'の扱いが適切に処理できていないと推測される

・'||(MS-SQLなら'++、MS-Accessなら'&)も危ない
→'～'||''(●● or 空文字列)で正(True)

・MySQLの場合は改行、"も扱い注意

・数字の場合は計算式で判別→計算した結果が検索される場合はほぼ確定(e.g. 500と300というレコードがあり、500-200で300のレコードが検索された場合はアウト)

・union式を入れて通ってしまった場合もマズイ

---プラットフォームの特定---
・MySQLの場合 /*!(VerNo) 1*/ /*!(VerNo) or id=2*/などのように、コメントの中にバージョン番号によってコメントアウト化する機能を利用する事で特定可能

・他のシステムでも「この機能がある、ない(日付に関する関数など)」を利用する事である程度種類やバージョンを特定する事ができる

・また特定の機能の戻り値の違いによっても、OSの種類を特定することができる

・よくOR(' or 'a'='a とか)を入れて強制的にTrueにする方法があるが、使い方によってはシステムを(多量のデータにより)止めてしまう場合もあるので、使う場合は要注意!!
　・同様にUpdateに対してコメントアウト(--)を使った検索式を入れると、重要な条件がスキップされてしまい、マズい事になる場合もあるので要注意!!

---PostgreSQLのOS command Injection---
・Ver7限定、SQL Injectionが可能で管理者ロールでアクセスしている場合に成立
・SQLの中にOS Commandを実行する関数を登録、流す
・コマンドはpostgresqlのユーザ権限で実行される
・Ver8だとエラーになる→不成立

行ってきた＞AVTOKYO2010

AVTOKYO(日本語サイト)
ようやく都合が付いたので、行ってきました。
内容については、多分色々な処で出てる筈なので省略。

うん、楽しいです、是非来年も行きたいです。
今回はAfter Partyには参加できなかった(※1)んですが、来年こそはコチラも行きたいですね。

No Drink, No Hack!!
---
(※)何せ3時間しか寝ていなかったので(汗)、多分行ったら「屍」になっていたと思ふ……。

(matcha445)まっちゃ445勉強会#13

第13回 まっちゃ445勉強会 - まっちゃ445
今回も適宜更新いたします。

「Session 1:ライトニングトークセッション」
(LT1：JailBreakMeの悪用事例(totoroさん))
今回は珍しく「フルオフレコ」じゃない、totoroさんのセッション。
JailBreakMe(JBM)についての詳しい事は割愛するとして……
JBMの本体は「wad.bin」、この中身を入れ替える事で好きな環境を構築可能。
と言うか、よくウイルス出ないですよね、ホント。

(悪用例)
・Cydia(非公式アプリのインストーラ)をインストールしない

(仕込み方)
・SSIDを偽装した無線LAN的な何か(認証部に仕込んでID・Passも頂く)
・Honey Wirelessを用いる(ここでSafariをクラッシュさせる)
・wad.binを仕込む

(具体的な手法)
・定期的に外部サーバにアクセス
・特定プロセスに対してあれやこれや

(適用方法)
・行動監視とか(以下検閲により削除)

(そのほかの効能)
・条件さえクリアすれば、メールを表示しただけでもJBできるケースアリ
・iOSに仕込まれた全てのデータ(メール、写真、電話の会話内容など)がダダ漏れになると想定
・しかも殆ど気づかれない

(JBM以外では?)
・JBM以外でも実行可能
・利用者が意図しない状況で仕込まれている危険性
・利用者はそもそもリスクに気づいているか?→殆どの人はまず理解していないでしょうね

……で、デモ用の現物が回ってきたので見てみましたが……iPhoneの操作画面がそのままプレゼンの画面に表示されている!!
お、恐ろしすぎる……。

(LT2：フロッピー証拠改ざん事件から 見えたこと(Oroさん))
(一部オフレコアリ)
先日無罪が確定した某事件の中で発生した「FD改ざん事件」をテーマにした話。

……何というか、証拠の「原本」の扱いの杜撰さが何とも。orz
(以下、ヤバげな話が多いので割愛。)

「Session 2：『情報セキュリティマネジメントとモチベーションOSの相性を探る（仮）』 情報セキュリティ大学院大学客員研究員 miryuさん (twitter ID: @miryu )」
インシデント発生要因→「設備的な不備」の他に「モチベーション」もある
モチベーションとは「自ら何かしよう!と思う事」

内部犯罪のトリガーは「個人の資質」「企業風土」と「動機の形成」の3つの要素によって構成されている。
とは言え、ここまで行くと「犯罪心理学」なので、深追いするには辛すぎる……。

もう1つのインシデント→「ミス」、実は内部犯罪の半分以上はコレが原因
意図的な内部反抗はどう防ぐのか?、人的ミスをどう防ぐのか?

業務を持って帰る問題→従業員が自ら行動しているので、内部犯行(意図的な内部不正)と捕らえる

セキュリティって「めんどくさい」(給料は増えないし、生産性もやる気も下がる)……でもやってもらわないといけないのが事務局

モチベーションが下がる→「モラル低下」「集中力低下」「作業効率低下」「ミス発生が増加」
上げられれば重大インシデントは防げるのでは?

モチベーションマネジメントとは?
・マズローの要求階層理論→肝は要求は上がると下がらない
・アダルファのERG理論
・ハーズバーグの二要因説
・マクレランドの達成動機説

モチベーションOS(ダニエル・ピンク)
・OS1.0→生存を目的
・OS2.0→与えられた動機付け(飴と鞭)
・OS3.0→自分の内面から湧き出る「やる気」、「自律性」「マスタリー(熟達)」「目的」

(注意点!!)
・OS3.0が有効な環境では、OS2.0が有効に機能しない
・OS2.0が有効な環境では、OS3.0が有効に機能しない

つまりOS2.0とOS3.0は全くの別物と考える必要がある(ちなみにOS1.0は2.0/3.0の下位互換である)。

ならOSをアップグレードすればいいのか?
・後発のOSは先発のOSを駆逐するべきか?→そうではない、環境によっては使い分けるべき

業務におけるミスを防ぐには?
意図的に起こす事はない(意図的なのは内部犯行)

システム化による防止→有効だがコストが大きい
教育、啓発による抑止→コストは低いがモチベーションは下がるし効果は???

ハイブリッドOSなのか?→実はバージョンアップした方が良いのか?
リスク対応計画の策定～運用～管理を同じ人がやる方が良いのではないか?


「Session 3:ディスカッション 実際のイシンデント事例に基づく事例考察」
ディスカッション内容はオフレコなので、割愛。

勘違いしている人多し＞UNLHA32.DLLの件(と言うか……)

UNLHA32.DLL の開発停止、作者がLHA書庫の使用中止を呼びかける - /.J
UNLHA32.DLLの作者も含め、殆どの人がIPAの脆弱性関連情報の届出を勘違いしているし、葉っぱさめが呟くのもむべなるかな。

いやね、UNLHA32.DLLにそのような脆弱性があって届け出て採用されないならまだ憤るのも分かるんですが、単に具体名も実例(検証データ)も挙げずに可能性だけ論って採用されないと喚いても、ハンドリングする窓口側(この場合だとIPA→JPCERT/CC)が何処に投げて良いのか、どのように説明したら良いか分からないので余計困っているはず。

例えば某アンチウイルスソフトで、検体(テスト用ウイルス(eicar.com)を問題のあるLZH書庫形式でラッピング化したモノ)をスキャンしたらパスしてしまった、というなら、多分受理されるでしょう。何故なら、対象(プロダクトと開発元)と現象と因果(脆弱性の原因)がハッキリしており、ハンドリング可能だから(※1)。
---
(※1)勿論、最終的に報告された件が脆弱性なのか仕様なのか、また脆弱性であっても対応可能か否かを判断するのは開発元であって、窓口側ではないのは言うまでもありませんが。

(matcha445)まっちゃ445勉強会#12 雑感

前回の記事はあくまでRAWデータという事で、雑感等をとりまとめてみたいと思います。
-----
【Session1：「願い」～ペネトレーションテスターからセキュリティ担当者へ～(NTTD 辻さん)】
「ペネトレーションテスト」とは何か、そして何をする(している)のかからスタートし、作業の省力可に用いるツール(脆弱性スキャナ)の紹介と、ツールの弱点(False PositiveとFalse Negativeの発生)と、それを踏まえた上での対策(意志と思考を持つ人の力)について紹介されていました。

ツールについては、以前紹介したNessusのように色々なツールがあり、いずれも一長一短(ツールの癖)があります。
(例えばNessusだと以前はSSH系の調査がやや苦手という癖を持っていました……今は大分良くはなりましたが。)
このツールの癖というのは、調査対象によって調査し易い・し難いという形で表れるので、その辺は日頃からツールに関する情報収集を行い、この調査対象ならこのツールという形に持ち込むのが「輝手」かと思われます。

またツールはその性質上、False PositiveとFalse Negative(「ツールの嘘と沈黙」という言葉で表現していました)が発生してしまうのですが……

False Positive→検査する側が精査し本当に脆弱か否かを判断、その上で時としてレポートから除外する(または深刻度を下げる)などの対応を図る

False Negative→前述のツールの癖を把握し、その上で「他に類似する侵入口は無いか?」などを推測し、実際に手を動かして検証する事で対応を図る
……という事で対応を図る必要があるでしょう。
(質疑応答の時に、False Negativeに関する情報の共有について質問させて頂きましたが、NTTDではマインドマップを活用し、ある対象についてはこのような脆弱性が発生し易く、それに対する検査項目を整理した上で技術者間で情報共有しているとの事だそうです。)

最後に「調査するのは『人』である」という事、結局ある程度ツールでの自動化が図れるようになったとは言え、ツールは「自分の判断で任意に調査項目・方法をツール自身が変更する」というのは出来ない事から、調査漏れというのはどうしても発生してしまいます。そこは人の英知と柔軟性でカバーしましょうという事で。
(この事を「攻める側も守る側も、システムの後には人が存在している」という言葉でまとめていました。)


-----
【Session2：LTセッション】
［LT1：ペネトレーションテスターより愛を込めて part2(辻さん)］
Session1に引き続き、LTにも辻さんが登場。実際にペネトレーションテストをしていてよく遭遇する脆弱性を3種類紹介していました。
先に言ってしまうと、いずれもシステムを構築・運用する側が自ら検査する事で防ぐ事ができる「ついウッカリミス系」が多いとの事。第三者による検査を受ける前に自己診断を行う事で余計な指摘をされる事も防げますし、何より検査する側も検査対象・範囲・項目の削減が図れる事によって工数を削減できますよね。

1位は「推測されやすいパスワード」として「パスワードが空」「Joeアカウント」「デフォルトパスワードのまま」というのを挙げられていました。対象はSSH、Telnet、SNMP(コミュニケーション名)、SMB、VMC、DBMSなどと様々。

2位は「SSL関係」という事で「今更ながらSSL2.0が有効になっている」「鍵長が128bit未満」というのを挙げられていました。なお特に128bit長未満の鍵の件についてはPCIDSS 要求項目4.1が関連します。

3位は「Apache関係」という事で「Expect リクエストヘッダにおけるXSS」413エラーメッセージにおけるHTTPメソッドを適切に処理しない問題」を挙げられていました。Apacheについてはプロダクトの中に含まれているにも関わらず、システム運用側がそれを把握していないというケースがあるとの事……皆さんご注意を……。

-----
［LT2：とあるシステムの脆弱性」(totoroさん)］
相変わらず黒いのでオフレコ、一言で言うと「それは仕様です」。

まぁ強いてツッコミすると、確かに今のままなら仕様と言われても仕方がないかと。
と言うのも、「ソレ」を突く悪意有る行為のシナリオを挙げても、それが成立する前提条件が「客観的でない(統計的なデータが無い)」以上、受ける側としては納得できないのではないかと……。まずはその辺(客観的なデータを取り、確かにそれは成立するというのを証明する)を解決しない事には進展はしないのではないかと思います。

---
［LT3：Google Chromium OS Forensics(Oroさん)］
フォレンジクスを行う者として、今後出てくるであろう「Google Chromium OS」を搭載する機器に対する検証結果を紹介していました。
結論から言うと、現時点では通常の手法では技術的もそうでうが、法的にも難しい部分があるという事だそうです。

簡単に説明すると……

Google Chromium OSにはセキュリティ対策、特に機器盗難時などにディスクイメージを取られて解析されてしまう事への対策の1つとして、ユーザデータ格納部分については、ユーザ毎に暗号化されている

その暗号化に用いる鍵の1つとして「Googleアカウントのパスワードハッシュ」が挙げられる

問題なのはその「Googleアカウントを如何に特定するのか?」という事

現在Googleアカウントは、Googleのサーバ(Internet上にある)に保管されている……誰が使ったのか分からない機器を調査するために、どのGoogleアカウントなのかを如何に特定するかが問題となる

下手にGoogleのサーバにアクセスしたら、それこそ不ア禁法が適用される可能性も無くは無い……
……という事だそうです。

---
［LT4：WASF conf 2010報告会(ikepyonさん他)］
時間が余った事もあって、急遽先日開催された「Web Application Security Forum カンファレンス 2010」の報告会が行われました。
まぁこの件については各所に記事があるので、ココでは割愛させて頂きます。

-----
最後に、いつもながらですが「美味しかった」です(笑)。
相変わらずスタッフ(まーさん)が選ぶお菓子は美味しいという事で(ヲ

(matcha445)まっちゃ445勉強会#12

今回もお昼から参加、会場は1F A・B会議室です。
広いのは嬉しいんですが、電源がぁ～(あってて良かった電源タップ)。

適宜更新したいと思います。

(2010/5/29 13:03 追記)
開会、スタッフからの連絡と自己紹介からスタート。

(2010/5/29 13:35 追記)
自己紹介タイム終了、最初の休憩後はいよいよセッションスタートです。
---
【Session1：「願い」～ペネトレーションテスターからセキュリティ担当者へ～(NTTD 辻さん)】
ペネトレーションテスト(ペネトレ)に対する理解を得てもらおうというのが今回のテーマ。
ペネトレとは何ぞや?→「貫通、洞察力、眼識」。
直訳すると「貫通試験、侵入試験」(世の中的には色々なキーワードで呼ばれている)。
昔長野県でFWに穴が無いかテストしてニュースになったのがコレ。
弱点を検出後、実際の攻撃手法を用いて侵入できるかを実証し、対象セキュリティレベルを診断する。
間違った認識「外からアタック」→中からやる事もある。
IPアドレスを持っている(要は通信できる)機器ならば全て対象になるという事。

何するの?
まずは情報収集、次に攻撃方法の考察、最後に実際に攻撃し、侵入できるか確認する。
情報収集→ポートスキャン、OSやアプリのバージョン推測などなど。
攻撃方法の推測→情報収集の結果から、脆弱性を推測、攻撃手法を考える。
実際の攻撃→考えた攻撃手法を実際に試し、侵入や機密情報の奪取が出来るかを試してみる。
(筆者補足:実際には、その後結果を取りまとめてレポート化するという工程があります。)

調査にも穴はある。
沢山の調査対象→手でやったら面倒なので「脆弱性スキャナ」を使う事が多い。
脆弱性スキャナ→各種調査・攻撃パターンが多数収録されている。
辻さんの所はNessusを使っているとの事。
ツールには得手不得手があるし、設定内容や解釈にも特有の癖がある。
→なので対象やツールの組み合わせによっては誤検出が発生する事がある。

誤検出→「False Positive」と「False Negative」の2種類。
「False Positive」→下手に報告すると「存在しないものを直せ」というのと同じ……受ける側としては困ってしまう。
なので報告する側がFalse Positiveを適宜排除する必要がある。

「False Negative」→本当は脆弱性があるのに「ない」と言われる。
脆弱性と呼ばれるものには「ユーザ権限奪取」「バージョン情報・プロダクトの判明」「推奨設定ではない」など様々……だけど発生するのは重要度に関係なく発生する!!
原因は?
1.検査パターンが間に合っていない
2.検査パターンの精度が低い
3.開放ポートを発見できていない

そんな事あるの???→脆弱性スキャナの特性や検査環境によって往々に生じるので、ある意味「日常」。
なので「脆弱性スキャナには『嘘と沈黙』というリスクは常にある」という事を留意する必要がある。
道具は道具なので、ツールで自動化するのではなく、作業の効率化・工数の削減を行うために使うというスタンスが良い。
結局は検査する人がツールの嘘と沈黙を見破る必要がある。

脆弱性スキャナは「レントゲン」、その写真の中に病巣があるかどうかを判断するのは医者(検査する人)、素人(検査される側)が正しく判断するためには、プロ(検査する人)の見識が必要という事です。

侵入ハイライト(ケース紹介)
(1)Sun Solarisのin.telnetdにおけるログイン認証回避の脆弱性
スキャナによる結果→「あぶない……かも」
ならば実際に手を動かして実証してみる(通常ログイン→脆弱性を突く方法でアクセス)→パス無しで入れてしまった!!!!!

(2)管理者ユーザのパスワードが推測可能
とあるNW機器を調べた(ID:admin、Pass:password)→ツール上では1つの口では入れたが、残り2つは検出できなかった
実際に対象のポートに接続→他の2つの口も入れた!!
人は色々推測できるけど、ツールは機械だから推測する事はできません...

最後に……
世の中に完全無欠の自動システムというものは存在しません。
1つの目的を達成するために、自動で良い部分と手動でやらないといけない部分があるはずです。
「セキュリティ製品」+「設定・運用」。
自然界とは異なり、人間の意志とは無関係に脅威が自然発生するような事は、今のところはありません。
敵は「意思を・思考を持つ人間」、システムの後ろには必ず人間が存在します(攻める側も守る側も同様)。


(2010/5/29 15:20追記)
お菓子タイム終了～、今回は「京都宇治 森半」の大福とどら焼き、それぞれまっちゃ味とほうじ茶味が用意されていました。
(写真は帰宅後にアップします。)


【Session2：LTセッション】
［LT1：ペネトレーションテスターより愛を込めて part2(辻さん)］
経験から、検出されやすい脆弱性を挙げてみます。
ブッチギリ1位は「推測されやすいパスワード(SSH、Telnet、SMB、SNMP、VNC、DB系)」
どんなパスワード?→パスなし、Joe、組織名・人名(+数字、@西暦)、初期パスワード
曲者なのはJoe……「FTPで/homeや/etc/passwd」「http://URL/~usernameで」「入っていそうなアプリ名」

2位は「SSL絡み」……「SSLv2が有効になっている」「128bit未満のキー」(これはPCIDSS 要件4.1に絡みます)
お手軽に確認「ManySSL」

3位は「Apache絡み」……「Expect リクエストヘッダにおけるXSS」「413エラーメッセージにおけるHTTPメソッドを適切に処理しない問題」
2006,7年度発表の脆弱性ですが、案外ポコポコ出る……何かのアプリのUIのために一緒にインストールされていて、注視されておらず、見逃されがち

最後に……リモートからシェル奪取や権限昇格も。発見して実際に実施する事もしばしば。
でも「いわゆるウッカリが原因」というケースが多いのも事実。言い換えれば検査前に自分でチェックできるものも多いというのも事実(ちゃんと事前に自主検査しておくと、検査する際の工数も減るからお互い嬉しいよね?)。
(筆者補足:事前に自主検査しておくと、検査にかかる工数が少なくて済む→安価に提供できるので、お互いwin-winの関係になりますよね?)


［LT2：とあるシステムの脆弱性」(totoroさん)］
いつもの通り、黒過ぎるのでオフレコw
一言で表すなら「それは仕y(ry」


［LT3：Google Chromium OS Forensics(Oroさん)］
Google Chronium OSに対するフォレンジックについて検証。
ブラックボックステストという事で、コンパイル済みのモノに対してテストしています。
Google Chromium OSについての説明は割愛。
マルチユーザ対応でユーザ毎にデータ暗号化している。
ディスクイメージ解析時のユーザデータの保護のため、「小憎らしい」暗号化(技術的だけでなく法的も)、ユーザデータのワイプ、スワップアウトされたデータの保護が行われている。
初回ログオン時は要オンライン(2回目以降はキャッシュのお蔭でオフラインでも可)、ログオン認証時はHTTPS通信で行っている。
起動直後は最小構成で起動している。
ディスクイメージ解析では、ユーザディレクトリを見る事が出来ない!!
初回ログオン時に暗号化イメージとキーを作成、ループデバイスとしてマウント、暗号化キーはランダムなキーとGoogleアカウントのパスワードのハッシュ。なので、Googleアカウントのハッシュが分からないと……。

今後は……
メモリ保全&解析
ユーザログオン時にリモートから……
ディスクのイメージファイル解析を前提としたタイムラインの検討(解析にはGoogleアカウントを知る必要があるけど、それをどうやって知るのかという点で、調べた瞬間に不ア法が適用という可能性もあるのかも……)

そう遠くない未来、chromeOS搭載の環境で「内部統制や訴訟対策したければGoogleエンタープライズ買ってね」となるのかも……

［LT4：WASF conf 2010報告会(ikepyonさん他)］
先日開催されたWeb Application Security Forum カンファレンス 2010の報告会。

悪意ある者もTwitterを活用するという一例

「Twitterウイルス」の作成ツール出現、ツイートで感染PCを操作 - ITPro
ツイートそのものでウイルス(と言うかBot(※1))を広めるのではなく、ハーダーからの指令をツイートで行うモノですね。
単純にターゲットはTwitterユーザ、実際の拡散シナリオはこんな感じか?

Twitter絡みの便利なツールがあるという「偽の情報」と、偽のツール(実態はBot)を用意

偽の情報を拡散しターゲットが罠に引っかかるのを待つ

偽の情報に騙された人が、偽のツールをダウンロードしてインストールしようとする(この時点でBotに感染)

頃合を見計らって、ハーダーは指令を送る

一般の利用者にとって便利なサービスは、悪意ある者にとっても便利なツールであるという一例という事で。
---
(※1)TwitterにおけるBot……ではなく、ボットネットの方のBot。つーか同じ用語でも界隈が変わると全く意味が異なるから(他の人に伝えようとする時には)困ってしまう(苦笑)。

(matcha445)申し込みました＞まっちゃ445勉強会#12

第12回 まっちゃ445勉強会
土曜(5/15)夜に募集開始アナウンスがML経由で流れてきたので、速攻で参加申込みを実施。

今回は久々に会場が蒲田PiO(※1)、個人的にはアクセスし易いので嬉しいです。
---
(※1)履歴を調べたら、第5回(2009/2/28)以来だとか……。

今XenServerを触っているのだが……

今、諸々の事情でXenServer5.5.0 Update2を触っているんですが……初期状態のままだと、パスワード認証でrootユーザとしてSSH接続できてしまう事に驚いていたりします。

内部で使っている分には(危険性を認識した上で使うなら)まあ許容できるのかもしれませんが、これを外向け用として使う場合には危険過ぎますな。
なので初期構築はクローズドな環境で実施し、その上でsshdの設定等を変更してあげる必要がある……と。
(具体的には「接続できるホストを限定(hosts.allowとhosts.denyで設定)」「作業用ユーザを作成し、公開鍵を準備」「公開鍵による接続ができたのを確認後、rootユーザでの接続とパスワード接続を共に禁止する」などが該当。)

機密情報って「業務マニュアル」扱いに……できるのか?

日本大学、個人情報1万件以上を含む内部情報がShareで流出 - Internet Watch
日大が職員情報流出で緊急会見「業務情報は無断持ち出しだった」 - Internet Watch
いやー、あまりの「尿漏れ」っぷりに乾いた笑いしか出ないという感じ(勿論当事者からすれば顔面蒼白モノなのですが)。

単に個人情報(氏名とか)ならばまだしも、明らかに「機密(極秘)情報(※1)」扱いな情報が、一職員が閲覧できてしまえてた状況には「？」が付かざるを得ないですな。

――今回流出した情報は、大学にとって機密情報に近い内容とも思われるが、これらの業務情報は人事課の職員であれば誰でも閲覧できる状況だったのか。

　閲覧に関しては、業務マニュアルということで可能だった。情報管理についてはかなり厳しくしていたが、職員は4月24日、業務情報を USBメモリーに保存して無断で持ち出してしまった。業務情報の持ち出しは、ガイドライン上で禁止している。
(「日大が職員情報流出で緊急会見『業務情報は無断持ち出しだった』(Internet Watch)」より引用)

……記者会見でも「業務マニュアル」扱いとして閲覧可能との回答が出ていますが、この手のヤバげな情報は「マニュアル」なんでしょうかね?
(仮に事例対応集としてマニュアル扱いにするなら、個人等が特定できないようにボカした上で掲載するならまだ話が分かるんですが、情報を収集する限りではそうではないようなので。)
---
(※1)公開されたら、明らかに「組織の恥」となるような情報も含まれていた模様。

改めて概算見積してみた＞メッセサンオー個人情報流出事件

メッセサンオー個人情報流出事件の損害賠償額を計算したらエラいことになった - カオスな情報置場
ヤマガタさんの処経由、まぁ考え方としては悪くはないんですが、ちょいと評価を厳し目にしてません?

という事で、改めて自分の方でも評価してみました。なおこの評価結果等については、個人的に評価・試算したものであり、必ずしもこの通りになる訳ではない事を予めお断りしておきます。

-----
まず、今回概算評価に用いたのはJNSA セキュリティ被害調査WGが毎年出している「情報セキュリティインシデントに関する調査報告書」の「個人情報漏えいにおける想定損害賠償額の算出モデル」になります。
公開されている最新版は、現時点では2007年度版(Ver1.6)になりますので、それに基づいて評価してみます(報告書はリンク先のページにあるPDFファイルをダウンロードして下さい)。

【Step.1 : 漏えいした個人情報の価値を算出する】
漏れた項目(判明している分)に対して、「図36：Simple-EP図」の項目に当てはめ、経済的損失レベル(x)と精神的苦痛レベル(y)を算出します。
各項目に対する経済的損失レベルと精神的苦痛レベル(x,y)はこんな感じかと思われます。

名前→(1,1)

メールアドレス→(1,1)

パスワード→(2,1)

性別→(1,1)

住所→(1,1)

年齢→(1,1)

生年月日→(1,1)

携帯電話番号→(1,1)

一般加入電話番号→(1,1)

注文商品の一部（購入履歴）→(2,2)
元記事では「注文商品の一部（購入履歴）」を「性癖(1,3)」としていますが……これは過大評価でしょう。ここで言う性癖とは「これがバレたら身の破滅を招く(命が無くなる or 社会的に抹殺される)」位のヤバい情報の事を想定しており、たかがエロゲを買っていた事がバレたとしても、精々「周囲から生暖かい or 白い目で見られる」くらいでしょうから、性癖には該当しないものと想定。よって文字通り「購入履歴(2,2)」で評価しています。

そして実際に漏洩した個人情報の価値(単位はpt)を求める訳ですが、その公式は次の通りです。

漏えい個人情報価値 = 基礎情報価値 * 機微情報度 * 本人特定容易度

まず基礎情報価値ですが、これは「500pt」固定になります。
次に機微情報度ですが、この公式は次の通り。

機微情報度 = 10^(x-1) + 5^(y-1)
x,yは各評価で最大の値を用いる

今回はx(max)が2、y(max)が2なので……
10^(2-1) + 5^(2-1)
= 10^1 + 5^1
= 15
……で、「15pt」となります。
最後に本人特定容易度ですが、これは「表10：本人特定容易度 判定基準」を元に当てはめると、今回は「住所、氏名が含まれており、容易に特定可能」という事で「6pt」となります。

で、漏えい個人情報価値ですが……

500pt * 15pt * 6pt = 45,000pt

……という事で「45,000pt」となります。

【Step.2 : 情報漏えい元組織の社会的責任度を求める】
これは「表 11：情報漏えい元組織の社会的責任度 判定基準」に当てはめれば良いだけなので簡単。
今回は超有名企業という訳ではないので「一般的(1)」と評価しましょう。

【Step.3 : 事後対応評価を行う】
これは「表 12：事後対応評価 判定基準」および「表 13：事後対応 行動例」に当てはめて評価する事になるんですが、何せ現在進行中のインシデントであり、これについては「評価不能(不明、その他)(1)」としておきます。
(ある程度時間が経たないと評価できない項目なので……。)

【Step.4 : 損害賠償額の概算見積を行う】
損害賠償額の概算見積の公式は次のとおり。

損害賠償額 = 漏えい個人情報価値 * 情報漏えい元組織の社会的責任度 * 事後対応評価

で、Step.1～3で求めた値をそれぞれ当てはめると……

45,000pt * 1 * 1
= 45,000円/名

……となります。
もし仮に該当者全員(1,405名)が民事訴訟を起こし、完全に訴えが認められた場合……

45,000円/名 * 1,405名 = 63,225,000円

……6,300万強という値になります。
が、実際にはお詫び品(500円の商品券など)で満足してしまう人や、そもそも気にしていない人などが存在する事から、この額より遥かに小さい値になるものではないかと思われます。

IPA「安全なSQLの呼び出し方」を公開

安全な実装方法を解説、IPAが「安全なSQLの呼び出し方」公開 - Enterprise Watch
資料(PDF)はIPAの「安全なウェブサイトの作り方」からダウンロードできます(同名資料の別冊という扱い)。

最近はWebアプリへの攻撃の主流はGumbler型に変わっていると言われていますが、それでもWebアプリへの攻撃方法の主流である事に変わりはなく、発生した場合の被害も大きいし、直すのも大変なのも変わりはないです。

……やはり執筆に関わった人が人だけに、かなりシッカリとした資料ですね。DBの操作を伴うWebアプリを開発している人/これから開発している人は是非読むべきです。
つーか、この程度の資料を読んで理解できない時点で、Webアプリを作る資格がn(ry

勿論読む事も重要ですが、一番重要なのは(安全な環境(※1)にて)実際に手を動かして試してみて、どういうモノなのかを体感する事なのではないかと。
(結局の処、セキュリティホールと言えども、バグである事に変わりは無いですし。)
---
(※1)ローカルの開発・検証環境の事。勿論本番環境で試すのは論外だし、ましてや人様の環境に対して行うのは、不ア禁法でとっ捕まっても文句は言えませんがな。

(matcha445)まっちゃ445勉強会#11

今回は青山にあるOracle青山センターさんよりお送りしております。
随時まとめを投稿していきたいと思います。

(2010/3/6 13:07追記)
スタートしました。まずは恒例のご挨拶＆自己紹介から。

(2010/3/6 13:50追記)
自己紹介終了、只今1回目の休憩中。休憩終了後はいよいよ本編の開始です。

(2010/3/6 15:05追記)
Session1:「Security Development Lifecycle(MS ジョン・ルー氏)」
MSにおけるSDLの考え方については、ココを参照。
英語Onlyですが、ココも参照されると良いでしょう。

・各種S/W、特にWebAppについてはオンラインという特性上、常に悪意ある攻撃に対する危機に晒されていると言える。
・しかも攻撃のルート・方法は多岐に渡る。
・例え内部でしかアクセスできないモノであっても、様々なルートから攻撃が来る以上、対策する必要がある。
・セキュリティ対応は「パッシブ」と「プロアクティブ」の2種類がある。
・パッシブは従来型の対応、基本何かあったら都度対応(パッチとかパッチとかパッチとか(笑))。
・対してプロアクティブは、先に対応してしまおうという方法、ベストプラクティスを普及し、それに従い開発等を行い、脆弱性の芽を潰すという考えである。
・SDLとは言え、基本はソフトウェア開発ライフサイクルの延長線上でしかない……各段階でセキュリティの事を考慮するというエッセンスを加えているに過ぎない。
・例えはトレーニング段階では、通常のトレーニングに加え、セキュリティのトレーニングを加えると言った感じ。
・従来のソフトウェア開発ライフサイクルでは機能を重視していたが、SDLの場合、更にセキュリティの三要素(CIA)を考慮する必要がある。
・MSでは実現するために、体制を組んでいる。セキュリティアドバイザはセキュリティに関する技術・知識を伝達する事が役目で、1～数名存在する。各チームにセキュリティチャンピオンと呼ばれている人が存在し、チーム内のプロダクトに関するチェックを行っている。
・プロジェクト開始時……全員セキュリティトレーニングを実施する。
・勿論その際、上層部に対してこれらの対策を施すには十分なリソースが必要である事を申し送る事も重要である。
・設計段階では、採用するモジュールのメリット・デメリットを十分に検討する。
・今回はトレーニング、脅威モデル、Verificationについて説明を進める。
・セキュリティチャンピオンはプロジェクトの各段階において、チェックシートに対して必要事項を入力し、可否を確認しながら作業を進めている。MSでは全チェックがクリアになるまでリリースできない規定になっているとの事。
・トレーニング段階では、全員が受けるモノ、開発者が追加で受けるモノ、テスターが追加で受けるものがある。全員で受けるモノはセキュリティに関する基礎を、開発者追加版はコーディング時における危険性と対策を学ぶ事になる(例えば各種脆弱性を作りこまないようにするにはどうすればよいかというベストプラクティスを学ぶ事になる)。テスター追加版は、如何に脆弱性を見つけ、開発者に報告するかについて学ぶ。
・脅威モデルについては、この辺が参考になるかも。
[Web アプリケーションの脅威モデル - MSDNライブラリ]
http://msdn.microsoft.com/ja-jp/library/ms978516.aspx
・評価にはSTRIDE脅威モデルを用いる(ココ参照)。
・これらを設計段階で十分に検討する事になる。その際、単純に技術的に検討するのではなく、そのアプリの目的・特性も考慮する事になる。それによって、特に注意するポイントも見えてくる。
・注意するポイントを特定したら、次に対策を検討する。検討では作用・副作用両方と、アプリの目的・特性を考慮した上でどの対策を採用するか検討する事になる。
・結局リスクアセスメント・マネジメントを人力で地道に行う事で実現できている。
・実施はデータフローを用いてブレインストーミング形式で行う。勿論技術的な話だけでなく、コストも考慮する必要がある。
・マネジメントを説得する場合、攻撃を受けた場合の予測被害額と、それに対する対策にかかる金額を示す事で行っている。
・イニシャルコストは確かにかかるが、繰り返しが効くので、結果としてペイ可能との事。
・また既に外部事業者からのチェックを活用している場合でも、SDLを導入した方が良い。

(2010/3/6 15:47追記)
お菓子タイム終了～。後で写真上げます。

(2010/3/6 16:20追記)
Session2:「アクセス制御の共通化を考える（XACMLの話）(Oracle 澤井氏)」
・アクセス制御部分の一元管理→意外と難しい(できる処とできない処がある)
・アクセス制御→認証と認可の2要素で成り立っている
・なぜ共通化が難しい?→「1.それぞれに実装している」「2.共通化するための条件を満たしていない(共通項が存在し、標準化・正規化できないと辛い)」
・XACML(ザクムルと読む)、現在はVer2.0、XMLベースのアクセス制御ポリシーの標準化とプロトコルを規程している。

古い情報だが、この辺りが参考になるかも。
[PKIとPMIを融合させる次世代言語XACML - @IT]
http://www.atmarkit.co.jp/fsecurity/rensai/webserv05/webserv01.html

・SAMLとXACML……排他するものでなく、両方一緒に使うケースもある。
・実装の考慮点
　・実現性……適用範囲が狭すぎると対費用効果が低い←JavaAPI/RMI、.NET API、SOAP API、特定のアプリ
　・性能面……セキュリティ強化(認可の徹底)のために性能を犠牲にしてはいけない←PEPの実装(キャッシュ、プロトコル)、PDPの配置を工夫する
　・ポリシー管理……どのようにポリシーを管理するか?(運用できないシステムに意味はない)←使いやすさ(視覚化)、運用効率、展開計画
・XACML実装例(ココで図が表示された)
・ポリシー設定例(が示されたが割愛)
・動向:NIST RBACに対する認識→スタンダードはあるが、現実に即していない?
・動向:Access Control Model
・ソフトウェア開発とセキュリティ要件の話
　・構築フェーズ(既知の問題を潰す)と運用フェーズ(新たな問題を潰す)の違いとか
　・機能(コントロールの精度)とポリシーの違い(コントロールの鮮度)とか

(2010/3/6 16:35追記)
　　　
お菓子はこんな感じでした～。

悪くは無い、寧ろ良い事だと思う。が……

Winnyでの著作権侵害に警告メール、ISPと権利者団体が3月1日から - Internet Watch
うん、悪くは無い、寧ろ良い事だと思う。が……

取り組みの流れは、まず権利者団体がツールを用いてWinny上のファイルを入手し、団体に加盟する会員が保有する著作物であるかを確認。権利侵害が確認された場合は、IPアドレスの情報に基づいてISPに警告メールの送付を要請し、要請を受けたISPがユーザーに対して当該ファイルの削除などを求める警告メールを送付する。
(「Winnyでの著作権侵害に警告メール、ISPと権利者団体が3月1日から(Internet Watch)」より引用)

メールって、ISP側から発行されているメールアドレス宛への電子メールでしょうね。
これだと「読まずに捨てた」とされる可能性があるのではないかと……。
(ISPのメールアドレスは分かりにくいから、普段はフリーメール(Yahoo!メールとかGMailとか)を使っていて、ISPのメールアドレスは無視・放置していますって人もいるのではないかと……。)

多少コストはかかるが、書面(郵送)による警告の方が遥かに「効く」と思うんですけれどね(ISPと契約している人(親)は使っていないが、家族(子供とか)が使っていますなんて事もあるかと思いますし、その場合電子メールより書面の方が警告の度合いが強いと思うんですけれど)。

読むべき記事＞Winny裁判 控訴審判決に対する識者コメント

賢人たちのリレーコラム セキュリティ「言いたい放題」:Winny判決を考える - PC Online
うん、これは読むべき記事だと思う。

しかし、ここで少し考えてみたい。そもそもこのWinnyというソフトは包丁に相当するものなのだろうか。

　どちらかというと、筆者はもっぱら殺傷の為だけに使われる手榴弾のようなものの気がしてならない。
(「賢人たちのリレーコラム セキュリティ『言いたい放題』:Winny判決を考える(PC Online)」より引用)

手榴弾かぁ……その発想は確かに無かった。色々な処で「包丁での例え話」を目にし、その都度「何か違うんだよなぁ……」という違和感を感じていたのだが、手榴弾なら納得がいく(笑)。

技術開発に萎縮を及ぼす意見に対して、反論を怖れずに私見を述べれば、「このような判決一つで萎縮してしまう技術者には、技術開発をやって欲しくない」というのが社会科学者の本音である。いや、ITの知識のある法律学者の本音と言えば良いのかもしれない。

　確かに技術者からしてみれば、「技術のことを全く理解できない法律家なんて困ったものだ」という意識があるのだろう。しかし、これは法律家からしても同じであって「法律の知識を全く持ってない、あるいは法律を無視する技術者は困ったものだ」となるのである。文系／理系などといった壁を取り払った双方への乗り入れの意欲が大事であり、今後は法律家にしろ技術者にしろ、それが求められるべきである。
(「賢人たちのリレーコラム セキュリティ『言いたい放題』:Winny判決を考える(PC Online)」より引用)

この意見に対しては、自分も同意する。(一応高等教育機関で学んではいるが)かじった程度の身とは言え、両方の領域を知る者からすれば、別に深く潜る必要は無いけれど、さわり(概論)レベルを知るだけでも全然変わる筈なんだけれどなぁ……。

(参考情報)
香母酢とライムの違いから日本の異端ぶりを読み解く - 高木浩光＠自宅の日記
WinnyではなくGnutella系のクライアントである海外産である「LimeWire」と国産である「Cabos」の違いについて、スナップショット付きで説明されている。
仮にLimeWireが裁判の主題として取り上げられたならば、ここまで(しつこい程に)警告しているならば説明責任は果たしていると思われるだろうが、Cabosの場合は多分そうは思われないだろうと思われる。
(サイトやReadmeに書いてあると言っても、見ない人は見ない。起動後の画面ならば必ず一度は目にするし、仮に使った側が読んでいないと言っても「それは読んでいない貴方が悪い」の一言で片付けられるし。)