मिग हैश एलगोरिदम वल्नरेबिलिटी

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

यह पाठ स्वयं भेद्यता शोधकर्ता योहनस नुग्रोहो के शब्दों का अनुवाद है। अच्छा समय है।

मिग हैश एलगोरिदम वल्नरेबिलिटी

पिछले साल, मुझे MIGS (मास्टरकार्ड इंटरनेट गेटवे सर्विस) द्वारा उपयोग किए गए MD5-आधारित हैश एल्गोरिथ्म में एक त्रुटि का पता चला। इसने आपको लेन-देन के आकार में परिवर्तन करने की अनुमति दी। कंपनी ने मुझे इस समस्या की खोज के लिए पुरस्कृत किया। उसी वर्ष, MIGS ने HMAC-SHA256 का उपयोग करने के लिए स्विच किया, लेकिन कुछ कमजोरियाँ थीं।

MIGS क्या है?

जब आप किसी वेबसाइट पर भुगतान करते हैं, तो उसके मालिक आमतौर पर एक मध्यवर्ती भुगतान गेटवे के लिए अपने सिस्टम को जोड़ते हैं (दूसरे पृष्ठ पर संक्रमण होता है)। यह भुगतान गेटवे तब किसी विशेष देश में उपलब्ध कई भुगतान प्रणालियों से जुड़ा होता है। क्रेडिट कार्ड के लिए, कई गेटवे अन्य गेटवे (जिनमें से एक एमआईजीएस है) से जुड़ते हैं, जो कि 3 डीecure प्रदान करने के लिए कई बैंकों के साथ काम करते हैं।

यह कैसे काम करता है?

भुगतान क्रम, यदि आप MIGS का उपयोग करते हैं, तो आमतौर पर ऐसा दिखता है:

1. आप साइट पर एक उत्पाद का चयन करें।
2. अपना क्रेडिट कार्ड नंबर दर्ज करें।
3. कार्ड नंबर, भुगतान का आकार, और अन्य मापदंडों पर हस्ताक्षर किए जाते हैं और ब्राउज़र में वापस आ जाते हैं, जो स्वचालित रूप से मध्यवर्ती भुगतान गेटवे के लिए एक POST अनुरोध उत्पन्न करता है।
4. यह प्रवेश द्वार सूचना को एक प्रारूप में परिवर्तित करता है जो MIGS द्वारा समर्थित है, MIGS कुंजी के साथ संकेत करता है और इसे ब्राउज़र में वापस करता है। जिसके बाद ब्राउज़र खुद ही MIGS सर्वर के लिए एक और POST अनुरोध उत्पन्न करता है।
5. यदि 3DSecure सक्षम नहीं है, तो यह चरण छोड़ दिया गया है। अन्यथा, MIGS कार्ड जारी करने वाले बैंक को अनुरोध हस्तांतरित करता है। बैंक OTP का अनुरोध करता है और HTML उत्पन्न करता है, जो MIGS सर्वर के लिए POST अनुरोध उत्पन्न करता है।
6. MIGS ब्राउज़र में हस्ताक्षरित डेटा लौटाता है और मध्यवर्ती भुगतान गेटवे के लिए एक POST अनुरोध बनाता है।
7. एक मध्यवर्ती भुगतान गेटवे द्वारा डेटा और हस्ताक्षर की मान्यता। यदि डेटा गलत है, तो एक त्रुटि पृष्ठ उत्पन्न होता है।
8. MIGS प्रतिक्रिया के आधार पर, भुगतान गेटवे विक्रेता को भुगतान की स्थिति को प्रसारित करता है।

MD5 एल्गोरिथ्म में भेद्यता

यह गलती बहुत सरल है। हैश विधि निम्न सूत्र का उपयोग करती है:

MD5 (गुप्त + डेटा)

लेकिन हैश एक्सटेंशन के लिए कोई भेद्यता नहीं है (इसे रोकने के लिए कुछ जांच की गई)। डेटा इस तरह से बनता है: सभी अनुरोध पैरामीटर जो vpc_ से शुरू होते हैं, क्रमबद्ध होते हैं, जिसके बाद मान बिना जुदाई के जुड़े होते हैं। उदाहरण के लिए, हमारे पास निम्नलिखित डेटा है:

नाम: जो
राशि: 10000
कार्ड: 1234567890123456

vpc_Name = जो और Vpc_Amount = 10000 & vpc_Card = 1234567890123456

छँटाई लागू करें:

vpc_Amount = 10000
vpc_Card = 1234567890123456
vpc_Name = जो

हम मूल्यों को जोड़ते हैं:

100001234567890123456Joe

यदि मैं पैरामीटर बदलता हूं तो सूचना दें:

vpc_Name = जो और Vpc_Amount = 1 और vpc_Card = 1234567890123456 और vpc_B = 0000

