Skip to content
KitploitKITPLOIT
उपकरणब्लॉग
जमा करें
उपकरणब्लॉग
जमा करें

हैकिंग, पेनटेस्ट और साइबर सुरक्षा उपकरण आपके सुरक्षा शस्त्रागार के लिए!

Kitploit हैकिंग, साइबर सुरक्षा और पेंटेस्टिंग टूल्स की एक निर्देशिका है। कमजोरियों को खोजने, सिस्टम का विश्लेषण करने, परीक्षण को स्वचालित करने और अपनी सुरक्षा को मजबूत करने के लिए नवीनतम प्रोजेक्ट अपडेट खोजें।

··फ़ीड·संपर्क·गोपनीयता·© 2026 Kitploit

टूल निर्देशिका

श्रेणियाँ

सभी श्रेणियाँ देखें
Loading categories
PrestaShop-CVE-2018-19126 — PrestaShop (1.6.x <= 1.6.1.23 या 1.7.x <= 1.7.4.4) बैक ऑफिस रिमोट कोड निष्पादन (CVE-2018-19126) | Kitploit
उपकरण/GitHubGitHub/farisv/prestashop-cve-2018-19126
भेद्यता विश्लेषणशोषणवेब एप्लिकेशन शोषणपेनिट्रेशन टेस्टिंगलर्निंग और शिक्षापेलोड डेवलपमेंट
GitHubfarisv/prestashop-cve-2018-19126

PrestaShop-CVE-2018-19126

PrestaShop (1.6.x <= 1.6.1.23 या 1.7.x <= 1.7.4.4) बैक ऑफिस रिमोट कोड निष्पादन (CVE-2018-19126)

रिपॉजिटरी देखें
39107 साल पहलेKitploit द्वारा समीक्षित

सबसे लोकप्रिय

सभी देखें →

हमारे समुदाय द्वारा सबसे अधिक उपयोग किए जाने वाले उपकरण खोजें।

सभी उपकरण खोजें

हमारे उपकरणों का संग्रह ब्राउज़ करें

सभी उपकरण देखें →
साझा करें

PrestaShop बैक ऑफिस रिमोट कोड निष्पादन (CVE-2018-19126)

यह CVE-2018-19126 के लिए PoC है, जो PrestaShop बैक ऑफिस में कई कमजोरियों को जोड़कर phar के माध्यम से deserialization को ट्रिगर करता है ताकि दूरस्थ कोड निष्पादन प्राप्त किया जा सके।

पूर्वापेक्षा:

  • PrestaShop 1.6.x जो 1.6.1.23 से पहले या 1.7.x जो 1.7.4.4 से पहले।
  • बैक ऑफिस खाता (लॉजिस्टिक्स विशेषज्ञ, अनुवादक, विक्रेता, आदि)।

PrestaShop रिलीज़ नोट: http://build.prestashop.com/news/prestashop-1-7-4-4-1-6-1-23-maintenance-releases/

कमजोर पैकेज लिंक: https://assets.prestashop2.com/en/system/files/ps_releases/prestashop_1.7.4.3.zip

चेतावनी

केवल शैक्षणिक उद्देश्यों के लिए। इस स्क्रिप्ट का उपयोग अवैध गतिविधियों के लिए न करें। लेखक किसी भी दुरुपयोग या क्षति के लिए जिम्मेदार नहीं है।

उदाहरण

आपको एक्सप्लॉइट चलाने के लिए php की आवश्यकता है जिसमें curl एक्सटेंशन हो और php.ini में phar.readonly = Off सेट हो।

root@kitploit:~
# Download repository
wget https://github.com/farisv/PrestaShop-CVE-2018-19126/archive/master.zip -O PrestaShop-CVE-2018-19126.zip
unzip PrestaShop-CVE-2018-19126.zip
cd PrestaShop-CVE-2018-19126-master

# Run the exploit
# Usage: php exploit.php back-office-url email password func param
php exploit.php http://127.0.0.1/admin-dev/ [email protected] 54l35m4n123 system 'cat /etc/passwd'

ध्यान दें कि अपलोड निर्देशिका का नाम बदल दिया जाएगा और यदि फ़ोल्डर का नाम वापस नहीं बदला गया तो आप दुर्भावनापूर्ण phar फ़ाइल को फिर से अपलोड नहीं कर सकते। हो सकता है कि आप स्थायी RCE प्राप्त करने के लिए रिवर्स शेल निष्पादित करना चाहें या अपने पेलोड में फ़ोल्डर का नाम वापस बदलने का कमांड शामिल करना चाहें (आपको अपलोड निर्देशिका का पथ जानना होगा)।

स्पष्टीकरण

हम [back-office-path]/filemanager/ajax_calls.php में getimagesize() फ़ंक्शन के माध्यम से phar रैपर के साथ अंतर्निहित deserialization प्राप्त कर सकते हैं।

https://github.com/PrestaShop/PrestaShop/commit/4c6958f40cf7faa58207a203f3a5523cc8015148#diff-0f03d65f71cdd8eeb12913a97a6b8945

