Garbage Script on Goo BLOG

某SIerの"元"研究者 兼 情報Security技術者"F.Koryu"の日常の雑記置き場

OWASP Japan 1st Local Chapter Meeting

2012-03-27 18:38:04 | セキュリティ(技術者向け)
OWASP Japan
OWASPの日本チャプターが結成された記念という事で、初めてのMeetingが水天宮の日本橋公会堂で開催されました。

今回もいつもの勉強会レポートと同様、速報ベース、かつ聞き取れた範囲内でざっくりとレポしていきたいと思います。
---
【OWASP/OWASP Japanについて(Benny Ketelslegers)】
・OWASPとは?
・既にご存知の方も多いですが、(Web)アプリのセキュリティ向上のための活動をしているボランティア団体です
・OWASP謹製のツール、レポート等は自由に利用する事が可能
・(有償の)会員になる必要は無いけれど、なればそれなりの特典がある(Appsecへの優待割引が適用されるなど)
・最近はAndroidセキュリティに関する活動も行っているよ

・OWASP Japanとは?
・OWASPの日本チャプターの事、メンバーや各種活動への参加は随時募集中!!
(詳しくは記事頭のリンク先をご覧下さい。)
---
【Introduction of CSP(Yosuke Hasegawa)】
・scpとは?→コンテンツセキュリティポリシーの事
・Firefox出自の機能(他のブラウザでも対応しているものがある)
・XSS根絶の切り札
・指定された以外のコースが読めない、インラインスクリプトの禁止、evalやイベントの禁止
・レスポンスヘッダで許可するリソースを指定(ブラウザの種類によって指定方法が違うケースがあるので注意)
・metaでも指定できるけど、あまりオススメしない(上書き禁止だし、metaが読み込まれるまでの間が無防備である)
・リソースの種類毎に指定が可能
・ポリシー違反時にレポートを送信できる機能もある(この機能だけ有効にする事も可能)
・しっかり指定することで、第三者によるリソースの読み込みを確実にブロックする事が可能だが、まだ過渡期の技術のため、副作用もあるので注意

