スリープ後のMeterpreter SSLエラー
ペンテストでメタスプロイトを多用している間、私はsleep meterpreterコマンドの使用を開始します。これは永続化方法ではないことを理解していますが、非常に便利な場合もあります。
悲しいことに、セッションが起動すると、このエラーで接続を確立できません。
OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version
6つか7つのセッションをスリープ状態にすると、目が覚めてから1つまたは2つしか得られません。デッドセッションを愛する人はいません。
exploit/windows/smb/psexecおよびペイロードはwindows/x64/meterpreter/reverse_tcp。 TCPペイロードはhtHTTPpの代わりにSSL暗号化を使用することを知っていますが、失敗する理由を詳しく説明することはできません。
MSFバージョンはFramework: 4.12.23-dev-e403df5 Console : 4.12.23-dev-e403df5。
また、セッションがスリープしている間はmsfを更新しません。また、複数のセッションが1つのLPORTまたは複数のセッションにウェイクアップしても、違いはありません。
誰もがこの問題を解決するのを助けることができます、それはそれが非常に迷惑です。
OpenSSL::SSL::SSLError SSL_accept returned=1 errno=0 state=unknown state: tlsv1 alert protocol version
これは、ハンドシェイクの下のTCPストリームが壊れている場合の一般的なOpenSSL応答です。これが発生した時点でペンテストしていると言います。これにはネットワークセキュリティの意味合いがありますが、おそらく推測されるものではありません。最初に、この答えは、そのエラーを数回見ることに基づいた知識に基づく推測です。
セッションがスリープ状態の場合、キープアライブパケットは送信されません（つまり、追加のACKは送信されません）。このような「死んだ」TCP=セッションは、ファイアウォールが接続を有効（または無害）と見なすかどうかに関係なく、ステートフルなファイアウォールによって切断されます。侵入テストをしているので、複数のファイアウォールが配置されているネットワーク内で作業する。
ステートフルファイアウォールがこれを行うのはなぜですか？
今日、ステートレスファイアウォールはかなりの履歴*であるため、すべてのファイアウォールはステートフルであり、ファイアウォールを通過する各接続の状態（および履歴）を保持します。これは、NATだけでなく、ファイアウォールを通過するトラフィックに対しても実行されます。このようなステートフルなファイアウォールは、ハングしている接続を多く残し、メモリをいっぱいにすることにより、DoS攻撃に対して脆弱です。ステートフルファイアウォールにタイムアウトがあり、ハングした（タイムアウト中にトラフィックがない）接続がドロップされるのを防ぐため。
SSLセッションをウェイクアップすると、ACKが送信されます。しかし、ファイアウォールはその接続を長い間メモリから切断しており、TCPセッションの存在について無知なので、RSTで応答します。RSTはstate=unknown SSLレベルからのエラー。
ファイアウォールの反対側にあるシステムは、接続を認識していて、ACKが到達すると応答します。しかし、ファイアウォールはそれを通過させません。
あなたはそれについて何ができますか？
あまりない。自分のマシンでステートフルプロキシを実行すると、一方の側（外側）でTCPキープアライブを送信し続けますが、反対側（内側、ループバック）ではキープアライブを必要としません）。
しかし、たとえば、マシン全体をスリープ状態にした場合、ステートフルプロキシは、目的を達成するために余分なACKを送信することはありません（ファイアウォールのみの場合と比べて、接続のデバッグがさらに困難になります）。
*ステートレスファイアウォールは、最初のSYNパケットのIPフラグメンテーションなどのささいな攻撃（バイパス）に対して脆弱です。