せきゅぽろ 13

セキュリティ

前回に引き続き、今回も豪華２本立てでした。

マルウェア解析

LAC の新井 悠さんによる、マルウェア解析のお話ですが、まずは時事ネタとして、誤認逮捕で大騒ぎになった iesys.exe に関する話から始まりました。

iesys.exe 自体は、素人の自分から見ても、技術的に見るところがないなぁ、と、思っていたのですが、専門家から見ると、逆に「あり得ない」ぐらい、珍しい物だったようです。

「ここが変だよ、iesys.exe」と題して、次の３つを挙げられていました。

  • .Net Framework 3.5 がインストールしないと動かない（デフォルトのままで動作するのは Windows 7 以降）
  • 通信できないとぬるぽで落ちる。
  • 難読化されてない。

そのほかにも、用意されているんだけど動かない機能とか、まぁ、出来の悪いプログラムだった事は間違いないみたいです。

個人的に興味を引かれた話は、この一連の事件の最初で、CSRF の脆弱性を使った書き込みの件です。そのこと自体は知っていたのですが、そもそも、CSRF が使われるのは、金銭が絡む場合やパスワードの変更など、重要な処理がある時に驚異となる、と思っていたのが、必ずしもそうではない事を示す事例だった、という点です。

CSRF 自体、「なんとなく知ってる」という程度で、最近、徳丸本を読んで、ようやく理解出来たところだったのですが、こういう事件に発展するケースがあると、「CSRF 対策するほどでも...」と言っていられないことになるなぁ、と思いました。

後半は、実際のマルウェア解析の話

と言っても、アセンブラとにらめっこ、という話ではなくて、どうやって「怪しい」を突き止めるか、といった事が中心でした。

以前、LAC の西本さんがおっしゃっていた「標的型攻撃はウィルスではない」の通り、一般的なウィルス対策ソフトでは検知されないものですが、それでも、いくつか兆候が見つけられる、ということでした。

一つは、いつもとは違う種類のマルウェアが検出される、という話。本来はプロが使う「ハッキングツール」の類が、一般的なウィルス対策ソフトとではマルウェア扱いされる事がありますが、標的型攻撃のマルウェアが内部ネットワーク内で活動する際に、これらのツールが使われるそうです。で、本来はまっとうなツールが悪用されているだけなので、検出されたとしても「危険度：Low」といった評価で示される事が多く、一見、問題が無いように思えるけど、実は氷山の一角、という事があるようです。

あと、やはり、通常はアクセスしないようなサイトへのアクセスが増える、という兆候があるそうです。以前に Microsoft の小野寺さんもおっしゃっていましたが、外向きの通信で統計を取る、というのは有効そうです。

実際の標的型攻撃に使われるファイル形式としては、実行ファイルを ZIP で固めた物が、意外に多くて４割ほど。残り６割ほどが、PDF や Office のファイルなどの「文書系」が占めるそうです。

実行ファイルは RLO*1 を使った拡張子偽装がよく使われる、とのことでした。

文書系ファイルに関しては、本来はファイルの中に含まれないはずのシェルコードやマルウェアの中身が入っていることになるので、意外に、「このファイルは怪しい」というのは見つけやすい、ということで、そういった「怪しいファイル」に対する、とっかかりとなる調査方法として、いくつかのツールをデモ付きで見せてもらえました。

解析ツールを集めた Ubuntu ベースのディストリビューションの「REMnux」、PDF 解析の「PDF X-RAY」、Office ファイル解析の「OfficeMalScanner」、xor や ror を使ったいった処理での難読化に対して、ブルートフォース解析をする「xorsearch」といった物が紹介されました。

改正著作権法

前回に引き続き、北大の町村泰貴先生が、違法ダウンロード刑罰化で話題になった、改正著作権法の話でした。

改正著作権法に関しては、はてなでの質問に回答できる程度には知っていたのですが、やっぱり、いろいろ「グレーゾーン」があるんだなぁ、という感じでした。

改正著作権法で「写り込み」に関して OK になった、という話があるのですが、じゃぁ、どこまでが OK なのか、というので、先生の奥さんが写っている記念写真の例がありました。