・Breaking CSP
・E4X(JavaScript内でXML型をサポート、Firefoxのみ)
・HTMLをJavaScriptと解釈させれば
・自分自身(HTML)は読み込み可能
・ちゃんとDoctype宣言をすれば対応可能
---
【脆弱なWebサーバを作ってみた(仮)(Yoshinori Takesako)】
・脆弱なWebサーバを突いてみた
・実は社内の勉強会(新人参加可)でやってみた事の顛末だったり
・LASDECのセキュリティ健康診断(これで検索すると仕様書が見つかるので、各位それを見ましょう)
・Badstoreを用いたハンズオンを実施(筆者補足:isoイメージをダウンロードして、CDブートさせればすぐ環境が出来上がります、お勉強には最適ですヨ)
・検索結果(エラー画面)から、内部で走っているSQL文を推測→全部のデータを表示させてみる→それを踏まえて色々とSQL Injectionしてみよう
・エラー画面にMD5っぽいハッシュ値が出た→MD5クラック用の検索エンジンというモノも併せて活用してみる
・他にも色々と面白い?仕掛けがあるので、色々と試してみると良いお勉強になります
・Badstoreの類似教材として、以下のようなモノもあります
・IPA AppGoat
・Web Security Dojo
・OWASP WebGoat
・警告:他所様が管理しているサーバにはやってはいけません!!(不ア禁法でとっ捕まりますので)
---
【ここが変だよ、グローバルスタンダードの脆弱性対策~入力値の考え方~(Hiroshi Tokumaru)】
・OWASP Top10とは?→ワールドワイドでのWebセキュリティを脅かす脆弱性をランク付けした、年1回の風物詩
・2004年版で出た入力値検証
・CWEとは?→Common Weakness Enumeration(ココとか)
・入力値検証→CWE-20→範囲広すぎ!!
・バリデーション至上主義な解説例(某Ajaxセキュリティな本)を滅多切り(ヲ
・バリデーションでは防げない攻撃ってのもあるんだよ
・実は2007年版以降は入力値検証は出てきていません……
---
【バイナリパッチによるAndroidアプリの改ざんとセキュリティチェックのバイパス(Yoshitaka Kato)】
・Androidアプリのリバースエンジニアリングは非常に容易→改ざんも容易
・今回はバイナリパッチで改ざんを試みます
・バイナリエディタとdexdump(SDKに収録されているツールの1つ)があれば出来ます
・バイナリデータの解析には、Dalvik opecodeが参考になります
・classes.dexというファイルが実行バイナリです→これにdexdumpを当てます
・基本的にマーケット規約上では禁止されているので、その点は注意!!→なので今回は自分で作ったアプリで試しています
・アプリ内でセキュリティチェックをかけているが、それを回避するパッチを当てる
・プロセスはこんな感じ
(1)アプリを入手し必要なファイルを抜き出す→(2)dexdumpでパッチを当てる場所を特定→(3)バイナリエディタで該当箇所を修正(チェックサム修正も併せて)→(4)CRCを再計算→(5)ZIP化と署名
---
【Broken Logic: The Test Site Fallacy(Isaac Dawson)】
・Webアプリ脆弱性スキャナを使っていますか?
・テストサイトって?→スキャナの開発会社が用意したデモ用のサイトの事
・顧客はスキャナをかけた結果(脆弱性の発見具合)でスキャナの実力を測る
・テストサイトの問題点って?→基本的にクローズドソースである(完全なるブラックボックステストである)→実際にどの位仕込まれているかが分からない
・多くのサイトがPHP+MySQL or ASP/ASP.net+MS-Accessで開発されている→プラットフォーム依存の脆弱性は???
・アプリが正常に動作しているか?→この手のテストサイトは世界中の人からアクセスされるため、正常に動作していないケースが発生する場合もある
・最も厄介なのは「非現実的または『偽』の脆弱性」が仕込まれている場合がある事
・上記のような事があるため、テストサイトでスキャナの実力を測る事は、じつはあんまりよろしくない(何せテスト結果が信頼できないから)
---
【ぼくらのすすむみち featuring Rakuten-CERT(Yusuke Gunji)】
・楽天CERTの紹介
・楽天全体での開発者数は1,600名程→これらの人が楽天の各種サービスを開発しています
・楽天グループ内部に対するセキュリティサービスを提供する組織として社内CSIRTが組織された
・楽天の開発プロセス→大きくは一般的な開発プロセスとは変わりはないが、各プロセスにおいてセキュリティプロセスを設けている
・ツールはAppScanを利用
・手動監査は基本ブラックボックステスト+実験的にグレーボックステストも取り入れている、外注だけでなく、社内でも実施(6:4)、専門のテスターは数名程度
・監査のペースは1日1件弱ペース、最も多く発見されるのはXSS、次いでエラーコードの表示も、CSRFと続きます
・今後はセキュリティ教育や、アジャイルとセキュリティの融合に力を入れていきたいと模索中
---
【Japan ChapterからWebアプリケーションセキュリティ要件定義書の提案(Sen Ueno)】
コレのご紹介
・早めの対策の方が、かかるコストを抑えられる→ならば要求仕様・要件定義段階だ
・開発工程での脆弱性の発見の割合→多いのは「設計」と「実装」段階
・システム開発を依頼する側→素人なので良く分からない→曖昧な仕様の出来上がり→でもこれってトラブルの元だよね(お互いにとって不幸だ)
・開発を依頼する側、受ける側お互いが幸せになれる(瑕疵担保責任の範囲を明確にする)ようにするために、要件は明確化する必要がある
・攻撃の殆どはパターン化されたモノ→要件もパターン化できるのでは?→作ってみた(ライセンスはCCなので、ご自由にお使い下さい)
・今後の流れ→WG作る?、内容の精査や諸外国の要件定義との比較、英語への翻訳・公開など

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

2012-03-17 16:57:48 | セキュリティ(技術者向け)
第19回 まっちゃ445勉強会
開始しました。毎度の如く、速報ベースでレポートしていきたいと思います。
-----
(Session1:情報漏えいの効果的な対策(AIDOさん))
・スタートはいつものネタ(ラ○ブ○ス)なので割愛(ヲ

・情報漏えいのケースと対策
・メール経由での情報漏えい
→添付ファイルが問題だが、一律に禁止にするのは業務上難しい
・原因→宛先間違い、添付ファイル間違い、消去漏れ、顧客のメアド間違い(BCCにするはずがCCに)、不正持ち出し、自宅への無許可持ち帰り
・手間がかかる対策→上長承認(人的タイムラグ、上長の負荷大)
・効果の低い対策→暗号化(自動・手動問わず)の場合は宛先間違いには効果なし、添付ファイルにパスワードを設定して別メールで送信→盗聴に弱い
・効果的な対策→社内宛送信メールは上長のBCCを強制、宛先の数、メアドの種類、ファイルの内容等によってスコア付けして、閾値を超えたら各種対策が発動する(上長の許可、暗号化など)

・FAX経由
・原因→宛先間違い、送信文書の間違い、FAX機内に残っていた文書をまとめて送信(複合機だとリスクが高い)、電話帳の登録ミス、無断持ち出し、発信時に着信すると混信する
・手間がかかる対策→ダブルチェック(複数人立会い)は形骸化する、業務センターに集約した上で監視、再送信
・効果の低い対策→暗証番号による無権限者の送信禁止(でも送る人は権限持っている人ですよね?)
・効果的な対策→ログ(送信イメージ含む)をサーバに蓄積、送信記録簿を「手書き」で記入し月次でログと付き合わせる、Web FAXシステム(FAXサーバ経由で送信し、利用者はWebアプリで確認)

・無断持ち出し(カバン)経由
・原因→紛失、盗難、電車の網棚の置き忘れ、タクシーの中におき忘れ、カバン間違い(良く使われるカバンは要注意)、媒体の紛失、自宅PCに取り込んだ後に漏洩
・手間がかかる対策→事務フロア入室時にカバンをロッカーに預ける(DCなど限定した部署への導入では効果は高いが……)、PC持ち出し専用のカバン
・効果が低い対策→プリント時に、印刷した人のIDを透かしとして入れる
・効果的な対策→媒体への出力禁止 or 許可制、媒体への出力時に強制的に暗号化、リスクの高い日(給料日、連休前、忘年会シーズンなど)の前週に役員から部長以下へ注意喚起メールを送付、カバン紛失は入退館IDカードの再発行申請で発見できる

・無断持ち出し(Web)経由
・原因→あて先間違い、ファイル間違い、消去漏れ、ネットストレージの公開設定の間違い、自宅PCに取り込んだ後に漏洩
・対策を難しくする要因→顧客・取引先のファイル送信時に、先方からアプリを指定されるケースがあり禁止にしにくい、送信時にダブルチェックできるアプリが少ない、SSLを利用されると持ち出した情報が暗号化されていて分からない
・効果的な対策(部分的)→Webメールについては、Webフィルタリングソフトで殆ど禁止可能、大容量のアップロードのみログを検出し、抜き打ちで検査

・Winny等のP2Pでの情報漏えい
・問題点→自宅PC内のメールや個人の趣味嗜好に関する情報が漏れる、場合によっては社会的な信用失墜にも……
・事前策→規定で利用禁止にし、自宅PCでの利用状況を検査する

・社外利用での情報漏えい
・盗難、紛失、覗き見
・対策→HDD全体の暗号化、覗き見防止フィルタ、貸し出し管理簿の記録管理、ログイン中の離席は厳禁

・社外利用端末での情報漏えいの事例
・個人情報保護対策(内部データは暗号化、24時間で内部データを消去)を施した専用端末(PDA)を一斉導入
・持ち出せる情報の量は、1日で訪問できる範囲内に制限し、営業日報をシステム化して連動
・認証は指紋のみ、一定回数失敗すると初期化のみ(なった場合は支店に戻る(車で30分程度で戻れる))
・業務以外のアプリは削除
・結果、紛失、盗難はゼロ
・訪問予定と実績の管理が強制され、業務が効率化した

・マネジメントサイクルで見た対策
・事故情報の収集→小さな情報であっても漏れなく収集、起こった事象ではなく、原因や状況、環境まで記載させる
・記録遅延は厳罰とする代わりに、第一報は簡便なレベルで可とする

・原因の分析
・リスクは数値化する、母数が変わったり統計的に不正確であっても、感覚的に頻度や大きさがつかめればOK
・4半期単位で変化を見る
・どのように集計したか明記されていれば、それこそ期毎に集計方法が変わっても構わない(統一するに越した事はないか)

・対策→優先度をつけて行う
・残存リスクの扱い→放置ではなく、文書化して、役員の決済を取る
・何もしていないこととは違う
・取りやめと検討の継続は違います

・評価
・対策前後を数値化して効果を計測
・無理はしない、原因が不明な事も当然ある

・役員報告
・短時間で実態を把握するためのサマリは必要だが、実データも合わせて付ける事

・年度リスク管理計画
・達成できる目標は意識しない

・監査による改善促進
・どこを監査する?
・エビデンスがベース、リスクがある監査対象は、原則何らかのエビデンスが残っているはず
・記録があれば、規則・実務・記録の比較ができる
・数字で変化が見られれば、評価もできる

・メールの場合、外部宛の送信件数(添付ファイルの有無もだけでも統計を取る、サンプルチェックなら、のサンプルチェックを毎月何件と決めて実施する→記録するから変化が見られるので、足りているか否かが客観的に見られる→見られる形であれば、監査においても過不足を指摘できる

・ファイル転送の場合、アクセス履歴を元に業務上の理由を上長に提出させる→監査が入る可能性があれば、上長のチェックも形骸化を防げる

・まとめ
・箱物導入して満足していた時期から、管理部署は自分達で評価する時期に来ている
・評価できれば、改善の余地はまだまだ工夫できる

-----
(Session2:東日本大震災から1年~情報セキュリティは組織に何を提供できるか?~(頼長さん))
・情報セキュリティとは
・情報セキュリティは何をカバーするのか?→情報セキュリティのCIA→バランスを取るのが重要と言われているが、本当にバランス取れてる?
・ISMS→資産目録をベースにリスクアセスメントを行う
・これまでの情報セキュリティ
・例えばJNSA→インシデント、個人情報漏洩以外の報告書はない
・情報漏えいは怖い
・需要がない?
・定義ができない?(機密性が高い情報資産とは?、可用性が高い情報資産とは?)
・対策(の例は多いので割愛)→共通性は?→全部機密性に偏っている
・情報セキュリティが機密性管理に寄ってしまう背景→法令、Pマーク、Winnyなど
・完全性、可用性が問題になった事はないのか?
・阪神淡路の時はまだ機運が高まっていなかった
・なら東日本大震災は?

・東日本大震災と情報セキュリティ
・津波による被害が甚大だった→この前となると93年の奥尻地震になってしまう
・複合、超広域災害
・津波による被害
→事後対策の無力化(津波が来るまでMaxでも30分程度)
・業務の早期再開、継続要求
→経営資源がないと事業が再開できない
→実は可用性、完全性対策も重要だった

・津波によるインシデント事例
・住民基本台帳、戸籍データ
・南三陸町→地震・津波で壊滅、バックアップ先(気仙沼)も津波でアウト
・結局再申請になった
・もし企業だったら???
→失われたら完全に喪失してしまう

・情報セキュリティへの問題提起
・この情報管理に問題は無いのか?
・機密性は確保されている
・でも問題は無いのか?

・非常時に組織はどう行動するか、「生き残る」ために活動する
・業務を絞り込む
・絞り込んで業務は継続するのか、リソースを確保するのか
・情報→続けるために必要となる情報

・事業継続マネジメント→初動対応+事業継続(復旧)対応
・初動対応→残存リソースの確保
・時宜用継続対応→予め定めた優先度に従って、事業を復旧させる

・よくある可用性評価基準の例→実は良く分からない(曖昧過ぎる)

・震災を乗り越えるための情報セキュリティ
・緊急時に必要な情報の特性
・可用性→一刻も早い復旧のために、リソースを確保する事が重要
・情報がないと業務再開はできない
・迅速に取り出せないといけない
・平時と異なる人が業務を行う事もある

・災害を踏まえたセキュリティ
・リスクアセスメントの問題
・可用性リスクを如何にアセスメントするか
・教務と情報資産のリンク付けは不可欠

・セキュリティポリシー(リスク対応)の問題
・平時とは異なるポリシー

・情報リスクの既存の考え方を拡張する
・時間の概念の導入
・重要業務の考え方の導入
・重要業務と情報資産との関係の明確化

・ビジネス・インパクト・アナリシス(BIA)
・簡易的な業務分析→重要なのは経営資源(人・モノ・カネ)と時間(許容される停止時間(他社志向)と、目標とする復旧時間の設定(自社志向))
・更にRPO(リカバリー・ポイント・オブジェクティブ)を加えると良い

・可用性の視点を考えるときに最も重要な考え方
・時間の概念を導入→いつまでに必要なのか?(BCM的な考え方)
・ISO27002 Annex 14項(JISの場合はQ 27002)を見ると良い(クライシスマネジメントの考え)

・重要業務に紐付く情報資源が、最も重要な情報である

・リスク対応における機密性と可用性の関係→相反する要素になるので、基本は「どこまで機密性を犠牲にするのか」というアプローチになる(だからBIAのような根拠付けが必要となる)

・情報の可用性を確保するための対策例
・アクセスする人間(キーマン)の喪失・人員の不足
→手順書の開示範囲を広げる、アクセス可能な対象者を増やす など
・アクセスできる場所の喪失(交通機関の寸断など)
→社外から社内への接続環境の用意、クラウド化 など
・アクセスされる情報(情報自体)の喪失・バックアップの同時滅失
→クラウド化、遠隔地バックアップ など
・システム対応と平行してポリシーの改定も必要

・まとめ
・これまでの対策は機密性に偏り過ぎ
・震災ではこれまでの対策で乗り越えるのは困難
・クライシスマネジメント観点での対策と組み合わせる必要がある→可用性対策、そのための評価
・時間と重要業務という評価項目の追加は必要
・機密性と可用性のバランス感覚を取り戻す必要がある

iPod Touchを買っていたり

2012-03-10 01:48:06 | 雑記
そろそろiPod nano(第4世代)のバッテリーがヘタり始めてきたというのが1つ、それと現行のnanoでは動画は見られないというのが1つ、それとどうしてもプレイしたいゲームがあったという事もあり、遂にiPod Touch(第4世代)を購入してしまいました。

何が一番変わったかと言うと、モバイルルータ(Wimax)を使う時間が劇的に増えたという事でしょうか。
Wimaxのモバイルルータとコレを組み合わせる事で、音声通話の出来ない「iPhone 4S」モドキとして使えるのが、最大の誤算。Safariを立ち上げて移動中、待ち時間にWebブラウズする時間が一気に増えました。

今遊んでいるゲームは次のとおりです。

  1. ダライアスバースト セカンドプロローグ
  2. ミクフリック
  3. ソウルキャリバー
  4. rRootage