江戸前セキュリティ勉強会(2014/10) #edomaesec

随時更新していきます。全ての更新は完了しました(最終Fix版です)。
---
1:セキュリティ技術者になるには(Asuka Nakamuraさん)

セキュリティ人材が不足
盛り上がってはいるが、「なり方の定石」が無い
既知の方のキャリアパス→独自に勉強してなった!
何を学び、行動すれば良い?

高校生時代に興味を持った
・ほぼ知識0からスタートしている
・大学1年の頃から明確にセキュリティ関係の仕事を目指していた
・今はセキュリティ人材育成基盤がある状況である
→今からセキュリティを始める人/もっと関わりたい人には最適な話ができる?

(注意!!)
セキュリティ技術者になる事が「ゴール」ではない!!

今回の話は個人(講演者)の体験談が中心なので、あくまで一例と捉えて頂ければ

どんな知識を学べば良いの?
IT技術の基礎知識→セキュリティ関係の基礎知識→当該(※)分野の技術知識→セキュリティ技術・知識→先端的知識…という流れ

(※)例えばS/WとかN/Wとか…

基礎的な技術・知識を習得する
初心者向けの教材や資格が増えているので、まずはそれを活用すると良いのでは(資格で言えばITバスポート・基本情報技術者とか…)

セキュリティの基礎知識・情報を学ぶ
情報セキュリティスペシャリストやCISSPなどの資格、情報セキュリティ白書や各種学校・研修を用いるのがベター
更にネットでの情報収集(一次/二次情報源)も良い

(余談1)人の学び方、モチベーションについて
学び方→インプット中心/アウトプット中心
動機→内発的(興味・関心)/外発的(CTFで優勝したい、賞金が欲しいなど)
⇒人によって何が良いかは異なるので、自分のやり方に合わせる方が良いかと

特定分野の技術・知識を学ぶ
疑問点
・必要な技術知識体系とは?
・知識取得の方法、教材は?
・手法は?

どうする?
・最近はまとめサイトが増えた
・やはり上級者(先輩とか先生)に聞くのが早い
・勉強会に行くとか…

地域体系の例(ソフトウェア開発)
・アセンブラの知識
・コンパイラの知識
・実行ファイルの知識
・リンカ・ローダの知識
・OS、CPU、メモリの知識
・プログラミング能力、開発経験
・IDA/デバッガの使い方　など

書籍例
・はじめて読む486
・たのしいバイナリの歩き方
・リバースエンジニアリング～コード再創造の美学～　など

勉強方法
・デバッガ自作
・ゲームの(省略
・CTF　など

特定分野のセキュリティ技術・知識の習得
問題点
・知っている人が限られている
・なかなか分権がない
・習得も難しくなる

どうする?
・尖った人材育成の場に行く
・・尖った人が開催する勉強会に参加
・同、発表資料の閲覧
・専門教育(SANS、Black Hatなど)の受講
・英語で情報収集
・CTFのWriteupを検索
・技術論文(博士論文)の閲覧　など

この辺りまで来ると、上級者向けの書籍やWeb(英語中心)を読み進めるのがベター

先端的知識の領域へ
・論文/カンファレンス
・海外の掲示板/ブログ
・第一線で活躍している先達のTwitter/FaceBookをチェック

特に海外の技術者については、来日された際に話しかけてみるとか、逆にこちらから行ってみるとか…
自らも最先端(尖った)人になる事!!


キャリアの作り方
学生時代
・専門の教育機関(情報セキュリティ大学院大学とか)
・大学の情報セキュリティ系研究室
・情報セキュリティ人材育成コース
・各種支援制度の活用(未踏プロジェクト、サイボウズ・ラボユースとか)
・インターンシップへの参加(MSKK、JPCERT/CCD、JNSAなど)
・セキュリティ系のアルバイト(少ないし人づてが中心だけどあるにはある)

選択肢のお話
・内的キャリア→なぜ/何のために働くの?、その仕事をしたいのか?(個人的で主観的な評価)
・外的キャリア→具体的な職務・職位・技術・実績など

その人によってこれは変わってくるので、自分で良く考えてみる必要がある


(学生向け)どうやって就職する?
・セキュリティ業種以外から
・セキュリティベンダーから
・セキュリティサービス/コンサルから
・IT企業のセキュリティ部門から
・独法/警察から
・高いセキュリティが求められる業界(例えば金融系)から
→ルートは色々あるので、視野は狭くしない事!!

場合によっては起業するのもアリだけど、やはりある程度何処かでキャリアを積んでからがベター?

自宅セキュリティ技術者(趣味と実績を兼ねる)
・バグハンター(最近はバグハント制度を用意している処も増えた)
・クラウドソーシング(個人事業者として)?

個人的な心がけ
・迷ったら難しい方を選択する
・できるできないではなく、やるかやらないか
・自分のやりたい事を公言する
・口だけ、行動だけにならないように


---
2:調整中(と言う名のCTF for Beginnersのお話)(Satoshi Mimuraさん)
CTF for Beginnersとは?
→CTF初心者向けの勉強会

(ここで過去開催分の資料を例示)

CTF4bをやってて思うこと
・やってみたら、実はそんなに難しくないよー
・好きな事を時間の許す限りやってみませんか?

(以後「しょしんしゃ」の実例(Not「初心者」))

・「技術で楽しむ」ことが重要かと

ポインタとして
・自宅の通信内容が気になる
・プログラムはどうして動くの?

CTF4bでやりたいこと
・CTFの人材を作ること?→それだけではない
・セキュリティ人材育成?→そこまでは行かない

・IT技術に対して「気づき」や「疑問」を持ってもらえる人を増やしたい

CTF4bでやっていること
・x86のマシン語の流れ
・逆アセンブルの方法
・Wiresharkでの通信の解析
・XSSってどういうもの?
・SQL Injectionってどういうの?
・簡易CTFによる実習

・「ておくれ」とか「あの人怖い」
→その人が何でぶっ飛んでるかを観察してみるといいかも
・そんな人になりたい
→何でも良いから、とにかく取り組んで大好きになる
・「クソ」っていうなキャンペーン
→「クソ」は簡単に言える
→でもどこがマズイのかどうすれば改善できるのかを調べてみよう
→出来そうなら改善へのアクション、無理ならそれを持って「ダメ」と言ってみる

始めたいけど何をしたら良いか分からない人はCTF4bは如何でしょう


---
3:ヤマ張り上等！あと２週間情報セキュリティスペシャリスト試験(村山さん)

ポケットスタディシリーズ(秀和システム)を書いている方です
なお試験は再来週(10/19)です

今日お話「しない」こと
・お盆明けから蓄積してきた「ネタ繰り」の全成果
・合格者の下限未満だと判断した範囲の知識
・H26春SC試験から抽出した「即効サプリ(R)」
・この試験を合格する事のメリット
・如何に上司や経営層の同意を得るか

内部不正対策→IPAからガイドラインが出ているので、読むと良さげ
信頼の拠り所(root of trust)が崩れる(相手を信じきっちゃう)→発覚を遅らせるための手法である
・あまり疑わなかった箇所
　・ベンダ提供のファームウェア、ぱっと
　・証明書
　　・Rondomizerのエントロピーがしょぼいと
　　　・複数の証明書で、同じ秘密鍵が!
　　　・解析法は?→「ユークリッドの互除法」

今まで信じていたのに…の例
・RSA暗号
・サプライチェーンリスク
・これまでは「定期的にウイルススキャンを行っていた」と書かれていれば疑わなかったが、そこを疑わせる出題も出るか?
→「マルチベンダ化」ただし無料のモノばかり入れていたらランサムウェアを取り込むリスク有り
・2048bitの証明書でも、ガラケー向け1024bit証明書でも、通ればOK　とか

「プライバシー、パーソナルデータ」と絡めた「午前2」予想問題
ex)k-匿名性を満たす事の目的とは?
→正しくは「属性を保護することで、検索時のk人未満への絞込みを不可能とする」

