次の方法で共有


コールバック (RPC)

多くの場合、プログラミング モデルでは、リモート プロシージャ コール (RPC) または信頼されていないサーバーへのクライアント呼び出しを介してクライアントへのサーバー コールバックが必要になります。 これにより、多くの潜在的な落とし穴が発生します。

まず、十分に低い偽装レベルでクライアントへのコールバックを行う必要があります。 サーバーが高い特権を持つシステム サービスの場合、偽装レベル以上のローカル クライアントを呼び戻すと、システムを引き継ぐのに十分な特権をクライアントに提供できます。 必要以上に権限借用レベルの高いリモート クライアントを呼び戻すと、望ましくない結果になる可能性もあります。

第 2 に、攻撃者がコールバックを実行するようにサービスを誘導した場合、 ブラック ホール (サービス拒否攻撃) と呼ばれるものを起動できます。 このような攻撃は RPC に固有のものではありません。これらの攻撃では、マシンはトラフィックを送信するように誘導しますが、要求には応答しません。 あなたはブラックホールを呼び出すことにますます多くのリソースをシンクしますが、それらは戻って来ることはありません。 このような攻撃の一般的な例の 1 つは、TCP/IP SYN フラッド攻撃と呼ばれる TCP レベルの攻撃です。

RPC レベルでは、攻撃者がインターフェイスを呼び出し、サーバーにインターフェイスを呼び戻すように要求すると、単純なブラックホール攻撃が発生します。 インターフェイスは準拠していますが、攻撃者は呼び出しを返しません。サーバー上の 1 つのスレッドが関連付けられています。 攻撃者はこれを 100 回実行し、サーバー上で 100 スレッドを関連付けます。 最終的にサーバーのメモリが不足します。 サーバーをデバッグすると、ブラックホール呼び出し元の ID が表示される可能性がありますが、多くの場合、ファウル プレイを疑わずにサーバーが再起動されるか、攻撃者を特定するのに十分な専門知識がない可能性があります。

3 つ目の落とし穴はクライアントにあります。 多くの場合、クライアントはサーバーに対して呼び出しを行い、サーバーからの呼び出し (通常は文字列バインディング) をサーバーに通知し、サーバーからの呼び出しが到着するまで待機し、サーバーからの呼び出しを要求するそのエンドポイントの呼び出しを盲目的に受け入れます。 サーバーからクライアントへのコールバック プロトコルには、コールバックがクライアントに来たときに実際にサーバーで発生したことを確認するための検証メカニズムが含まれている必要があります。