TLS 1.3に基づくドメインフロンティング。 パート2

導入

最初の部分で 記事 暗号化された SNI (eSNI) メカニズムについて簡単に説明しました。 彼らは、これに基づいて、最新の DPI システムによる検出を回避することがどのように可能であるかを示し (Beeline DPI と禁止されている RKN ルート トラッカーの例を使用して)、また、このメカニズムに基づいた新しいバージョンのドメイン フロント処理についても検討しました。

記事の後半では、RedTeam スペシャリストの難しい作業に役立つ、より実践的な内容に進みます。 結局のところ、私たちの目標は、ブロックされたリソースにアクセスすることではありません (そのような些細なことのために、古き良き VPN を使用します)。 幸いなことに、あらゆる好み、色、予算に合わせて、さまざまな VPN プロバイダーが存在します。

私たちは、ドメイン フロント メカニズムを最新の RedTeam ツール (たとえば、Cobalt Strike、Empire など) に適用し、最新のコンテンツ フィルタリング システムを模倣および回避する追加機能を提供することを試みます。

前回は、eSNI メカニズムを OpenSSL ライブラリに実装し、使い慣れたcurl ユーティリティでそれを使用することに成功しました。 しかし、よく言われるように、鶏一羽だけでは満足できません。 もちろん、同様のものを高級言語でも実装したいと考えています。 しかし、残念ながら、eSNI メカニズムのサポートが完全に実装されているのは GOLANG のみであるため、インターネットで簡単に検索してみるとがっかりしてしまいます。 したがって、私たちには選択肢があまりありません。パッチを適用した OpenSSL ライブラリを使用して純粋な C または C++ で記述するか、CloudFlare からの別の GOLANG フォークを使用してそこにツールを移植してみるかのどちらかです。 原理的には、Python の eSNI サポートを実装するという、より古典的ではありますが、同時に時間がかかる別のオプションがあります。 結局のところ、Python は https を処理するために OpenSSL も使用します。 しかし、このオプションは他の人による開発に残し、私たち自身は Golang での実装に満足します。特に、私たちの最愛の Cobalt Strike は、サードパーティ ツールによって構築された通信チャネル (外部 C2 チャネル) と完全に連携できるためです。 - これについては記事の最後で説明します。

もっと頑張って...

Go に実装されたツールの XNUMX つは、ネットワークにピボットするための開発であるトンネラーです。 rsockstunちなみに、これは現在、Microsoft と Symantec のツールによって、世界的な安定性を破壊することを目的とした非常に悪意のあるソフトウェアとして検出されています...

この場合にも以前の開発を使用するのは素晴らしいことです。 しかし、ここで小さな問題が発生します。 実際のところ、rsockstun は最初はサーバーとの同期 SSL 通信チャネルの使用を暗黙的に示しています。 これは、接続が一度確立されると、トンネルの動作中ずっと存在することを意味します。 そして、ご存知のとおり、https プロトコルはこの動作モードを対象としたものではありません。HTTP プロトコルは、新しい http リクエストがそれぞれ新しい tcp 接続内に存在する、リクエスト/レスポンス モードで動作します。

この方式の主な欠点は、クライアントが新しい http リクエストを送信するまで、サーバーがクライアントにデータを転送できないことです。 しかし、幸いなことに、この問題を解決するためのオプションは数多くあります。それは、http プロトコルを介したデータのストリーミングです (結局のところ、私たちはお気に入りのテレビ番組を見たり、https で実行されているポータルから音楽を聴いたりすることができますが、ビデオとオーディオを送信することは他のことではありません)ストリーミングデータより）。 HTTP プロトコルを介して本格的な TCP 接続の動作をエミュレートするテクノロジの XNUMX つは WebSocket テクノロジです。その主な本質は、クライアントと Web サーバー間の本格的なネットワーク接続を組織することです。

