■ Kerberosが受けうる攻撃

おね〜さんと、

ほげたんのっ!!

3 Minutes Networking、

Supplement !!

なんか、気付いたら4回目なんだけど、このKerberos。
ま、それはいいとして。Kerberosは認証システムなんだけど、なんで認証なんて必要なのかな？

え？ そりゃ使用するユーザや使用されるサービスが「正規」である、つまり認められているって識別するためでしょ。

そうよね。逆に言えば、この認証系さえ騙せてしまえば、あとはどうとでもなるってことよね。

ん、そうだね。本来は使ってはいけないユーザとかでも、何らかの手段を使って認証されれば、その時点で「正規」であるって認められるからね。

でしょでしょ。なので、認証プロトコルはそれらの「騙し」を防ぎ、攻撃から身を守らなければいけない、ってのはわかるわよね。

そだね。

というわけで、Kerberosも毎回毎回蜂蜜菓子に手もなくひねられるわけにはいかないので、ちゃんと防衛手段が考えられている、というのが今回の話。

防衛手段？

そう。その話をする前に、まず先に。
Kerberosが防げない攻撃も、もちろんあることを知っておいて欲しいわけ。

え？ 防げない攻撃があるの？ ダメじゃん？

そりゃあるわよ。完璧なシステムなんてあるわけないんだから。もしあったとしたら、それは神が作りたもうたシステムよ、そんなの。
で、残念ながら人間にはそんなものは作れないので、防げない攻撃もあるのよ。

おね〜さん、神様信じてるの？

信じてるわよ。「♪今日会う人と結ばれる、今週も来週もさ来週もずっと〜♪」

なるほど？ 神だのみもしたくなる気持ちはわからなくもないなぁ。
いくら美人でも、命の危険があるとなるとちょっと引くよね。ロマンスの神様でも荷が重いかなぁ。

……。

あ、嘘。嘘嘘嘘。
きっと美人すぎて周りが躊躇してるだけ、うん、そうそうそうそう。

……ま、いいわ。ともかく、Kerberosが防げない攻撃。ポイントはココ。

ユーザの鍵はパスワードから生成されて。
KRB_AS_REPを復号化してセッション鍵を入手し、TGTを受け取る。ココ？

そう。つまり、どんなにKerberosが優秀であっても、パスワードとそれに類するものをネットワーク上に流さなくても、パスワードが破られればおしまい、ということなのよ。パスワードが破られると、共通鍵を手に入れられてしまうからね。

でも、どうやって破るの？

こう。確かにKerberosはパスワードに類するものを流さないけど、暗号化したデータ自体は存在するわけだから。それを入手して、鍵をいろいろ試すのよ。

ふむふむ。復号化できるかどうか試すんだね。

そうそう。復号化できたら、鍵を入手できたことになるから、そうなったらTGTもセッション鍵もすべて入手できちゃう。

あぁ、TGTとセッション鍵を入手されちゃったらダメだよね。
でもそれってKerberosの責任じゃないよね。

まぁ、確かにそうね。
つまり、Kerberosがセキュリティが高いといっても、そういう面ではどうしようもないってことなわけ。

なるほど。

あと、このパスワードの問題以外にも、DoS、Kerberosソフトウェアのセキュリティホール、管理者など内部からの漏洩なんかは防げないけどね。

まぁ、そこらへんはどうしようもないと言えばないよね。

■ 事前認証

さてさて、パスワードを破られれば結局おしまいなんだけど。
まず、パスワードを破るためには暗号化されたデータが必要よね。

ん、そだね。暗号化したデータがあれば、それに対して「予想されるパスワード」から鍵を作って、復号化を試すことができるよね。

で、その暗号化されたデータの入手だけど、さっきは盗聴して、って書いたけど。実際、盗聴って結構面倒なのよね。
でも、もっと簡単な方法があるのよ。

簡単な方法？ 簡単にデータを手に入れることができると困るような気がするけど。

たしかに、みすみす辞書攻撃や総当り攻撃を試すデータをあっさり渡しちゃうのは困りものよね。
なんで、こんなことになっちゃうかっていうと…。

はい、ポイントは？

KRB_AS_REQが平文だってところ？

そう、暗号化がいらないのがKRB_AS_REQなのよ。それに対し、ASは…。

ユーザプリンシパルと現在時刻だけを確認して、KRB_AS_REPを返してしまう。
つまり、要求の内容とその送信元が一致するかどうか確かめないで応答するのよ。

あ〜、そうか。要求自体は平文だから誰でも作れるし。
ASは送ってきたユーザプリンシパルが、本当にその持ち主のものかどうか確かめないんだ。

そう。だから、これを防ぐために、「ユーザプリンシパルが送信元のものかどうか」を確かめることを行うことができるのよ。これが事前認証。

なるほど。TGTの要求のために、認証子を送信させるわけだね。

そういうこと。これでASは正しいクライアントにのみ暗号化したデータを送ることになるってこと。
WindowsのActiveDirectoryで使われているKerberosは事前認証が標準になってたりするわね。

へ〜。

■ リプレイ攻撃

一般的に、この手の認証系でよく使われる攻撃として、「リプレイ攻撃」があるわ。

リプレイ攻撃？ 繰り返し攻撃？

認証用データを盗聴して、そのまま使う攻撃ね。

ん〜、認証されるためのデータをまるまる送りつけるんだね。
そうすると「認証用データは正しい」から、「送ってきたユーザも正しい」と判断しちゃう？

そうそう、そういうこと。
さて、Kerberosの場合はどうなるの？ 認証用のデータって何？

