先日開催されたセキュリティ・ミニキャンプin名古屋に参加してきました。 とりあえすそのレポート的な感じでかきかき

セキュリティ・ミニキャンプin名古屋 1日目

今回の内容はWebセキュリティの話が中心のイベントでした。

「セキュリティ・キャンプの紹介」

最初に園田さんのセキュリティ・キャンプについての紹介がありました。 セキュリティ・キャンプとは何なのか、セキュリティ人材が不足している、などのセキュリティ全般についての話などからキャンプの開催までの話などがありました。

「あなたに解決してもらいたい Webセキュリティの課題」

次に上野さんからWebセキュリティの基礎についてのセッションがありました。 以下はセッション中にとったメモをぺたぺたした感じの内容です。

一般的なWebアプリケーションのセキュリティ対策はかなり確立した物となっておりセキュアに作るための要件定義、設計、実装、テスト手法などはかなり出揃っているらしい しかしそれでも、セキュリティインシデントが止らない、理由としては開発者や開発会社がセキュリティ対策を知らないか導入しようと思ってないという事があるらしい。導入しようと思っていない理由としては値段を安くするためにセキュリティをまっさきに削ったりするらしい また、新しいWeb技術のセキュリティ対策は出揃ってないものもあるらしい、新しいOSだとか新しいWebの仕様だとか

最近のセキュリティインシデント

#### 遠隔操作ウイルス事件 ゆうちゃんのあれ 片山被告が他人のPCにウイルスを感染させ遠隔操作を行い脅迫行為などを行なった。 その時に警察は遠隔操作されたPCの持ち主をIPアドレスのみを頼りに誤認逮捕を行った、またその誤認逮捕された被害者の一部が犯行を認めちゃったりした。

東京都19歳男子大学生はCSRFによって脆弱性のあるWebページに犯行予告を書き込んでしまった。その結果、警察に誤認逮捕されてしまいその結果逮捕を認めてしまったりした。

CSRFとは?
特定の処理を行うページに正規ユーザーに処理を強制的に実行させる攻撃 ユーザーがその罠を踏むまでまつ 被害者の持つ権限を利用した被害が発生するため、罠にかかったユーザーが出来る事は出来てしまう。

また今回の事件でIPアドレスは直接は犯人を示さない事を示してしまい警察は従来行なってきたIPアドレスを証拠とした操作だけでは犯人を特定と出来なくなってしまった。

狙われているのは個人情報ではない

標的型攻撃
特定の個人や組織がターケットで攻撃の課程でフィッシング、ネットワーク攻撃、Web攻撃、ゼロデイなどが使われる
攻撃者の主な目的としては社内のイントラネットなど

組織内のユーザーを罠にはめてマルウェアを実行させる。メールなどを使用して攻撃コードを含んだファイルを開かせたり水飲み場型攻撃を行なったりする。

水飲み場型攻撃
ターゲットが普段アクセスしているWebページを調べてそのWebページに攻撃を仕掛けるなどをしてアクセスするターゲットを攻撃する

水飲み場型攻撃を行うにはなんらかの方法でWebページを改竄しなければならない。 Webページの改竄手法として、SQLインジェクション、フレームワークなどの脆弱性、ftpなどのアップロードツールなどが狙われる 水飲み場揚型攻撃はWebページの信用度を目的に行われる。そして標的のよくアクセスするWebページの中からセキュリティの弱いページが狙われる、つまり、標的がアクセスするなら有名ページだとかそんな事はとくに関係はない。

パスワードは死んでいる

パスワード
最も普及している認証の仕組みで、特別な機器を必要とせずに導入出来る、1960年代からコンピュータの認証の仕組みとして導入されている

パスワードの役割りはパスワードさえ正しければそのユーザの正当性を認識出来る事にある

認証
コンピュータにおける本人確認で本人しか知りえない情報で確認などを行なうもの、パスワードやディジタル署名、身体認証、ICカード、ワンタイムパスワードなどがその例である

Webページのパスワードに対する攻撃

総当たり攻撃、辞書攻撃などが行なわれる。 パスワードに対する攻撃にはオンライン攻撃やオフライン攻撃などが存在する。 オンライン攻撃はWebページのフォームに対して行う攻撃で必ずネット経由で行なわれる オフライン攻撃はなんらかの方法で入手した暗号化されたパスワードなどを解析する攻撃

