読者です 読者をやめる 読者になる 読者になる

まめ畑

ゆるゆると書いていきます

セキュリティ&プログラミングキャンプキャラバンに行ってきた【後半】

イベント Tech

後半の内容です。
後半はセキュリティのお話。
前半はセキュリティ&プログラミングキャンプキャラバンに行ってきた - まめ畑
後半最初は、セキュリティ&プログラミングキャンプの説明と、その様子をビデオで紹介でした。
自分は、既に応募出来る年齢を超えているのですが、若いうちからこんな熱いイベントに参加出来るって凄い機会だなぁと思った。
出会いって本当に大切ですね。
今年もあるそうなので、参加資格出来る方は是非!

情報セキュリティ基礎(正しい情報セキュリティを学ぶ)(園田 道夫さん)

  • 個人情報漏洩事件発生(銀行)
    • ラップトップがいつの間にか消えたらしい
    • セキュリティ対策を聞いてみた
    • 凄く固いです
    • 認証が何十にもかかっていた
  • 最強のノートPC
    • 指紋認証
    • パスワードを覚えなくていいので便利
    • でも、指紋はノーパソに付いている
    • 「生体認証」破って入国
  • 生体認証は安全?
    • 指紋 → テープ・接着剤
    • 顔 → マスク・顔写真
    • 静脈
    • 光彩 → 同じ反射の模型
    • サイン → タイミングや筆跡の模倣訓練
  • 生体認証の弱点
    • 鍵となる情報は広義のハッシュ = オリジナル情報のダイジェスト版
    • 鍵を盗まれたときの交換など
    • 認証精度不足
  • Windowsパスワードの問題点
    • 14文字以下は脆弱な暗号化
    • 下位互換のため
    • LAN Manager
    • XPは標準だとこれ(Vistaは違う)

これは、XPでも無効に出来るはずだけどProfessionalだけっだった気がする。15文字以上にすればいいんだけど。

  • いつものWebサイトを汚染する
    • 2008年前半から大流行中 = SQLインジェクション
    • パッチを当てとく
    • ブラウザでも対策が進んできている
  • パスワードは短いのはだめ
  • 定期的にパスワードは変更しよう
  • 鍵の管理が重要
  • HDDの暗号化
    • HDDを外しても中身を見られないようにする
    • 暗号化の仕組み = データ+暗号化
    • EFS(低レベルだとHDDに鍵が保存されている)
    • 鍵を外部で保存するモードにしないとだめ
    • チップで暗号化を行うやつがういいよね
  • HDDの鍵はどこにある?
    • 普通は読めないHDDの領域の中
    • 上書き?
    • 同型のディスクで同設定
    • 領域特定で無力化
  • ノートPCのセキュリティ対策
    • ログオンしにくくする
    • USBキーによるログイン制限
    • 中身を直接覗かれなくする

セキュリティ応用(文字コードとセキュリティ)(はせがわ ようすけさん)

  • やる夫でわかる脆弱性
  • 脆弱性の様な仕様もあるんだ
  • でも、公表をとめられる・・・
  • みつけたらどうすんの?
  • 脆弱性と仕様のボーダーライン上にあり、文字コードに関連する事例
  • 多対一の変換が引起す問題
    • Unicodeには2種類の「\」がある
    • パス区切り(バックスラッシュ)
    • 円マーク
    • Unicodeから他の文字コードへの変換では多対一で行われる
  • Unicodeで入力された文字→検査→文字コードの変換→処理
    • 検査をすり抜ける
    • パストラバーサル発生
    • インデックス対象外のファイルも登録されたり
    • メールの添付ファイルが上書きされたり
    • Windowsが暗黙のうちにUnicodeS-JISに変換する
    • Windowsの仕様ですとの返答がMSから
    • 円記号以外にも多数の文字がこの対象
    • Windowsの仕様なのでアプリ作成側で正しく対策しないといけない
    • Unicodeのまま扱い、文字コードを変換しない
    • 変化後に検査をする
  • Unicodeを利用した拡張子の偽装
    • Unicodeは「双方向機能」を持つ
    • 文字列の一部分だけを右から左に表示出来る
    • RLOやPDF
    • (RLO)ABCD(PDF) → DCBA
    • Unicode文字の挿入
    • hoge.txt.exe → hoge.exe.txt ←反転するけど実行ファイルとして認識される
  • みつけたらどうする?
    • 脆弱性の定義を確認(ベンダーが規定している場合もある)
    • 連絡先を探す
    • 専用の連絡先だと問題が伝わらない事もある
    • 一般の連絡先だと問題点が伝わらない場合も
    • 連絡先を調べなくていい
    • 脆弱性を握りつぶられることが少ない
    • 公開や周知の手間が減る
    • 他いろいろ
    • 期待してはいけないこと
    • 確実な修正
    • 違法な手法で発見したときの保護
    • 匿名での通報
    • 他いろいろ
  • 仕様ですって言われたら・・・
    • 脆弱性でないと明確なら公開もあり
    • 原理を知らしめる事で広く注意喚起につながるなら公開
    • 脆弱性で無いことが明確でも、IPAである程度対応してくれる
  • ベンダに仕様変更を強く促す
  • 仕様変更の要望のフィードバックを提出
  • 正規のルートを通じたほうが改善の見込みが高い
  • コミュニティを通して改善を望む声を集める
  • ケースバイケースで判断する必要がある
  • 重要なのは、影響範囲を考えつつ、「どうすれば安全になるのか」を考える
  • 正しい知識を身につけ、正しい道に技術を生かそう

感想

今回のキャラバンでは、ソフトウェアとセキュリティの両方のお話を聞く事が出来て凄く勉強になった。
ソフトを作る上でも、サーバを管理する側でも安心してユーザが利用出来る状態でサービスを提供するためにセキュリティはやっぱり重要で、それを意識して作っていく事の重要性を改めて強く感じました。
こういう機会は本当に重要で刺激になります。