げんたろう's備忘録

セキュリティに関して思ったことをまとめます。

江戸前セキュリティ(2017/08)

しのぎさんによるShinobotの解説


第一章

Powershellを使ってみる

パイプでオブジェクトが渡せるらしい。

f:id:gntrua:20170826141758p:plain
一体何だこれは・・・。

Powershellで絵が描けるらしい。

http://www.shino.club/


で、画像を投げるとpowershellのコマンドが帰ってきて、それを実行すると画像が書けるらしい。
f:id:gntrua:20170826144536p:plain

powershellで音を鳴らしてみる

え?beepで単調な音が鳴ったと思っていたら・・・

f:id:gntrua:20170826143402p:plain

ピアノが弾けるらしい・・・
ピアノの会が始まる


カエルの歌を引いた。
めっちゃ面白い

WMIオブジェクトが簡単に参照できる

WMIとは、
windows management instrumentationのことで、なんかいろんな情報が入ってるらしい?

例では、BIOSの情報なども取得できるらしい。
例えばVMでやってたりすると、VMwareとかになっていると、サンドボックスだな~とわかるらしい。

第二章

Q.なぜ悪用されるのか?
A.便利だから。
A. .NETのライブラリが利用できる
A.C#のコードがコンパイルせずに実行できる
A.ネイティブコードも実行できる
A.しかもファイルレスで!

powershellとかでできないネイティブコードとして実行させれば、良い。

Shinobotとは

ウイルス対策ソフトとの闘いの中でいろいろ新たなものを作っている・・・

  • Shinobot Suite
  • Shino Encoder

等々

ShinoBot.ps1を使ってみる

f:id:gntrua:20170826153139p:plain
ブラウザからスクリーンショットも撮れるし、ejectもできる・・・

青羽さんによる『自力で取りたいCISSP』

鮭のきり身さん

CISSPについて

  • 日本には約1800人しかいない
  • CBK8ドメインというものがあってそれらの知識が必要とされる

どういう試験?

  • Webで予約
  • 受験料600ドル
  • 東京・大阪一か所ずつ(東京なら帝国ホテルタワー!)
  • 試験時間6時間
  • CBT方式
  • 言語は日本語でもOK
  • 合格ラインは70%以上
  • 結果はその場で紙でもらう
  • 再試験ポリシーは3回/年
  • 認定に必要な要件・700/1000、2ドメイン以上で5年以上の業務経験、資格保持者による推薦
  • セミナーを受ける(50万円)→受験→認定

CISSPの具体的な勉強方法

  • 判断問題(テキスト基準)と知識問題(テキスト以外からも補填)それぞれある。
  • 教材:テキスト・CISSP Study apps・One note(自分でまとめる)・暗記シート/暗記ペン
  • 全体理解→理解の深化→記憶・想起力強化
  • テキスト読み込み&まとめのサイクルを永遠に回す(9段ぐらい回されたそう)
  • いろいろセミナーもある(メルマガとかで情報収集しよう)
  • 2018年の4月に試験内容が変更になる

もっちーさんによる経済産業賞を取った理由

  • つよい。
  • お話が面白くてメモを取り忘れた。
  • サイバーレンジを作った経験が役立ったらしい
  • セキュリティ技術者は中間層が足りないのでは?
  • セキュリティの初歩を倫理と一緒に全員に教えていくべき

C1 ブラウザの脆弱性とそのインパクト

スライド資料については
https://speakerdeck.com/nishimunea/burauzafalsecui-ruo-xing-tosofalseinpakuto
にてアップロードされています。
記述することのほとんど全てはスライド上にあります。
また、内容については僕がスライドを読んで思ったこと、考えたことを書いています。なので、お二人の思いや伝えたい内容を十全に伝えられていない可能性もあります。
真にお二人の話された内容を知りたい方は上記の資料を読まれることをおすすめします。

講師のお二人の簡単なプロフィール

Masato Kinugawaさん
ドイツのCure53という企業に所属されている。
ご飯を食っていけるぐらい脆弱性報奨金で稼いでた(現在進行形かもしれない)