まとめ、今秋のねらい目は…
・内部不正対策、髭右津代の中心は「人的な管理策(所謂ISO27001系側の話、技術的対策を書いたらアウト!!)」
・信頼の拠り所(root of trust)が崩れる話
・午前2対策:k-匿名性、本年5月改定の脆弱性報告制度
・組込系/制御系(今が旬な話!なのに出題は手薄)

SC試験について
計算上の平均的な合格者像
・応募10～11回目で合格
・受験6～7回目で合格

午前2試験について
・40分、25問なので1問96秒程度
・高度試験の前提知識を問う試験
・60点以上で合格だけど、実は甘くない(ギリギリだと午後は相当辛いと考えて良い)→目安は21問正解/25問中!!

「こそあど言葉」には注意!!
→出題者は「分かっている」ので、その辺りが非常曖昧な書き方になっているケースがままある

「出題」身構えていない?
・受験者は「AはBだからCである」と知識を持つだけでなく、理路整然と語れるか?
・そこで「B」を隠した本文を用意して「Aは、Cである」を用意しそれを問う
・様々な「Bだから」候補のうち、答えて欲しい「Bだから」に沿ってもらうヒントは、文中に与える
・別解が出ると面倒だから「D、E…だから」を排除する、枝払い用のヒントも与える
→ここまでヒントを与えても、書けない人の方が多い

紙(問題用紙)に書かれた事が、試験では「正義」(勿論知識や経験は重要だけど)
→できる人は答えを出来る限り考え、本文を読んで枝払いをしていき、最終的な解答を得る

最新の「情報セキュリティ白書」は試験対策として一読の価値有り(今からでも遅くないので、受ける人は読もう)


---
なおお菓子はTwitter(@fkoryu)側で報告いたしました。
https://twitter.com/fkoryu/status/518281865082310657
https://twitter.com/fkoryu/status/518282132104306688
https://twitter.com/fkoryu/status/518282371490009088

(matcha139)まっちゃ139勉強会#26

第26回 まっちゃ139勉強会

