Kerberos は、SSH 中間者シナリオ (攻撃者がユーザーにサーバーの公開キーを信頼させ、そのサーバーを介してトラフィックをリダイレクトするシナリオ) において、攻撃者がユーザーの資格情報を取得できないようにすることを明確に防ぎます。ただし、認証後にセッションをリッスンして、その後に入力された資格情報などの貴重な情報を取得できるため、攻撃者がユーザーの資格情報を取得しなくても問題ない場合はどうなるでしょうか。
明確にするために、シナリオは次のとおりです。
- SSH サーバー (Server1) とクライアント (User1) は Kerberos 用に設定されています。Server1 には、認証などのための標準の公開/秘密キー ペアがあります。
- User1 は最初に Server1 に接続しようとしますが、攻撃者によって接続が Server2 にリダイレクトされます。
- User1 は、提示された Server2 からの公開キーを詳しく調べず、それを Server1 の既知のホスト キーとして受け入れます (これにより MITM が設定されます)。
- User1 は、Server2 を介して Server1 との Kerberos 認証を実行します (Server2 は 2 つの個別の SSH セッションを設定し、それらの間で情報を渡します)。Kerberos の動作方法により、攻撃者は認証中に貴重な情報を取得できません。
- ただし、認証されると、User1 は sudo を含む操作を Server1 で実行し始めます。攻撃者は、Server2 を通過するセッションのすべての内容を見ることができます。
これは機能しますか? このシナリオは、認証手順中に公開キー認証を使用すると明らかに阻止されます。しかし、Kerberos または SSH プロトコルには、この状況を防ぐ何かがあるのでしょうか?
答え1
コメントでの議論を少し拡張します:
質問は、SSH トラフィックをクライアントから不正な SSH サーバーに転送した場合、不正な SSH サーバーがクライアントの Kerberos チケットをキャプチャして実際の Server1 に転送することで、リプレイ攻撃に使用できるかどうかです。
これは、MiTM 攻撃の失敗を防ぐ SSH セキュリティ メカニズムに依存しています。つまり、クライアントが Server1 からの実際のサーバー キーをまだキャッシュしていないか、キャッシュしていたとしてもStrictHostKeyChecking無効化または無視されています。
SSH + Kerberos GSS-API はデータ暗号化に SSH に依存しているため、SSH は SSH 暗号化に加えて Kerberos ベースのデータ暗号化を使用しないため、Server1 への認証が成功した場合、中間者不正 SSH サーバーは送信されたすべての情報にアクセスできると想定されます。
はい、それは理論上は機能しますが、不正な SSH サーバーである Server2 が Server1 のクライアントになりすますことに成功した場合のみです。
実際のServer1は転送された認証情報を拒否する（または少なくとも拒否するべき）と思います。Kerberos認証の一部として、クライアントは2つのメッセージを送信します。サービスチケットと認証システム転送されたサービス チケットは有効ですが、付随する認証子は有効ではありません。
RFC 4121SSH で使用される Kerberos GSS-API 仕様には、認証メッセージの一部としてチャネル バインディング情報が含まれています。
「チャネル バインディング タグは、GSS-API セキュリティ コンテキスト確立トークンが対象とする特定の通信チャネルを識別するために使用され、傍受されたコンテキスト確立トークンが攻撃者によって再利用される範囲を制限します。」
つまり、認証メッセージには、送信者の IP アドレスと送信元ポート、および宛先の IP アドレスとポート番号が含まれます。これらが実際の接続のものと一致しない場合、Kerberos 交換は Server1 によって拒否される必要があります。