ブログを再開しました

ブログを再開しました

ブログを再開しました。ぼちぼち更新していきますので、よろしくお願いします。

マネジメントと開発は遠いようで近かった(リスクマネジメントと脅威分析)

昨日のゼミで、ISO/IEC 27005の改訂について、委員の方に紹介いただく場がありました。それを聞いていて、しかもその後の議論の中で思ったんですが、セキュリティマネジメントのリスクアセスメントと脅威分析(分析レベル)の手法って似てるなと。何をいまさら…とお思いでしょうが、そもそもソフトウェア工学にしてもマネジメントとはコミュニティも違う訳で…あとは前の会社の時に15408と27001の間にはギャップがギャップが…と言われ続け、固定観念があったのかもしれません。まあ言い訳な訳です。(いいわけぇもんが…)

で、要求分析における脅威分析では、資産ベースのアプローチをとることが多いです。私が講義で紹介するミスユースケースの分析手順もそうですし、C.Haleyがまとめたセキュリティ要求分析の要素にもばっちり「asset」が登場します。で、この資産ベースのアプローチは、もともとこの27005から来ていると思われます。27005では、分析のアプローチは以下の2つと言われています。

  • 資産ベースのアプローチ
    守るべき資産を洗い出し、資産に対する脅威(リスク源)を識別する
  • イベントベースのアプローチ
    リスクに影響のあるイベントのシナリオを想定し、リスクを見積る

実は、このイベントベースというか攻撃シナリオベースのアプローチが、最近注目されているようです。この紹介があった後に、私が、「イベントベースでは、脅威が十分に洗い出されたという網羅性はどのように保証するのか」という質問をしました。実は、このイベントベースのやり方は日本以外ではわりと使われているようです。なぜかというと、資産ベースはどうしてもボトムアップで資産を洗い出しでいくので、手間がかかる。それに対し、イベントベースは、「このシナリオにフォーカスしてみたい」という場合に使うんだそうで。だから、私の解釈では、イベントベースは網羅性をそもそも解決するものとしていないと。日本人は、資産ベースが好きなんだそうですね。細かい性質に合っているのかな。あとねえ~わたくしも元ベンダーですので、お客さんが、「これって何分の何で起きるの?」とか、「100%リスク対策できてるの?」とか、言うじゃないですか。ちょっとセキュリティかじった人なら、「分母なんかねえんだよ!」「100%なんてあるわけないだとクソが!」ということは理解できるけど、でも…じゃないですか。すいませんクソは言いすぎでした。

ちなみに、脅威分析に関しては、この資産ベースとイベントベース以外に「 事業被害ベース」という方法があります。このシステムではどんな被害を受けるとまずいか、から考える手法です。情報処理推進機構(IPA)の発行する「制御システムのセキュリティリスク分析ガイド第2版」では、資産ベース分析を行った後にこの事業被害ベース分析を行うことになっています。でも実は、事業被害ベース分析の中でも攻撃シナリオを検討することになっています。ですから、どれか一つのアプローチを排他的にする必要もないですよね。まあ要はケースバイケースで使い分けしたり、補完的に使えばいいということでしょうか。

機械学習/深層学習でマルウェア分類することの意味とは

またまたごぶさたしています。ようやっと仕事に余裕が出てきました。

最近、うちの学生が深層学習でマルウェア分類する研究をしています。これはもうそろそろ発表されるので言ってもいいと思うんですけれども、具体的には、マルウェアバイナリを画像変換して、CNN系の学習をかけています。

画像変換!?

おまゆう!?

とおっしゃるでしょうね。ええ、ええ。確かに以前のブログで私は画像化して分類することに、批判ではないんですけれども疑問を投げかけましたとも。でも学生がやることを止められます?止められないではないですか(開き直り)

まあ、別にそのことはいいんです(論点ずらし!?)。今回言いたいのはそのことじゃなく、マルウェア分類そのものについてです。この学生の成果もありがたいことにですが、他の先行研究でも、分類を行って、かなりいい成果を出してます(F1値0.97、Accuracy0.99とか)。でも、そのこの単体では、マルウェアを発見し分類するという実際の活動において、どんな意味があるんですかね?

例えば、この学生の使っているデータセットは2種類。1つは、kaggleで公開されているMicrosoft Malware Classification Challenge (BIG 2015)。こちらは、コンテスト用に提供されているもので、PEヘッダが削除されているため、そのままでは実行できず安全に扱えるのが特徴です。もう一つは、Malimg Datasetと呼ばれるもので、文字通り、マルウェアデータを画像変換したデータセットです。Dropboxでダウンロードできるようになっています。kaggleの方は9種類、Malimgは25種類のマルウェアファミリで構成されています。

