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