久々にセキュリティ…に限った話じゃなくて、ブログの投稿そのものが久々まような気が…(汗
-----
（Session1-1 「共通番号制度（旧：マイナンバー制）施行に合わせて、IT会社は何をすべきか」（岡村先生） 前半戦）
[番号法とは?]
・正式には「行政手続における特定の個人を識別するための番号の利用等に関する法律」
・以前は「マイナンバー法」と呼ばれていたモノ→現在は「社会保障・税番号法」
・今年の5/24に成立、5/31公布→3年以内に全面施行予定だけど、五月雨式に部分施行される

どういうモノ?
・社会番号・税番号制度を行うための法律
・国民1人^2にユニークな番号を割り当てる(住民票を有する外国人含む)
・法人(少なくとも登記されていれば)にもユニークな番号が割り当てられる


[番号制度]
・個人に悉皆性、唯一無二性→分かりやすく言うと全員にユニークな番号が付く
・「見える」番号が付く→最新の氏名、住所、性別、生年月日に紐付く番号が付く
→これが住民基本台帳番号とも紐付く
・この番号が「複数の機関」間において管理・相互利用される
・運用するためには、自分が「自分である事」を示す仕組み(本人認証)が必要で、実装される
→顔写真付きのICカードになるとの事(免許証以上の有効期限になるのでは?、との事)


[個人情報の管理]
一元管理ではなく「分散管理」方式で管理される
→何かしらの「共通DB」ができる訳ではない

では、誰が管理しているのか?
→自治体なり何なりの「各行政機関等」が、である

今までもそれぞれがそれぞれで個人情報を保有・管理していた
が、連携している訳ではなかったので、相互連携が難しかった
→その最たる悪い例が「消えた年金」

共通番号ができる事で、相互連携しやすくなるようにするのが目的の1つである
…勿論それは良い事ばかりではない…
「情報漏えい時の被害規模拡大」「成りすまし」など…
→だから「一元管理」にしない、という理由の1つ

そもそも現実的にも一元管理する仕組みを作るのは難しいでしょ?


[概要]
概要はこちらを参照(アンダーラインの箇所が重要なので押さえておくとベター)
http://www.cas.go.jp/jp/houan/130301bangou/gaiyou.pdf

重要なキーワードのうち、「特定個人情報保護評価」については後述

あくまで概要は「案」レベルのモノも含まれているので、将来的にどう実装するのかは分からない部分の含まれているのでご注意を…

利用は次の3点に限定
(1)社会福祉
・年金
・労働
・福祉・医療・その他
(2)税
(3)災害対策


[メリット]
・届出の負担軽減
・公平な給付(不正受給の抑止)
・社会保障に関する自己情報が容易に入手できる
・確定申告の利便性向上
・公平な税負担の実現


[目的と基本理念]
1条(目的)と3条1項(基本理念)がリンクされているので、よく読むと良いかと


[個人情報保護法との関連]
メリットは「光」とすると、当然「陰」の面もある
例えば「ビッグブラザー的」な懸念とか→当然そんなのは予め予測して対応を考えている
・制度上で守る(こちらは個人情報保護法の得則を定める事で対応している)
・技術で守る
…この2点で陰の面に対抗しようとしている

…が、これがまた難しい専門用語が大量に出てくるので、この条文で出てくる○○は何、どうすれば良いの?、というのが想定される
例えば「特定個人情報」とは?
→正解は「個人番号＋個人情報」の事


[個人情報と特定個人情報]
一言で言うと…
・個人情報→従来の「個人情報保護」に関する法規に定められている個人情報
・特定個人情報→個人情報に個人番号を付加したモノ

同様に…
・個人情報ファイル→個人情報が記録されているファイル
・特定個人情報ファイル→特定個人情報が記録されているファイル

…という感じ

・個人情報「利用」事務→例えば税務署とか(行政サイト)
・個人番号「関係」事務→例えば企業(の経理)とか(主に民間サイド)
事務「者」→上記事務を行う事
…正直紛らわしいキーワードが多いので、要注意!!


[個人番号の生成、指定、通知、変更]
どういうプロセスで付けられる?
(1)自治体が機構(LASDECの事)に住民票コードを指定し、番号生成を依頼
(2)機構が番号を生成し、自治体へ提示
(3)自治体が個人へ「通知カード」で通知

変更も場合も同様で…
(1)本人が自治体へ請求(無い場合もある)
(2)自治体が機構に住民票コードを指定し、番号再生成を依頼
(3)機構が番号を再生成し、自治体へ提示
(4)自治体が個人へ通知する
(例えば情報漏えいが起きた場合等は(2)からスタートする場合もある)


[利用範囲]
9条で定められている
ポジティブリスト形式

(QA)
・個人事業主の場合、法人番号は付くの?→付かない(個人番号で代用)
・出向の場合どうなるの?→給与がどう支払われるのかによって変わる(2つ以上が給与元の場合、それぞれ付けられるというイメージ)


-----
（Session1-2 「共通番号制度（旧：マイナンバー制）施行に合わせて、IT会社は何をすべきか」（岡村先生） 後半戦）
[安全管理措置義務(要はセキュリティ対策の事)]
・再委託の制限、再委託先の監督
→これは10、11、12条で定義されている

委託は「情報漏えい」が発生しやすいポイントと認識
この辺は個人情報保護法と同様(個人番号に対して新たに明示されたという認識でOK)

ならどうすれば良いのか?
・まずは信頼できる委託先を選定する処からスタート
・次いでシッカリとした「委託に関する契約」を締結
・契約の内容が守られているか、監査・調査が行えるようにし、実施する
→レベルは扱う内容次第
・当然回らなければ、その部分は見直しする
・再委託する場合は、委託元がOKしないとダメなようにする


[本人確認の措置]
16条で明示

個人番号カードはあくまで希望者のみ配布される
全員に通知されるのは「紙の通知書(通知カード)」→なりすまれるのでは?
→この場合は顔写真入りの公的証明書を併せて提示する方向に

マイポータルの場合は紙じゃNGなんでカードじゃないと無理
→この場合スマホはどうする?(この辺は方法がまだ定められていない)


[個人番号カード]
住民基本台帳カード(ICカード)が基→これに個人番号が追加される
住所が含まれている→転勤した場合は14日以内に申請、再交付
氏名の変更(結婚して苗字が変わったなど)も同様

このICカードの空き容量の利用目的については、条例で定めた用途で利用しても良いとの事

住民基本台帳カードは、有効期限が切れ次第フェードアウトとなる


[ICカードへの記録事項]
当然盗難時等の事を想定し、プライバシー性の高い情報は記録されない
(あくまで氏名、性別、住所、生年月日の基本情報と、電子証明書と写真の画像データ→画像データはカードの写真にたいする偽造対策)


[マイポータル]
2017/1以降に提供開始予定
ここには「情報提供記録表示機能」「自己表示機能」「行政系等の手続のワンストップサービス」「プッシュ型サービス(お知らせなど)」が提供される予定

ただし機微な情報を扱う事になるため、15、19、20条で「特定個人情報の提供の制限等」を定めている
→ポイントは第三者に提供する事だけでなく、求める事、集める事、記録する事もNGという事!!(例外事項(例えば家族内でのやり取り等)は別途定めている)
(単純所持もアウトって事???→流石に広すぎ影響大きすぎなので議論中との事…その辺が実は後回しになってるので、今後継続的にウォッチする必要があります)


[情報連携の基本的な流れ]
情報のやりとりは「情報提供ネットワークシステム(総務省配下)(以下NS)」経由で行われる
Aが、Bが持っている情報が欲しい場合
(1)Aが持っている符号AをNSへ渡す
(2)NSは符号Aから符号Bへ変換
(3)符号BをBへ渡す
(4)Bは符号Bを基に個人情報を取得
(5)提供OKならBはAに情報を提供する

NSはこれらのやり取りを記録している(利用状況に応じて課金をする)

意図的に「使い勝手を悪くしている」→串刺し検索しにくくしている
…が、使い勝手優先派、プライバシー優先派両方から叩かれているのが現状(「基本的に正しく、基本的に間違っている」…の意味)


[特定個人情報保護評価の実施の仕組み]
基本的には多段階評価を行っている


[違反したら?]
・報告・立ち入り検査
・指導・助言
・勧告
・命令(通常・緊急)
それでも従わない場合は「2年以下の懲役または50万円以下の罰金」

むしろ報告時に虚偽報告の方が痛い(1年以下の懲役または50万円以下の罰金)

更には色々な罰則が定められている(最も重いのが「番号を利用する職員や事業者などが、正当な理由なく特定個人情報ファイル等を提供した」場合の4年以下の懲役または200万以下の罰金)


[導入に向けたロードマップ]
今は法案が成立したばかりの段階

これから「政省令等の整備」「条例の改正」や「システムの要件定義、構築」などが待っている
番号通知は2015年の秋に待っている


(QA)
・企業が個人番号を扱わない(収集しない)という選択肢は取れる?→取れないと考えてOK(関連する法規が改正され、例えば納税申請の際に記載必須となると、書かない場合は正しく申請していない→法に触れるという具合になるので)
・個人番号カードは「身分証明書」としては使えない?→前述の通り番号を目的外に収集するのはアウトのため、使えないと考えてOK(無論例外事項として定められている範囲(6条)については問題無し)

-----
（Session2 ライトニングトーク）
[Pasta-kさん:キャンプのお話]
・セキュリティキャンプの紹介
・プログラミングキャンプ→昨年から有志で「私立プログラミングキャンプ」やってます
今年はツアー形式で行うとの事です(こちらは社会人OKです)


[黒林檎さん:公衆無線LANのセキュリティに関するお話]
・セキュリティが甘い箇所(例えば未だにWEPとか)に繋ぐと、色々な情報が取れるので、要注意というお話


[村山直紀さん:NWスペシャリスト試験対策のお話]
・午前で初出のキーワードは、早めに午前試験を片付けて、お昼にぐぐると幸せになれるかも…


[愛知県警:人材募集のお話]
・現在セキュリティに関わる職員を募集中との事(詳しくは公式サイトをご覧下さい)

[えのきさん:LibreOfficeなお話]
・LibreOffice使おうというお話
・LibreOffice4.0の特徴のご紹介
・来週の土曜に、新大阪で勉強会やります

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

(Session1:「すべらないMetasploit実演～今日からあなたもMetasploiter！」 NTTセキュアプラットフォーム研究所　川古谷裕平さん)

講師はMetaspliot本の6、11、16章を担当しています。

・Metasploitの紹介(特に本に記されている機能を中心に解説)
本は1～6章が基本編、7～12章が応用編、13章以降が上級編(要:Ruby)という構成になっています。
初心者はまずは1～6章を中心に読んで頂ける事で、Metasploitを一通り使えるようになります。7章以降は、より検査を効率的に行うための技術知識が記されています。
なおMetasploitを改造する場合、Rubyで記述する必要があるため、Rubyによるコーディングを学習して下さいとの事。
付録は特に1(ターゲットマシンの設定)がオススメとの事です。

Metasploitとその周辺ツールの関係(細かい図は書籍第2章に書いているとの事です)
「Metasploit(コアライブラリ、モジュール、I/F、ユーティリティ)」と「Metasploitを利用するツール(kama、Faast-trackなど)」「Metasploitが利用するツール(Nessus、Nmap、各種DBMSなど)」によって構成されています。

ツールは直で繋がる(Nmapなど)ケースと、Pluginやドライバを通じて繋がるケース(Nessus、各種DB)に分けられます。

なおBacktrack起動時には標準でPostgreSQLが起動するようになっています。

ディレクトリ構造
標準では/opt/framework/msf3以下にインストールされている(細かい構造は当メモ上では割愛)。

(用語)Post-Exploit→侵入が成功した後に実行される攻撃(権限昇格など)

もしMetasploitを改造する場合は、これらの構造を理解しておく必要があります(何処に何を入れるか?)。


・Metasploitのデモ
検査は「情報収集」→「Exploit(侵入する)」→「Post-Exploit(権限昇格などの更なる攻撃の実施)」の順で実施されます。

今回は仮想環境(VMware)上に作成した各種仮想サーバ(計4台)に対してアタックをかける形になります。

インテリジェンスギャザリング
NmapやNessusなどの外部ツールを利用して、攻撃対象の状況や弱点などを調査、取得する段階(フットプリンティング)。

Metasploit(msf)上から外部ツール(Nmapなど)を呼び出す→結果をDBに格納する事で、Exploit実施時に検査の一助とする。
Nmapの場合「dbnmap」コマンドで達成できる(オプションはNmapと同じ)。

Nessusの場合、Backtrack5には標準で導入されていないので、自分で導入する必要がある点に注意!!
Nessusによる調査はNessus側のI/F(GUI)を用いる→結果をDBに格納するにはレポートをダウンロード(XML形式)し、ダウンロードしたファイルを「dbimport」コマンドを用います
Nessusの結果をDBに格納すると「vulns」コマンドで脆弱性情報を確認できるようになります。

Exploit→今回はサーバサイド攻撃を行います
手順は「検索(searchコマンド)」→「モジュールの利用(useコマンド)」(→「ヘルプで確認」→「リストで確認」)→「設定(setコマンド)」→「攻撃開始(exploitコマンド)」となります。

オプションのうち、RequiredがYESになっているモノは必須になるので注意!

攻撃が成功すればセッションが確立し、失敗するとエラーが返ります。


Post-Exploit
metapreter→攻撃成功後にペイロードとして利用します
metapreterのコマンドは本の第6章などに記載されているので、そちらも併せて参照の事。

一旦乗っ取ると、(取得した権限次第ですが)アンチウイルスやFWの停止、画面のスナップショット取得、キーロガーの動作など、やりたい放題状況となります。

metasploitの本領発揮は「複数マシンの侵害」にある!(pass-the-Hash攻撃、ピボッティング、トークンの奪取など)(本の第6章に記載されています)


Rubyによるスクリプトを用意する事で、攻撃の自動化も可能。面倒な検査手順もテンプレート化する事で、検査に掛かる負荷を抑える事も可能です。
(この辺りはRubyによるコーディング知識も必要となるため、Rubyのお勉強も併せて実施して下さい。)


-----
(Session2:「できるシェルコード解析～シェルコードを見るだけの簡単なお仕事」 NTTセキュアプラットフォーム研究所　岩村誠さん)

原書に無い付録Cに関するお話となります。

@ITの連載記事(リバースエンジニアリング入門)も併せてどうぞ。

Metasploitには多くのシェルコードが存在している
その多くは機械語
未知のシェルコードに遭遇した時に備える(Metasploitのシェルコードは良い教材です、サイズも小さいし、何より色々なCPU、OSに対するモノが揃っていますので)

題材：Linuxで動くx86シェルコード
覚える事は最低限
・記憶領域は3つ
・機械語命令は10個
・Linuxのシステムコールは3つのみ

記憶領域
レジスタとメモリ……この辺はmasmを知っている人はご存知ですよね(なので割愛)

機械語命令(覚えるのは10個)
データ転送系(4個：MOV,XCHG,PUSH/POP)
演算系(4個：INC/DEC,MUL,XOR)
分岐系(2個：JNS,INT)

Linuxのシステムコール
INT 0x80でシステムコールを呼び出せる(EAXにシステムコールのIDを、EBX,ECX...にシステムコールに対するパラメタをセットして呼び出します)
sys_socketcall(通信ソケット、コネクト等に関するシステムコール)
sys_dup2(デュプリケートに関するシステムコール)
sys_execve(プログラムの起動に関するシステムコール)

実際にMetasploitに収録されているシェルコード(/linx/x86/shell_reverse_tcp)を基に解説
コードを読むのは「気合」でw


-----
(Session3:「Metasploit監訳陣によるパネルディスカッション」)
コーディネーター：殿(本の監訳統括担当です)
パネラー：今回の講師陣(川古谷さん、岩村さん)、辻さん、川島さん、青木さん

2011/7末頃から監訳活動の準備がスタート
当初は監訳者が3名を想定→気が付いたら7名に膨れ上がった

2011年
7月、監訳メンバー集め、原書の確認
11月、役割分担

2012年
1月 監訳開始
3月 監訳完了

(Q1)Metasploitを用いる上で注意する点は?、またMetasploitを使っていて便利な事は?
・アンチウイルスに引っかかるので、導入する環境に要注意(特にお仕事で使う場合、情シスに睨まれないように注意して下さい)
・ダウンロードする時点でも引っかかる場合があります
・お仕事で使う場合は、情シスに事前にネゴ取りしましょう
・アンチウイルスに引っかかって情シスにアラートが飛ぶ導入先のフォルダ名に「管理してます」を入れて対応した(ヲ
・完璧なツールではないので、その辺は信頼し過ぎるのはダメですよ
・自動化ツールは便利ですが、ありったけの攻撃を力いっぱい送り、サーバ側のメモリ不足で本来動くはずのExploitが動かなかったという事もあるので注意して下さい。

(Q2)エロイって本当ですか?w
・(回答者名は秘しますが)エロイですw

(Q3)クライアントタイプ(標的型メール攻撃)の作成例とかも紹介して頂けると有難いです
・モジュールの中にWeb経由での攻撃用モジュールが含まれているので、それを利用すれば良い
・ソーシャルエンジニアリングキットがあるので、それを用いれば良い(標的型メールのメール部分は自分で作成した方が良い)
・添付ファイルはアンチウイルスで引っかかる可能性があるので、リンクの方が良いかと(更に短縮URLを併用するとか)
・最新のExploitコードがMetasploitに収録されている事があるので、防御する側もウォッチしておくと良いです

(Q4)学生です、本を購入する予定ではいますが、現在資金が無いため未購入です。購入した時に楽しめるように参加させて頂きたいです
・研究室で買ってもらえるなら、買ってもらうとか、共同で購入するとか
・欲しい本は自分で書こう(ヲ by 殿

(Q5)1週間で、どのくらいの時間をセキュリティの研究・学習に当てていらっしゃいますか?、また皆様にとって「セキュリティ」とは何ですか?
・全部(プライベートの時間を除く)!!、好きな事なので気にならない
・波がある(殆どやらない時もあるし、延々とやり続ける事もある)
・あまり意識はしていない(生活と切り離して考えていない)
・気が付けば起きている時間は(セキュリティの事を)考えているかも
・最近仕事の内容が変わって、仕事であまりタッチできなくなった & 家族の関係でプライベートでも減ってるけど、空いている時間を当てていたりします
・同じく波があります、セキュリティ以外のテーマでも、攻撃者の視点で考える場合が多いです、トータルで見ると週で2日くらい

・セキュリティが何かって普段あまり意識していないが、パズル的に考えている(攻撃者の視点⇔防衛者の視点で相互に考える)
・特殊な感じ、何かしらに付帯するキーワード（○○のセキュリティ）、幅広い技術、知識が必要になるし、攻撃者の意図・視点といった、人に掛かる部分もある、「終わらないもの」
・個人的には「大嫌い」、考えなくて済むならその方が良い、セキュリティ畑で集まるのは避けた方が良い(幅広い分野での付き合いが必要ではないか?)
・単体では成立しない、総合的な技術・知識が要求される。相手がいて「いたちごっこ」にならざるを得ないため、どれだけ先に進められるものなのか?
・技術的な好奇心を満たすための分野
・単体では成立しない、「舞台」みたいなモノ(役者は様々な技術、要素)

(Q6)MSFconsoleでdbがうまく動きませんでした(backtrack32bit、DBは動いているとの事です、ステータスも取れますが、調査結果をDBに書き込めない)
・パスワードやユーザ名はちゃんと設定しました?
・接続すらできないなら、dbconnectを確認する必要がある
・手動でDBに接続し書き込めるか確認しましょう
・dbドライバが対応するDBMSに対応するように設定されていない

(Q7)本の監訳で一番きつかった事
・監訳期間中に出張が多かったため、色々な人にお願いせざるを得なかった事
・コマンドが想定したとおりに動かなかった事(原書に書いてあったコマンドが無いなんて事もあった)、ソースレベルで確認した結果、脚注でフォローしたケースも多かった
・コマンドが動かない事が多数、Rubyを知らなかったため、Rubyを改めて勉強した事、日本語対応していないケースが多く、それを直した事
・書いた後ですが、細かい誤植が多数出てきた事(今が一番辛いです)
・スケジュールがタイトだった事、Rubyを大急ぎで学習した事(コーディング規約に適しているかという事で気を使いました)
・動かした時の結果マチマチ、Wikiからのコピペがそのまま残っておりしかも動かなかった事、原書のリビジョンが明示されていなかった事

(Q8)「監訳」と「翻訳」の違いって?
・翻訳とは、日本語以外の言葉を日本語に変換する事(翻訳する人は、その内容の専門家でなくても良い)
・監訳とは、翻訳した結果を、その内容の専門家がチェックし修正する事

(Q9)学習・解析等で心が折れそうなポイントって?
・例外を起こして分岐する命令で、事前に例外判定をセットしているようなケース、これは解析が大変(既存のデバッグツールで追うのが難しいから)
・マルウェアの解析時に、難読化されたコードを複合する際に独自の中間コードに落とす & その中間コードでないと動かないインタプリタがセットされたケース

(Q10)Metasploitにはモジュールが沢山ありますが、入れるルールってありますか?
・正式なルールはよく知らないけど、「面白いのがあったら送ってくれ」と書いてあるので、開発者側が判断するのでは?
・(補足)13章に書き方のルールがあるので、それを読んで下さい。
・正直滅茶苦茶な位、統一感が取れていない(寄せ集め感が強い)

OWASP Japan 2nd Local Chapter Meeting

(はせがわ“Short talk of XSS – 短いXSSの話”)
某サイトのXSSの話(会場では伏せられてないが)
alertを使っていない、なぜ?→入力が21文字に限られていたから
XSSで任意のコード動かすには何文字必要?
まともなモノなら22文字あれば→21文字以下にしてみました。
>

→実際には22文字あれば成立できるかな?
単純なJavaScriptだけなら?
→一番短いのは6文字「$(URL)」(但しJQuery使用時に限る)

-----
(徳丸 KDDI新GWの「かんたんログイン」なりすまし問題を振り返る)
敢えてガラケー、攻撃者視点での話です。
かんたんログインの話はどうせ皆さん知ってると思うので割愛(分からない人はググって下さい)。

書籍に載っているような標準的な実装に対してアタックしてみよう。
（キャリアGWのIPアドレスとAgent情報をチェックして入れる/弾くを決める）

DNS Rebinding攻撃でアタックしてみる→当然成功(same origin policyは破られてしまう)

リクエストヘッダの書き換え
(EZブラウザはJavaScriptは動かないがPCSVは実行可能なので)
発売時点で、2010年に発表された手口(X_UO_SUBUNO)は封じられていた…が、X.UO.SUBUNOは攻撃が成立してしまった
多分実装依存だとは思うが、ヘッダが上書きされていた
PCSVの仕様で同期モードでのみ成立、ブラウザのURL欄に攻撃コード(JavaScript)を挿入する形で実施→能動型の攻撃なので、誰でも実施できてしまう

これは脆弱性?
私見だけど脆弱性とは言えない
リクエストヘッダが化けるのはCGI or PHPの問題(仕様)

対策は?
→基本的にいたちごっこなので、使わない事が一番の対策
→ケータイIDも使うのを止めましょう

-----
(赤嶺/クリス モバイルアプリケーションセキュリティ101)
今度はスマホの話。
昨年のスマートデバイスの出荷は、全世界で10億台。2012年度はその倍になるのではないかとの予測。

セキュリティの課題
・デバイスの盗難、紛失リスクが高い
・容易にroot化、脱獄が可能
・プラットフォーム、デバイス毎に機能が異なる
・パッチ、アップデートが困難
・スクリーンが狭い
・キー入力が面倒　など

OWASPモバイルセキュリティプロジェクトの話

1.機密データの識別と保護→暗号化されていないデータはデバイス上ではなく、サーバに置く。デバイス上に置かざるを得ない場合は暗号化する。
2.パスワードクレデンシャルの安全な管理→パスワードの代わりに、デバイス上に安全に保存できるトークンを用いる、ログに記録されていないか確認する、SNSはセキュアチャネルではなく、機密情報は置かない
(iOSにおけるPINコード、KeyChainのクラックのデモを実施)
3.送信時における機密データの保護→通信は暗号化を必須(強制)、その暗号化方式も安全な(信頼性の高い)方式を用いる
4.適切なユーザ認証、認可・セッション管理の実装(iOSアプリにおけるクライアント認証バイパスのデモ)
5.バックエンドAPI(サービス)とプラットフォーム(サーバ)の継続的堅牢化→当然サーバ側も堅牢である必要がある
6.3rd Partyサービス/アプリとのセキュアなデータ連携→使うライブラリ、APIは安心して利用できるモノかを確認する必要がある
7.ユーザデータの収集と利用に対する承諾の収集、保存の注意→個人情報絡みでもあるが、必要でない情報を集めようとするモノは要注意
8.有料リソースに対する権限のないアクセスを防止する対策の実装(Androidアプリにおける有料リソースに対する権限のないアクセスのデモ)
9.モバイルアプリのセキュアなディストリビューション/プロビジョニング
10.コードのランタイムインタプリテーションのエラー確認

-----
(上野/野渡 「OWASPの歩き方」)
サイトには、Webアプリに関する各種資料(ガイドラインとか、チュートリアルとか)が沢山転がっている

有名なのはOWASP Top 10 for (Year)→Webアプリにおける脆弱性のトップ10

ZAP Proxy→昔Parosと呼んでいたモノ(日本語化されています)
Webアブリ脆弱性スキャナ、Paros時代よりレスポンスが良くなったっぽい?

WebScarab→Proxy型のテストツール(日本語版は無いです)

ESAPI→Enterprise Security API

ASVS→セキュリティ評価のための検査標準、コードレビュー方式の要件(日本語版あります)

AntiSamy→HTML/CSSへの出力を安全に行うためのAPI、ポリシーファイルの変更で要件を変更できます

Development Guid→開発、構築、運用まで含めたガイドライン、特に運用部分まであるのは少し嬉しい限り、最新版は英語版のみです

Code Review Guide→コードレビューのガイドライン、代表的な脆弱性に対するサンプルとか対策のベストプラクティスが掲載されています

Testing Guide→Webサイト、アプリ含めたテストのガイドライン、全349Pの大作です、脆弱性別、機能別のテスト方法が載っています(必要なところからつまみ読みするのを推奨)

SAMM→ソフトウェアセキュリティ保障成熟度モデル

Contracting→セキュア・ソフトウェア開発契約付属書

現状
日本語版がないプロジェクトもいくつか、停滞しているのもいくつか
求むボランティア

(本職の方)ようやく語れるようになったので……

去年から暫くブクブクと潜水状態だったんですが、ようやく語れるようになったので、ご報告とか。

1つはこれのお手伝いをしていたという事。
「添付ファイルの開封率は1割」、6万人対象の標的型攻撃訓練 - ITPro
まぁお手伝いと言うか、何故か「作業責任者」とか言う役割だったりしますが(ヲ

詳しい事は「大人の事情(※1)」というヤツなので、例えば何処に対して実施したとか、どの位だったのかなんて事は言えない(ニュース等で公表されている分は除く)んですけれどね。

もう1つは、前のに関係しますが、もともとこの手のサービスはかなり前から本職のサービスメニューに載せていた(※2)んですが、それだと人手がかかるし面倒という事もあり(※3)「だったら自分達の手でできるようにすれば良いんじゃね?」という事でWebサービス化して、先日(4/27)に無事サービスインしたという事(一応プレスリリースも打っています)。

この絡みもあって、4月より異動となったという訳です(もっとも事業部内での異動なので、それほど変化がある訳じゃないけど)。
---
(※1)いわゆるNDAというヤツです。ちなみにこの手のNDAは何度も結んでいるのでもう慣れましたが、有効期限はありません(うわぁ)。
(※2)一応2006年頃から、まぁ「知る人ぞ知る」というヤツで、あまりマスコミにも取り上げられていませんが(汗)。
(※3)何が面倒って、訓練用のメールの内容を検討しカスタマイズするのが面倒だし時間もかかるんですよ。相手にもよるんですが、気合が入っていると準備段階だけで数ヶ月もかかるという事も……。

OWASP Japan 1st Local Chapter Meeting

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

第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のような根拠付けが必要となる)

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

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

(matcha139)まっちゃ139勉強会#23

第23回まっちゃ139勉強会
今回は大阪電通大の寝屋川キャンパスのJ号館が会場になります。新しい建物ですよ～。

今回は人数が多い(100名程度)という事もあり、アイスブレイクである「自己紹介」がいつもとは少し違うスタイルになっています(中身は非公開なので、来た人だけのお楽しみという事で)。
-----
session1:Androidフォンのセキュリティ(KDDI研究所 竹森敬祐さん)
初っ端からオフレコですm(_ _)m

……感想だけならOKかな?、話自体は面白いけれど、非常に深い話です。色々と考えさせられますね。


Session2:アンチウイルス屋から見たAndroidセキュリティ(Kaspersky 前田さん)
前振りネタ……UFO:Blocked???→URL Forward Objectの略???
URL転送型のマルウェア???

今日のテーマ：「煽」

観測情報
残念ながら増加傾向、但しマルウェア全体(PC等も含む)からするとごく少数ではありますが
2011/10/28現在のシグネチャ数は4,706
2008年を境に急増しています(収益化の期間に突入したかと)
2011年は集計期間が半年でありながら昨年(2010年)の実績を遥かに越えています

プラットフォーム別で見ると、最も多いのはJ2ME(50%以上)ですが、Androidもじわじわ増えています(24%)。

ファミリー数で言うと300以上(亜種入れて、4,706種)
過去最多で出現したのは2010/8期で、314種類
最も多いのはSMS Trojan

スマートフォンはアンチウイルスでどこまで守れるのか?
一般的な各社セキュリティ製品で実装されている機能
・盗難対策
・暗号化
・アンチウイルス・ファイアウォール
・プライバシープロテクション　など
……アンチウイルスは、あくまでセキュリティ対策製品として、一部機能であるという扱いになっている

Android製品→ユーザモードで動くモノが中心
iOSとWindows Phone→API非公開なので、まず無理

アンチウイルスは有効か?
WindowsのアンチウイルスとAndroidのアンチウイルスの違いって?
・セキュリティ特権上で動いているか否か?
→Androidの場合は、どうしてもユーザ権限で動作させざるを得ない状態である
・パターンマッチング以外(振る舞い検知など)以外の検知方法を実装しているか否か?
→Androidの場合、パターンマッチング以外の検知方法は実装していないケースが多い

ではAndroid OSは強いのか?
Android 2.2までは、DEPなどのセキュリティ対策システムが含まれていなかったので、あまり強いとはお世辞にも言えない
2.3以降は一部だけれどそのような機能が実装されている(DEPとか)……が、まだ未実装な機能があるため、その点では弱いという点は認識する必要がある

Androidアンチウイルスの課題
リアルタイム保護?

電池問題

一般ユーザ権限で動作
他ユーザに許可していない限り、インストール済みの他のアプリのデータにアクセスできない
root権限で動作するマルウェアを駆除できない
→rootを奪取する穴を突かれた後、どうするのか?
→もっと凶悪なrootkitが出てきたらどうする???

root(/system)を保護するアイデアとして……
OS側からAPI提供を受ける→本当はkernel callをフックしたい
もしくはdalvik(サンドボックス)を串してくれるようなものとか?
予めroot権限で動くアンチウイルス製品を入れておく


Session3:結構やりたい放題？Androidアプリの実際(はるぷさん)
アプリをインストールするとどこまで行く?
……普通に考えると「端末の中」ですよね

Androidでは「USBデバッグ」という便利で凶悪(?)な機能がある
(補足)
USBデバッグの凶悪さは、@ITの記事が参考になるかと思います。

USBデバッグでできること
1.SDカードの中身が見られる
写真、電話帳のバックアップ、ブラウザでダウンロードしたファイルなど
→漏洩したら大変だけど、全てのアプリでパーミッション無しで見られるので、今回は放置

2.システムのファイルを見られる
インストールしたアプリにフォーカスして見ると、次のいずれか
/data/app-private
→コピー防止オプションを指定している場合が該当、取得にはroot化が必要
/data/app
→コピー防止オプションを指定していない場合が該当、USBデバッグや他のアプリから取得可能
基本的にはAPKファイルはZIP形式のファイルで、中の設定ファイルはテキストベース(xml形式など)なので、解凍するだけで、結構な情報が見えてしまいます
実はiOSのアプリも似たような形式なので、調べようと思えば調べられたりするとか……
ならば、対リバースエンジニアリングとして難読化しよう
「ProGuard」→Eclipseから呼び出す事が可能
でも、それで本当にOKなの???
→ハードコーディングしているデータなどは難読化されていない!!
→難読化されている場所も、あまり難読化されていないのでは???
なので過信は禁物!!

まとめ
・Androidアプリのコードを守るのは難しい(リバースエンジニアリングで見られる事を前提とする必要がある)
・見られたら困る情報は端末上には置かない(サーバと通信するアプリの場合、見られてはいけない処理や情報はサーバ上に置く)
・何かが起きた時に、ユーザが判断できる情報を提供する(自社のHP上で告知など)

(筆者補足)
ちょうど一週間前に行われたまっちゃ445勉強会#18の話と被る部分が多いので、そちらも参考にされると良いかも。


Session4:iOSの審査なんてくそくらえさ！(TWORKS@楽しいアプリ製作の会 さん)
スマートフォン→アプリケーションプラットフォーム
アプリケーション審査の有無
iOS→ある、不自由なプラットフォーム(クローズド)
Android→ありません、自由なプラットフォーム

(補足)
auマーケットのように、審査を行うマーケットプレイスも中にはあります

iOSのアプリケーション審査
1年ほど前から、22のガイドラインが設けられている
今回は「機能」「インターフェース」「法律」に特化してお話します

「機能」
隠し機能の禁止
サンドボックス外のデータの読み書き禁止
実行コードを外部からダウンロードするのも禁止
明記・明示されていない、偽の機能やジョーク機能もアウト　など

「インターフェース」
Appleが定めた基準(ガイドライン、PDFにして100p超)を逸脱する場合はアウト

「法律」
各地の法律を理解し準拠するのは開発者の責務である
誤り、虚偽、誤解を招く説明を含むアプリはダメ
違法なファイル共有を行うアプリはアウト　など

審査の意義
バグがあるアプリや、悪意を持つアプリを事前に排除できる
類似するアプリや無意味なアプリを除外できる
→ユーザが安心できる環境を作るため

適切なアプリの増加→利用者の増加右→市場の拡大・開発者の増加→……

審査のコスト
iOS、Windows Phone→$99/年
ただしWindows Phoneの場合、101本目からは別途審査料が発生する
Android→25$、マーケット使用料は審査無し

(まとめ)
・審査には市場を健全化する効果がある
・健全な環境には、健全にアプリと開発者が流通する
・Apple頑張っている
・オープンプラットフォームにもそれなりの良さはあるけど、やはりそれ相応のリスクがある事も認識する必要がある
・タイトルはまっちゃさんが決めた事でくぁwせdrftgyふじこlp

(matcha139)LT資料公開＞第23回 まっちゃ139勉強会 めざまし勉強会

まだ発表前ですが、資料公開しました。
第23回 まっちゃ139 午前の部 発表資料 - End of ... wiki
このページの末尾から資料(PDF)がダウンロードできます。

また当日であればUSBメモリ経由でもお渡しする事が可能です。

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

第18回まっちゃ445勉強会 - まっちゃ445
今回は横浜にある情報セキュリティ大学院大学が会場です。
-----
Session1:「マルウェア解析王に、俺はなる！」(ラックホールディングス株式会社/サイバーセキュリティ研究所/新井悠さん)
そんなものはない(ヲ
タイトル→標的型マルウェアを高速に解析するために必要なたった一つの事

文書型マルウェアの解析法
1.OfficeやAdobe Readerを準備
2.動的解析ツールを準備
3.文書ファイルを開封
4.動的解析結果をレビュー

課題1:OSやアプリのバージョンに強く依存する
まともに動かない場合もあるし、どの環境に対して脅威なのかを特定するのには非常に時間かかる
バージョン、パッチの適用状況、言語によって動く、動かないは大きく変わる
なので様々な環境をセットしたVMを沢山用意する必要がある(コストに影響)

課題2:そもそも解析に時間がかかる
詳細に解析するばするほど時間がかかるし、中には対解析機能を有している場合は、それを回避する必要がある
でいざ解析を始めても、静的解析にかかる時間(アセンブリコードを読む時間)はとにかく時間がかかる

解析で得られる情報量、時間などのコストはこの逆です
表層解析＜動的解析＜静的解析

表層解析は「あたり」を付ける作業、なのでコードはこの時点では読まない
動的解析は、実際に動かして様子を探る作業、この時点もコードは読まない
解析時間は短くて済むが、発病要件を満たさなければ空振りに終わる可能性も……
静的解析は、いわゆるリバースエンジニアリング作業、ツールを用いて逆アセンブルしてコードを読む作業になる

効率性は……
表層解析＞動的解析＞＞＞(超えられない壁)＞＞＞静的解析

標的型マルウェアを解析する目的
対策は何か?、痕跡はどこにあるか?、通信で感染端末を特定する方法はあるか?
これらを短時間で効率的に実現できればベスト

一般的に、文書型のマルウェアは「スクリプト」「マルウェア本体」「代替文書」の3つのコンポーネントによって構成されている。
まずはトリガであるスクリプトを解析する事で、速やかに解析できるようになる(解析にはツールを用いる)

REMnux→マルウェア解析用Ubuntuイメージ、イメージさえ使えばすぐに使える便利なツール、最近ver2.0にアップデートしました

jsunpack→フリーの難読化JavaScript解析ツール、入力してPDFも受け付ける便利なものです。コマンドライン版で脆弱性の特定ができ、前述のREMnumxにも収録されています

OfficeMalscanner→MS-Office文書専用のツールで、シェルコードの有無をチェックして検体として取り出してくれるツールです

最近は検知回避するために、前述の3つのコンポーネントに対して、検知回避用のXOR、ROL/RORによる符号化がされている場合があります(いわゆる難読化)
xorsearch→これらの難読化に対するブルートフォースを行うツールです(これもREMnuxに収録)、引数として与えられた特定の文字列と一致する複合結果が得られるのであれば、結果を出力します

「Zero Wire Tryouts」という動的解析ツール(VMイメージで提供されている)がある(exeのみ対応)ので、それを活用するのもアリ

(まとめ)
・標的型攻撃には、文書型マルウェアがよく使われる
・マルウェア解析には時間がかかるが、対策・復旧目的の情報をすばやく解析する方法はある
・これらを行うためのツールがフリーで用意されているのでそれを使うと良い

-----
Session2:「モテる男子のためのアンパック」(NTT情報流通プラットフォーム研究所/岩村誠さん)

(その1)コンパイラ出力コードモデルの尤度に基づくアンパック手法
アンパッキングの自動化→書込み後に実行されたメモリ領域を検出することで、オリジナルエントリポイント(アンパッキングの完了ポイント)を検出する

動的に生成されたコードは、実はまだオリジナルのコードではない場合もある→コンパイラが出力したバイナリっぽさを検出する
よく使う命令(mov edi,edi)が出てきて、逆にコンパイラではあまり使わない命令や分岐処理がないコードが、コンパイラが出力したバイナリでは?、と仮定して、それを検出する
(どうやって検出するかは「隠れマルコフモデル」を用いる……詳しい数式などは省略)

CCCで得た検体(230検体)を基に、実証実験を実施→結果、アンパッキング中のコードとアンパック後のコードを完全に識別できた


(その2)マルウェアのエントリポイント検出後のおけるコード領域識別手法
オリジナルのエントリポイントを検出した→じゃあ、どこからどこまでがコード or データなのか?
マルウェアの場合、抽出を難しくしているケースもある→全部調べるだと、当然検出精度が低下する

通常の命令分岐の場合は、相対アドレス指定の分岐命令が使われる、これがコード領域をまたぐことは通常ない→ならばそれを上手く活用できれば特定できるのでは

特定するために、やはりここでも隠れマルコフモデルを活用して、プログラムコードの切れ目を特定する


(その3)IATエントリ格納場所の特定方法
マルウェアがどんなAPIを呼び出しているのかを調べる

パックされていない場合は、PEヘッダのImport Tableを見れば一発だけど、アンパックしたばかりのプログラムの場合は、PEヘッダが消えてしまっている場合がある→プログラムコードからIATの場所を特定する必要がある

オリジナルコードから0xFF、0x15/0x25を探し、オペランド部をIAT格納場所として認識→データ部分にあると誤検知してしまう(単純計算で32KBに1つ程度)
→ランタイムパッカーが意図的にこれらコードを混入させる事は可能か?
→可能、PEヘッダのリロケーションテーブルを参照すれば、逆アセンブルせずともベースアドレス変更が可能、これを活用して錯乱させる事も可能

とは言えパッカー、パックした結果元のコードが動かないのでは本末転倒→パックするのに自身のある箇所とそうでない箇所(あまりいじらない場所)が発生し、その特徴を上手く利用するで、通常の逆アセンブルツールよりも高い精度でIATエントリ格納場所を特定する事が可能


-----
Session3：「モバイルマルウェアやばい。まず広い。」(ラックホールディングス株式会社/サイバーセキュリティ研究所/山城重成さん )

(その1)Androidマルウェアの実例
大きく4分類に分けられます。
・端末情報取得系
・ボット系
・金銭目的系
・Root奪取

Androidマルウェアの特徴は次の3点。
・通常のアプリの裏で悪さをする
・正規のパッケージを改ざんしたものが殆ど
・感染してもアプリケーションの削除で駆除可能(なものもある...Root奪取は除く)

リパッケージによるアプリ改ざん
元のアプリパッケージは、実はZIP書庫、解凍したデータをデコンパイルし、不正コードを埋め込み、リコンパイル～リパッケージしてマーケットプレイスで公開という流れで生成、公開されている

パーミッション
アブリ毎に使える機能を制限するのだが、通常はインストール時に確認画面が表示されます(こんな機能を使うよ、というメッセージが出ます)
……が、普通の人が見ても分かりませんよね


(その2)ボットアプリによる遠隔操作デモ
メール(GMail)経由で不正コードが埋め込まれたパッケージが置かれたサイト(今回はAndroidマーケットではなく、専用に用意されたサーバ)にアクセス、アプリをインストールすると、ボットとして振舞う、というシナリオでデモが実施されました。


(その3)マルウェア解析手法
APKファイルの構造はこんな感じ。
・asset
・AndroidManifesto.xml
・classes.dex
・その他データ

・apktool→APKに内包したファイルをデコード、但し出力されるデータは見にくいかも
・dex2jar(dex→jar変換ツール) + jad(classをソースコードに変換)→結構綺麗なコードが出力されるが、変換精度があまり高くないのが難点(例外処理とかが該当)

とは言え、実際にやると面倒なので、実際に解析ツールを作ってみました(まだ非公開です)

(まとめ)
・Androidアプリの構造はシンプル
・呼び出されるインテント情報を集めれば、挙動解析は容易
・ただし一部のマルウェアについては、部分的に暗号化しているものもある
・NDKでコンパイルされてる部分はIDAで解析
・静的＋動的解析の組み合わせ
-----

(matcha139)まっちゃ139#23のめざまし勉強会 LTで話す事になりました の続き

前回の続き。
とりあえず資料の方は固まりました。

タイトルは「XenServer をさわってみた(Management APIもね)」という感じです。

内容は当日までのお楽しみって事で。

(matcha139)まっちゃ139#23のめざまし勉強会 LTで話す事になりました

第23回まっちゃ139勉強会
午前の部「めざまし勉強会」のLTに立候補したら通ったので、話す事になりました。
正式なタイトルはまだ確定じゃないですが、ネタは「XenServer」に関する話を予定しています。

いやね、今話題の「標的型攻撃」に関する話をしたいんですが、色々あって(※1)ちょっとこのネタはオフレコでも話せない状態という事もあり、泣く泣くパス。
で、少し前まで扱っていたXenServerに関する話(当然セキュリティの話込み)をしようという事になりました。

只今鋭意資料作成中(ヲ

あ、そうそう、今回は「一泊三日」です(マテ
(29日の夜は宿で寝て、早朝新幹線に乗って帰るという具合です。観光しようかとも考えましたが、早めに帰ってゆっくりしたいので。)
---
(※1)本当に話したくても話せない事情があるので……つーか、リアル o... rz 状態になるので、勘弁して下さい。

今回は申し込みそのものが不可……＞まっちゃ445

第17回 まっちゃ445勉強会 - まっちゃ445
もう既に満席ですが、そもそも今回の募集形式だと申し込みそのものが出来ないという。
(何故なら、対象となるサービスのアカウント全て持っていないから。)

尤も、その日は用事がある(※1)ので行けませんが。

そうなんだよねぇ、開発系の勉強会だと何処かのソーシャル系サービスに入っている事がある意味当然というか前提というか、そんな状態なんだよねぇ(ため息)
(ご存知かとは思いますが、色々な理由があり、その手のサービスについては全て敬遠しているので。)
---
(※1)別館寄りのネタですが、8/5～7にかけてボダブレのイベント戦(エースボーダー決定戦)が発生するため。しかもソレ、9/17に開催されるAMショーにおけるステージイベントの出場権を賭けた「オンライン予選」も兼ねており、少しマジメに取り組みたいのですよ。

実は今日はこちらにいたりします

現在の日本のセキュリティ～ブラックハットジャパンその後 東京編～ - IAJapan
実は先にコチラの方に申し込んでいた事もあり、コチラの方に行っています。

内容はボチボチ書ければという感じで。

(Session.1:脅威と技術の意味の変化....日本では今何が起きてるの？～2010年版～)
・ここ1～2年で急激に状況が変化している(2001年頃～→第1ステージ、2005年前後～→第2ステージとすると、2010年前後～は第3ステージと言える)
・徐々に高まる攻撃技術と、それに相対して低下した情報管理体制強化、以前として続く脅威の見えない化
・急激に高まっているサイバー攻撃・防御

・Botnetの次、正規サービスの攻撃基盤利用(いわゆるクラウドサービスを正しいルートで、攻撃に使う)

・情報セキュリティ分野は多種多様な業界分野の複合体、ゆえに言葉の意味が整理されておらず、話が分かりにくい所以)

・APT(情報攻撃)

・エストニアでの事例(DDoS)
・規模としては日本では日常茶飯事レベル
・出口がやや特殊

・中国での事例(DDoS)

・韓国→米国での事例(DDoS＋α)
・マルウェアの拡散方法が特殊
・マルウェアが10数個バラバラに作成され、うまく連携している(1つ1つがサブルーチンである)
・単純なBotnetではなく、ある意味スマートグリッドであった

・DDoSにも色々ある
・プロパガンダ的(主に中国→日本)、安全保障的(韓国→米国、エストニア)……

・米軍での事例(2008)、Agent.BTZがUSBメモリ経由でオープン系に感染→クローズ系にも拡散

・stuxnetの話

・Night Dragonの話
・攻撃のシナリオはある意味レトロ、Stuxnetと比べると稚拙
・メジャー5社で被害が出た事で、話題になった
・でも日本ではあまり話題になっていない

・APT(情報搾取攻撃)に対する話
・今の攻撃のメインストリーム
・既存の防御はほぼ役に立たない
・バックドアを確保、バックドアを通じて必要な情報を搾取またはシステムの破壊を試みる
・実は日本でも2年前からこの攻撃に対する検討を進めていた(現在はIPAで継続して検討している)
・CND(サイバー攻撃防御)とIA(情報管理)の分離


(Session.2:After AD200X)
・AD 200x直後→まっちゃ139、セキュそば、セキュリティもみじ
・2008年頃→キャンプ出身者が増え、全国的に急激に増加

・特徴→セキュリティ技術習得、ギリギリネタはやらない・中継無しなど
・経験則的には、組織の1%程度が参加している
・東京は人が多いので、1%程度でも沢山集まる
・地方は人が少ないので人を集めるのが大変だけど、色々な興味分野の人が集まるため、コミュニティが被る部分が多い

・現地に合わせた勉強会
・スタートアップはまっちゃさんがサポート(あくまでサポートである点に注意)、ある程度回せるようになったら地元の人のみで回す
・アンケートで参加者層を調べ、興味を引くテーマや講師を引っ張ってくる
・一部ではグループディスカッションも実施
・参加者の自己紹介(全員に参加意識を持たせ、話してもらうようにする)とお菓子が重要
・内輪間を出さないように

(Session.3:CTFにチャレンジしよう！)
・世界中で開催されているが、代表的なのはDEFCONとか……
・協議のタイプは大きく分けて2種類、1つ目は実際にNW上の攻撃と防御を行うもので、オフラインで行われる。2つ目はセキュリティ技術を利用した課題を解く方式、主にオンラインでの予選で用いられる
・出題ジャンルはTrivia系、(Forensics含む)解析系、暗号系、(Webアプリ攻撃含む)リモート系など
・参加は、基本的に期限内に申し込むだけ(オンラインものなら)、但し一部に条件付きもあるので注意
・本戦は予選突破が必要なので注意
・勝つためには「基礎的な知識と応用できる力」「力を合わせる組織力」「実戦経験」「出題問題の傾向と対策(大会によっと特徴がある)」「気力と体力(MAXで60時間ぶっ通し)」
・参加するメリットは「賞金」「名誉、ステータス」「知的意欲と問題が解けた時の達成感」「世界中に友人ができる」辺り
・是非気軽に参加して欲しい


(Session.4:リバースエンジニアリングの実際)
・リバースエンジニアリング技術の応用分野例
・S/W脆弱性検査(コード無しでも検査できるが、時間がかかるのと検査人に一定の技術・知識が必要)
・脆弱性脅威分析(脆弱性情報が公開されていないケースもあり、それらの正確な脅威を把握したい時に)
・脆弱性対策の技術研究開発
・マルウェア対策
・マルウェア対策の技術研究開発
・情報漏えい対策
・互換製品開発技術
・検査、調査

・色々なツールが出てきているので、大分楽になった(IDA ProとかWindows Symbolとか……)
・とは言え個人がやなろうとすると資金的なものとかモチベーション的なものとか色々な点で障害になっているのが事実

セキュリティネタ つれづれ

「2ちゃんねる壊滅」？　スレ乱立騒動、弱点を外部から突かれたのが原因か - TIMedia
サーバの設定がアホだったせいで、内部の重要な情報が尿漏れ→グダグタというパターンとの事。そう言えば昨年末セキュリティ系のサイトがクラックされたってのも細かい設定ミスやパッチ適用忘れが原因で突かれたってのもありましたなぁ……。
結局のところ外部公開のサーバを立てて運用するってのは、こういう細かいミスも許されない(物凄く運が良ければ被害は免れるけれど、普通はそうじゃない)って事を改めて認識させられます。

やっぱり出てきた！Androidボット - エフセキュアブログ
ヤマガタさんの処経由、そういう話は実のところ昨年末のまっちゃ445勉強会の懇親会で聞いていた(ヤバいモノが出回っているという内容)んですが……。
今までもスマートフォンに対する攻撃については話が出ていた(と言ってもその当時はSymbian OS搭載のモノが中心だった)んですが、いよいよAndroidの世界にも手を伸ばしてきたという処でしょうか。
特に今年はAndroidに限らずスマートフォンがより身近になっていくものと想定、よりこれらに対する脅威には注意を払わないといけないでしょう。

ひょっとしてサイバー攻撃か　判断に迷ったら…ＤｏＳ攻撃被害、企業の脅威に - 日経新聞
まっちゃさんの処経由、Librahack事件のアレじゃないですが、不正攻撃かなぁ……と思ったら、まずはIPAの相談窓口へ連絡、相談してみましょう。こんな時のIPA、有効活用しないと損ですよ。
また国外からのアタックと思われる場合はJPCERT/CCの窓口という手もあります。