…ということはですよ。先ほどの先行研究にしろ高い精度ってのは、必ず9なり25種類のどれかに分類されることが分かっているデータでやっての話であって、現実にはそれ以外のファミリ、ひいては未知のマルウェアもある訳で、もしそんなマルウェアが来た際に9なり25種類のどれかに分類してしまったら、それは正しい結果ではないですよね。では、この分類器を現実のマルウェア解析で使おうとすると、まず、9ないし25種類以外のファミリらしきものはあらかじめ除いておいて、それから分類器にかけるということになりますが…なんでしょうね。それって。
…という議論に先日のゼミでなったので、メモしておいたのでした。

何が言いたいかというと、見た目結果よさそうな研究でも、現実的にそれってどう役に立つの?っていうのが多々あるってのと、特にうちのドクターに行くような学生には、もっとそういう実際的、かつ俯瞰的な観点からマルウェアの研究を行ってほしいところです。

…あくまで、「うちの学生」向きに話してるので、今回は(?)喧嘩売ってないと思いますよー。

攻撃と社会の悩ましい関係

ごぶさたしています。コロナも大変ですが、それ以上に年度末でなかなか更新の時間がとれません。

さて今回は、学生の研究その2です。以前に研究室サイトで公開したものです。

社会的イベントがダークネットワークの攻撃トラフィックに及ぼす影響についての分析

http://lab.iisec.ac.jp/~okubo_lab/docs/darknet_socialevent.pdf (※PDF)

この研究は、サイバー攻撃のトラフィックデータ(量)の遷移と社会的イベントの関連性を発見した上で、社会的イベントの際の攻撃の増減を推測、あるいは、攻撃の量の増減の聴講から社会的イベントを推測することを最終目的としています。皆が「できたらいいな」と思う。かつ、現状でそのような成果はなく非常にチャレンジングだと思います。ですが、状況はごらんの通りongoingの研究です。どの辺がongoingなのかを解説していきたいと思います。

まず、何もコネがない状況(社会人学生でSOCに努めていてかつ自社データが使える、またはNICTと共同研究してる、でない)では、攻撃データを収集するのがまず大変。ですが、ありがたいことに、NICTでは観測したダークネットを2019年から公開してくれています。

サイバー攻撃の観測情報をWebで公開

https://www.nict.go.jp/publication/NICT-News/1205/06.html

今回、このデータを使わせていただきました。で、学生がやりたかったのが、攻撃データの国別の分析。なので、ダークネットの攻撃元を国別に分類して、日毎に傾向を見ています。その結果いろいろ面白いことが分かりました。まず、国別パケット総量では、ロシアアメリカ中国といったところが上位を占めますが、それに混じって、まさかのオランダ2位。なぜでしょうね。

次に、トラフィック量の増加について、いわゆる特定の日にトラフィックが急激に増加(いわゆるスパイク的なやつ)している箇所がいくつかの国で見られます。たとえばロシアでは、5月5日に通常時の2.3倍の増加がみられますが、この日は「ロシア軍がシリア北西部で軍事活動を行っており、 テロ組織と交戦 している」日だそうです。また、中国でスパイクが観測された2月19日は、ファーウェイの諜報疑いで「ファーウェイ創始者が米国に対抗声明を表明した日」、同じく3月16日は、3 月 16 日は中国の政策に対して 米国が批判 を行った日だそうです。

…と、ここまで読んで、「へえーそうなんだ!」と思いました?まあ、ご推察の通りなんですが、このイベントと当該国のトラフィックの関連性が高いことを科学的に示してあげるには、もう少し努力が必要ですね。

まず、合理的疑いをする人は、このイベントが日付に合わせて恣意的に選ばれているのではと考えます。他にもいろいろイベントがある中で、たまたまそのスパイクに合ったものをピックアップしたのではと。ファーウェイ関連に絞ったとしても、それらのポイントとなるイベントをすべてピックアップした上で、それぞれでトラフィック増加が起きているのか?もし起きていないとすると、本当にそれらは関連性が高いのか?これらが統計的ないし論理的に示されないといけません。もう一つは、そのイベントが発生した時に、当該国以外でトラフィックが増加しているのかどうか?他の国は増加していなければ、関連性は高いことの証左の一つになるはずです。

もう一つは、国ごとの相関分析です。トラフィックの増減について、例えばイギリスとフランスの正の相関が高いことについて、「両者が地理的に近いから」としてしまうと、国ごとに分析していることの意義を否定することになってしまいます。確かに、例えば地理的に近くない国どうしが特定のイベントに対して正の相関が高ければ、あるいは常に高ければ、両者に何らかの関係がありそうなことは言えそうですが、そこから先は、イベントとの関連を示せないと難しそうです。