छँटाई लागू करें:

vpc_Amount = 1
vpc_B = 0000
vpc_Card = 1234567890123456
vpc_Name = जो

हम मूल्यों को जोड़ते हैं:

100001234567890123456Joe

वह MD5 मान समान होगा। यही है, वास्तव में, जब डेटा को MIGS में स्थानांतरित किया जाता है, तो हम अंतिम अंक को हटाने के लिए भुगतान आकार के बाद एक अतिरिक्त पैरामीटर जोड़ सकते हैं, या इससे पहले - पहले निकालने के लिए। और आप मैकबुक के लिए 2000 के बजाय $ 2 का भुगतान कर सकते हैं।

इंटरमीडिएट गेटवे और व्यापारी हमेशा इस जाँच से बच सकते हैं कि क्या MIGS द्वारा दी गई भुगतान राशि मेल खाती है या नहीं।

मास्टरकार्ड ने मुझे $ 8500 के प्रीमियम के साथ इस त्रुटि की पहचान करने के लिए पुरस्कृत किया।

HMAC-SHA256 हैश वल्नरेबिलिटी

नए HMAC-SHA256 में एक भेद्यता है जिसका शोषण किया जा सकता है यदि हम मध्यवर्ती भुगतान गेटवे में गलत मानों को इंजेक्ट करते हैं। मैंने भुगतान गेटवे (फ़्यूज़न भुगतान) में से एक पर इस त्रुटि की जाँच की। उन्होंने मुझे इसके लिए $ 500 का बोनस दिया। यह भेद्यता MIGS से जुड़े अन्य भुगतान गेटवे को भी प्रभावित कर सकती है।

नए संस्करण में, क्षेत्रों के बीच परिसीमन (और), फ़ील्ड नाम (न केवल मान) जोड़े गए, और, निश्चित रूप से, HMAC-SHA256। पहले की तरह ही डेटा के लिए, हैशेड लाइन इस तरह दिखती है:

Vpc_Amount = 10000 & vpc_Card = 1234567890123456 और vpc_Name @ जो

हम कुछ भी स्थानांतरित नहीं कर सकते, इस योजना में सब कुछ क्रम में है। लेकिन क्या होगा अगर मूल्य में वर्ण और या = या कुछ अन्य शामिल हैं?

MiGS वर्चुअल भुगतान क्लाइंट एकीकरण संदर्भ दस्तावेज़ पढ़ने के बाद, मैंने पाया:

"नोट: सभी नाम / मूल्य जोड़े में मूल्य, हैशिंग के उद्देश्य के लिए, URL वर्ण नहीं होना चाहिए"

मैं नहीं पर ध्यान केंद्रित। इसका मतलब है अगर हमारे पास निम्नलिखित क्षेत्र हैं:

राशि = 100
कार्ड = 1234
सीवीवी = 555

होशिंग इस तरह होगी: HMAC (राशि = 100 और कार्ड = 1234 और CVV = 555)

और यदि फ़ील्ड इस तरह हैं (का उपयोग करके & =):

राशि = 100 और कार्ड = 1234
सीवीवी = 555

यह हैश इस तरह दिखता है: HMAC (राशि = 100 और कार्ड = 1234 और CVV = 555)

उसी तरह से। लेकिन अभी तक, ऐसी समस्या नहीं है।

बेशक, मैंने सोचा था कि आधिकारिक दस्तावेज में कोई समस्या हो सकती है, शायद URL वर्ण अभी भी उपयोग किए जाने चाहिए। लेकिन मैंने MIGS सर्वर के व्यवहार की जाँच की, सब कुछ दस्तावेज़ में था। हो सकता है कि वे अलग एन्कोडिंग (जैसे कि% 20 के बजाय) के साथ काम नहीं करना चाहते।

ऐसा लगता है कि कोई समस्या नहीं होनी चाहिए, गलत मान MIGS द्वारा जांचे जाएंगे और एक त्रुटि देंगे (उदाहरण के लिए, गलत भुगतान आकार अस्वीकार कर दिया जाएगा)।

लेकिन मैंने देखा कि कुछ भुगतान गेटवे में, सर्वर की ओर से दर्ज किए गए डेटा की जांच करने के बजाय, वे बस हस्ताक्षर करते हैं और MIGS को सब कुछ पुनर्निर्देशित करते हैं। क्लाइंट पक्ष पर जावास्क्रिप्ट का परीक्षण करना, सर्वर साइड पर डेटा पर हस्ताक्षर करना बहुत आसान है, और फिर MIGS तय करें कि कार्ड नंबर सही है, क्या CVV में 3 या 4 अंक शामिल हैं, चाहे कार्ड सही ढंग से समाप्त हो, आदि। तर्क यह है: MIGS डेटा की दोबारा जांच करेगा और इसे बेहतर बनाएगा।

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

