微步の脆弱性警告情報を見て、nday の脆弱性の再現プロセスをゼロから記録しようと思いました。今回はコードレビューがほとんどなかったですが、それでも一つの経路として記録しておきます。
まず、警告情報を見てみましょう。
まず、キーワードを抽出します：accessToken デフォルト、application.properties で設定、認証をバイパスして executor を呼び出す
次に、xxl-job の公式リポジトリでこのファイルを探します。
このファイルは複数ありますが、ここでは xxl-job-admin を選びます。application.properties に accessToken の設定項目があり、その値は default_token です。properties は純粋な静的ファイルなので、何の構文変数も存在しないため、これらの文字列 "default_token" であることが確定しています。
さて、accessToken の値が確定したので、これがどのようにバイパスされるかを理解する必要があります。つまり、警告情報で言及されている executor です。
プロジェクトディレクトリを見ると、似たようなフォルダが見つかりました。
中を見てみましょう。
さらに 2 つあり、frameless と springboot が現れました。おそらく 2 つのバージョンまたはコンパイル方法の違いです。
ここで深入りするのは怖いです。理解していないと底なし沼にはまってしまう可能性があります。では最初に戻って、公式ドキュメントを見て、ソフトウェアアーキテクチャを理解するのに役立つ情報を見つけましょう。
ドキュメントからわかるように、xxl-job は実際には Docker のような C/S 構造であり、ミドルウェア / エージェントアーキテクチャのようなものです。スケジューラセンター（デフォルトポート 8080）は xxl-job-admin であり、エグゼキュータ（デフォルトポート 9999）は executor と呼ばれます。エグゼキュータはスケジューラセンターからの命令を受け取り、自身のマシンで実行して結果を返します。上位の指示を受けるためには、必ず認証が必要であり、その認証が accessToken です。
それでは、脆弱性の利用方法を大まかに理解しました。非常に簡単で、スケジューラセンターの命令リクエストをエグゼキュータに送信し、accessToken がデフォルトの場合、エグゼキュータを自分のバックドアとして使用できます。では、このリクエストの形式はどのようなものですか？最初はコードレベルで追跡しましたが、深く探ると複雑になるため、インターネットからアプローチを変えました。キーワードを検索してみましょう：xxl-job executor rce というキーワードで、以前の脆弱性を見つけました。
クリックして中を見ると、同じコンポーネントの同じ問題です。今回の場合、デフォルト値であり、この脆弱性では空値でした。日付を見てみると、2022 年に最初に再現分析が行われたようです。彼のペイロードを使えるでしょうか？
明らかに accessToken フィールドは言及されていません。おそらく、空値の場合はパラメータを送信する必要がないためです。しかし、別の情報を得ました。コンポーネント間のデータは RESTful API を介して送信されるため、このフィールドの形式はドキュメントに必ず記載されています。ドキュメントに戻って確認しましょう。
よし、これでリクエストパケットを構築するためにドキュメントに従って直接進めることができます。（glueType フィールドには他のタイプもあるかもしれませんので、bypass に有利かもしれません）
記事中のフィンガープリントも直接使えます。
すなわち：shodan request, HttpMethod not support.
つまり、ボディの内容は invalid request, HttpMethod not support です。
他の国産エンジンの構文は自分で構築してください。
次に、ターゲットを見つけて試してみましょう。
コマンドが正常に実行され、dnslog で取得できました。
デフォルト値が変更された場合は、次のようになります。
全体的にはこんな感じです。ただし、サーバーのエグゼキュータが機能しない場合があります。これは C/S アーキテクチャのためで、エージェントは必ずしも admin のマシン上にある必要はありません。これにより利用の成功率は低下しますが、ある意味で内部ネットワークの横断に一定の役割を果たします。
最後の小さなおまけ：
2022 年のエグゼキュータの未認証の脆弱性の後、公式はデフォルトでトークンを開始しました。しかし、彼らはハードコーディングされた固定値を使用して修正しました。つまり、この修正によりエグゼキュータがバイパスされるようになりました。修正されましたか？修正されたのか？
なぜこんなに簡単な脆弱性が 1 年も経ってから発覚したのかわかりません。
最後に：今回はコードレビューの観点から深く分析しませんでしたが、別のアプローチを指摘しました。ネットワーク検索と既知の脆弱性を上手に活用することは、しばしば近道です。