マイクロソフト セキュリティ情報の事前通知 - 2010 年 12 月 - Microsoft
今回は計17本、内訳は次のとおりです。
OS ... 12本
OS+IE ... 1本
Office ... 2本
Share Point ... 1本
Exchange Server ... 1本
今回は非常に多いので、それなりに時間がかかるかと思います。
今回は計17本、内訳は次のとおりです。
今回は非常に多いので、それなりに時間がかかるかと思います。
第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だとエラーになる→不成立
今回もメモレベルですが、ざっと書き記してみたいと思います。
[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だとエラーになる→不成立