शोषण

इस भेद्यता का फायदा उठाने के लिए, हमें एक स्ट्रिंग बनाने की आवश्यकता है जो सही अनुरोध होगा और MIGS सर्वर से सही प्रतिक्रिया प्राप्त करेगा। हमें MIGS सर्वर के साथ संचार करने की आवश्यकता नहीं है, हम सिर्फ क्लाइंट को सही डेटा पर हस्ताक्षर करते हैं।

मूल अनुरोध:

vpc_AccessCode = 9E33F6D7 & vpc_Amount = 25 & vpc_Card = Visa और vpc_CardExp = 1717 और vpc_CardNum = 4599777788999999 और vpc_CardSecurityCode = 999 और vpc_Or/Info = vdd_feat=fo

और सर्वर से मूल प्रतिक्रिया इस तरह होगी:

vpc_Message = स्वीकृत और vpc_OrderInfo = ORDERINFO & vpc_ReceiptNo = 722819658213 और vpc_TransactionNo = 2000834062 और vpc_TxnResponseCode = 0 & vpc_SecureHash = THEHASH & pcb

फ्यूजन भुगतान के मामले में, शोषण vpc_CardSecurityCode (CVV) को लागू करके किया जाता है

vpc_AccessCode = 9E33F6D7 और vpc_Amount = 25 & vpc_Card = वीजा और vpc_CardExp = 1717 & vpc_CardNum = 4599777788889999 और vpc_CardSecurityCode = 999% 26vpc_Message% 3DApproved% 26vpc_OrderInfo% 3DORDERINFO% 26vpc_ReceiptNo% 3D722819658213% 26vpc_TransactionNo% 3D2000834062% 26vpc_TxnResponseCode% 3D0% 26vpc_Z% 3DA और vpc_OrderInfo = ORDERINFO और vpc_SecureHash = THEHASH और vpc_SecureHashType = SHA256

क्लाइंट / पेमेंट गेटवे इस लाइन के लिए सही हैश उत्पन्न करता है।

अब हम इस डेटा को क्लाइंट में (MIGS सर्वर के साथ किसी भी तरह से बातचीत किए बिना) दर्ज कर सकते हैं, लेकिन हम इसे थोड़ा बदल देंगे ताकि क्लाइंट आवश्यक चर को पहचान ले (अधिकांश ग्राहक केवल vpc_TxnResponseCode और vpc_TransactionNo की जाँच करते हैं):

vpc_AccessCode = 9E33F6D7% 26vpc_Amount% 3D25% 26vpc_Card% 3DVisa% 26vpc_CardExp% 3D1717% 26vpc_CardNum% 3D4599777788889999% 26vpc_CardSecurityCode% 3D999 और vpc_Message स्वीकृत और = vpc_OrderInfo = ORDERINFO और vpc_ReceiptNo = 722,819,658,213 और vpc_TransactionNo = +२०००८३४०६२ और vpc_TxnResponseCode = 0 और vpc_Z = एक% 26vpc_OrderInfo% 3DORDERINFO और vpc_SecureHash = THEHASH और vpc_SecureHashType = SHA256

नोट:

पिछले डेटा के साथ हैशिंग समान होगी।
क्लाइंट vpc_AccessCode और उसके मान को अनदेखा करेगा।
लेनदेन को सही मानते हुए ग्राहक vpc_TxnResponseCode आदि को संभालेंगे।

यह कहा जा सकता है कि यह एक MIGS क्लाइंट त्रुटि है, लेकिन MasterCard द्वारा उपयोग की गई हैश विधि इस त्रुटि को मौजूद है। यदि मानों को एन्कोड किया गया था, तो यह भेद्यता मौजूद नहीं होगी।

MIGS से उत्तर दें

मास्टरकार्ड ने HMAC-SHA256 में इस बग का जवाब नहीं दिया। मैंने कई लोगों से संपर्क किया, जिनसे मैंने पहले एक पिछली भेद्यता के बारे में संपर्क किया था। कोई जवाब नहीं है। यहां तक ​​कि "हम इसका परीक्षण करते हैं" की शैली में भी सदस्यता समाप्त कर सकते हैं। उनके पास मेरा फेसबुक है अगर वे मुझसे संपर्क करना चाहते हैं (एमडी 5 के बारे में पत्राचार के बाद से)।

कुछ स्पष्ट रूप से दिखावा करते हैं कि उन्होंने मेरी रिपोर्ट नहीं देखी थी, लेकिन मैंने पत्र पर एक पासवर्ड डाला। मास्टरकार्ड आईपी पते से कम से कम 3 बार देखा गया था। उसी समय, ये बिना पढ़े यादृच्छिक क्लिक नहीं हैं, क्योंकि आपको जानबूझकर पासवर्ड दर्ज करने की आवश्यकता है। मैं उन्हें हर हफ्ते लिखता हूं।