と、いった具合に、まだまだやるべきことは多いです。学生自身も分かっていたと思いますが、そもそもがチャレンジングなテーマなんですよね。だって、イベントも歴史的なのからongoingなのから、経済から政治から山ほどある訳ですよね。たぶん対象を絞りこんだ上で消去法的にいかないと、そもそもが複数の要因でトラフィックが成り立っているので難しいんです。それに、関連性が高いことは示せても、それと因果関係はすぐには示せません。まあそこまではしなくてもいいのかもしれませんけどね。そういった、高いハードルの中で、ここまではがんばって、次の方向性を示せていると思います。またもう少し(?)がんばってほしいところです。

「ワトソン君!同じ指紋だ」fingerprintとattackとprivacyと

ん?エピソードはどこに行ったのかって?あと、ホームズ時代に指紋分析ってあったっけ?まあいいや。今回はタイミング的に、学生の研究の話をさせてください。先日、研究室サイトで公開した↓の件です。

ブラウザフィンガープリンティングとTLS フィンガープリンティングによるユーザトラッキングとその対策の研究(PDF)

フィンガープリントといっても、リアル指紋じゃないです。え、当たり前だって?だって学内でまぎらわしいって言われたんだもん。具体的には、Webとかネットワーク上における指紋ですね。最近、ヨーロッパの方でcookieの使用についての承諾確認がうるさくなっていますよね。GDPRのせいかなー。なので、最近は非cookieによるユーザトラッキングが流行りらしいです。cookieじゃなければユーザによる拒否関係ないからってことでしょうね。でも、そんな同意もなしに勝手にトラッキングするなんてけしからん!と、上の研究は、この背景と動機によるものでした。

でも、特定/トラッキングされたくない!という人達がいれば、特定/トラッキングしたい!と思人達もいる。特定/トラッキングしたい人達の中にも、正当な(と本人たちが主張する)理由をもってる人もいます。例えば、「攻撃者を特定/追跡したい!」という理由。実は、当研究室にもそんな動機で「fingerprintにより攻撃かを特定したい!」という学生もいますし、何より上の研究をしてる学生自身が、昔はその動機で研究してたりして(キリシタン的にいうと、「転んだ」訳です:-)。そんな風に、fingerprint精度を上げたい側と、アンチfingerprinting側が双方研究のシノギを削っていて、どえらいカオスになってます(fingerprintの研究は、日本だとあんまりなくて、明治大学の齋藤孝道先生のところぐらいですね)。これはそのまんま、セキュリティにおける攻撃と防御のarms race(出た!)の縮図だったりします。例えば、browser fingerprinting(BF) toolではCanvas Fingerprintingなんてのが出ていたりします。これは、ユーザがダウンロードしたページで、Javascriptによりグラフィックやアニメーションを描画させます。それにより、ブラウザの種類や端末の性能などを「指紋」として抽出できるツールです。ちなみに上のリンクにアクセスすると、あなたのfingerprintを出してくれます。どれぐらい特定できるかというと…さすがにchromeの同じウィンドウの違うタブでやっても同じ結果になりますが、新しいウィンドウのchromeやedgeでは違うfingerprintが生成されます。でもセッションcookieとは同等のトラッキングはできるかもしれません。一方、特定ができてるかは…これだけではわかりません。

また一方では、アンチfingerprint、つまりfingerprintによる特定やトラッキングを避けるツールも出てたりします。例えばFirefoxは2019年5月以降、fingerprintの採取を抑止する機能をデフォルトで実装していたり、Chromeの拡張機能でもcanvas fingerprintingなどによるfingerprinting対策の拡張機能がいろいろ出ています。先ほどのcanvas fingerprinting対策だと、Canvas Fingerprint Defenderってのがありますね。私これをChromeに入れて使ってますが、canvas fingerprintingしてるサイトを検出してくれます。例えば、これにより、某航空会社サイトはcanvas fingerprintしてることが判明しました。これは検出するだけでなく防止もしてくれてるはずなので、canvas fingerprintはされてないと思いますが、特にサイト閲覧には支障ないようです。

このように、推しとアンチ混在のfingerptint界ですが、この中でこの学生が行った研究は、「トラッキングされないfingerprint対策」の研究です。具体的には以下の3つ。

  1. browser fingerprinting(BF)対策ってあるけど、それってどの程度危険なのか?
  2. BFだけじゃなく、TLS fingerprinting(TF)も組み合わせると、BFだけでは防げないよね?
  3. BF+TF組み合わせに対する対策を考え、実装、評価した

