mpgn/poodle-poc🐩 Poodle (Padding Oracle On Downgraded Legacy Encryption) हमला CVE-2014-3566 🐩
यह Poodle Attack (Padding Oracle On Downgraded Legacy Encryption) का एक proof of concept है :
एक man-in-the-middle शोषण जो Internet और सुरक्षा सॉफ़्टवेयर क्लाइंट्स के SSL 3.0 पर वापस जाने (fallback) का लाभ उठाता है
Poodle हमला आपको उस एन्क्रिप्टेड डेटा को प्राप्त करने की अनुमति देता है जो क्लाइंट द्वारा सर्वर को भेजा गया है, यदि उपयोग की गई Transport Layer Security SSLv3 है। यह आपको अनुरोध को एन्क्रिप्ट करने के लिए उपयोग की गई private key प्राप्त करने की अनुमति नहीं देता है।
SSLv3 आपके डेटा को एन्क्रिप्ट/डिक्रिप्ट और सुरक्षित करने का एक प्रोटोकॉल है। हमारे मामले में, यह CBC सिफर मोड चेनिंग का उपयोग करता है। प्लेनटेक्स्ट को एन्क्रिप्शन एल्गोरिदम (AES, DES, 3DES) के अनुसार ब्लॉकों में विभाजित किया जाता है और लंबाई 8 या 16 की गुणज होती है। यदि प्लेनटेक्स्ट लंबाई को नहीं भरता है, तो लापता स्थान को पूरा करने के लिए अंत में पैडिंग जोड़ा जाता है। मैं दृढ़ता से सलाह देता हूं कि इस readme को पढ़ने के लिए आप एन्क्रिप्शन और डिक्रिप्शन की इन छवियों को खोलें।
| एन्क्रिप्शन | डिक्रिप्शन |
|---|---|
| Ci = Ek(Pi ⊕ Ci-1), and C0 = IV | Pi = Dk(Ci) ⊕ Ci-1, and C0 = IV |
मूल रूप से यह कुछ सरल XOR है, आप यह वीडियो भी देख सकते हैं (मैं नहीं) https://www.youtube.com/watch?v=0D7OwYp6ZEc।
SSLv3 का उपयोग करके HTTPS पर भेजा गया अनुरोध AES/DES और CBC मोड के साथ सिफर किया जाएगा। TLS1.x की तुलना में SSLv3 की विशेषता पैडिंग है। SSLv3 में पैडिंग random बाइट्स से भरी जाती है, सिवाय अंतिम बाइट के जो पैडिंग की लंबाई के बराबर होती है।
T|E|X|T|0xab|0x10|0x02 जहां 0xab|0x10|0x02 पैडिंग है।
T|E|X|T|E|0x5c|0x01 जहां 0x5c|0x01 पैडिंग है।
इसके अलावा अंतिम ब्लॉक को पूरे पैडिंग ब्लॉक से भरा जा सकता है, जिसका मतलब है कि अंतिम ब्लॉक अंतिम बाइट को छोड़कर random बाइट्स से भरा हो सकता है।
T|E|X|T|E|0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 जहां |0x5c|0x01|0x3c|0x09|0x5d|0x08|0x04|0x07 पैडिंग है और केवल 0x07 हमलावर को ज्ञात है। इसलिए यदि कोई हमलावर पैडिंग ब्लॉक को प्रभावित करने में सक्षम है, तो वह जान सकेगा कि अंतिम ब्लॉक का अंतिम बाइट एक ब्लॉक की लंबाई के बराबर है।
एक हमलावर को पीड़ित से अनुरोध भेजने में सक्षम होना चाहिए (उदाहरण के लिए XSS का शोषण करके javascript का उपयोग करके)। फिर वह प्रत्येक अनुरोध के path और data को नियंत्रित कर सकता है:
उदाहरण: अनुरोध के path में "A" बाइट जोड़ना
GET / HTTP/1.1\r\nSECRET COOKIE\r\n\r\n
GET /AAA HTTP/1.1\r\nSECRET COOKIE\r\n\r\nDATA
इस तकनीक से वह पैडिंग को प्रभावित कर सकता है।
SSLv3 प्लेनटेक्स्ट की अखंडता (integrity) की जांच करने और प्रमाणित करने के लिए HMAC का भी उपयोग करता है।
keyed-hash message authentication code (HMAC) एक विशिष्ट प्रकार का message authentication code (MAC) है जिसमें एक गुप्त cryptographic key के साथ एक cryptographic hash function (इसलिए 'H') शामिल होता है
इसके साथ, कोई हमलावर अनुरोध को रोककर बदल नहीं सकता और फिर उसे वापस नहीं भेज सकता। यदि सर्वर को कोई समस्या आती है, तो वह HMAC त्रुटि भेजेगा।
प्रोटोकॉल SSLv3 निम्नलिखित प्रक्रिया का उपयोग करता है: वह क्लाइंट से डेटा प्राप्त करता है, डेटा को डिक्रिप्ट करता है, HMAC के साथ अखंडता की जांच करता है।
MAC-then-Encrypt: सिफरटेक्स्ट पर कोई अखंडता प्रदान नहीं करता है, क्योंकि जब तक हम संदेश को डिक्रिप्ट नहीं करते, हम यह जानने का कोई तरीका नहीं रखते कि यह वास्तव में प्रामाणिक था या नकली। प्लेनटेक्स्ट अखंडता। यदि सिफर योजना परिवर्तनशील (malleable) है, तो संदेश को बदलकर वैध दिखाना और वैध MAC रखना संभव हो सकता है। यह निश्चित रूप से एक सैद्धांतिक बिंदु है, क्योंकि व्यावहारिक रूप से बोलते हुए MAC secret > को सुरक्षा प्रदान करनी चाहिए। यहां, MAC प्लेनटेक्स्ट के बारे में भी कोई जानकारी नहीं दे सकता, क्योंकि यह एन्क्रिप्टेड है।
https://crypto.stackexchange.com/questions/202/should-we-mac-then-encrypt-or-encrypt-then-mac
इसका मतलब है कि हम सर्वर को जाने बिना सिफर किए गए टेक्स्ट को बदल सकते हैं। यह बहुत बढ़िया है, सच में :)
सबसे पहले अंतिम ब्लॉक को पैडिंग से भरा होना चाहिए, जैसा कि हमने पहले देखा, हमलावर अनुरोध के path का उपयोग करता है और अनुरोध की लंबाई की जांच करता है।
चूंकि अंतिम ब्लॉक अंतिम बाइट को छोड़कर random बाइट्स से भरा होता है, वह इस अंतिम ब्लॉक Cn को उस ब्लॉक Ci से बदल सकता है जिसे वह डिक्रिप्ट करना चाहता है। परिवर्तित अनुरोध सर्वर को भेजा जाता है।
सर्वर :
अंतिम ब्लॉक को बदलकर, हमलावर अंतिम ब्लॉक के अंतिम बाइट (पैडिंग की लंबाई) को भी बदल देता है। 1/256 संभावना है कि पैडिंग ब्लॉक में बदला गया अंतिम बाइट मूल के समान है, इस स्थिति में कोई पैडिंग त्रुटि नहीं होगी और हमलावर निम्नलिखित ऑपरेशन के माध्यम से ब्लॉक Ci का अंतिम बाइट प्राप्त करने के लिए इस XOR ऑपरेशन का उपयोग कर सकता है:
Pn = Dk(Cn) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
Pn = Dk(Ci) ⊕ Cn-1
xxxxxxx7 = Dk(Ci) ⊕ Cn-1
Dk(Ci) = xxxxxxx7 ⊕ Cn-1
Pi ⊕ Ci-1 = xxxxxxx7 ⊕ Cn-1
Pi = Ci-1 ⊕ xxxxxxx7 ⊕ Cn-1
(xxxxxxx7 या xxxxxxx15 और x random बाइट)
ब्लॉक का अंतिम बाइट प्राप्त किया जा सकता है Pi[7] = Ci-1[7] ⊕ xxxxxxx7 ⊕ Cn-1[7] पैडिंग के मामले में हमलावर को एक और handshake (नई AES कुंजी) करने के लिए SSL सत्र बंद करने की आवश्यकता होती है और नया सिफर प्राप्त करके अंतिम ब्लॉक को बदलना होता है आदि। (सामान्यतः +300 handshake की आवश्यकता होती है)
एक बार एक बाइट प्राप्त हो जाने पर, वह path में एक बाइट जोड़कर और data से एक बाइट हटाकर ब्लॉक के बाकी सभी बाइट प्राप्त कर लेगा:
| बाइट E,I,K,O प्राप्त करने के लिए अनुरोध |
|---|
| GET /a SECRET_COOKIE dataazerty PADDING_7 |
| GET /aa SECRET_COOKIE dataazert PADDING_7 |
| GET /aaa SECRET_COOKIE dataazer PADDING_7 |
| GET /aaaa SECRET_COOKIE dataaze PADDING_7 |
भले ही TLS विनिर्देशों के अनुसार सर्वरों को पैडिंग की जांच करनी आवश्यक है, कुछ implementations इसे सही ढंग से मान्य नहीं करते, जिससे कुछ सर्वर SSL 3.0 को अक्षम करने पर भी POODLE के प्रति असुरक्षित हो जाते हैं
TLS सामान्यतः Poodle से सुरक्षित है, लेकिन कुछ implementations पैडिंग की जांच नहीं करते, यह ऐसा है जैसे हम SSLv3 का उपयोग कर रहे हों, इसीलिए कुछ TLS संस्करण असुरक्षित हैं।
इस repository में तीन फ़ाइलें हैं:
यह poc हमले के पीछे की क्रिप्टोग्राफी का पता लगाता है। यह फ़ाइल हमें यह समझने की अनुमति देती है कि हमला सरल तरीके से कैसे काम करता है।
python3 poodle-poc.py
फ़ाइल parallelization-poodle.py एक प्रोजेक्ट और विचार है :) देखें https://github.com/mpgn/poodle-PoC/issues/1
python3 parallelization-poodle.py
यह असली exploit है। यह वास्तव में उपयोगी है यदि आप किसी क्लाइंट के लिए pentest के दौरान Poodle Attack के बारे में proof of concept बनाना चाहते हैं, यदि उसने पुराने सर्वर और ब्राउज़र का उपयोग किया है। बस अपने malicious proxy का IP सही port के साथ ब्राउज़र कॉन्फ़िगरेशन में डालें, बाकी का ध्यान proxy रखेगा।
आवश्यकताएँ:
security.tls.version.min: 0 का उपयोग करके केवल SSLv3 को बलपूर्वक लागू करें। वैकल्पिक रूप से, यदि क्लाइंट TLS का भी उपयोग करता है, तो आप downgrade को बलपूर्वक लागू कर सकते हैं
💀 यदि आपके पास ये पूर्वापेक्षाएँ हैं तो आप हमला शुरू कर सकते हैं 💀:
इस exploit के लिए दो विकल्प उपलब्ध हैं:
$> echo 1 > /proc/sys/net/ipv4/ip_forward
$> iptables -i vmnet1 -t nat -A PREROUTING -p tcp --dport 1337 -j REDIRECT --to-ports 1337
arpspoof, ettercap या bettercap टूल का उपयोग करें$> bettercap -iface vmnet1
net.show
set arp.spoof.internal true
arp.spoof on
⋊> ~/T/poodle-Poc on master ⨯ python3 poodle-exploit.py -h 13:10:24
usage: poodle-exploit.py [-h] [--start-block START_BLOCK]
[--stop-block STOP_BLOCK] [--simpleProxy SIMPLEPROXY]
proxy port server rport
Poodle Exploit by @mpgn_x64
positional arguments:
proxy ip of the proxy
port port of the proxy
server ip of the remote server
rport port of the remote server
optional arguments:
-h, --help show this help message and exit
--start-block START_BLOCK
start the attack at this block
--stop-block STOP_BLOCK
stop the attack at this block
--simpleProxy SIMPLEPROXY
Direct proxy, no ARP spoofing attack
$> python3 poodle-exploit.py 192.168.13.1 4443 192.168.13.133 443 --start-block 46 --stop-block 50
ब्लॉक चुनना: यदि आप block विकल्प निर्दिष्ट नहीं करते हैं, तो सभी ब्लॉक डिक्रिप्ट हो जाएंगे लेकिन इसमें लंबा समय लग सकता है। मैं दृढ़ता से सलाह देता हूं कि आप जानें कि अनुरोध कैसे स्वरूपित होगा और यह जानने के लिए request-splitter.py स्क्रिप्ट का उपयोग करें कि आप कौन सा ब्लॉक डिक्रिप्ट करना चाहते हैं (आदर्श रूप से cookie ब्लॉक! :)
फिर उदाहरण के लिए XSS का उपयोग करके असुरक्षित वेबसाइट में javascript malicious कोड (poodle.js) डालें। Python स्क्रिप्ट चलाएं और help टाइप करें, फिर search, और अंत में active। उस दौरान, javascript के साथ केवल दो इंटरैक्शन की आवश्यकता होगी (search और active कमांड)।
अपडेट 01/04/2018: exploit में downgrade विकल्प जोड़ा गया है। जब exploit TLS प्रोटोकॉल का पता लगाता है, तो SSLv3.0 पर downgrade करने के लिए downgrade कमांड दर्ज करें।
यह कैसे काम करता है ? handshake के दौरान (hello client के बाद), exploit एक handshake_failure 15030000020228 भेजता है, फिर ब्राउज़र को SSLv3.0 को डिफ़ॉल्ट प्रोटोकॉल के रूप में एक hello client फिर से भेजना चाहिए। Chrome संस्करण 15 पर परीक्षण किया गया है लेकिन यह Firefox पर काम नहीं करता है (मुझे लगता है कि वह protocol renegociation का समर्थन नहीं करता है), #4 देखें
शोषण का पूरा वीडियो:
Asciinema:
