- PCI DSS कार्ड डेटा के स्टोरेज और डिस्प्ले को सीमित करता है, लेकिन BIN, आख़िरी 4 अंक और expiry date जैसी अनुमत जानकारी भर से भी दूसरे merchants पर अतिरिक्त payment attempts जारी रखे जा सकते हैं
- compromised account में हमलावर ने बैंक के 3D Secure पेज के जरिए कार्ड के usable होने की स्थिति, बैंक का नाम, masked card number और पूरी expiry date हासिल कर ली, और लगभग 6 घंटे बाद कई merchants पर authentication attempts शुरू किए
- Payment card number (PAN) में IIN, account identifier और Luhn check digit की संरचना होती है, और अगर payment gateway response यह बता दे कि कौन-सी value गलत है, तो PAN·expiry date·CVV का अनुमान लगाना आसान हो जाता है
- वास्तविक test speed लगभग 6 requests प्रति second, और प्रति API लगभग 2 requests प्रति second थी; proxy के कारण IP बदलता रहा और card number भी लगातार बदलते रहे, इसलिए merchant के लिए brute-force detect करना मुश्किल था
- हमलावर ने 3D Secure exception merchants का उपयोग कर घटाई गई limit की पूरी राशि e-wallet में ट्रांसफर कर दी; chargeback से पैसा वापस मिल गया, लेकिन बैंक की CVC2 rate limit सिर्फ कुछ मिनट के block तक सीमित रही
PCI DSS क्या रोकता है और क्या छोड़ देता है
- PCI DSS एक industry standard है जो credit card जैसे sensitive banking data को संभालने के लिए आवश्यक न्यूनतम security measures को परिभाषित करता है, और account compromise होने या card data third party तक पहुँचने पर भी पूरी जानकारी उजागर न हो, इसके लिए storage और display को सीमित करता है
- PCI DSS 4 के अनुसार स्क्रीन या receipt पर दिखाई जा सकने वाली जानकारी में masked PAN, cardholder name, service code और expiry date शामिल हैं; PAN में BIN और आख़िरी 4 अंक तक दिखाए जा सकते हैं
- जो जानकारी दिखाई नहीं जा सकती, उसमें full track data, card verification code और PIN/PIN block शामिल हैं
- e-commerce sites और physical receipts दोनों इस समस्या से प्रभावित हो सकते हैं; account compromise के अलावा, नष्ट न की गई receipts के जरिए भी कुछ card information उजागर हो सकती है
घटना का क्रम
- पीड़ित एक limit-restricted virtual credit card इस्तेमाल कर रहा था, उसने 2-step authentication वाला 3D Secure enabled किया हुआ था, और कार्ड को केवल well-known merchants पर save करके इस्तेमाल करता था
- बहुत पहले बनाया गया एक account compromise होने के बाद, कार्ड save किए गए website से purchase attempt का SMS आया; पीड़ित ने तुरंत login कर password बदला, purchase की पुष्टि की, और virtual card की limit को काफ़ी कम कर दिया
- कार्ड को पूरी तरह disable न करने का कारण यह था कि उसे लगा पूरी card information compromise नहीं हुई है
- शुरुआती compromise के लगभग 6 घंटे बाद, कई अनजान merchants से 3D Secure SMS के 3-4 attempts आए; सभी असफल रहे, लेकिन बाद में attack method समझने के लिए यह एक अहम सुराग बने
- कुछ मिनट बाद जब पीड़ित बैंक को कॉल करके कार्ड पूरी तरह disable करवा रहा था, उसी दौरान हमलावर ने 3D Secure न मांगने वाले दूसरे merchants का उपयोग करके घटाई गई limit की पूरी राशि कई payments में निकाल ली
- पैसा cash withdrawal की सुविधा देने वाले market के e-wallet में भेजा गया, और पीड़ित ने chargeback request के बाद बैंक से पैसा वापस पा लिया
हमलावर को मिली जानकारी
- हमलावर ने compromised account में payment attempt किया, बैंक का 3D Secure पेज देखा, फिर order cancel करके चला गया
- इस प्रक्रिया में उसे पता चल गया कि कार्ड अभी भी usable है, बैंक का नाम क्या है, masked card number क्या है, और पूरी expiry date क्या है
- सामान्यतः card payment सफलतापूर्वक पूरा करने के लिए पूरा 16-digit PAN, expiry date, CVC2 number, और 3D Secure में इस्तेमाल होने वाला mobile phone जैसी जानकारी चाहिए होती है
- वास्तविक हमले में, केवल आंशिक जानकारी के आधार पर दूसरे merchants पर अतिरिक्त कोशिशें जारी रखी जा सकीं
PAN की संरचना और अनुमान की संभावना
- Payment card number (PAN) एक card identifier है, जो credit card, debit card, stored-value card और gift card आदि में इस्तेमाल होता है
- PAN, ISO/IEC 7812 के अनुसार एक common numbering scheme का पालन करता है, और इसकी internal structure इस प्रकार है
- 6 या 8 अंकों का Issuer Identification Number(IIN)
- अधिकतम 12 अंकों का individual account identifier
- Luhn algorithm से निकाला गया 1-digit check digit
- पीड़ित का बैंक सिर्फ card number के आधार पर payment allow नहीं करता था; वह PAN, expiry date और CVV तीनों मांगता था
- कुछ बैंक और payment gateways केवल card number से भी payment process कर सकते हैं, और यही वह हिस्सा था जिस पर पीड़ित को विशेष रूप से विश्वास करना मुश्किल लगा
payment gateway responses ने brute-force के लिए कैसी स्थिति बनाई
- पीड़ित का बैंक जरूरी values न होने या गलत होने पर payment reject करता था, लेकिन response code के जरिए यह भी बता देता था कि कौन-सा हिस्सा गलत है
- response examples इस प्रकार थे
- “यह वैध credit card नहीं है”
- “कार्ड की expiry हो चुकी है”
- “बाकी सारी जानकारी सही है, लेकिन CVV गलत है”
- ऐसे responses हमलावर को यह अलग करने में मदद कर सकते हैं कि card number, expiry date और CVV में कौन-सी value सही है और कौन-सी गलत
- वास्तविक हमलावर लगभग 6 requests प्रति second, और प्रति API लगभग 2 requests प्रति second की रफ़्तार से test कर रहा था
- merchant के दृष्टिकोण से यह गति detect करना मुश्किल है, क्योंकि proxy के कारण source IP बदलता रहता है, brute-force की प्रकृति के कारण card number भी एक जैसे नहीं होते, और request frequency भी बहुत कम होती है
3D Secure exception merchants की भूमिका
- बैंक के पास 3D Secure exception merchants की एक सूची होती है; इन्हें बैंक भरोसेमंद मानता है, इसलिए ये 3D Secure के बिना payment और subscription स्वीकार कर सकते हैं
- ऐसे merchants पर chargeback होने की स्थिति में ज़िम्मेदारी उन्हीं की होती है
- हमलावर ने 3D Secure न मांगने वाले merchants का उपयोग करके कार्ड limit के भीतर की राशि e-wallet में पहुँचा दी
बाद की प्रतिक्रिया और बाकी बची समस्याएँ
- chargeback के जरिए पैसा जल्दी वापस मिल गया
- card payment को cash में बदलने वाली जिस system का उपयोग unauthorized withdrawal में हुआ, उसके बारे में संबंधित merchant को बताया गया, लेकिन merchant ने जवाब दिया कि बैंक से पूछें
- e-commerce site को बताया गया कि expiry date के साथ card number के 10 अंक दिखाने से attack आसान हो जाता है, लेकिन उस site ने इसे vulnerability मानने से इनकार किया और कहा कि यह PCI DSS 3 और 4 standards के अनुसार जानबूझकर किया गया design है
- payment API बनाने वाले या payment industry में काम करने वाले लोग इससे हैरान नहीं थे, और कुछ merchants ने कहा कि वे expiry date के बिना भी transaction कर सकते हैं
- इस घटना के बाद, credit card payment को cash में बदलने वाली संबंधित party अब इसे 3D Secure के बिना process नहीं करती
- पीड़ित का बैंक अब भी CVC2 brute-force के खिलाफ अपेक्षाकृत ढीली rate limiting रखता है; limit hit होने पर वह उस कार्ड को केवल कुछ मिनटों के लिए अस्थायी रूप से block करता है
अभी कोई टिप्पणी नहीं है.