写り込みでは、どっちが主でどっちが従か、という問題があって、全面に建物が写っている点では、建物が主とも言えるけど、真ん中に写っている奥さんが主とも考える。でも、真ん中に写っている奥さんが角になるように写真をトリミングしたらどうか、といった話がありました。

違法ダウンロードの刑事罰化でも、CD は有償だけど、プロモーションビデオは無償、といった具合に、有償・無償の両方がある場合にどうか、という話がありました。これに関しては、音楽の場合は同一性の範囲が広くて、例えば、CD とライブ音源といった具合に、違っているところがあっても同一の音楽と見なされるので、たとえ無料のプロモーションビデオから抽出した音楽でも、有償著作物として扱われることになるだろう、とのことでした。

町村先生のお話が終わった後の質問タイムは、まさに、このグレーゾーンに関する質問のオンパレード。ある方が、アマチュアの人が作った音楽が、後から CD 化された場合は？ という質問に便乗して、私も、文化庁は TV 番組は OK と言っているけど、後から DVD 化された場合はどうなるのか、という質問をしました。

基本的に、ダウンロード時点で無償の物は、後から有償になっても、刑罰は問われない、とのことでしたが、でも、ドラマのように、後から DVD 化される事が当然とされるようなものだと、微妙かもしれない、といったお話しでした。

次回は LOCAL とのコラボ

来年１月に、去年もあった LOCAL とせきゅぽろのコラボが予定されているそうです。具体的な内容は追ってお知らせ、とのことでした。

*1:アラビア文字のように、右から左に記述する言語のための Unicode 上の制御文字

MS-CHAPv2 is Obsoleted

セキュリティ

DEFCON で、PPTP の認証方式として一番ポピュラーな MS-CHAPv2 をクラックするツールが登場した事が、大きな話題になりました。

DEFCON参加の専門家、「MS-CHAP v2」をクラックするツールを発表 - CNET Japan

DEFCON というと、一介のエンジニアには遠い存在で、自分が理解できるような話はない、と思っていたのですが、この話は、思いの外、簡単な話でした。

わかりやすい解説が、英語のブログ記事ででています。

https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/

書いてある中身が分かると、「なんで誰も気がつかなかった？」と思えるほど、単純なことでした。

MS-CHAPv2 とは

PPTP で最もよく使われる、チャレンジ・レスポンス型の認証方式で、PPTP 以外にも、無線 LAN の認証機構としても使われる事があるそうです。

チャレンジ・レスポンス型、というのは、サーバ側がチャレンジ・コードと呼ばれる、その場限りの乱数をクライアントに送り、クライアント側は、その乱数とパスワードを使った計算を行い、その結果をサーバ側に返します。こうすることで、通信上にはパスワードそのものが流れる事がない上に、クライアント側から送られるレスポンスが、毎度違う物になるため、「パスワードそのものは分からないけど、この情報をサーバに渡せば認証が通る」といった事が起きなくなります。割と有名なのは、POP サーバへ繋ぐときの APOP も、このチャレンジ・レスポンス型になります。

レスポンスの計算方法

前述の英語のブログで、「The Protocol」の章にある絵を見ると、クライアント側がユーザのパスワードから、どんな方法でレスポンスを計算するのかが分かります。

クライアントは、サーバからチャレンジ・コード（ServerChallenge）を受け取ります。それが、図ではサーバからクライアントへの矢印が引かれて「Random 16 Byte Server Challenge」と書かれているところです。

その下に書かれた、クライアント側の手順を順に追うと、下記のようなになります。

  1. 16 Byte の乱数を生成する。
    （Generate 16 Byte ClientChallenge）
  2. 自分が生成した乱数と、サーバから送られてきた乱数と、アカウント名をつなげ、それに対する SHA1 のハッシュ値を計算する。
    （ChallengeHash = SHA1(ClientChallenge || ServerChallenge || UserName)[0::8]）
  3. ユーザのパスワードに対する MD4 のハッシュ値を計算する。
    （NTHash = MD4(UserPassword)）
  4. ２番目の手順で計算したハッシュ値（ChallengeHash）に対して、３番目の手順で計算したハッシュ値（NTHash）を鍵として、DES による暗号化を行う。このとき、NTHash の値を３つの値に分割して３つの鍵を作り、３つの鍵それぞれで暗号化した結果をつなげる。
    （ChallengeResponse = DESNTHash[00:07](ChallengeHash) || DESNTHash[07:14](ChallengeHash) || DESNTHash[14:21](ChallengeHash)）