私たちにとって幸運なことに (万歳!!!)、このテクノロジーはすべての CloudFlare 料金プランにデフォルトで含まれており、eSNI と組み合わせてうまく機能します。 これはまさに、トンネラーにドメイン フロントを使用し、最新の DPI から隠すように教えるために使用するものです。

WebSocket について少し

まず最初に、WebSocket について簡単かつ簡単な言葉で説明し、誰もが何を扱うのかを理解できるようにします。

Websocket テクノロジーを使用すると、確立された TCP 接続を中断することなく、http 接続から標準ネットワーク ソケット ストリーミングに一時的に切り替えることができます。 クライアントが WebSocket に切り替える場合、http リクエストにいくつかの http ヘッダーを設定します。 XNUMX つの必須ヘッダー - 接続: アップグレード и アップグレード: WebSocket。 WebSocket プロトコルのバージョンを強制的に指定することもできます (Sec-Websockset-バージョン: 13) および Base64 WebSocket 識別子のようなもの (Sec-WebSocket-Key: DAGDJSiREI3+KjDfwxm1FA==）。 サーバーは http コード 101 スイッチング プロトコルで応答し、ヘッダーも設定します。 接続、アップグレード и Sec-WebSocket-Accept。 切り替えプロセスは、以下のスクリーンショットで明確に示されています。

この後、WebSocket 接続のインストールは完了したと見なされます。 クライアントとサーバーの両方からのデータは、http ではなく WebSocket ヘッダー (バイト 0x82 で始まる) で提供されるようになります。 これで、サーバーはクライアントからのデータ転送要求を待つ必要がなくなりました。 TCP 接続は切断されていません。

Golang には、WebSocket を操作するためのライブラリがいくつかあります。 その中で最も人気のあるのは、 ゴリラ WebSocket そして標準的な WebSocketの。 ここでは後者を使用します。なぜなら... それはよりシンプルで小さく、そして彼らが言うように、少し速く動作します。

rsockstun クライアント コードでは、net.dial または tls.dial 呼び出しを対応する WebSocket 呼び出しに置き換える必要があります。

トンネルのクライアント部分をユニバーサルにし、直接 SSL 接続と WebSockset プロトコルの両方で動作できるようにしたいと考えています。 このために別の関数を作成します func connectForWsSocks(アドレス文字列, プロキシ文字列) エラー {…} との類推によって connectForSocks() また、クライアントの起動時に指定されたサーバー アドレスが ws: または wss: (Secure WebSocket の場合) で始まる場合、Web ソケットを操作するためにそれを使用します。

トンネルのサーバー側については、Web ソケットを操作するための別の関数も作成します。 http クラスのインスタンスを作成し、http 接続ハンドラー (wsHandler 関数) を設定します。

そして、すべての接続処理ロジック (パスワードを使用したクライアント認証、yamux セッションのセットアップと終了) を WebSocket 接続ハンドラーに配置します。

プロジェクトをコンパイルし、サーバー部分を起動します。

./rsockstun –listen ws:127.0.0.1:8080 –pass P@ssw0rd

そしてクライアント部分は次のようになります。

./rsockstun -connect ws:127.0.0.1:8080 –pass P@ssw0rd

そして、ローカルホストでの動作を確認します。

ドメインのフロンティングに移りましょう

WebSocket を理解したようです。 ここで、eSNI とドメイン フロントに直接移りましょう。 前述したように、DoH および eSNI と連携するには、会社から特別な golang ブランチを取得する必要があります。 CloudFlareの。 eSNI をサポートするブランチ (pwu/esni) が必要です。

ローカルにクローンを作成するか、対応する zip をダウンロードして解凍します。

git clone -b pwu/esni https://github.com/cloudflare/tls-tris.git

次に、GOROOT ディレクトリをコピーし、クローンされたブランチから対応するファイルを置き換えて、それをマスターとして設定する必要があります。 開発者をこの頭痛の種から救うために、CloudFlare のスタッフは特別なスクリプト - _dev/go.sh を用意しました。 ただ起動するだけです。 スクリプトとメイクファイルは、すべてを自動的に実行します。 楽しみのために、Makefile 内で詳細を確認してください。

スクリプトを実行した後、プロジェクトをコンパイルするときに、スクリプトによって準備されたローカル ディレクトリを GOROOT として指定する必要があります。 私たちの場合は次のようになります。

GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" go build ….

次に、目的のドメインの公開 eSNI キーを要求して解析する機能をトンネルに実装する必要があります。 私たちの場合、これらは CloudFlare フロントエンド サーバーからの公開 eSNI キーになります。 これを行うために、次の XNUMX つの関数を作成します。

func makeDoTQuery(dnsName string) ([]byte, error)
func parseTXTResponse(buf []byte, wantName string) (string, error)
func QueryESNIKeysForHost(hostname string) ([]byte, error)

原則として、関数の名前自体がそれを物語っています。 tls-tris の一部である esni_query.go ファイルからコンテンツを取得します。 最初の関数は、DoH (DNS-over-HTTPS) プロトコルを使用して CloudFlare DNS サーバーへのリクエストを含むネットワーク パケットを作成し、XNUMX 番目の関数はクエリ結果を解析してドメインの公開キーの値を取得します。XNUMX 番目の関数は、最初の XNUMX つのコンテナ。

次に、新しく作成した関数に Web ソケット接続を追加します。 ConnectForWsソックス ドメインの eSNI キーを要求する機能。 サーバー部分が動作するところでは、TLS パラメーターを設定し、偽の「カバー ドメイン」の名前も設定します。

ここで、当初、tls-tris ブランチはドメイン フロントを使用するように設計されていなかったことに注意してください。 したがって、偽のサーバー名には注意を払いません (空のサーバー名フィールドが client-hello パケットの一部として送信されます)。 これを修正するには、対応する FakeServerName フィールドを TlsConfig 構造に追加する必要があります。 構造体の標準の ServerName フィールドは使用できません。 これは内部 TLS メカニズムによって使用され、元のメカニズムと異なる場合、TLS ハンドシェイクはエラーで終了します。 TlsConfig 構造の説明はファイルに含まれています tls/common.go - それを修正しなければなりません:

さらに、ファイルに変更を加える必要があります tls/handshake_client.goTLS ハンドシェイクを形成するときに FakeServerName フィールドを使用するには、次のようにします。

それだけです！ プロジェクトをコンパイルして動作を確認できます。 ただし、スキャンを実行する前に、CloudFlare アカウントを設定する必要があります。 そうですね、セットアップを何と言いますか。cloudflare でアカウントを作成し、ドメインをそれにリンクするだけです。 DoH、WebSocket、ESNI に関連するすべての機能は、デフォルトで CloudFlare に含まれています。 DNS レコードが更新された後、eSNI キーをクエリしてドメインの動作を確認できます。

dig +short txt _esni.df13tester.info 

ドメインに同様のものが表示された場合は、すべてがうまく機能していることを意味し、テストに進むことができます。

打ち上げ Ubuntu 例えば、DigitalOceanのVPSなどです。追記：私たちの場合は、プロバイダーから受け取ったばかりのVPSのIPアドレスがRoskomnadzorのブラックリストに載ってしまいました。ですから、あなたにも同じようなことが起こっても驚かないでください。私はVPNを使ってVPSにアクセスする必要がありました。

コンパイル済みの rsockstun を VPS にコピーし (ちなみに、これは Golang のもう XNUMX つの利点です。プロジェクトを自分でコンパイルし、システムのビット容量のみを観察して任意の Linux 上で実行できます)、サーバー部分を起動します。

そしてクライアント部分は次のようになります。

ご覧のとおり、クライアントは WebSocket を使用して CloudFlare フロントエンド サーバー経由でサーバーに正常に接続しました。 トンネルがトンネルとまったく同じように機能することを確認するには、サーバー上で開いているローカルの Socks5 を通じてカール リクエストを作成します。

次に、DPI が通信チャネルで何を認識するかを見てみましょう。

まず、トンネラーは DoH メカニズムを使用して Cloudflare DNS サーバーに接続して宛先ドメインの eSNI キー (パケット番号 1 ～ 19) を取得し、次にフロントエンド サーバーに接続して TLS 接続を確立し、ドメインの背後に隠れます。 www.google.com (これは、クライアントの起動時に偽のドメインが指定されていない場合のデフォルト値です)。 偽のドメインを指定するには、-fronfDomain パラメーターを使用する必要があります。

さて、もう一つ。 デフォルトでは、CloudFalre アカウント設定はフレキシブル SSL に設定されています。 これは、クライアントからCloudflareフロントエンドサーバーへのhttpsリクエストが暗号化されずに（http）サーバーに転送されることを意味します。 このため、トンネルのサーバー部分を ( -listen wss:0.0.0.0) ではなく、非 SSL モード ( -listen ws:0.0.0.0) で起動しました。

完全暗号化モードに切り替えるには、次の項目を選択する必要があります。 フルまたは フル（厳密） サーバー上に実際の証明書がある場合。 モードを切り替えると、https プロトコルを使用して CloudFlare からの接続を受け入れることができるようになります。 トンネルのサーバー側の自己署名証明書を生成することを忘れないでください。

好奇心旺盛な読者はこう尋ねるだろう。「クライアントはどうなるのか？」 Windows「結局のところ、トンネラーの主な用途はおそらく企業のマシンやサーバーからバックエンド接続を確立することであり、それらは通常常にWindowsです。Windows、特に特定のTLSスタックでトンネラーをコンパイルするにはどうすればよいでしょうか？」ここで、Golangがいかに便利であるかを示すもう1つの機能を紹介します。KaliからGOOS=windowsパラメータを追加するだけで、Windows向けに直接コンパイルできます。

GOARCH=amd64 GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" GOOS=windows  go build -ldflags="-s -w"

または 32 ビット バージョン:

GOARCH=386 GOROOT="/opt/tls-tris/_dev/GOROOT/linux_amd64" GOOS=windows  go build -ldflags="-s -w"

全て！ そして、これ以上の面倒なことは必要ありません。 それは実際に動作します！

–w および –s コンパイラ フラグは、実行可能ファイルから不要なガベージを削除してファイルを数メガバイト小さくするために必要です。 さらに、UPX を使用してパッケージ化してサイズをさらに縮小することもできます。

代わりに、結論の

この記事では、Golang で書かれたトンネルの例を使用して、TLS 1.3 プロトコルの興味深い機能に実装された新しいドメイン フロント テクノロジの使用を明確に示しました。 同様の方法で、Golang で書かれた既存のツールを CloudFlare サーバー経由で動作するように適応させることができます。 マーリン - 有名な C2、または Teamserver 経由で作業するときに CobaltStrike Beacon に eSNI ドメイン フロントを使用させる 外部 C2 チャネル、Golang、または記事の最後の部分で説明した OpenSSL のパッチ適用済みバージョンを使用する標準 C++ で実装されます。 一般に、想像力には制限がありません。

トンネラーと CloudFlare の例は概念の形で示されていますが、このタイプのドメイン フロントの長期的な見通しについて言うのはまだ困難です。 現時点では、CloudFlare のみが eSNI をサポートしており、理論上、この種のフロンティングを無効にすることや、たとえば SNI と eSNI が一致しない場合に TLS 接続を切断することを妨げるものはありません。 一般的には、将来が教えてくれます。 しかし今のところ、「kremlin.ruの隠れ蓑」の下で働くという見通しは非常に魅力的に見える。 そうではありませんか？

更新されたトンネラー コードとコンパイルされた実行可能 exe ファイルは、次のプロジェクトの別のブランチにあります。 githubの。 GitHub のプロジェクト ページに、考えられるすべてのトンネラーの問題に関する問題を書くことをお勧めします。

出所： habr.com