オフライン攻撃の対策として パスワードは通常は暗号化が行なわれて保存されている ハッシュ化などを行いその認証を行なう また、そおのハッシュ化にソルトなどを混入しさらに解読の何度などをあげている

オンライン攻撃の対策として 一定時間にパスワードの試行を一定回数失敗した場合にそのアカウントを一定時間ロックを行なうアカウントロック 不正認証の監視を行ないアクセスの禁止などを行なっている

ユーザー側の対策 推測が困難なパスワードにする パスワードを使い回さない 二段階認証などを使用する

パスワードは用意に導入出来る? はずだったか、それを安全に運用する事は困難に

パスワードに変る新しい技通が必要

新しいプロトコルや新しいWebの技術、新しいクライアント、新しいデバイスなどではまだまだ対策が出来ている感じではない

最近はWebの技術とOSの境目があいまいになっていて、従来はWebの技術ではアクセス出来なかったような所にまでアクセス出きてしまう。

セキュリティの問題解決のために セキュリティ人材の育成、セキュリティ技術の研究・開発、セキュリティの啓発活動、セキュリティ製品・人材・サービスを買ってもらう

Webセキュリティを学ぶためのポイント 徳丸本、HTTPの教科書、めんどうくさいWebセキュリティなど

「脆弱性指摘する人される人」

次は、はせがわようすけさんのセッションでした

そもそも脆弱性ってなに?

攻撃された時に安全が損なわれる部分 保護されるべきリソースが見られるようになっていたりする部分

脆弱性の判断は流動的

仕様です!!っていう解答も珍しくない 仕様でも危険なら改善するべき

脆弱性を見つけた。さぁどうする?

#### どこに報告する? ベンダ、サイト運営者 公的機関(IPA)

連絡先を探す

確実に連絡できる先を探す 報告様式が用意されている事もマレにある セキュリティ情報の取り扱いが正しくできること

脆弱性をベンダに報告

個人だと相手に連絡されない 一般の連絡先だと問題が伝わらない 専用の連絡先を用意しているのはごくわずか 連絡先が不明な事も多い

ベンダーと信頼関係があるとやり取りが少なくてすむ

IPAを通じで報告

ソフトウェアの脆弱性とWebサイトの脆弱性の報告を受け付けている #### IPAがやってくれること 受けとった脆弱性の内容を確認 - その届出形式の判断など

開発元・運営元への連絡 影響を受ける他のソフトとの調整 修正完了後の情報公開

IPAに届けるメリット

連絡先を調べる必要がない 連絡時に相手に対して気を使う必要がない 脆弱性を握りつぶされる事が少ない 公開や周知の手間が減る

期待してはいけないこと

脆弱性の再現の確認 報告した内容の確実な修正 サイトの砲撃に対する免責 違法な手法で発見したときの保護 匿名での通報


ぞれぞれメリットデメリットがある 届出ないより届け出る方が圧倒的によい

ケーススタディ

#### 報告する側の立場で

脆弱性と仕様のボーダーライン上の問題

ぜじゃく性の定義から外れる、おそらく仕様と言われる。 具体的にはユニコードの問題ユニコードの制御文字をファイル文字に使用する事で拡張子の表示を入れ替える事が出来る 問題:ファイル名にこういうのが使えるのはどうなの

脆弱性ではない事は明らか

公開して原理を知らせしめる事で注意喚起などをした方がいいのか

ユーザーによる対策はむつかしい

危険かどうかの判断を困難にする

IPAに届けてみる

脆弱性の範囲から外れるが問題ではあるので、MSに連絡を行ってみてくれるらしい。

公開して注意喚起するよりベンダーに対して注意を行ったほうがよい

脆弱性と仕様の間の問題が多い

WebサイトのXSSをたまたま発見

それを攻撃されてると判断されISPに連絡され、止められてしまった Webサイトの運営者、報告者、ISPの連絡手段の違い

見つけたときにIPAを通せばよかったんじゃないの?

そんな事はなくて、サービス運営者が先に連絡を行っていた。 IPAを通したところでたいして変わらなかった

何をもって攻撃と判断するか

攻撃検知システムが反応すれば 攻撃検知システムのログ確認作業にリソースをさかれる 利用者に実害があれば? 判断基準が人によって変わる

原則として、第三者のサイトは軽い気持ちで検査するべきではない? 許可をえたうえで、自身で責任がもてる範囲で

良心にもとずく自主的な検査で ISPを止められた 学校を停学になった 相手から訴訟直前までいった

報告される立場で

Namazu Project

###### 2001-11-25 高木先生からのメール なんと脆弱性の報告メールが公開メールだった!!

セキュリティ用の報告用の窓口を作った

翌日に問題があり再リリース

3日後にさらにバッファオーバーフロー さらにIIS上でのXSSの脆弱性

そして一年後JPCERT/CCから突然メールがきた タブから始まる文字列だとエスケープされない脆弱性があった

Githubで公開のpull-reqで脆弱性の修正がありオープン状態

これまでの教訓

セキュリティ関連の専用の窓口を用意する 脆弱性を修正したらテストスクリプトを書く 古いコードを放置しない リリースを急ぎすぎない

なぜIPAのような調整機関が必要?

公表日一致の原則

正しい脆弱性の報告窓口?

いきなりブログで公開? 礼儀正しく挨拶が先?(こんにちは!) メーリングリストに投稿? 担当者に直接メール? 会社に電話? 手紙を送る? はてなブックマークで指摘? -> IPAなどの調整機関を使うといい感じ

オープンな脆弱性の指摘は犯罪

不正アクセス禁止法 威力業務妨害罪 電子計算機損害等営業妨害罪 国内のSOCでは多数の攻撃を把握

XSSは国内 ほとんど悪戯

運営者は少しでも違法性があるなら訴えたいっぽい

まとめ

もし脆弱性を発見したら 正しい窓口に報告する 積極的に脆弱性を探すのは運営者に良い印象を与えないのでやめたほうがいい 脆弱性を指摘される側にもいろいろと事情がある 脆弱性を指摘して世界をよくしていける

「JavaScript Security基本」

続いてはせがわようすけさんのセッションでした

HTML5時代のWebアプリ

次々とリリースされるブラウザ ブラウザーのリリース速度が速い どのブラウザにどの機能が実装されているのかわからない

html5の新機能

ルチメディアのサポート 書構造を表す要素 フォームの拡張 JavaScriptAPI

HTML5時代のブラウザ

高速化、高機能化

実行コードのブラウザ上へのシフト 攻撃もクライアントサイドへ XSSやCSRFの増加

Webの技術、楽しい

HTML5を使った攻撃 攻撃側こそ新しWebの技術を活用できる クロスブラウザ対応不要 誰に遠慮する事なく使いたい技術を使える 多少不安定な技術でもかまわない

攻撃もクライアントサイドにシフト

jsでやる処理の増加 XSSのリスクも増加、多くの点からXSSはバッファオーバーフローに匹敵するらしい?

XSS

html5の新要素など jsのコード量が増えた AjaxデータによるXSS

ブラウザ内で発生する脆弱性の増加

受動的攻撃 XSS,CSRF

サーバー側の対策は確立している

近年のブラウザに対する攻撃としては同一オリジンポリシーの突破が主な攻撃対象

同一オリジンポリシー?

オリジンを境界としてリソースの読み書きを保護する仕組み Origin = スキーム+ホスト+ポート file:,data:,javascript:は実装依存 オリジンにもとずく制約 XMLHttpRequest 同一オリジンでない場合は明示的な許可なしにレスポンスを読めない WebStorage オリジン単位で保存、オリジンを超えてデータのやりとりを出来ない WebWorkers

オリジン以外にもとずく制約 cookie デフォルトではhttp,httpsで共有される domain,pathなどが指定できる HTTP Authentication ディレクトリ単位で制限 document.domain オリジンを超えでデータ転送が可能

そもそもXSSって?

対象 動的にHTMLを生成するWebアプリケーション 問題 攻撃者が用意したスクリプトが実行される 対策 HTMLを生成する時点でエスケープする

反射型XSS ユーザーの送信内容をそのまま表示

やってはいけないXSS対策 入力時のサニタイズ->最初からデータをいじると仕様変更で問題が生じてくる

HTML5 with XSS