この手順の中をよく見ると、ユーザのパスワードが直接分からなくても、３番目の手順で計算した NTHash の値が分かれば、「詰み」な事が分かります。

クライアントから送られるレスポンスの内容は、図で上記の処理を列挙した後に、クライアント側からサーバ側へ引かれた矢印の線の上に「24 Byte ChallengeResponse, 16 Byte ChallengeHash, UserName」と書かれています。ChallengeResponse を計算するための入力値になる物は、ChallengeHash と NTHash で、ChallengeResponse と ChallengeHash はネットワーク上を流れているデータなので、隠された値ではないです。という事は、ChallengeResponse と ChallengeHash の値から、NTHash が逆算できれば、ユーザのパスワードそのものが分からなくても、ChallengeResponse の値を計算する事ができます。

NTHash の値を逆算するには

NTHash の値は、MD4 で計算された値なので、128 bit の数値です。一方、DES の鍵長は 56 bit 固定です。128 bit の値を３つに分けて、56 bit の鍵を３つ作るのですが、ここが実にお粗末です。

「Divide And Conquer」の章の下の図でも説明されていますが、この図を見る前に「どうやって、128 bit の鍵から 56 bit の鍵を３つ作るんだ？」という疑問をもって、MS-CHAPv2 の RFC を読みました。

RFC 2759: Microsoft PPP CHAP Extensions, Version 2

上記ページの「8.5. ChallengeResponse()」を読むと、下記のように書かれています。

Set ZPasswordHash to PasswordHash zero-padded to 21 octets

「zero-padded」つまり、ゼロで穴埋めしています。

という事は、56 bit の３つの鍵のうち、最初の２つは NTHash の 128 bit で賄えますが、最後の鍵は、余った 128 - 56 × 2 = 16 bit に、40 bit のゼロが続く鍵、という事になります。たかだか 216 = 65,536 の鍵候補を調べれば良いことになります。

残り２つの鍵は 256 = 72,057,594,037,927,936 通りの鍵を調べれば見つかります。見つけるべき鍵が２つだから、この倍を調べる必要があるように一瞬思いますが、１つの鍵候補に対して、その鍵候補が１つ目の鍵なのか、２つ目の鍵なのか、といった判断をすれば良いので、計算量としては 256で変わりません。

DES の安全性

今時はほとんど AES で、「DES なんて古い暗号は...」と思われがちですが、実は、それほど脆い物でもありません。少なくとも、数分で解けてしまうような穴がある訳ではありません。

http://ja.wikipedia.org/wiki/DES_(%E6%9A%97%E5%8F%B7)

理論的には、256より少ない計算量で解ける方法は考案されていますが、あらかじめ平文と対応する暗号文がある程度集まっている時に、鍵の候補を絞れる、というもので、単純に暗号文だけがある状態から解ける訳ではありません。

それでも、DES の安全性に疑問が付き、それに換わる AES を作ることになったのは、256という鍵長が、十分に長いとは言えなくなってきたためです。

先の Wikipedia での記述にもありますが、1999 年に 22 時間で DES が解けた話が載っています。ただし、25 万ドル掛けた専用マシンに、インターネットで募った 10 万台の PC を使って、ですが、個人ではともかく、組織がお金を掛けて解けば１日足らずで解ける、という状況になった訳です。しかも、13 年前。

ということで、DES 自体には欠陥らしい欠陥は無いのですが、56 bit という鍵長は今時、短すぎるので使われなくなった、といったところです*1。ちなみに AES は最短の鍵長でも 128 bit です。

まとめ

ということで、MS-CHAPv2 の問題は、

  • クライアントから送られるレスポンスを解析するのに必要な計算量は、56 bit の DES を解くのと同等。

