web-dev-qa-db-ja.com

SSHを介した攻撃の可能性

接続したいターゲットマシンTがあるとしましょう。 Tはプライベートネットワークにあるため、プロキシネットワークP（そのネットワークに接続されている）を介して接続する必要があります。このため、最初にPにsshし、そこからもう一度Tにsshします。

Pが悪意があると仮定しましょう。これは私のマシンMにとってどれほど危険なのでしょうか？可能な攻撃方向は何でしょうか？ PはMとTの間で何らかの [〜＃〜] mitm [〜＃〜] 攻撃を実行できますか？

attacksman-in-the-middlessh
1
Tomasz

このため、最初にPにsshし、そこからもう一度Tにsshします。

これを正しく解釈した場合は、Pにログインしてシェルを取得し、このシェル内からsshを実行します。 Pが危険にさらされている場合、期待されるシェルや期待されるsshバイナリではなく、期待される端末を取得することを信頼できません。すべてにバグがある可能性があります。つまり、実行するすべてのキーストローク（パスワードを含む）を傍受したり、すべての入出力を記録したり、送信前に変更したりできます。

6
Steffen Ullrich

Opensshを使用している場合（覚えていれば> 7.3）、これにはMITM機能がないことを保証するProxyJump機能があります。 （以前のバージョンでも同じことができますが、ProxyJumpを使用すると非常に便利になります。）

ssh -J me@P me@T

できました。

man sshのスニペットは次のとおりです：

-J destination
    Connect to the target Host by first making a ssh connection to the
    jump Host described by destination and then establishing a TCP
    forwarding to the ultimate destination from there.

クライアントは最初にジャンプホストに接続し、クライアントとターゲットのポート22の間に双方向パイプを確立するようジャンプホストに指示します。次に、クライアントはその双方向パイプを使用して、ターゲットとのssh接続を確立します。ジャンプホストはフェリーを実行しているだけです-「攻撃」は最悪の場合のサービス拒否に限定され、それ以上のものはありません。

Sshが「proxyjump」を追加する前は、次のようにします（以下の-fはメモリからのものです。それが-fか-Nだったかは思い出せません）：

ssh -f -L 2222:target:22 me@jumphost
ssh -p 2222 [email protected]

しかし、proxyjumpはそれをずっと簡単にします。

2
sitaram

まず、仮定：

  • それが許可されていると仮定します（許可されていない場合もあります）。
  • Tに保存されているPの正確な公開鍵があると仮定します（Sを通過しないチャネルを通じて取得する必要があります）。

これらの前提条件が満たされる場合、S（ソースシステム）とPの間にポートフォワードを確立して、SからTに直接接続することができます（コメント@sitaramに感謝）。次に、SからTに直接SSHで接続し、Tを公開鍵で検証します。また、Pが侵害される脆弱性はありません（接続がないか、安全な接続です。

コマンド：

S:> ssh -L 9999:T:22 Puser@P  # Don't use this Shell, but keep it running.
S:> ssh -p 9999 [email protected]  # Use this Shell

これにより、Pが信頼できない場合に説明した攻撃を軽減できます。ただし、TのSSHポートはマシンSのすべてのユーザーに公開されるため、注意して選択する必要があります。

2
Slartibartfast

関連する質問を見ていると、2つの重要な概念が見つかりました。

  1. SSHエージェント転送 （回答を参照 こちら ）。質問で述べたケースでは、悪意のあるマシンのルートPがMの秘密のsshキーを使用して他のサーバーで認証できます。

  2. X11 Forwarding （フラグ-X、つまりssh -X user@Hostを使用してsshを実行する場合）、ここでサーバーはクライアントマシンでコマンドを実行できます。

0
Tomasz