チケットと、認証子？

そう。攻撃者は盗聴してチケットと認証子、つまりKRB_AP_REQをそのまま送って騙そうとするわけね。
そのKRB_AP_REQの中身はこうだったわね。

で、このチケットと認証子に、リプレイアタックを防ぐ項目が入っているわけなの。

ん〜ん〜。クライアントIPアドレス？

まず、それ。チケットにはクライアントのIPアドレスが入っているので、送信元IPアドレスとチケットのIPアドレスが一致するかどうかでチェックできる。

そうだよね。KRB_AP_REQの送信元アドレスとチケットのIPアドレス違ったら変だもんね。

ただし、チケットのクライアントIPアドレスは、場合によっては「任意」だったりすることもあるの。
それに「ユーザ認証」だから、ホストがそのIPアドレスでも使ってるユーザが攻撃者の可能性だってあるし。

う、う〜ん。

なので、リプレイ攻撃防御その2。タイムスタンプ。
Kerberosではタイムスタンプとサーバの時間が5分以上ずれている場合、チケットを拒否するのよ。

5分？
チケットの送信時間（タイムスタンプ）とサーバが受信した時間に5分以上のズレがあるとダメってことだよね。

そう。つまり、KRB_AP_REQを盗聴しても、5分以内に使用しないとチケットに書かれてるタイムスタンプが古くなってしまって、チケットが使えなくなるのよ。

じゃあ、攻撃者は5分以内に使用すればいいんじゃない？

ま、そうなるわよね。
ともかく、Kerberosを使用する場合、サーバ/ホストはKDCと時計を合わせなければならないってこと。

そういえば、WindowsのActiveDirectoryドメインだと、ドメインに参加してるホストはドメインコントローラに時計が自動的に合うようにされてたっけ。

そうよ。ActiveDirectoryではKerberosを認証に使ってて、ドメインコントローラがKDCになってるの。だから、ドメインコントローラに時計を合わせるようになってるわけね。

へ〜。あれってそういう理由だったんだ。

IPアドレスでもタイムスタンプでもリプレイ攻撃を防げなかった場合の、最後の防御法。
それはリプレイキャッシュと呼ばれてるわ。

同一の認証子が送られてきたら破棄する？

そう、リプレイ攻撃はかならず「本物より後に使用される」わよね。

そうだね。まず本物のKRB_AP_REPが送られて、それを盗聴してから使うから、本物より後になるよね。

認証子は暗号化されたタイムスタンプでしょ。正規のユーザは同じタイムスタンプのKRB_AP_REPを送ってくるはずはない。

ん、まぁ、ないかな。同時に2つの認証要求を送るのって変だし。

そして、リプレイ攻撃は同じ認証子が送られてくる。だって、攻撃者は復号化できないから盗聴したものをそのまま使わざるを得ないから。

そだね。

結果、「もし同じ認証子が送られてきたら最初が本物である」「後から来たのはリプレイ攻撃である」といえるわけね。

ふ〜ん。でも、キャッシュは一定時間だけでしょ？ しばらくしてから送ってきたら？

それはタイムスタンプの「5分制限」に引っかかってアウト、ね。

あぁ、そうか。リプレイキャッシュは「5分以内にリプレイされた」場合に有効なんだ。

そゆことね。

■ 仲介者攻撃

リプレイ攻撃以外にも、認証系が受ける攻撃として、仲介者攻撃ってのがあるわ。

まんいんざみどる？ 仲介者？

「フィッシング」とか「なりすまし」って呼ばれる行為だっけ、これ？

そうねぇ、確かにユーザからみれば「サーバになりすまし」、サーバからみれば「ユーザになりすまし」てるから、なりすましの一種って感じかしら。
これのポイントはサーバやユーザからみると、普通に通信しているように思えることよ。

んん〜っと、確かにユーザはサーバ（攻撃者）と、サーバはユーザ（攻撃者）とやりとりしてるから、普通に見えるよね。

そう、攻撃者は単純にやりとりの中継もすることもできるから、見破られにくいのよね。
で、この仲介者攻撃を防ぐ方法としては、「サーバが正しいサーバであるか」という点が重要になるでしょ。

そうだね。攻撃者がサーバになりすましているのを、ユーザが見破ればいいわけだからね。

Kerberos以外だと、例えばSSLならサーバがユーザに電子証明書を送ってくるからそれを確認すればいいわけよ。

あぁ、右下の鍵マークをクリックすると確認できるよね。

うん。
一方、Kerberosの場合、クライアントが相互認証を要求できるのよ。

セッション鍵で暗号化されたタイムスタンプをサーバが応答にいれて送り返す…。

うん。それが復号化できるということは、送信元がセッション鍵を持つということでしょ？
セッション鍵を持つためには、サービスの鍵でサービスチケットを復号化できないとダメじゃない。

サービスの鍵を持つのは、TGSとサーバだけ。よって、送信元がサーバとわかる。
う〜ん、つまり、応答にサーバが認証子をつけてくれると思えばいいね。

そうね。その理解でいいかも。
さてさて、ほげたん。Kerberosがセキュリティのために考えて要求/応答を送っているのがわかった？

うん、大体は。

じゃ、今回はこれぐらいにしておきましょ。
Kerberosはあともう1回だけやります。

ん〜あと何の話？

Kerberosのオプション機能のお話ね。
じゃ、また次回。おね〜さんと、

ほげたんのっ!!

3分間ネットワーク、

サプリメントでした〜〜〜っ!!
まった次回〜〜〜〜!!