ということになります。

私はこの記事を読んだとき、LM Hash の問題を思い出しました。LM ハッシュの問題はWindows のパスワード強度 理論編 - JULYの日記でも書きましたが、パスワード文字列を分割してから、それぞれにハッシュ値を計算しているところです。これも、３つの DES の結果をつなぎ合わせるのではなく、Triple DES の様に、「DES の結果をさらに DES にかける」という事をしていれば問題は無かったのに、と思います。この「分割してから計算」というのが、いかにも Microsoft らしいと思ってしまいました。

*1:DES を三回繰り返すことで、強度を高めた Triple DES は今でも見かけます。三回の暗号化処理で鍵を変えることで、使える鍵長を長くしています。１回目と３回目は同じ鍵を使う 112 bit 鍵の場合と、３回とも別の鍵を使う 168 bit 鍵の物があります。Triple DES に対して、１回だけのものを Single DES と呼ぶこともあります。

で次回は、なんと

話題の「バグハンター日記」の翻訳者の一人である、LAC の新井 悠さんだそうです。これまた楽しみだなぁ。

Bugハンター日記

Bugハンター日記

「最近のインターネット法律問題」 - 町村 泰貴さん

北海道大学大学院の町村 泰貴さんから、ネット関連でここ数年、話題になった事案に関するお話でした。

ステマ騒動やコンプガチャの問題など、いろんな出来事に対して、法律的な観点から見ると、という話なのですが、現状の法律に照らしてどうこう、というよりも、「これって何が問題なの？」という感じの話でした。

例えば、ステマの問題も「で、だれが被害者？」と考えると、「これは大変な被害だ！」というものは、実は無いかもしれない。食べログの件なんかは、強いて言えば、近所のお店は競業関係にあるから、やらせ口コミのせいで被害を、かと思うと、行列が出来たおかげで、かえってお客さんが入ったかもしれないし、実際にそのお店で食べた人から「まずかった」という話もほとんど無かった、となると、単に「だまされた！」という気分だけで、具体的な実害は見あたらなかったりします。

コンプガチャの問題では、広告以外のインターネット・ビジネスモデルをつぶすことになった、という事を言われることはあるし、同じように射幸心を煽るものなら、パチンコはどうなんだ、という話はあるけど、でも、射幸心の問題があるから、パチンコは風営法で出玉確率を制限したりしているわけで、コンプガチャにそういった規制無しに「出現確率が全く分からない」状態というのは問題だろう、といったお話がありました。

これはひどい、と騒がれた事件でも、一歩引いて考えてみると、微妙な問題が含まれているんだなぁ、という事を実感しました。

「情報セキュリティ最前線」- 山口 英さん

奈良先端科学技術大学院大学の山口 英さんと聞いて、真っ先の思いつくのは、今は無き UNIX Magazine での「UNIX Communication Notes」。当時の自分は、UNIX 系 OS は「とりあえず、触れる」程度で、UNIX Magazine 自体にあまりついて行けてなかったのですが、それでも、あのちょっと独特の硬派な雰囲気にあこがれて読んでいました。

で、テーマ通り、情報セキュリティを取り巻く「今」に関して、幅広いお話しを聞けました。

まず、昨今は、

  • マフィアやギャングのような、裏家業で儲けるため
  • 国家レベルでの諜報合戦

が多く、ここに Anonymous に代表されるような、ハクティビストによる動きが加わってきた、というところで、ここに「坊主」たちがぶら下がっている感じで、「坊主ばっかり捕まえてないで、もっとも上を捕まえろよ、○○府警*1」といった話から始まりました。

とにかく、いろんなお話しがあったのですが、手元のメモに残っていて、おもしろかったお話を紹介します。

掃除婦は見た

