CVE-2024-42327 zabbix भेद्यता राइटअप

लक्ष्य: 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 में संबोधित किया जाएगा।

CVE-2024-42327 का शोषण

CUser क्लास में स्रोत कोड का फिर से विश्लेषण करते हुए, हम पंक्ति 68 पर user.get फ़ंक्शन की जाँच करते हैं। पंक्ति 108 में निम्नलिखित कोड के साथ एक जाँच है: