目覚ましの会も終わり、お昼はmiryu-sanさんと一緒にうどんを食べてきました。「丸香」といううどんやさんで、私は知らなかったのですが、この界隈では大変有名な模様。多少彷徨いながらも私たちが着いたころには店前に行列が出来ていました。うどんをいただき、お腹もふくれ、午後からはまっちゃ445勉強会です。
■まっちゃ445勉強会
関東圏で有名な勉強会の1つがまっちゃ445勉強会です。セキュリティ業界で有名な方に沢山会うこともできます。
毎回特定のテーマに沿ってその方面に有名な方をゲストとしてお招きし、30〜60分ほどお話いただき、その内容についてのディスカッションや質疑応答が行われます。勉強会の初めには参加者全員の自己紹介タイムがあったり、セッションの合間にはお菓子タイムとして毎回おいしいケーキがふるまわれたりなど、盛り沢山な内容です。piyokangoも前回に引き続き今回もドキドキしながら自己紹介タイムで何かぶつぶつと唸っていましたが、気にしないで上げてください。
さて本題に入ります。が、メモを完璧にとった自信もなく、性格がら適当なのでところどころ抜けてるかもしれませんのでご容赦を。
(1) Session1 「パスワードの話」
勉強会一人目の方は春山(@haruyama)さんによるパスワードのお話。最近ツイッター界隈でもなぜかこの手の話が盛り上がってるのが記憶に新しいです。
まずは、自己紹介としてECナビでお勤めになっており、普段は本をスキャンされるお仕事を担当されているとのこと。また、執筆活動もされてらっしゃっていて、暗号技術大全(18章、20章)やOpenSSH本にも携わっている。また、ApacheのSolrといった勉強会、神泉セキュリティ勉強会の主催をしてらっしゃるらしいです。（すごいです。）また余談として、会場提供も出来るので、ぜひ必要な場合は相談してくださいとのこと。お酒をふるまっていただけるらしく、参加者の方に軽めの出費をいただくだけで懇親会を楽しめるのだそうな。。。行ってみたいですね。なお、セミナーの資料はここにあがっているので、興味のある方は是非。
ここ最近では、「第6回 経営者が注意すべきパスワードクラッキング」やTwitter上でやり取りされた「平文パスワードの再送問題」にあるように、パスワード関連の話が盛り上がっていますねというところからスタート。今回この勉強会で話すことになったキッカケとしては先の神泉セキュリティ勉強会でパスワードの話をしたのがあり、それに参加されていたikepyon(@ikepyon)さんから講演の依頼がきたためだそうです。またこの話をするに当たり、参考文献としては、man3crypt、CRYPTOGRAPHY ENGINEERING、認証技術パスワードから公開鍵までといった3つをあげてらっしゃいました。
今回の話をするにあたって、パスワード情報が漏れた時にパスワードが破られにくくする方法にポイントを置き、当然ながらパスワードが漏れないこととユーザー自身に強度の高いパスワードをつけてもらうこと、これら2つが行われることが望ましいとのことでした。ただ、強度の高いパスワードを無理やりに強制することも考え物で、場合によっては利便性が損なわれたり、長すぎるパスワードはおのずとわかりやすい単語を使いがちで、結果として辞書攻撃に弱くなってしまったりもするので、一概にはこれ自体がよいと決めつけてしまうのも早計とのこと。
パスワードの保存については、「saltをつけてハッシュ化する」という方式がよく言われており、この常識化した理由としてその方式がUNIXで取られているからではないかと。しかしながら、案外その中身の仕組み自体を知っている人は少ないらしく、UNIX的なパスワードの保存を紹介いただきました。今回説明いただく対象として取り上げていただいたUNIXはGNU/Linuxでのパスワードの保存方式。/etc/shadowに決まった形式で保存されている。形式は$id$salt$hashといった文字列で構成されており、最初のidの箇所でどのような暗号方式でハッシュ化されているかが決まっている(1の時はMD5、5の時はSha256,6はSHA-512）そうです。
ハッシュについての説明（一方向性、衝突耐性など）もありましたが、Wikiのページを参照されたとのことです。（なお、IISECの有田先生の書かれたHashの項も参考になりますので紹介させて頂きます。）次にSaltについてですが、パスワードとなる文字列とともにまぜる文字列のことで、いわゆる調味料的な存在で、なぜSaltが必要とされるのかについては、レインボーテーブルによる攻撃が存在するため。レインボーテーブルによる攻撃とは、あらかじめ文字列に対となるハッシュ値を計算し、平文を変換するテーブルを用意することでハッシュ値から値を取得することが出来るというもの。ただSaltを利用するに当たり、Saltを使いまわしてしまうと同じパスワードを使うユーザーはすべて同じハッシュになってしまいあまり意味がないので、ユーザーごとに異なるSaltを利用する必要があるとのことです。とはいっても、ランダム性はあまり必要ないそうで、重要なのはあくまでもユーザーごとだそうです。これは、特にセッション内では取り上げられていなかったと思いますが、タイムスタンプでも十分ユーザーごとのSaltになるかと思います。
このレインボーテーブルによるパスワードクラックについては、デモも行われました。デモは、FreeRainbowTablesを用いてMD5で生成された文字列を推測するというもの。会場では「ikepyo」という文字列をハッシュ化したものをレインボーテーブルを用いて、合致するものを検索するというものでしたが、およそ3分もかからずに合致するハッシュが見つかり、ハッシュ化された文字列がikepyoであることが分かるというものでした。なおSaltのサイズについては、伝統的なLinuxでは4096通り(12bit)で少ないそうで、現在ではハッシュのサイズと同じbit数にする(たとえばSHA-256ならSaltも256bit)というのが安全だそうです。
また、強度を高める手法としてストレッチング(Stretching)と呼ばれる方法があり、その紹介がされました。Stretchingとはハッシュを繰り返し何度も利用することで、ハッシュ値を求める時間を増大させる効果が期待できるとのこと。8コアのCPUであれば、現在は6文字のパスワードであれば0.2日、7文字なら13日もあれば合致するハッシュが求められるものの、このStretchingをすることで5文字であれば3日、6文字なら半年以上計算にかかるようにすることが可能となるそうです。ただし、ハッシュ関数自体やハッシュ化の方法に問題が見つかったり、またStretchingの回数を変更するなど、長く運用するシステムの場合は将来的な問題の発生に備えるために、パスワードをどのような方式で保存したのかをパスワード情報とともに保存する必要が出てくるのことで、これは先のUNIXでいうID番号に該当します。
次にUNIXでこのような方式がとられる理由について説明されており、それは「鍵を管理するのが難しいこと」と「1つの物理的マシンですべて完結させていたため、パスワード情報と鍵を同じマシンで管理しなくてはならないため」というのが理由だそうです。UNIX的なパスワードの保存についてのまとめとして、弱いパスワードは記録された情報だけで破られてしまいますが、ストレッチングで寿命を延ばすことは可能。ただし、これは根本的な対処ではなく、ある程度の対処に留まることに留意してほしいとお話されていました。また、UNIX的な方式の場合は、鍵管理が不要で、生パスワードを復元できないというのが性質としてまとめられていました。
さて次にWebシステムではどうかとうお話です。Webシステムでは、パスワード情報と鍵を別に管理可能で、UNIXよりもパスワード情報と鍵がともに漏えいするリスクは小さくできるというのが特徴とのこと。鍵を適切に利用すれば攻撃者がカギを入手できない場合、その鍵の強度そのものをパスワード情報の強度となりますが、鍵管理のコストも軽率に考えることは出来ないので注意が必要とお話しされていました。これは漏えい、改ざん、紛失などに対処するコストとして見る必要があるよというお話のようです。
そして、Webシステムでのリスクとしては表側だとSQLインジェクションなどによるものやバックアップファイル、実サーバー、廃棄サーバーなどからの漏えい、開発者・運用者によるパスワード情報の漏えいや悪用があり、つまるところパスワードを利用するシステムでは、サイト（開発者など）を信用できなければ、どうにもならないのではないかとのこと。
鍵を用いる場合の手法案として、共通鍵暗号、ハッシュ＋暗号、鍵付ハッシュそれぞれの使い方、性質を取り上げられていました。
最後にharuyamaさんの個人的な考えとしては、ユーザーになるべく強度の高いパスワードを利用してもらい、UNIX的パスワード管理で利用してもらうのがやはり望ましいのではと考える。
質問は下記の通りです。
ソルト、ストレッチングについてWindowsベースのシステムの場合、実装例があるか。
→Widowsの場合は、ソルトを使わないのが標準となっている。ユーザーとしてやっているのは15文字として（NTLM方式で）パスワードを保存させるように推奨している。14文字以下だとLM方式のハッシュも保存されてしまうため。
Windowsだとスマートカード認証もNTLM認証形式で行われるのか。
→スマートカード認証は今回取り上げていないので、ご存知の方は調べてください。。。
定期的変更はしている人いるか。
→Pマークなどで定まっているので、15文字以上で1カ月がんばってつけている。パスワードはおぼえないほうがいい。パスワードを覚えてしまう場合も、戦略的に対応するのもあり。（バス停を列挙するなど）
今回お話しいただいたネタ以外にも、パスワードに関するお話をたくさんご用意いただいていたようで、先ほどのharuyamaさんの資料に掲載されています。定期的変更やパスワードリマンダのお話など興味深いものがたくさんあります。
(2) お菓子タイム＆抽選大会みなさんお待ちかねのお菓子タイムです。今回のお菓子はシェシーマさんよりご用意いただいたものだそうです。7種類あったみたいです。私はモンブランをセレクトしました。こぼしてしまわないか慎重に食べつつではありながらも、甘くておいしかったです。また、抽選ジャンケン大会としては先日発売されたばかりのHackerJapan1月号や、某メーカーのお猿卓上カレンダーなどが景品として取得できたみたいです。私は既にHackerJapanを買ってしまっていたので、残念ながら参加できませんでした。今後はそこらへんの未来を読むスキルも必要なのかもしれません。
(3) LT 「サルでもできる安全なWebアプリケーション」
休憩後、プログラムにはなかったのですがikepyonさんのLTが行われました。
以前IPAのページに掲載されていた安全なWebアプリケーションを作るにはどうすればいいかのサイトで取り上げられていた「例えばPHPを避ける」という今考えると不思議な対策として取り上げられた内容にのっとって、「例えば〜避ける」というのを考えられたそうです。
例えば、コピペプログラミングを避ける
例えば、コ−ドを書くのを避ける
例えば、コードをかけないプログラマを避ける
例えば、RDBMSを避ける
例えば、SQLを避ける
といったものを紹介されていました。他にもあれば、ぜひつぶやいてほしいとのことなので、何か良いものがあれば皆さんも考えてみてはどうでしょうか。私は仕事を避けたいです。
(4) Session2 SQL Injection 小ネタ集
勉強会2つ目のセッションはNTTコムテクノロジーの佐名木(@tomoki0sanaki)さんによるSQLインジェクションの小ネタ集紹介について。佐名木さんは1998年からセキュリティ診断の担当をされているそうで、他にもIPAのセキュアプログラミング講座やセキュアWebプログラミングTips集の執筆を担当されている。手動で診断サービスをやっており、SQLインジェクションが得意技だそうです。なぜSQLインジェクションかといえばそれは、心のふるさとだからだとおっしゃっていました。素晴らしいです。
まずはSQLインジェクションの歴史についてで、1998年にPhrack54にWebAP経由でDBを攻撃する手法として紹介されて以降、2001年に日経オープンシステムにこのSQLインジェクションのことを書かれたそうで、そして2005年の価格コムや2008年のサウンドハウスの件で有名になったそうです。ただ、入社2，3年目の人でも、今一つこのSQLインジェクションについて知らない人が多いそうで、5年サイクルぐらいで有名になったり、下火になったりを繰り返しているんじゃないかとお話しされていました。過去の傾向から次は2017年に流行るかも？だそうです。
SQLインジェクションについての説明もあり、「Webアプリケーションの背後で稼働しているDBを対象に、SQLを使ってデータを取りに行くが、その問い合わせをうまく細工することで、構文エラーとせずにDB側で実行したデータを取得することが可能になる。」とのことです。そのSQLインジェクションの対策ですが、時間があるならマニュアルが読むのをおすすめするそうです。実は意外な発見もあったりするそうで、MySQLではエスケープがバックスラッシュとなるというのもマニュアルから見つけられたとのこと。対策の基本は入力文字のエスケープで、数値リテラルを用いた文字列については、妥当性検証としてバリデーションによる対策も必要。また、シングルクォートだけではなく、バックスラッシュも見る必要があるとのことです。また、静的プレースホルダ（バインド機構他いろいろな呼び方があります)などのデータマッピング用のライブラリを利用するのがお勧めで、これは本来はセキュリティの対策ではなく、問い合わせ速度やオブジェクトの可視化などを目的としたものだそうですが、その副次的産物として自動的にSQLインジェクションを防ぐことが出来るようになるので対策に漏れなどのリスクのあるエスケープによる対処だけでなく、この静的プレースホルダを用いた対策も有効とのこと。そして、アクセス制御も出来ればやったほうがいいらしく、全部をがんばろうとすると非常に複雑になってしまうので、最低限SELECTとそれ以外を分けることはしたほうがいいとのことです。参照のみのテーブルなどを対象とした場合のお話です。
ここからはデモによるSQLインジェクションの事例紹介です。ポストグレス7が背後にいるWebアプリケーションで、一覧→詳細といったページ構成になっています。該当のサイトにSQLインジェクションがあるかどうかは、シングルクォートを入れてエラーが出るかどうかで判別するそうです。エラーが出ればほぼ黒、さらに2つシングルクォートを入れて何も出なければほぼ確定だそうで。これはシングルクォートのエスケープに起因した話だそうです。
次に文字列結合演算子のお話で、稼働しているデータベースによって扱われる文字列が異なるとのことです。||(パイプを2つ)はポストグレス、SQL Serverの場合は＋、Accessは＆で、これを使うことで、利用しているDBも把握することが出来るそうです。また、MySQLの場合は改行コードも文字列結合演算子として扱うことができるみたいです。またMySQLでは、文字列をくくる際にダブルクォートでもでき、シングルクォートだけではとのことです。
次にSQLインジェクションを使ったプラットフォームの調査方法の紹介です。MySQLの場合、コメントの中にバージョンごとに実装を分けて操作することが出来るようになっているそうです。ポスグレやOracleは実装されている関数で調べるそうで、Oracleは特にUnicode系で試すことが出来るみたいです。またMySQLではCrypt関数を呼ぶとUnix上で動いているかどうかを調べることが出来るそうで、Windowsだと値にNullが返却されるのでそれで識別が可能だそうです。
佐名木さんがよく行う手法として、ポスグレとOracleの見分け方はCurrent_dateを使うそうです。Sysdate、Nowとかの日付関数を使うことで文字列結合演算子以外で調査することが出来るため。また数字の場合は、計算式を入れてそれが機能するかを確認することで、数字以外のものを入れることが出来ると判断することが出来るとのこと。引き算がおすすめ。(足し算はURLエンコードがめんどうらしいので)
次にUNIONの話で、詳細画面でUNIONがうまくいっても1件しか出てこない、おもしろくない、とのこと。実装としては、1つ目に何件取ることが出来たか、、2つ目で該当の内の10件とかをとるようなタイプのWebアプリケーションが主であるため、UNIONが動くからといってもそれそのものがうまくいかないケースは少ないみたいです。なので、うまくいったときは神に感謝しましょうとのこと。
次にOSコマンドインジェクションで、これはポスグレのバージョン７のみで確認できているそうです。DBにSQLインジェクションが出来、OSコマンドインジェクションが出来、かつ管理者権限で動いているという前提です。CreateFunctionでLibcを定義した後、一度実行し、関数を登録します。Bashの中に仮想ネットワークファイル（/dev/tcp/192.168.***.***）が存在するので、それを利用してバックドアを生成することが出来るそうで、デモでも入力と出力をそれぞれポートを分けてデモをされていました。なお、ポスグレ8の場合はlibcが存在しないのでダメと怒られるので動かないそうです。
次はよくためす「'or 'A'='A」についてですが、これはログイン画面のみにしたほうがいいとのこと。なぜならアップデートがかかってしまうと全部のデータが書き換わってしまうので、もし動いてしまった場合は非常に大変なことになってしまう。ハイフンハイフンも同様だそうです。
質問は下記の通りです。
データベースへパスワードを平文で保存するWebアプリは多いのか。
→診断した経験上多めに感じる。これは元から意識してないケースの他、リマインダー方式などを採用するとユーザー自身がこなくなってしまうことが要因ではないかと考えている。
カラムの名前はよくあるもの？
→大体同じ。攻撃者と知恵比べしてもしょうがない。テーブル一覧、カラム一覧などをとることが可能であり、それを使うことで対処することが出来る。昔のMySQLは使えなかったが、最近は使えるようになって、インフォメーションスキーマー経由で取得することが出来る。
なお、最後には睦月さんのITSEC_JPの紹介が再度行われました。
14回目は以上で終了です。
まとめたつもりが全然まとまってなかったですね。すみません。
今回も非常に勉強になりました。ありがとうございました！