物理的なアクセスで、清掃業者の格好をするのが効果的で、データセンターとかはともかく、一般企業だと、結構、中まで入れる。あっ、うちの会社は、自分たちで掃除当番だから関係ないや(^^;

Botnet vs. Amazon EC2

ボットネットの相場の話で、いろんな値段があるけど、1000 台 1 時間で 360$ ぐらいという話。ところが、同じ規模、時間なら Amazon EC2 で 120$ で使えちゃう。ということで、Amazon EC2 を使うケースも多いそうです。こうなると、まっとうな Amazon EC2 を使っているサイトも多いので、フィルタしづらくてやっかい、という話がありました。

Amazon EC2 でパスワードのブルートフォースをすると、英数字（おそらく、記号文字は含まない）パスワードで、下記のような金額になるそうです。

文字数 金額($)
8 45
12 75,935,598

記号を入れると、30 倍ぐらい*2で、1350$ にはなりますが、それでも、それほどの金額では無いです。パスワードクラッキングツールで有名な John the Ripper が GPGPU に対応した*3、なんていう話もあるので、もう、８文字のパスワードは不十分と言って良いかもしれませんね。

マルウェアの主流はドライブ・バイ・ダウンロード

というのは知っていましたが、最初につながるサイトは、本来はまっとうなサイトに仕掛けを入れられたもので、そこからいくつかリダイレクトした上で、本当にマルウェアダウンロードさせるサイトにたどり着く、となっている事が多いそうです。

しかも、そのダウンロードサイトは時間限定だったり、実際にダウンロード出来るためには、Cookie や Referrer などの条件が揃っていないとダメだったり、で、気づいた時には、もう、どんな相手だったかは分からないそうです。

What is manageable should be measureable

管理する物は計測できなければいけない。第８回せきゅぽろで Microsoft の小野寺さんも同じ事を言ってましたね。まずは、計測すること。ログを取るだけじゃなくて、それを集計して計測していれば、何かが起きれば気づく事が出来る。がんばろっと。

「不審なファイルを開くな」は宗教

激しく同意。そんな物に期待しちゃいかん。だけど、それに対応したシステムを入れると、メールで 2000 万円、Web で 2000 万円、計 4000 万円は高い！ 標的型攻撃にシステムで対応するのは、まだまだ、コストが高いなぁ。

*1:って二択(^^;

*2:ASCII 図形文字の 95 文字として、958 / 628 倍

*3:https://twitter.com/matsuu/status/218932562469470208

その DNS サーバ、信用できますか？

セキュリティ

Google Public DNS の登場辺りから、DNS サーバを ISP や回線業者のお仕着せの DNS サーバではなく、別の DNS サーバを使うとレスポンスがよくなる、といった具合の話を、ちょくちょく見かけるようになっていますが、その極めつけとして、「お使いの回線で、最もレスポンスの良い DNS サーバをお調べします」というソフトが、こともあろうか「窓の杜」で紹介されました。

【レビュー】応答の速いDNSサーバーを探すのに便利な「Domain Name Server Benchmark」 - 窓の杜

まぁ、そういうソフト自体が存在すること自体は否定しないし、実際に DNS サーバを立てる側に回れば、自分の立てた DNS サーバがどんなパフォーマンスかを計測できるわけだから、有用性はあるとは思うけど、それを、昨今の「DNS サーバを変えれば、あなたも快適なネット環境！」といったノリで紹介しちゃ、絶対ダメにです。

フィッシング詐欺に代表されるような、偽物のサイトに何とか誘導して、アカウントやパスワード、うまくいけば、各種個人情報等をせしめたい、と思っている人たちから見ると、DNS のレスポンスをごまかせるのは、すごく「美味しい」んです。

なぜなら、本物と全く同じ URL でありながら、偽物のサイトに繋がるようにできるからです。

偽物サイトに誘導する側は、一生懸命、紛らわしいドメイン名を考えて、それっぽく見せかけて誘導しようとするのに、ドメイン名が全く同じでは、偽物だと機械的に判断できる材料がありません*1。

このソフトが問い合わせるドメイン名に対して、素早く応答できるようにチューニングした DNS サーバを用意して、「この DNS サーバ、早いよ」とか触れ回っておいたら...。

その DNS サーバ、信用できますか？

*1:SSL/TLS 化されている場合には、本物と同じドメイン名で証明書が取得できるか、というところが大きな壁になると思いますが、もし、ずぼらな CA が発行しちゃうと、もう、本物と見分けがつかなくなります。