今回もお昼から参加、会場は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の報告会。
広いのは嬉しいんですが、電源がぁ～(あってて良かった電源タップ)。
適宜更新したいと思います。
(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の報告会。