これまで間違ったXSS対策->険そうな要素を検出 これまではこれでいけていても、あたらな要素の増加により対応が出来ていない

HTML出力時にエスケープすれば防げる

DOM based XSS

JavaScriptが引き起こすXSS サーバー上で生成するときには問題はない JavaScriptでレンダリングするときに動いてしまう JavaScriptのコード量の増加に伴って増えている JavaSciptによってHTMLをレンダリングするさいに発生するXSS ブラウザのフィルタを通過しやすい サーバー側のlogから被害を追えない 対策としてはサーバー側でやってる事と同じ。 HTML生成時にエスケープを行う URL生成時はHTTP(S):のみにする textNodeを使うとjavascrptが完全なテキストとしてやってくれる

リダイレクトは同一のホストに制限 URLの確認は実はめんどうくさい

XSS with Ajax Data

IEのContent-Typeは無視 HTMLではないものがHTMLに昇格してXSS

Windowsはファイルタイプに基づいてコンテンツを処理する

文章化されてない複雑なメカニズム ファイルタイプの決定因子 Content-Type X-Content-Type-Option

Ajaxでやりとりするデータを直接ブラウザ上で開いたときにXSS jsonならエスケープできなくはないけど、text/plainとかtext/csvはエスケープできない

サーバー側で返す時に X-Content-Type-Option: nosniffを付け加えるといい感じにブラウザにお知らせできる

対策としては従来と大きく変わらない 生成時にエスケープ http(s)スキームのみ許可 X-Content-Type-Option: nosniffはとりあえず付けておけ

攻撃可能は箇所は増える

参考資料 IPAの安全なウェブサイトの作り方 JPCERT/CC HTML5 調査報告書 HTML5時代「新しい〜〜〜〜」

一日目終了

この後にちょちょっと協賛企業さんのパナソニックさんやサイボウズさんなどの会社紹介のセッションがあったりしました そんでもってその後に懇親会です!!

懇親会

一日目終了後に栄に行き、講師の方やスタッフ、IPAの方、他の参加者などと一緒に色々とお話ししました。 二日目に参加する人や同じネットワーク系が好きな人同い歳くらいの人などが見付けれたりして楽しかったです

セキュリティ・ミニキャンプin名古屋 2日目

二日目です!! 二日目は朝から初まって一日目を参加した人の中で二日目の応募資格があって応募した人が参加出来るっぽい感じのです!

二日目の内容としては、全員にCampSNSという脆弱性がいっぱいあるWebサービスのソースコードを配りそれを実行し皆でそれを攻撃して脆弱性を探してみよー! みたいな感じでした 私はとりあえず、簡単なXSSは最初に見付けられたのですが、それ以降の脆弱性がぜんぜん分からずに色々なフォーム的なので頑張ってみたりだとか色々していたのですが結局、午前中に見付けられたのはそれだけでした。 お昼はお弁当がありました!! ひっさびさに唐揚げをもぐもぐしてテンションがあがったりました。

午後からはもうWebの技術とかぜんっぜん分っかんないのでWebページから頑張る事を諦めまして、配られたソースコードを読む作業に従事していました。 JavaScriptは書けない読めない感じでしたが、まぁ、やる気さえあれば読めるんだなぁ、、って事を実感しました。 その中でセッションを生成している部分が起動時に0から初まり新たなセッション毎に1ずつ増えた値をSHA1するって所を見付けたので、とりあえず、SHA1で生成したセッションを1ずつ試行してみるコードをちょうど何故かノートPCに入っていたこれまた殆ど書けないPythonでかきかきして時間が終了しました。

その後、みんなでどんな脆弱性があったかなどを話てわいわいがやがやしたあとに、 Masato Kinugawaさんのハンズオンがありました、 とりあえず、Masato Kinugawaさんすげー! すげー!

そんなこんなでセキュリティ・キャンプ in 名古屋が終了しました。

その後に二日目で同じ机で作業していた方が名古屋大学の高倉先生の研究室の方だったので、ちょっとお願いして研究室を見学させて頂きました!! 研究室がめちゃくちゃ広くて、めちゃくちゃ綺麗でした!! CISCOのルータとかRTX1200とかが落ちてて羨しかったです!!!

まぁ、そんなこんなで二日間楽しかったです!!