西村 宗晃さん
株式会社リクルートテクノロジーズに所属されている。
朝電車でコミット履歴とか仕様書とかを読んで日夜脆弱性を探しているらしい・・・。

講義

講義は、お二人の経験に基づく脆弱性探しのポイントをお話しされる形です。

ブラウザのモジュール

ブラウザがいろんな機能を持っていることは、多くの人が知っている事実ですが、それらは多くのモジュールによって構成されています。
まずはブラウザはどのようなモジュールで構成されているかを知るところから始まりました。

ブラウザには、Html,XML,SVG...等々のパーサやJS,VBS,asm.js等々のスクリプトエンジン、ネットワークプロトコルなどなどなどなど・・・・
物凄く沢山あるらしいです。
そりゃあ脆弱性の1つや2つや100つぐらいありますよね。

プロが教える脆弱性発見の狙い目

  • 新しい機能

そうか!新しい機能か!確かに新しい機能は洗練されてない!

  • 古い機能

確かに!古い機能はセキュリティ意識なく記述されたものもあるのかもしれない!

あれ?全部じゃない?

とかいう冗談は置いておいて、
新しい機能については、やはり洗練されていない可能性があります。
また、古い機能についても長い間注目されて調査され尽くしている機能ならばいいですが、結局マイナーな機能として使われることが少なかった機能や標準化されていなくて仕様が不明確なものなどには脆弱性発見のチャンスがあるらしいです。

  • 概念のまとまりを列挙してその中から探す

例えば、HTTPリクエストを送信できるAPIだとか、windowオブジェクトにぶら下がってるものだとかそういう列挙されているものの中から探す。

  • コミット履歴から探す

これがめっちゃ面白そうでした。新しいモノならワンチャンあるんじゃないか、そう思えました!

  • 攻撃のシナリオをイメージする

攻撃のシナリオをイメージして、ブラウザが本当にその攻撃シナリオを防げる仕様になっているかを見ていく。
例:
CSPが正しく機能しなければ...という攻撃シナリオを考えたなら
→CSPの実装が正確かを見てみる

  • 過去に学ぶ

過去に修正された脆弱性情報を見る。大体人間がやる間違いは似たようなものなことが多いのは何となくこれまでの人生経験からも感じられますよね。

実際にコミット履歴を見て、脆弱性を見つけてみる演習

演習としては、以下の修正が題材として挙げられ、その中の脆弱性を見つけるお題でした。

https://github.com/mozilla-mobile/firefox-ios/commit/78be54586c9e027465d8e0da28bb42595d4ebe32
https://github.com/mozilla-mobile/firefox-ios/pull/2249/files

是非皆さんも探してみてください。
(解答等は冒頭に上げた資料の38スライド目あたりにあります。)

でも実際に数あるコミットの中から脆弱性があるものを見つけ出すのって、相当根気とかいろいろ必要ですよね。