この研究についてコメントする前に、TFについて。TFは、TLSのhandshakeの通信、つまり暗号化前の通信の特徴をとらえて指紋を採取するものです。具体的にはserver helloの中のCipher suite(暗号化できるアルゴリズム一覧)が、ブラウザにより異なる。こういった情報により、クライアントの指紋を採取します。BFと異なるTFの利点は、暗号化された通信でも、TLSのserver helloは暗号化されていないので通信の途中でも指紋が採取できることです。

で、学生の研究ですが、1ではまず、各種BF対策ツールを適用して、BFに対する有効性と、更に2として、BFとTFを組み合わせた場合の有効性(トラッキングされないかどうか)を検証しています。具体的には、組み合わせた場合と単独の場合で、対策ツール適用前後で値が「変化」しているかを見ています。変化していれば、対策ツールが有効だという判断、「変化」していなけば、有効ではない(危険)という判断です。結果、TFを組み合わせると既存のBF対策ツールでは十分ではないので、BF対策+TF対策を組み合わせる手法を提案しています。その提案手法の評価は、対象サイトに10回アクセスしてそのユニーク度を見ています。つまり、ユニークな値が表れた数をカウントしています(詳細はPDFを見てね)。

どうですか、この研究。私はこの研究自体は面白い観点だし、もっと研究されるべきだし、複数のツールで評価し、かつ対策も実装して評価したことは大いに評価すべきと思います。すばらしい。ここで褒めたことを皆さん、覚えておいてくださいね!じゃないと、文句ばっか言ってるように思われるので。

指導する立場として言うと(ちゃんと指導しとけよというお叱りは甘んじて受けます)、この評価方法には問題があります。
その前に、TFとBFの粒度の違いについてちょっとだけ。これは研究会発表の際にも指摘されたことですが、TFが特定できるのは、Cipher suiteなどを使ってるようにブラウザ(の特定のバージョン)までで、BFのようにマシンまで特定できる訳ではない。なんで、BF対策だけでTFが防げないのはある意味当然。でもまあ、この問題は本筋ではないんで、とりあえず脇に置いときます。

プライバシーをはかるには、少なくとも2つの特性に着目する必要があります。一つは識別性(identifiability)で、もう一つは追跡性(tracability)です。識別性とは、ホストあるいは利用者を一意に特定できる、ということ。一方、追跡性は、「誰だか分からないが、特定の誰かの利用を追跡できる」ということです。で、この2つは別々に考えるべきと私は考えます。

情報量エントロピーとは、各事象が持つ情報量の尺度で、「あることが起きにくい」ほど、値が大きくなる。逆に、「特定される確率が高い」とエントロピー値は低くなります。このエントロピーはプライバシーの評価尺度としても結構使われています。(例えば[1]など)

[1] Datta, A., Lu, J., & Tschantz, M. C. (2019). Evaluating Anti-Fingerprinting Privacy Enhancing Technologies. WWW’19, May 13–17, 2019, San Francisco, CA, USA, 2, 351–362.

その計算式は下記の通り。

または、確率変数を用いるとこう。

では、次に識別性のエントロピーについて考えましょう。「誰かまでは分からないが、一意に特定できる」確率を考えます。複数人がアクセスして得られたfingerprintのうち、2つが一緒だったら、特定できる確率は1/2、3つなら1/3になりますよね。ではここで、10人のfingerprintがa,a,a,b,b,c,c,d,e,fだったとします。すると、エントロピーは-((1/3log(1/3)k×3)+(1/2log(1/2)×4)+(log1×3))=1.079となります。

次に、追跡性を考えてみます。とりあえず、識別性はおいておくとすると、同じクライアントが複数回アクセスした時に、特定できる可能性なので、こちらは、同じ値が出る可能性=頻度で考えてみます。10回アクセスして、同じ値が2つ出たと。そうすると、エントロピーは-(1/5log(1/5)×2)=0.280。

でも、本当は複数回で同じ値が出ても、他の人と同じ値になると追跡が難しくなるので、識別性も考慮しないといけません。だから実際には、「複数回アクセスしたら同じ値が出て、しかもそれはユニーク」である確率を求めるんですかね?

てな感じです。なんか、合ってる自信はあんまりないので、ツッコミお待ちしています。

ML4WS EP1.5 サイトクローラー・ストーリー

助「いやーひどかったですね」
Dr.「ひどかったねー。パルパティーンを復活させるなんてねー」
助「その話じゃない!」
Dr.「あ、「時間差ゲロずるい!」って話のほう?」
助「違う!jてか映画のネタバレするな!あんたのブログの話でしょ。内容スカスカっていう」
Dr.「あれはひどかった。時間なかったし。すみませんでした」
助「ということで、今回はEP2ではなく、前回の補足編です」
Dr.「最初に、前回ブログの後半に誤りがありまして、次のように訂正します。
文献[1]では、以下の5つを満たせば、ユーザのリクエストではなくクローラと判断することにしてました。

  1. 既知クローラのIPアドレス
  2. 既知クローラのuser agent
  3. Robots.txtへのリクエスト
  4. HEADメソッドによるリクエスト
  5. 画像リクエストなし&referer値なし

