क्रेडिट कार्ड brute-force प्रकार के हमलों के प्रति संवेदनशील हैं
(metin.nextc.org)- 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 करता है
1 टिप्पणियां
Hacker News की टिप्पणियाँ
संबंधित मामलों को देखें तो संभव है कि मूल पोस्ट का लेखक गलत कारण के पीछे लगा हुआ था। हाल में मेरे credit card पर FB/Meta से जुड़े छोटे unauthorized charges दिखे, और लगा कि कोई यह टेस्ट कर रहा था कि कार्ड detect होता है या नहीं
मैंने card company को फोन करके charge cancel कराया और कार्ड बंद कराया, फिर नया card number, नई expiry date और नया CVV वाला कार्ड मिला, लेकिन एक बार भी इस्तेमाल न किए गए नए कार्ड पर भी फिर से FB/Meta fraud charges शुरू हो गए। वजह digital wallet निकला, और कार्ड बंद करने पर भी card number वगैरह digital wallet के ज़रिए आगे transfer हो सकते थे
मैंने फिर card company को फोन कर कहा कि सारे digital wallets बंद कर दें, तो ऐसे 99 निकले, और यह ऑनलाइन नहीं हो सकता था, इसलिए call center agent से बात करनी पड़ी। उन्होंने बताया कि recurring payments सब reset हो जाएँगे, फिर भी मुझे साफ़ कहना पड़ा कि कार्ड और सभी digital wallets बंद कर दें, और 20 मिनट इंतज़ार भी करना पड़ा। कार्ड बंद करना वैसा नहीं हो सकता जैसा लोग समझते हैं, और recurring payments card companies के लिए बहुत profitable हैं, इसलिए इन्हें बंद करना शायद बड़े revenue loss जैसा लगता है
Stripe ब्लॉग: https://stripe.com/resources/more/what-is-a-card-account-upd...
अगर leak कहीं और से हुआ होता, तो शायद कोई असंबंधित ecommerce account में login करने की कोशिश नहीं करता
यह पोस्ट सबसे अहम हिस्से को छूती ही नहीं। बैंक का मेरे account से merchant को पैसा भेजने पर सहमत होना, यानी settlement, authorization से पूरी तरह अलग चीज़ है
Authorization आधुनिक EMV, यानी “chip and PIN” authentication, online CVV, और वे तमाम उपाय हैं जिनसे बैंक खुद को fraud से बचाता है और साथ में merchant को भी कुछ हद तक बचाता है
Network Amazon की यह बात मान सकता है कि “यह रहा card number, और यह व्यक्ति हमें $400 दे रहा है।” वह बस settlement है और statement पर आ जाता है। बिना किसी sophisticated cryptography, बिना 4-digit PIN जैसी किसी सुरक्षा, यहाँ तक कि माँ का maiden name याद होने जैसी basic verification के भी, बस “ठीक है, मान लिया” हो जाता है। इसलिए अगर consumer credit card bill पढ़कर अनजान charges को dispute नहीं करता, तो वही पैसा दे देता है
Network के पास consumer के लुटने की परवाह करने का लगभग कोई incentive नहीं है। अगर dispute नहीं हुआ तो सब खुश, और अगर हुआ तो merchant से वसूल लिया जाएगा, तो यह उनकी समस्या नहीं
Payment processors पूरे card number पर brute force करने वाली card enumeration या card testing की अनुमति नहीं देते, और card networks भी ऐसे merchants और processors पर कड़ी penalties लगाते हैं जो इसे नहीं रोकते
एक ही PAN पर CVC2 enumerate करना अलग बात है
यह इस बात का सबूत है कि fraud-prevention infrastructure ने वास्तव में सुरक्षा दी। बैंक ने fraud loss उठाया और पैसा वापस भी किया
आखिरकार बैंकिंग सिस्टम fraud losses की परवाह करता है, और fraud detection में भी काफी सक्षम है। Card payment system का scale इतना बड़ा है कि उसे बदलना बेहद मुश्किल है, इसलिए जब तक इस बात का बहुत ठोस सबूत न हो कि कोई बदलाव वास्तव में fraud rate कम करेगा, बैंक बदलाव न करने को ही चुनते हैं
Issuing bank हर transaction पर interchange fee कमाता है, इसलिए अगर fraud की जिम्मेदारी उसकी न हो, तो उसका default incentive यह होता है कि जितना हो सके approve करो और बाद में chargeback से मामला निपटा लो। हालांकि 3DS इस गणित को काफी बदल देता है, और in-person payments में जिम्मेदारी अक्सर issuing bank की होती है
आख़िर में सभी consumers मिलकर सभी fraud costs उठाते हैं। यह bill में अलग line item की तरह नहीं दिखता, लेकिन हम जो भी सामान खरीदते हैं उसमें थोड़ा-थोड़ा extra दे रहे होते हैं
eBay पर stolen credit card से जुड़े मामले में मेरे साथ ऐसा हुआ; शुरू में सब ठीक चल रहा था, लेकिन जैसे ही eBay ने कागज़ों का ढेर बैंक को भेजा, chargeback पलट गया, और कुछ ही समय बाद मेरा bank account भी बंद कर दिया गया
Chargeback से पैसा वापस आ गया, इसका मतलब यह नहीं कि मामला खत्म हो गया। शुरुआत में शायद यह बस अस्थायी तौर पर किया जाता है ताकि दूसरी तरफ़ को जवाब देने का समय मिले, और eBay ने इतने documents भेजे कि chargeback फिर से खुलवाने में करीब 30 दिन लग गए। उनकी explanation इतनी असरदार थी कि मेरे बैंक ने उल्टा मुझे ही fraudster मान लिया
मुझे यह भी नहीं पता कि “बैंक fraud loss खाता है” यह 100% सही है या नहीं। Chargeback को challenge करने वाले ऐसा इसलिए करते हैं क्योंकि आखिरकार chargeback झेलने वाले या chargeback करने वाले में से किसी न किसी को loss उठाना पड़ता है। अगर बैंक ही वह loss झेलता, तो eBay पेशेवर staff लगाकर investigation और मेरे chargeback का जवाब देने की जहमत क्यों उठाता
अगर 3D Secure हर जगह अनिवार्य होता तो बहुत मदद मिलती, लेकिन मेरी समझ से अमेरिका में इसका लगभग इस्तेमाल नहीं होता। अमेरिकी बाज़ार इतना बड़ा है कि card issuers को 3D Secure के बिना requests allow करनी पड़ती हैं, नहीं तो customers बहुत सी जगहों पर कार्ड इस्तेमाल ही नहीं कर पाएँगे
यह काफ़ी शक्तिशाली fraud-prevention उपाय को बहुत सीमित कर देता है, इसलिए बाकी दुनिया के नज़रिए से यह निराशाजनक है
समझ नहीं आता कि अमेरिकी consumers थोड़ी सी inconvenience के बजाय fraud झेलना क्यों पसंद करेंगे। भले आप fraud victim न हों, merchants fraud और insurance की लागत को product prices में जोड़ देते हैं, इसलिए आखिर में सब लोग इसकी कीमत चुकाते हैं
लेकिन पूरे industry स्तर पर यह एक classic coordination problem है। Conversion इसलिए गिरता है क्योंकि आसान विकल्प मौजूद है; अगर सभी merchants और banks एक साथ 3DS लागू करें, तो लोगों के पास जाने के लिए आसान विकल्प बचेगा ही नहीं। पसंद हो या न हो, users नए और ज़्यादा सुरक्षित तरीके के आदी हो जाएँगे और conversion फिर बढ़ जाएगा
EU ने कई payments के लिए 3DS अनिवार्य करके कुछ ऐसा ही किया, लेकिन वहाँ regulators ने भी माना कि 100% लागू करना उल्टा असर कर सकता है, और कहीं बीच में एक सही संतुलन है
इसी तर्क का एक और उदाहरण है कि अमेरिकी credit cards में PIN नहीं होता। अगर कोई एक bank PIN लाता, तो customer PIN-रहित competitor card की ओर चला जाता और usage बहुत गिर जाता। दूसरे markets में regulatory intervention या card network incentives की वजह से सभी cards में PIN है, और लोग बस उसके आदी हो गए हैं
जब credit cards पहली बार आए थे, यानी उस दौर में जब वे अमेरिका में शुरू हो रहे थे, Congress ने 1974 Fair Credit Billing Act पास किया, जिसने यह तय किया कि अगर fraudulent billing cycle खत्म होने के 60 दिनों के भीतर खोए हुए कार्ड की रिपोर्ट कर दी जाए तो consumer liability $50 तक सीमित रहेगी। उस समय payments कागज़ पर होते थे, उन मशीनों से जो “ka-chunk” की आवाज़ के साथ card carbon copy बनाती थीं, और पूरा सिस्टम offline था
यह कानून बदला नहीं गया, और व्यवहार में ज़्यादातर banks $50 भी माफ़ कर देते हैं और reported incidents में card holder पर कोई liability नहीं डालते। ग्राहक को $50 के लिए नाराज़ करना bank के लिए फायदे का सौदा नहीं है
Internet की वजह से cards अचानक चोरी और misuse के लिए बहुत आसान हो गए, लेकिन banks को अभी भी billing cycle खत्म होने के 60 दिनों के भीतर report किए गए losses खुद उठाने पड़ते हैं। इसलिए अमेरिकी banks ने credit card transactions की real-time monitoring में बहुत भारी निवेश किया है, और क्योंकि आखिरकार liability उन्हीं पर आती है, वे इसे बहुत गंभीरता से लेते हैं। दूसरी ओर consumers कम परवाह करते हैं। Consumer के नज़रिए से अमेरिकी cards यूरोपीय cards की तुलना में कहीं ज़्यादा ढीले क्यों लगते हैं, इसका कारण यह है कि यूरोप के विपरीत अमेरिका में consumer largely indemnified है, इसलिए banks ने backend पर कहीं ज़्यादा निवेश किया है
अलग से, EU ने interchange fee पर regulation लगाया कि card companies कितना charge कर सकती हैं, लेकिन अमेरिका ने कोई cap नहीं लगाई। नतीजा यह है कि अमेरिकी card holders को card use पर काफ़ी rewards मिल सकते हैं, खासकर सबसे अमीर 10% लोगों को, और यह सीमित interchange fee वाले EU-issued cards के साथ लगभग असंभव है
अभी एक बड़ा lawsuit चल रहा है जिसका मकसद यह है कि merchants सिर्फ low-fee cards स्वीकार कर सकें। Standard VISA/MC/AMEX contracts सभी cards को समान रूप से treat करने की मांग करते हैं, और इसी वजह से card issuers के पास लोगों को higher-interchange-fee cards की ओर धकेलने का incentive होता है। उस lawsuit का नतीजा देखना होगा, लेकिन तब तक अमेरिका के high-spending consumers को card rewards काफ़ी ज़्यादा मिल सकते हैं, और यह भी card usage बढ़ाने और EU-style cards की तुलना में friction कम करने की दिशा में काम करता है
ऐसा नहीं कि हम fraud होना पसंद करते हैं; यह ज़्यादा issuer और merchant के बीच negotiation का मामला है
एक बार हमारी company में नया hire हुआ व्यक्ति शेख़ी बघारने लगा कि उसने gift cards में stored value जोड़ने का तरीका ढूँढ लिया है। बाद में पता चला कि FBI उसकी जाँच कर रही थी
वह एक government contractor में था, और आखिर में मैंने अपनी ज़िंदगी का सबसे बड़ा security guard देखा जो उसे लेकर बाहर गया
Virtual credit cards बहुत पहले से मौजूद हैं। मुझे याद है 15 साल से भी पहले Bank of America और Citi यह देते थे, शायद Java app था या standalone executable। हैरानी है कि यह ज़्यादा व्यापक क्यों नहीं हुआ
Robinhood ने इसे बहुत अच्छी तरह किया है। यह मेरे इस्तेमाल का सबसे अच्छा virtual credit card system है और बहुत smooth है। आप one-time, 24-hour, या cancel करने तक अनिश्चित अवधि के लिए कार्ड authorize कर सकते हैं, और UI/UX शानदार है
आज जब सब कुछ subscription बन चुका है, समझ नहीं आता कि यह feature क्यों नहीं फैला। Expiry date और spending limit सेट कर पाने की सुविधा बहुत बढ़िया थी ताकि subscription cancel करने के लिए गंदे negotiation न करने पड़ें
हाल में मेरी पत्नी के कार्ड पर विदेश से suspicious transaction होने का bank SMS आया, और रकम सचमुच $0 थी, उस समय पत्नी न फोन इस्तेमाल कर रही थी न कंप्यूटर
पहले लगा कि SMS ही phishing है, लेकिन online जाँचने पर message format सही निकला, और bank webpage ने यह भी भरोसा दिया कि feedback process में कोई जानकारी नहीं माँगी जाएगी, इसलिए हमने पुष्टि की कि यह payment हमने नहीं की
Bank ने तुरंत कार्ड cancel किया और नया कार्ड भेज दिया
पहले लगा कि bank security system overreact कर रहा है, लेकिन वास्तव में कोई वही काम कर रहा था जो इस लेख में बताया गया है, और bank ने उसे पहले ही पकड़ लिया
Online payments के लिए अलग कार्ड रखना और उसमें सिर्फ ज़रूरत भर का पैसा रखना अच्छा है
पता है यह थोड़ी naive सोच है
लेख पर लौटें तो कमजोरी password था, और वही 3D Secure न इस्तेमाल करने वाले दूसरे merchant तक पहुँचा
लेख को देखें तो attacker के पास पूरी तरह automated system लगता है, इसलिए बड़े merchants को एक ही IP address से अलग-अलग accounts पर automated login attempts को संभालना चाहिए। हमारे Wordfence logs में भी IP rotation इतनी तेज़ नहीं है, इसलिए permanent IP bans से कुछ हद तक निपटा जा सकता है
मुझे नहीं लगता कि password leak सीधे पूरे credit card data leak में बदल जाना चाहिए। यही data दुकानों की printed paper receipts पर भी आता है, कभी 4 digits, कभी 10 digits। दुकान में पड़े कागज़ी receipts से भी brute force अब तक संभव है
और जोड़ूँ तो merchants अपने credit card processor से मनचाहा security level चुन ही नहीं सकते। उदाहरण के लिए authorize.net में address match न होने पर भी आप payment accept कर सकते हैं
असली सवाल यह है कि पैसा निकाला कैसे गया। क्या किसी ढीले merchant से gift cards खरीदे गए?
Number guess कर लेना और system से पैसा बाहर निकाल लेना दो बिल्कुल अलग बातें हैं
Processor market में थोड़ा bifurcation है। एक तरफ़ वे हैं जो customers को simplicity देते हैं और बोझ कम करते हैं, और दूसरी तरफ़ वे जो पूरी complexity expose करते हैं और granular control देते हैं। पहला समूह security requirements specify नहीं करने देता, दूसरा सैकड़ों options देता है। बेशक इनके बीच की जगह लेने वाले processors भी हैं, और ये दोनों धुरियाँ आम तौर पर अलग-अलग customers को target करती हैं