KinugawaさんがKinugawaさんに成れた要因

  1. はせがわようすけさんの資料を熟読(http://utf-8.jp/)
  2. XSSの手法の勉強
  3. 手を動かして実際に再現
  4. さらに深堀り

https://l0.cm/encodings/table/
全ての文字コードの動作を一から調べられたとのこと・・・。
すげえ・・・文字コード一体めっちゃあるやん・・・
思ったよりも5倍ぐらい沢山ありました。
後は、about: URLをひたすら解析とかサードパーティライブラリの脆弱性探しなどもやられたそう。

素人が脆弱性を見つけられると思うな!

脆弱性を見つけたい対象のことを深く知っていなければ脆弱性は見つけられない。当然のことですよね。
モジュールの目的・使用用途、入出力、制限事項、そのモジュールを経由することで何かをバイパスできないか等々モジュールについて知る必要があります。

深く知るために
  1. 実際に動かす
  2. 仕様を読む
  3. コードを読む
  4. バイナリを読む

バイナリを読む!!!!!

誰が予想したでしょう、Web脆弱性の講義の中でバイナリを読むことを・・・!

f:id:gntrua:20170822141316p:plain
edge用はC:\Windows\System32\edgehtml.dll
IE11用はC:\Windows\System32\mshtml.dll

例えば、
{<[?]?im{p}ort[ /+\t].*?implementation[ /+\t]*=} を見てみると、importの「p」を別のものに置換するっぽい感じの雰囲気のような何かは感じられます。言われないとわかりませんね。
この部分のバイナリコードはXSSフィルターに関する正規表現が記述されているとのことでした。
(なぜ分かったのか聞き逃した・・・。)

つまり、ここに書かれている正規表現を理解したうえで、何とかバイパスするXSSを考えてみよう、ということです。

そこで、この正規表現を理解するために実際に動かしてみよう、ということで演習がありました。

そもそもXSSフィルターとは?

https://www.slideshare.net/codeblue_jp/xssxss-by-masato-kinugawa
より

「リクエストの値とレスポンスから
危険と判断される条件にマッチすればページを書き換える」

らしいです。

例えばリクエストで送っている内容をそのままWebページに表示していてかつ、その内容がscript実行に繋がる可能性がある場合にページの内容を書き換える
みたいな動作かと思います。

とりあえずXSSされそうだったら、いい感じに書き換えてくれるぐらいの理解しか持てていません。
厳密な条件は中々わからないのかな~

そうした中で

XSSフィルターの反応原因を探る演習

Kinugawaさんが用意された
https://goo.gl/WSEkgq
を使って、どの正規表現が反応してフィルターをかけられてしまっているのかを調査。

今回、

"instagram(インスタグラム)"

"instagram#インスタグラム#"

にフィルタリングされてしまっている。

f:id:gntrua:20170822153923p:plain

上記したバイナリをよーく読むことで

{[\"\'].*?{\)}[ ]*(([^a-z0-9~_:\'\" ])|(in)).+?{\(}.*?{\)}}

の辺りが反応していることが見つけられる。

f:id:gntrua:20170822153643p:plain

実際、上記のようなXSSは実行可能で
Kinugawaさんが用意された
https://goo.gl/Vmkebc
で試せる。

考察

q = "入力"

みたいな部分があったときに

q = "" alert(1)//

を試すんだけど、前半の式とalert()が繋がってしまっているから実行されないという問題の解消のために

q = "" in alert()//

とするんだろうと考えました。

なら例えば

q = "" * alert() //

できるんじゃね?ということですが
上記の場合でも上手くいきます(下記画像)
f:id:gntrua:20170822152201p:plain
しかし、やっぱりこれも当然
f:id:gntrua:20170822152313p:plain
XSSフィルターによってフィルタリングされます。
その中そんなに甘くねえ!

APIの仕様書を読んでルールを明確化してみる演習

仕様書の内容を理解していきます。そうすると、どのパラメタはどういう値が許されているかなどを明確化できます。
そして...

仕様通り動くかを調べるだけで脆弱性が見つかる

世の中甘いかよ・・・(深い知識が必要です)

対象のおかしな動作を探す

おかしな動作はすなわちバグであっても、時には悪用可能かもしれないこともあるとのこと。

おかしな動作 × 何か = 脆弱性
になる・・・可能性もある。

CSPバイパスXSSチャレンジの演習

おかしな動作からヒントを得、CSPをバイパスしてXSSをします。

CSPとは

Content Security Policyのこと。
WebサーバがHTTPヘッダのContent-Security-Policyにポリシーを設定します。
例えば、

Content-Security-Policy: default-src 'self'

とすると、全てのコンテンツを自身のドメインから取得するよう設定できますし、

Content-Security-Policy: default-src 'none'

と設定すれば、いかなるドメインからのコンテンツの読み込みも許可しません。
また、

Content-Security-Policy: script-src 'nonce-hogehogehogehogehoge'

と設定されていると、

<script nonce="hogehogehogehogehoge">alert()</script>

と正しいnonceが設定されているscriptタグのスクリプトのみが実行されます。

演習

https://vulnerabledoma.in/camp2017/csp

上記もURLパラメタに入力した文字が表示されるようになっています。
これを使ってCSPバイパスXSSにチャレンジします。

解答については、冒頭のスライドの85スライド目にありますので、参照してください。

仕様変更につながることも

こうした脆弱性の発見によって、仕様そのものも変わることもあるそう。

悪用のシナリオを考える

めっちゃ悪そう。
でも、やっぱり実際に示さないと人には理解して貰えない・・・。

演習

https://github.com/nishimunea/securitycamp2017
Firefox拡張には、脆弱性があってそれを最大限悪用するとどれだけのことが出来るのか?という演習でした。

解答については、冒頭のスライドの94スライド目にありますので、参照してください。

結論から言うと、
ページ内の全コンテンツを外部に送信可能
らしいです。
やばい・・・。
西村さんはgmailでデモされていましたが、他人とのメールが外部に送られたら困りますよね・・・。

結局

脆弱性探しは十人十色
らしい。結局!!!
まあ、そりゃそうですよね。
~プロが教える脆弱性探しの完全攻略~
とかいう本があったら誰も脆弱性生まないですよね。

Sakerity Camp 2017全国大会のインシデントレスポンスをした話

算数が出来ない人だけ見てください!

まず、冒頭にて私の過ちによってご迷惑をお掛けした関係各所の皆様にお詫び申し上げます。
そしてネタにさせてください。

セキュリティキャンプ2017 全国大会(8/14 ~ 8/18)開催期間中は、例え成人していようとしてしまいと禁酒・禁煙生活を余儀なくされていました。
(中学生も小学生もいるからね!)


その鬱憤を晴らすべく、Sakerity Camp(名称は個人に因る)に行きました。

セキュリティキャンプ参加者80名の中から厳正な審査によって選ばれた12名が参加し、
やれ1024bit CPUだの、カーネルエクスプロイトだの、Cでパケット作った話だの、コアな内容が飛び交ってました。
また、各参加者が受講した講義の情報共有等も出来、非常に有意義かつ面白い会だったと思います。

そう、これだけで終わっていれば・・・。

こういう会を行う上で最も気にしなければならないことは会計だと思います。
卓ごとの会計のため、私は都合4人分の会計を行いました。

[2017/08/18 19:00頃]
f:id:gntrua:20170820170842p:plain:w300
僕「4200お願いします~」

[2017/08/19 10:00頃]
いや、さすがにチェーンであの値段冷静になってみるとおかしいよな・・・。
f:id:gntrua:20170820171159j:plain

???
12,547 / 4 = 3,137

あれ・・・昨日絶対4千円もらった・・・

インシデント発生

早急に関係各所への連絡

今回は同じ卓に居たメンバーの詳細な連絡先を記憶していなかったため、Twitterアカウントの捜索。
1人は確実に分かっていたので、その人にも聞きながら関係する全員の連絡先を入手

ごめんなさいをする

大変申し訳ありませんでした、こういう事情で昨日間違えましたという旨をお伝えしました。

どう返済するか

問題は、ここからどうするかでした。
皆さんの居住地はバラバラなため、オフラインで会うことは困難・・・かといって住所や口座等を聞くのも・・・。
僕の間違いによってそんな個人情報明かさせるわけにはいかない・・・。

f:id:gntrua:20170820171934p:plain
アマゾンギフトカード

アマゾンギフトカードは基本的に、ギフト券を買って、アクティベートされた番号を渡せば相手に送付出来ます。
そこで、全員に伺いアマゾンギフトカードで以て返済とさせていただくことに。

コンビニでは、細かい単位のものを購入することが出来ないため、E mail形式で購入し、TwitterのDMで全員に送付。

f:id:gntrua:20170820172246p:plain

無事、受領していただけました。

同じ卓だった3人の方々、本当に申し訳ありませんでした。

また、このブログを見られてる方は算数ができるフレンズだと思うので、僕のような間違いは犯さないとは思いますが、もし起こしてしまった時の対応の一手法としてご紹介できればと思い、投稿しました。

また、僕自身もこのような間違いを二度と起さないよう生きていきたいと思います。