助「なるほど。これなら良性か悪性かの判断はないので、納得ですね」
Dr.「ところが、この4は実は微妙。
昔のお行儀のよいクローラはHEAD使ってたけど、最近のクローラはその辺考えてないかどうか、あまりHEAD使わないんだそうだ。
それと、前回、この文献が新規で採用した特徴量があったでしょ?」
助「ああ、次の2つですね。」

  • セッション中有効なリクエストの数
  • 固有の(繰り返しリクエストされない)ページ数

Dr.「そう。このうち、固有の(繰り返しリクエストされない)ページ数だけど、これは悪性クローラが無駄なアクセスをたくさんするからっていう仮定なんだけど、最近悪性クローラのクローリングがだんだんインテリジェントに効率化されてくることによって、仮定が危うくなっている。それに、サイトの作りによってはユーザがなんどもトップページに戻らされたりするので、ますますあやしい。実際に、この特徴量に反するデータも実験で確認されていて、著者らも課題として挙げている」
助「難しいですねー。また一般的な話として、こういう検知のための特徴を公開すると、攻撃者に裏をっかれるってのもあるでしょ」
Dr.「そうだな。refererなんてその例で、今クローラは何も考えてないからrefererつけてないけど、検知を回避しようと思ったらつけてくるかもしれないね」
助「いたちごっこすね。英語のフレーズだと、こういうのはarms raceでいいのかな?」
Dr.「ではこれで以上です。エピソード、つながったかな?」
助「ところでDr.、その中身は何ですか?」
Dr.レイア「…希望です」

ML4WS EP1: サイトクローラー

Dr.drokubo「助手ブローリン君!」
助手ブローリン「…一体どうしちゃったんですか?」
Dr.「え?」
助「いや、みんなの声を代弁してみました」
Dr.「いやそのあれじゃ、まだ著者自身方向性が定まっていないのじゃから、勘弁してほしいのじゃ」
助「その『…じゃ』は続けるんですか?」
Dr.「いや?」
助「(会話形式にする理由はいくつか考えられる…ボケのツッコミ役がいて楽、短かいコンテンツもだらだらやって長く見せられる、対立する両論併記しとけば炎上を避けられる…
それに今回は内容が薄い、というか内容がないののごまかし…たぶん全部だな)」
Dr.「何か言ったか?」
助「いえ。Dr.、それより今回のお題ですが、『ML4WS』って何ですか?」
Dr.「助手君、キミはエーアイとは何か知っているかね?」
助「ああ、確か解剖しなくてもCTとれば殺人の証拠が見つかるやつ」
Dr.「お前はどこのチームバチスタだ。それはAiで、Autopsy imagingな。てかお前がボケたらそれぞれの役割がボケるだろうが。全部大文字でAIだ!」
助「安室奈美恵 featuring」
Dr.「もうええわ!ありがとうございました!」
助「それで終わったら怒られますよね…。Artificial Intelligenceつまり人工知能ですね。最近も、崩壊したりいろいろバズッってるやつ」
Dr.「そうだ。流行の波はセキュリティ業界にも押しよせ、今やセキュリティもAIなんだ!」
助「といっても、AI=機械学習のコンテキストですけどね」
Dr.「その通り。MLとはMachine Learningつまり機械学習のことじゃ。しかしこの機械学習というやつは厄介な諸刃の剣での、攻撃側にも防御側にも使えるという。そのことが、今回のAI流行の前、2011年にそれを指摘した論文があっての」
助「↓ですか」

[1] K. Rieck, “Computer security and machine learning: Worst enemies or best friends?,” in Proceedings – 1st SysSec Workshop, SysSec 2011, 2011, doi: 10.1109/SysSec.2011.16.

Dr.「最悪の敵か最良の友…か。善悪はそれを用いる心の中にあり…」
助「科学者がよく使う詭弁じゃ!って、サクラ先生!?ひょっとして、それが言いたかっただけ?」

Dr.「(無視して)で、ここからが本題じゃ。ML4WSとは、Machine Learning for Web Securityのこと。つまりさっきのでいうと、ワーストエネミーでなくベストフレンドの方じゃ。もう、だいじょうぶ心配ない…」
助「(無視して)しかし、最近セキュリティ界だと、MLに対する攻撃(adversarial example)とか、ML応用でもマルウェア検知が流行りじゃないですか?」
Dr.「そこはあれだ、そんなみんなやってることをやっても、面白くないじゃろ!」
助「(きっと大人の事情だな…)」