मेरी अपेक्षा यह थी कि वे उन सभी को चेतावनी देंगे जो एम्बेडेड डेटा की जांच और फ़िल्टर करने के लिए अपने सिस्टम से जुड़ते हैं।

पेमेंट गेटवे में अंतराल

इसके अलावा, मैं कहना चाहता हूं: इस तथ्य के बावजूद कि भुगतान गेटवे पैसे का सौदा करते हैं, वे उतना सुरक्षित नहीं हैं जितना लगता है। मेरे पंचकों (पैठ परीक्षण) के दौरान, मैंने कई मध्यवर्ती द्वारों में भुगतान प्रोटोकॉल में कई कमजोरियों की खोज की। दुर्भाग्य से, मैं विवरण नहीं बता सकता (यदि मैं "पंचक" कहता हूं, तो यह कुछ ऐसा है जो गैर-विवेकाधीन समझौते के अंतर्गत आता है)।

मुझे कार्यान्वयन त्रुटियां भी मिलीं। उदाहरण के लिए, हैश एक्सटेंशन अटैक, एक्सएमएल, हस्ताक्षर सत्यापन त्रुटियों आदि। फ़्यूज़न भुगतान में मुझे सबसे आसान कीड़े मिले। मुझे जो पहली बग मिली, वह थी: वे MIGS के हस्ताक्षर भी नहीं देखतीं। इसका मतलब है कि हम केवल MIGS द्वारा लौटाए गए डेटा को संशोधित कर सकते हैं और लेनदेन को सफल के रूप में चिह्नित कर सकते हैं। इसका मतलब केवल एक चरित्र को बदलना है: एफ (असफल) से 0 (सफल)।

यही है, वास्तव में, हम किसी भी कार्ड नंबर को दर्ज कर सकते हैं, एमआईजीएस से गलत प्रतिक्रिया प्राप्त कर सकते हैं, इसे बदल सकते हैं, और अचानक भुगतान एक सफल हो जाता है। यह 20 मिलियन के बजट वाली कंपनी है, और मुझे उनसे 400 रुपये मिले हैं। इस तरह की भेद्यता के साथ यह एकमात्र भुगतान गेटवे नहीं है, मेरी पेंटेस्ट के दौरान मुझे अन्य गेटवे में यह मिला। छोटे इनाम के बावजूद, फ़्यूज़न भुगतान वर्तमान में एकमात्र भुगतान गेटवे है, जिससे मैंने संपर्क किया, जो कि बग के लिए इसके इनाम कार्यक्रम में बहुत स्पष्ट है। उन्होंने मेरे संदेशों का बहुत तेज़ी से जवाब दिया और जल्दी से अपने कीड़े ठीक कर लिए।

निष्कर्ष

पेमेंट गेटवे आपके हिसाब से उतने सुरक्षित नहीं हैं। इस तरह के कम पुरस्कारों के साथ (और कुछ मामलों में मुझे $ 0 प्राप्त हुआ), मुझे आश्चर्य है कि भुगतान गेटवे में कितने लोग पहले ही इन कमजोरियों का फायदा उठा चुके हैं।

अनुवादक से रिमार्क

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

क्या आपने भुगतान प्रणाली में किसी भी कीड़े का सामना किया है, या शायद आप भी ऐसे कीड़े के शिकार थे? टिप्पणियों में अपने आप को कैसे सुरक्षित रखें, इस पर अपने अनुभव, राय और सुझाव साझा करें। एक अच्छा दिन और सुरक्षित खरीदारी करें।

एक विज्ञापन के रूप में। विशेष प्रस्ताव! अब केवल नीदरलैंड और यूएसए में समर्पित ड्राइव (वीपीएस (KVM) - E5-2650v4 (6 करोड़) / 10GB DDR4 / 240GB SSD या 4TB HDD / 1Gbps 10TB - $ 29 ) के साथ VPS (KVM) का 4 महीने तक मुफ्त उपयोग हो सकता है। / महीने और ऊपर, RAID1 और RAID10 के साथ विकल्प उपलब्ध हैं) , समर्पित सर्वरों का एक पूर्ण एनालॉग, जब 1-12 महीने की अवधि के लिए आदेश दिया जाता है, तो कार्रवाई की शर्तें यहां हैं, मौजूदा ग्राहकों को बोनस के रूप में 2 महीने मिल सकते हैं!

भवन के बुनियादी ढांचे का निर्माण कैसे करें। एक पैसा के लिए 9,000 यूरो की लागत डेल R730xd E5-2650 v4 सर्वर का उपयोग कर वर्ग?