root@kitploit:~
case 'image_size':
    if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
        die();
    }
    $pos = strpos($_POST['path'], $upload_dir);
    if ($pos !== false) {
        $info = getimagesize(substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir)));
        echo json_encode($info);
    }

हमें ऐसा तरीका खोजने की आवश्यकता है जिससे कुछ जांचों को बायपास करके getimagesize() को phar रैपर URL के साथ पैरामीटर के रूप में कॉल किया जाए।

realpath() के साथ पहली जांच काफी सख्त है।

root@kitploit:~
if (realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) != realpath(_PS_ROOT_DIR_.$upload_dir)) {
    die();
}

$upload_dir चर config.php से आता है, जो डिफ़ॉल्ट रूप से $upload_dir = Context::getContext()->shop->getBaseURI().'img/cms/'; पर सेट है। हम $_POST['path'] में phar://[string] का उपयोग नहीं कर सकते क्योंकि realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) false लौटाएगा क्योंकि यह मौजूद नहीं है।

एक और कमजोरी मौजूद है (CVE-2018-19125) जो उपयोगकर्ता को $upload_dir को हटाने या नाम बदलने की अनुमति देती है। यदि $upload_dir निर्देशिका मौजूद नहीं है, तो realpath(_PS_ROOT_DIR_.$upload_dir) false लौटाएगा और हम इस जांच को बायपास कर सकते हैं क्योंकि realpath(dirname(_PS_ROOT_DIR_.$_POST['path'])) भी false है। यह कमजोरी कोड समीक्षा के दौरान खोजी गई थी जब बायपास करने का तरीका खोजने की कोशिश की जा रही थी :)।

संक्षेप में, CVE-2018-19125 execute.php में delete_folder या rename_folder क्रिया के कॉल में path पैरामीटर को खाली रहने देता है, जिससे एप्लिकेशन इसके बजाय $upload_dir को हटा/नाम बदल देगा।

दूसरी जांच सरल है, $_POST['path'] में $upload_dir होना आवश्यक है।

root@kitploit:~
$pos = strpos($_POST['path'], $upload_dir);
if ($pos !== false) {

हम phar URL में फ़ाइल पथ के बाद /img/cms/ जोड़ सकते हैं क्योंकि यदि निर्देशिका phar आर्काइव के अंदर मौजूद नहीं है, तब भी deserialization होता है। substr_replace($_POST['path'], $current_path, $pos, strlen($upload_dir)) केवल /img/cms/ को उस फ़ोल्डर के पूर्ण पथ ($current_path) से बदल देगा (जैसे, /var/www/html/img/cms/ यदि एप्लिकेशन /var/www/html/ में स्थापित है)।

क्योंकि हम getimagesize() फ़ंक्शन को phar रैपर URL प्रोसेस करने के लिए नियंत्रित कर सकते हैं, हमें सर्वर पर दुर्भावनापूर्ण phar फ़ाइल अपलोड करने की आवश्यकता है। डिफ़ॉल्ट रूप से, PrestaShop में FileManager केवल 'jpg', 'jpeg', 'png', 'gif', 'bmp', 'tiff', 'svg', 'pdf', 'mov', 'mpeg', 'mp4', 'avi', 'mpg', 'wma', 'flv', और 'webm' को एक्सटेंशन के रूप में अनुमति देता है। हम पेलोड तैयार कर सकते हैं और इसे मान्य एक्सटेंशन के साथ सहेज सकते हैं। हम PHPGGC (https://github.com/ambionics/phpggc/blob/master/gadgetchains/Monolog/RCE/1/) से Monolog गैजेट चेन का उपयोग कर सकते हैं क्योंकि इसका उपयोग PrestaShop द्वारा किया जाता है।

अंतिम शोषण चरण:

  1. दुर्भावनापूर्ण phar फ़ाइल तैयार करें और मान्य एक्सटेंशन (जैसे phar.pdf) के साथ सहेजें।
  2. phar.pdf को FileManager पर अपलोड करें।
  3. अपलोड निर्देशिका का नाम बदलने के लिए कमजोरी को ट्रिगर करें (जैसे renamed)।
  4. path पैरामीटर के रूप में phar://../../img/renamed/phar.pdf/img/cms/ के साथ image_size क्रिया को कॉल करें।
  5. phar.pdf में deserialization पेलोड निष्पादित होगा।

exploit.php स्क्रिप्ट स्वचालित रूप से सभी चरण करेगी।

याद रखें कि चरण 3 में अपलोड निर्देशिका का नाम बदल दिया गया है और यदि फ़ोल्डर का नाम वापस नहीं बदला गया तो आप दुर्भावनापूर्ण phar फ़ाइल को फिर से अपलोड नहीं कर सकते। हो सकता है कि आप पेलोड के रूप में रिवर्स शेल का उपयोग करना चाहें या पेलोड में फ़ोल्डर का नाम वापस बदलने का कमांड शामिल करना चाहें (आपको अपलोड निर्देशिका का पथ जानना होगा)।

टूल डाउनलोड करें