Dr.「マルウェアに比べ、ないない言ってるが、結構あるぞ。ML4WS。学習のターゲットもさまざま。ざっと以下に挙げてみよう。」

  • maliciousなWebサイトの検出
  • maliciousなクローラの検出
  • Web脆弱性の予測
  • 脆弱性テストの学習
  • WAF、フィルタリングの学習
  • Webアプリケーションに対する攻撃の予測

助「ちょっと待ってください。maliciousなクローラって何すか?クローラにmaliciousかそうでないか、なんてあるんですか?ていうか、判断できるんですか?]
Dr.「じゃ、これからいくか。」

[2] Hosseini, N., Fakhar, F., Kiani, B., & Eslami, S. (2019). Enhancing the security of patients’ portals and websites by detecting malicious web crawlers using machine learning techniques. International Journal of Medical Informatics. https://doi.org/10.1016/j.ijmedinf.2019.103976

助「patient?患者?」
Dr.「そうこれ、医療情報学ジャーナルなんだよね。分野違いのせいか、機械学習やクローラについて丁寧に説明しているのが好印象。ただ、内容は医療向けというより、一般にも通用する内容だな…
で、さっきの質問だけど、後でmaliciousなことをするための予備調査として動くのがmaliciousなクローラということらしい。ふるまいとして、クローラとそうでないものを、次の5つの観点で区別しているぞ」

  • 既知クローラのIPアドレス
  • 既知クローラのuser agent
  • Robots.txtへのリクエスト
  • HEADメソッドによるリクエスト
  • 画像リクエストなし&referer値なし

Dr.「上の条件に合致しなければ、クローラというわけだ。それをSVMで学習させているよ」
助「ふーん。でもまあなんかふつーですよね。この論文の新しい点は?」
Dr.「きびしいこと言うな。従来の特徴量に加えて、次の2つを加えたことらしい。それで精度がちょっと上がったらしいぞ」

  • セッション中有効なリクエストの数
  • 固有の(繰り返しリクエストされない)ページ数

助「なるほどー」
Dr.「気持ちこもってないなー。まあクローラ検出はこの論文が引用している通り、先行研究もあるぞ。
じゃ次いこかー。と、言いたいところだけど、それは、CMの後でーす」
助「上戸彩か!え?終わり?」
Dr.「はい。長くなりすぎたんで、この辺で切っときましょ」
助「長くなったのは脱線が多すぎるせいでは…」
Dr.「そういうなサノスよ。

誰かの文章を読んで「何を言いたいのかわからない」という感想を言ってくる人は「文章は何か言いたいことがあるから書くものだ」という思い込みを持っているのだろうね。「この文章の主題はなにか」「作者は何を言いたかったのか」式の試験問題に解答し続けてきた人たちの読み方なのかな。

小田嶋隆氏Twitter

と、小田嶋先生もおっしゃっておる!」
助「(小田嶋先生というか、伊集院光の悪影響だな)」

Dr.「まあ、これで終わるのもあんまりなので、次回予告をば。
次回は、maliciousなWebサイトの検出の話を。これは、↓の論文を読んでおくとよいぞよ」

[3] Saxe, J., Harang, R., Wild, C., & Sanders, H. (2018). A deep learning approach to fast, format-agnostic detection of malicious web content. Proceedings – 2018 IEEE Symposium on Security and Privacy Workshops, SPW 2018, 8–14. https://doi.org/10.1109/SPW.2018.00010

助「S&Pの論文ね。なんか、うっすいうっすいスープを飲まされたあげく、おかわりは来週まで待てとか…はぁー」

ファジィなファジング考

「ファジィ家電」って覚えていますか?たぶん、ファジィ理論に基いたファジイ制御をしてるってことで、洗濯機とか出てましたね。原理はよくわからんけど、なんか機械的にやるんじゃなくて、AI的に、「あいまい」に、なんかいい感じに洗濯してくれるとか。「マイナスイオン」とかと同様、ただの流行ではあったんでしょうな。それとも今は普通になっちゃったからあえて言わないのか。あ、理系出身のくせに「マイナスイオン」を標榜する製品開発に加担してたやつには、「プラスイオン」の天罰が下るであろう!

…閑話休題。

で、最近(でもないか)、セキュリティテストとしてファジングテストがもてはやされてますよね。自動車業界でも、某メーカーが下請けに、ファジングテストの実施を義務付けているとかなんとか。でも、個人的にはそういった風潮は行き過ぎというか、なんかファジング、過大評価されてね?と危惧を感じてしまう訳です。いや、もちろん一定の効果があるのは認めます。が、出荷前検査でそれをパスすればOKというのは、それは違うんじゃないの?ってことです。

