2001年 12月 17日
SSH1 プロトコルの脆弱性の概要
この概要の目的は、SSH1 (Secure Shell バージョン 1) ソフトウェアで発見された、セキュリティ上の重要な問題をいくつか取り上げることです。これらの脆弱性に関する詳細については、後の「レファレンス」の項を参照してください。「レファレンス」では、関連のホワイト ペーパーおよび CERT vulnerability notes へのリンクが記載されています。
SSH1 は、rlogin、telnet、ftp、Berkeley 'r' サービスなど、セキュアでないサービスに代わるプロトコルとして、1995 年に設計されました。しかし、時間が経過するにつれて、SSH1 にはセキュリティ上の脆弱性があることが明らかになりました。このような脆弱性には、弱いハッシュや、十分でない暗号化アルゴリズムがあります。
これらの脆弱性は、以下で説明するように、アクセス制御と認証、データ整合性、機密性、および接続のリダイレクトのいずれかの分類に当てはまります。
すべての脆弱性の一覧については、CERT/CC（カーネギーメロン大学のコンピュータ緊急対応センター） を参照してください。
概要
RC4 暗号を使用して SSH1 経由で送信されたパスワードは、サーバで NULL パスワードが許可されない場合、クラックされる可能性があります。
説明
この問題は、CERT VU#665372 に関連して発生します。SSH1 接続の暗号として RC4 が選択され、パスワード認証が使用された場合、攻撃者は最大 1 時間にわたってセッションをキャプチャし、再生できます。RC4 暗号独自の特性に加えて、認証の失敗ごとに返される応答が異なることを利用して、攻撃者は以前にキャプチャしたセッションを再生し、パスワードパケットを操作し、特定の応答が受信されたときにパスワードの最初の文字を特定できます。パスワードの他の文字も、同様の方法にいくつかの追加手順を加えて特定できます。
ＳＳＨ コミュニケーションズ・セキュリティ (ＳＳＨ社) では、1997 年に RC4 暗号の配布を無効にしています。
解決方法
SSH1 接続には RC4 暗号を使用しないでください。
概要
RC4 暗号およびパスワード認証を使用した SSH1 接続を再生できます。
説明
RC4 暗号を使用した SSH1 セッションが確立されると、クライアントとサーバはセッション 鍵 (SK) について合意します。SK は、定期的 (デフォルトで 1 時間ごと) に更新されるサーバ鍵 (VK) を使用して生成されます。サーバは、SK の最初の 16 バイトを RC4 鍵 (SK1') として使用してトラフィックを暗号化します。しかし、クライアントはこの XOR 操作を実行しないので、サーバへのトラフィックを暗号化するためだけにSK2 を使用します。
被害者 (クライアント) がこのセッションのパスワード認証を要求すると、攻撃者は被害者の対話を記録し、サーバ鍵 (VK) の有効期限が切れない限り、その対話を再生できます。デフォルト設定では、これによって対話を再生する 1 時間のウィンドウが攻撃者に与えられます。
ＳＳＨ社では、1997 年に RC4 暗号の配布を無効にしています。
解決方法
CERT VU#25309
概要
RC4 暗号に使用される CRC チェックサムは変更可能なので、パケットを任意に変更できます。
説明
RC4 暗号を使用する場合、SSH1 は CRC を使用して、受信用パケットで整合性チェックを実行します。CRC チェックサムは変更可能なので、攻撃者は SSH1 パケットを傍受し、内容を変更し、それに一致するように CRC を変更できます。パケットが再送信されると、CRC 整合性チェックは攻撃者から被害者に移り、チェックは正常に完了します。これにより、攻撃者はパケットを任意に変更できますが、被害者はそれを検出できません。
この攻撃が成功するのは、クライアントで RC4 暗号を使用していて、サーバは RC4 暗号の使用を許可しており、圧縮を使用していない場合です。
ＳＳＨ社では、1997 年に RC4 暗号の配布を無効にしています。
解決方法
CERT VU#684820
概要
SSH1 では、クライアントが不明なホスト鍵を受け入れた場合、クライアント認証が転送されてしまいます。
説明
I. 前提条件：
クライアントはサーバから不明なホスト鍵を受け入れます。
次の 3 つのホストがあります。
C - クライアント
M - 攻撃者によって制御された、悪意を持ったサーバ
S - 攻撃者がアクセスを試みているサーバ
暗号化が無効になっている場合：
クライアント C が M に接続を試み、これによって M は S に接続して公開ホスト鍵 (PubKeyS) を入手します。次に、M は PubKeyS を C に転送し、C では M 用のホスト鍵が変更されたことを示す警告ダイアログが表示されます。C の被害者がこの警告を無視して PubKeyS を受け入れた場合、クライアントの SSH1 ソフトウェアはセッション鍵 SessKeyC を生成します。この鍵は PubKeyS で暗号化されるので、S のみがこれを解読できます。しかし、C は暗号化を無効にする選択をしているので、このセッション鍵は実際にはいずれの場所でも使用されません。
これで、M は S に対するオープンな SSH1 接続を確立できましたが、まだ自らを認証する必要があります。S が M に対して RSA チャレンジ (ChalS-M) を提供すると、M はそのチャレンジを C に転送し、被害者はチャレンジに正しく答えます。この時点で、M は S に接続されて認証され、S 上にある被害者の任意のリソースにアクセスできるようになります。
暗号化が有効になっている場合：
攻撃は同様に行われますが、M はセッション鍵を所有している必要があります。そのために、M は PubKeyS から新しい鍵ペア (PubKeyS*、PrivKeyS*) を生成します。この操作は、S の公開鍵マテリアルから派生したセッション ID によって影響を受けません。M は、対象型の鍵 K での合意に使用される元のセッション ID とともに、PubKeyS ではなく PubKeyS* をクライアントに転送します。PubKeyS* は PubKeyS と同じセッション ID を作成するので、C とS は K とのネゴシエーションに成功します。しかし、M はこのセッション ID に一致する秘密 RSA 鍵の 1 つを所有しているので、これを傍受できます。
問題は、セッション ID によって、いわゆる偽の分割が許可されることにあります。つまり、セッション鍵とホスト鍵のモジュラスは、連結されたときに同じビット文字列を作成する擬似モジュラスを選択可能にする方法で連結されます。この擬似モジュラスがランダムに選択された場合、それらは 2 つのプライムの積ではないので、因数分解が格段に簡単になる可能性が高くあります。M は相手の秘密鍵を入手するために、擬似鍵の可能なペアの 1 つを選択して因数分解します。
II. 影響
攻撃者は、自らを被害者に認証させることができます。
解決方法
CERT VU#684820
概要
SSH1 では、暗号化が無効になっている場合、クライアント認証が転送されてしまいます。
説明
悪意を持ったサーバを制御している攻撃者は、有効なクライアント情報を使用して、クライアントがアクセス権を持っている 2 番目のサーバにアクセスできます。
解決方法
本書では、SSH1 でのセキュリティ上のいくつかの脆弱性について、概要を簡単に説明しました。さらに詳しい情報については、次の項に示された文書にある情報を参照してください。
CERT vulnerability notes: http://www.kb.cert.org/vuls
SSH1 は、rlogin、telnet、ftp、Berkeley 'r' サービスなど、セキュアでないサービスに代わるプロトコルとして、1995 年に設計されました。しかし、時間が経過するにつれて、SSH1 にはセキュリティ上の脆弱性があることが明らかになりました。このような脆弱性には、弱いハッシュや、十分でない暗号化アルゴリズムがあります。
これらの脆弱性は、以下で説明するように、アクセス制御と認証、データ整合性、機密性、および接続のリダイレクトのいずれかの分類に当てはまります。
すべての脆弱性の一覧については、CERT/CC（カーネギーメロン大学のコンピュータ緊急対応センター） を参照してください。
アクセス制御と認証
CERT VU#565052概要
RC4 暗号を使用して SSH1 経由で送信されたパスワードは、サーバで NULL パスワードが許可されない場合、クラックされる可能性があります。
説明
この問題は、CERT VU#665372 に関連して発生します。SSH1 接続の暗号として RC4 が選択され、パスワード認証が使用された場合、攻撃者は最大 1 時間にわたってセッションをキャプチャし、再生できます。RC4 暗号独自の特性に加えて、認証の失敗ごとに返される応答が異なることを利用して、攻撃者は以前にキャプチャしたセッションを再生し、パスワードパケットを操作し、特定の応答が受信されたときにパスワードの最初の文字を特定できます。パスワードの他の文字も、同様の方法にいくつかの追加手順を加えて特定できます。
ＳＳＨ コミュニケーションズ・セキュリティ (ＳＳＨ社) では、1997 年に RC4 暗号の配布を無効にしています。
解決方法
SSH1 接続には RC4 暗号を使用しないでください。
データ整合性
CERT VU#665372概要
RC4 暗号およびパスワード認証を使用した SSH1 接続を再生できます。
説明
RC4 暗号を使用した SSH1 セッションが確立されると、クライアントとサーバはセッション 鍵 (SK) について合意します。SK は、定期的 (デフォルトで 1 時間ごと) に更新されるサーバ鍵 (VK) を使用して生成されます。サーバは、SK の最初の 16 バイトを RC4 鍵 (SK1') として使用してトラフィックを暗号化します。しかし、クライアントはこの XOR 操作を実行しないので、サーバへのトラフィックを暗号化するためだけにSK2 を使用します。
被害者 (クライアント) がこのセッションのパスワード認証を要求すると、攻撃者は被害者の対話を記録し、サーバ鍵 (VK) の有効期限が切れない限り、その対話を再生できます。デフォルト設定では、これによって対話を再生する 1 時間のウィンドウが攻撃者に与えられます。
ＳＳＨ社では、1997 年に RC4 暗号の配布を無効にしています。
解決方法
- SSH2（SSH バージョン 2）にアップグレードしてください。
- RC4 暗号およびパスワード認証を無効にしてください。
CERT VU#25309
概要
RC4 暗号に使用される CRC チェックサムは変更可能なので、パケットを任意に変更できます。
説明
RC4 暗号を使用する場合、SSH1 は CRC を使用して、受信用パケットで整合性チェックを実行します。CRC チェックサムは変更可能なので、攻撃者は SSH1 パケットを傍受し、内容を変更し、それに一致するように CRC を変更できます。パケットが再送信されると、CRC 整合性チェックは攻撃者から被害者に移り、チェックは正常に完了します。これにより、攻撃者はパケットを任意に変更できますが、被害者はそれを検出できません。
この攻撃が成功するのは、クライアントで RC4 暗号を使用していて、サーバは RC4 暗号の使用を許可しており、圧縮を使用していない場合です。
ＳＳＨ社では、1997 年に RC4 暗号の配布を無効にしています。
解決方法
- SSH1 接続には RC4 暗号を使用しないでください。
接続のリダイレクト
CERT VU#684820
概要
SSH1 では、クライアントが不明なホスト鍵を受け入れた場合、クライアント認証が転送されてしまいます。
説明
I. 前提条件：
クライアントはサーバから不明なホスト鍵を受け入れます。
次の 3 つのホストがあります。
C - クライアント
M - 攻撃者によって制御された、悪意を持ったサーバ
S - 攻撃者がアクセスを試みているサーバ
暗号化が無効になっている場合：
クライアント C が M に接続を試み、これによって M は S に接続して公開ホスト鍵 (PubKeyS) を入手します。次に、M は PubKeyS を C に転送し、C では M 用のホスト鍵が変更されたことを示す警告ダイアログが表示されます。C の被害者がこの警告を無視して PubKeyS を受け入れた場合、クライアントの SSH1 ソフトウェアはセッション鍵 SessKeyC を生成します。この鍵は PubKeyS で暗号化されるので、S のみがこれを解読できます。しかし、C は暗号化を無効にする選択をしているので、このセッション鍵は実際にはいずれの場所でも使用されません。
これで、M は S に対するオープンな SSH1 接続を確立できましたが、まだ自らを認証する必要があります。S が M に対して RSA チャレンジ (ChalS-M) を提供すると、M はそのチャレンジを C に転送し、被害者はチャレンジに正しく答えます。この時点で、M は S に接続されて認証され、S 上にある被害者の任意のリソースにアクセスできるようになります。
暗号化が有効になっている場合：
攻撃は同様に行われますが、M はセッション鍵を所有している必要があります。そのために、M は PubKeyS から新しい鍵ペア (PubKeyS*、PrivKeyS*) を生成します。この操作は、S の公開鍵マテリアルから派生したセッション ID によって影響を受けません。M は、対象型の鍵 K での合意に使用される元のセッション ID とともに、PubKeyS ではなく PubKeyS* をクライアントに転送します。PubKeyS* は PubKeyS と同じセッション ID を作成するので、C とS は K とのネゴシエーションに成功します。しかし、M はこのセッション ID に一致する秘密 RSA 鍵の 1 つを所有しているので、これを傍受できます。
問題は、セッション ID によって、いわゆる偽の分割が許可されることにあります。つまり、セッション鍵とホスト鍵のモジュラスは、連結されたときに同じビット文字列を作成する擬似モジュラスを選択可能にする方法で連結されます。この擬似モジュラスがランダムに選択された場合、それらは 2 つのプライムの積ではないので、因数分解が格段に簡単になる可能性が高くあります。M は相手の秘密鍵を入手するために、擬似鍵の可能なペアの 1 つを選択して因数分解します。
II. 影響
攻撃者は、自らを被害者に認証させることができます。
解決方法
- この攻撃の影響を受けない SSH2 にアップグレードしてください。
- SSH1 を使用する場合、SSH1 接続用の不明なサーバ鍵の受け入れは慎重に行ってください。さらに、暗号化なしに SSH1 接続を試みないようにしてください。
- サーバでは、暗号化を無効にしている SSH1 接続は拒否してください。
CERT VU#684820
概要
SSH1 では、暗号化が無効になっている場合、クライアント認証が転送されてしまいます。
説明
悪意を持ったサーバを制御している攻撃者は、有効なクライアント情報を使用して、クライアントがアクセス権を持っている 2 番目のサーバにアクセスできます。
解決方法
- * 暗号化が無効になっている場合、SSH1 接続は試みないでください。サーバでは、暗号化を無効にしている SSH1 接続は拒否してください。
本書では、SSH1 でのセキュリティ上のいくつかの脆弱性について、概要を簡単に説明しました。さらに詳しい情報については、次の項に示された文書にある情報を参照してください。
レファレンス
"Fatal Vulnerabilities in SSH1," Antti Huima 著, SSH Communications Security Oyj.CERT vulnerability notes: http://www.kb.cert.org/vuls
© 2003 SSH Communications Security Corp. All rights reserved. ssh ® は、アメリカ合衆国及びその他の地域において、SSH Communications Security Corp の登録商標です。また、本文中に記載されている製品名は各社もしくは各団体の商標あるいは登録商標です。