当然、ただの言いがかりではなく、根拠のある話ですので、その根拠について考察していきましょう。

そもそも、ファジングテストとは何か?何をテストして(見つけて)くれるのか?
ファジングとは、データを大量に投入して、機械的にテストをする手法です。もともとセキュリティテストのための手法ではなく、単純にバグを発見するテクニックとして以前から使われていました。基本的にはブラックボックステスト、つまり、データを入力して動かし、その出力を見て正常かどうか判断します。
ということは、出力が「異常」かどうか判断できないと、テストが難しくなります。これ、あとで試験に出るので覚えておいてください(試験とテストがまぎらわしい)。
要は、プログラムが予測してない入力が来た時に、ちゃんとエラー処理してないと、おかしなことになる。それを、予測しないようなデータ(ファズデータ=「てきとー」なデータ?)をとにかくたくさん投入して、人海ならぬデータ海戦術で見つけだす、と。

ここで、ファジング成功の鍵となる大きなポイントは、「どうやって、そのファズデータを大量に生成するの?」です。ちゃんとバグによる異常なふるまいをつつき出してくれるようなデータでないといけない。このようなデータの生成方法としては、「ランダム生成」や、「突然変異」などがあります。「突然変異」の一手法であるビットフリッピング(BF)は、文字(やビット)をちょっと別の文字に置きかえるというもの。
例えば、「ソニー」を「ソニ一」に変えるみたいな。
…すみません。キム兄のネタ分かりにくいですね。もとい
「fuzz」という文字列を一部変えて「fuz_」にするようなものです。この入力を与えて読み取る側はおそらく文字列をパースするんですが、そこで変な文字列が入ってきたときにエラー処理でヘクると、落ちちゃったりする。落ちてくれれば、ファジングテストで見つけることができる、という訳です。

これが、普通のバグ探しならある程度うまくいくと思うんですが、セキュリティの脆弱性をテストする場合、意図的に脆弱性をつく攻撃ができるデータを入力しないと、挙動がおかしくなってくれない。つまりさっきのBFみたいなやり方では、脆弱性をつく攻撃が簡単にはできないのです。もちろん、バッファオーバーフローを見つけたければ、単純にバッファサイズをあふれさせるデータを入力させれば、落ちてはくれるかもしれません。でも、シェルコードを動かして「任意のプログラム実行」までいくためには、相当人為的にデータを工夫しないと難しいですよね。Web脆弱性検査やる人なら分かっていただけるかと思いますが、例えばSQLインジェクションを、HTTPリクエストに対するレスポンス(出力)で見てても、成功したかどうか分からないんじゃありません?

「ファジングがブラックボックスである」ことによる問題はもう一つあって、それはカバレッジ問題です。カバレッジとは、「そのテストによって、プログラムのあらゆるふるまいをカバーできたか」という指標で、「ソースプログラムで通ってないとこないよね」でもいいですが、なにせブラックボックスは中を見ないので、そもそも難しい。そしてファジングも、てきとーなデータを数撃っても、敵を全員倒せるかは誰にもわからない。
そんなファジングの弱点を克服しようとする試みも出てきていて、例えばシンボリック実行を使い、テストデータ候補を導出するという研究があります。シンボリック実行ツールはプログラムの指定した個所に到達するための入力値を算出してくれます。この技術は元々ソフトウェア業界ではあったものですが、これを使うと、プログラム中でフラグを出力している個所を指定して、求める入力を出してくれるので、CTF業界では知られてきていますね。そのシンボリック実行を使って、ある程度カバレッジを満たすようなテストデータを生成できるということなんですが…そこまでご親切にデータ生成したものって、はたしてそれは「ファジング」なの?という疑問は残ります…だって全然「あいまい」じゃないじゃない。

で、ですね(ここからが本題)。ファジングのことを書こうと思ったのは、先日SCIS2020で、車載に対するファジングの発表があったからです。

車載ECUへのファジング時におけるサイドチャネル情報を用いた異常動作検出手法
◎谷口亮介(立命館大学)、吉田康太(立命館大学)、久保田貴也(立命館大学)、汐崎充(立命館大学)、藤野毅(立命館大学)

車載というか、車の中の個々のコンピュータユニットであるECUに対するファジングで、さっき言ったように攻撃ができても反応がない場合に対する対策として、サイドチャネルを検出し、正常時との違いによりpositive/negativeを判定するというもの。これ、個人的には面白い着眼点だと思いました。うまくいけば、一見反応がないものでも攻撃成功してるか分かったらすごいじゃないですか。発表で扱っていたのはバッファオーバーフローだけですが、もし、仮に他の脆弱性でも同様にできたら、可能性が広がりそうです。
でも1個だけ気になる点があって…これ、車載のECUが対象なんですよね。質問時間がなくしそこねたんですが、たぶん個々のECUは\に対してファジングかけるってことですよね。ECUって、車1台につき100個以上あるんですよね。そのそれぞれのECUの特性をあらかじめ全部おさえた上で、更にファジング(大量のデータ…)で確認するのは、手間が大変そう…

ところで、完全余談ですが、タイトルの「ファジィ」の小さい「ィ」の使い方は、日本語では読み方が規定されていないのですが、こっちの方がなじみがあると思ったので使いました。個人的にこういうのはあまり使わないようにしてますが…最近はこういうの指摘する日本語ポリスの方もいなくなっちゃいましたかねえ。ガンダムの富野監督がよく使うイメージがあります。リ・ガズィやファ・ユイリィとかはまだわからんでもないけど、「ムーンレィス」の読み方は、よくわからん…

マルウェアのイメージ化→機械学習の「元凶」

「元凶」なんて、悪いイメージの言葉を使って、すみませんでした!

…と、先に謝っておいて、と。

そうなんです。最近、マルウェアのバイナリを2次元イメージ化して、CNNなどの深層学習で分類させるというのが、流行ってますよね。去年のCSSでもいくつかそういう発表を見かけました。バイナリって、そもそも1次元情報だし、特徴点だって2つじゃないだろうに、なんで2次元?ひょっとして、CNNとかが画像解析に実績があるからって、それだけ?と常々思ってました。そうこうしているうちに、うちの学生もそんなことやりたいと言いだしたので、「なんでなんで!?」と問い詰めた訳です。そしたら、下の論文を見つけてきまして…

[1]L. Nataraj, S. Karthikeyan, G. Jacob, B. S. Manjunath. “Malware Images:  Visualization and Automatic Classification”, VizSec’11, July 20, 2011, Pittsburg, PA, USA.

こいつだ!こいつが元凶(すみません)!
…という訳で読んでみました。概要はこんな感じ。

  • マルウェアのバイナリをイメージ可視化、パターン認識による分類してます
  • なんでかというと、同じファミリーに属するマルウェアは似たようなレイアウト、内容だから!
  • この方式ならば逆アセンブルもコード実行も必要ない!
  • ユークリッド距離のk-nearest neighborでやってます
  • 25ファミリー、9,458のサンプルをテストして98%の分類精度が得られたよ!

ってことなんですが。著者らによると、マルウェアのバイナリを画像化して見てると、模様のようなものが出てくると。だから分類可能なんじゃないかと、例として上がってる画像が下のもの。

出典:[1]

まあ、こいつなら目grepできそうだけど…
それにしても、こんなの幅次第で変わるじゃん?それに、packer変えたらバイナリも変わっちゃうから意味ないのでは?

幅については、次のように決められているらしい。

ファイルサイズ画像の幅
<10KB32
10KB~30KB64
30KB~60KB128
60KB~100KB256
100KB~200KB384
200KB~500KB512
500KB~1000KB768
1000KB≦1024
出典:[1]

…だからなんでこういう設定!?

packerについては、今回のはunpack後にやっている。が、packされていても98%の精度があると主張している!ホントかよ!後の研究によれば、packが完全な暗号じゃなかったり、同じファミリーが同じpackerを使う傾向が多いかららしい。じゃ、違うpacker使ったらアウトじゃね?

この元凶が(申し訳ございません)2011年ですが、国内でというと下記の発表でしょうか。

矢倉大夢,篠崎慎之介,西村礼恩,大山恵弘,佐久間淳.“CNNと注意機構による画像化されたマルウェアの解析手法”,コンピュータセキュリティシンポジウム2017.

なんと、その年の優秀論文賞を受賞されています。はーん。この受賞が流行の元か。

彼らは、単純に模様で見るのではなく、(1)されたバイナリデータをCNNにかけ、マルウェアに特徴的な領域を検出して、(2)CNN に注意機構と呼ばれる仕組みを組み合わせることによって,画像の中で分類に重要な領域を示す「注意度マップ」を出力しています。
注意機構というのは、深層学習において用いられる手法の1 つで、重要な特徴を動的に選び出し,それらを直接的に用いるのだそうです。自然言語処理の研究で提案されたものだそうです。画像認識では、画像につけられたキャプションを最も特徴的にあらわす領域を抽出することができます。例えば、画像に「バイオリン」というキャプションがついている時、バイオリンの領域を抽出できる訳です(この例の画像はこの解説記事を参照ください)

で、矢倉さん達も、unpackしなくても同等の精度が得られると言ってます。うーーん、そういうものなんですかね。今一つ釈然としないのだが