क्रेडिट कार्ड टर्मिनल में root shell हासिल किया गया

 (stefan-gloor.ch)
4 पॉइंट द्वारा GN⁺ 2025-06-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • स्विट्ज़रलैंड में इस्तेमाल होने वाले Worldline Yomani XR पेमेंट टर्मिनल को खोलकर और उसके firmware का विश्लेषण करने पर पता चला कि पीछे के hatch से एक्सेस किए जा सकने वाले serial console में सिर्फ root टाइप करके root shell में प्रवेश किया जा सकता था
  • टर्मिनल में housing खुलने, PCB contact disconnect होने, zigzag trace कटने, और card reader के आसपास flex PCB damage को detect करने वाली tamper protection थी, लेकिन debug port का exposed होना एक अलग attack path बन गया
  • ऑनबोर्ड flash से निकाले गए firmware में unencrypted filesystem शामिल था, और यह Linux 3.6 kernel, Buildroot 2010.02, BusyBox, uClibc, और custom bootloader Booter v1.7 पर आधारित था
  • card, PIN, screen, keypad जैसी security functions को अलग processor mp1 और encrypted/signed mp1.img संभालते दिखते हैं, और Linux mp2 से सीधे access के सबूत नहीं मिले
  • vulnerable firmware version तय नहीं हो पाया और कुछ devices में root login disabled था, लेकिन ऐसी स्थिति में जहां कोई व्यक्ति थोड़े समय के लिए terminal को physical रूप से अपने control में ले सके, वहां अनावश्यक रूप से बड़ा attack surface बचा हुआ है

Worldline Yomani XR विश्लेषण का लक्ष्य

  • विश्लेषण का लक्ष्य स्विट्ज़रलैंड में व्यापक रूप से इस्तेमाल होने वाला Worldline Yomani XR payment terminal था
  • boot होने के बाद UI check और port scan में कोई खास परिणाम नहीं मिला, इसलिए hardware disassembly की गई
  • अंदर कई PCB लगे थे
    • external connectors के लिए छोटा board
    • main board
    • card slot लगा हुआ vertical board
  • main SoC firmware में “Samoa II” code name से दिखने वाला dual-core Arm आधारित custom ASIC लगता है
  • Worldline documentation के अनुसार यह chip किसी off-the-shelf chip की rebranding नहीं, बल्कि custom ASIC है
  • SoC के बगल में छोटी external flash और RAM हैं

Hardware tamper protection structure

  • सामान्य housing-open detection switch नहीं मिला; इसके बजाय board-to-board interconnect को ही open detection mechanism के तौर पर इस्तेमाल किया गया था
  • boards के बीच pressure-sensitive Zebra strip है, जिससे contact बनाए रखने के लिए boards को screws से कसकर जकड़ना पड़ता है
    • कुछ screws खोलने भर से contact टूट सकता है और tamper event trigger हो सकता है
    • power disconnected होने पर भी detection की जरूरत होने के कारण coin cell battery इस्तेमाल की गई है
  • vulnerable PCB areas zigzag आकार की tamper detection traces से ढके हैं
    • physical intrusion से सिर्फ एक copper trace कटने पर भी tamper detection हो सकता है
  • card slot एक अलग internal housing में है, और उसके आसपास लिपटा flex PCB tamper protection का काम करता है
  • दोबारा assemble करने के बाद terminal ने सिर्फ “TAMPER DETECTED” वाली बड़ी red screen दिखाई, और इस mode में वह external input पर respond करता नहीं दिखा

Flash extraction और filesystem recovery

  • runtime exploration blocked होने पर onboard flash chip को हटाकर wires जोड़े गए और उसका content dump किया गया
  • dump किया गया content उम्मीद के विपरीत पूरी तरह encrypted नहीं था
  • flash में असामान्य ECC layout इस्तेमाल किया गया था
    • यह standard 2048 byte payload + 64 byte ECC/spare configuration नहीं था
    • इसमें 694 byte data chunks के 3 हिस्से थे, और हर chunk के बाद 10 ECC bytes लगे थे
    • spare area के आखिरी 16 bytes YAFFS2 filesystem metadata जैसे दिखे
  • सामान्य YAFFS2 की तुलना में metadata area छोटा था, इसलिए छोटे metadata structure को handle करने के लिए filesystem patch करना पड़ा
  • compatible filesystem reader implement करने के बाद filesystem contents को सफलतापूर्वक extract कर लिया गया

पुराने Linux आधारित system

  • extract किए गए filesystem से पुष्टि हुई कि terminal Linux चला रहा है
  • system में पुराने components शामिल थे
    • Linux kernel 3.6
    • Buildroot 2010.02
    • February 2023 build
    • custom bootloader Booter v1.7
    • init script, BusyBox, uClibc
    • libcrypt 0.9.26
  • dumped firmware version कितना latest था, यह confirm नहीं हुआ, लेकिन यह February 2023 के बाद release हुआ firmware होना चाहिए

बिना password वाला root shell

  • flash chip को wires से वापस connect करने पर terminal tamper message दिखाते हुए भी फिर boot हुआ
  • Linux boot log देखने के लिए debug connector के आसपास logic analyzer से जांच की गई, और unpopulated debug connector के एक pad पर activity मिली
  • serial console पर Linux boot log के साथ login prompt दिखाई दिया
    • boot log में “Reset reason: Tamper” दिखा
    • dropbear is not present, firmware update check, application monitoring daemon शुरू होने जैसे logs भी दिखाई दिए
    • अंत में samoa login: prompt दिखा
  • login के रूप में root enter करने पर बिना password के shell prompt ~ # दिखाई दिया
  • इस access के लिए exploit chain या brute-force password cracking की जरूरत नहीं थी

बाहर से accessible debug port

  • root shell access सिर्फ terminal के अंदर खोलने की स्थिति तक सीमित नहीं था
  • serial port terminal के पीछे छोटे hatch के जरिए बाहर से accessible था
  • terminal खोलकर tamper protection trigger किए बिना भी debug connector से connect किया जा सकता था
  • आकलन है कि अगर कोई थोड़े समय के लिए terminal को अपने control में ले सके, तो serial port से connect कर login करने, malware deploy करने और फिर चले जाने वाला scenario संभव है

Security processor और Linux role separation

  • exposed root shell का मतलब तुरंत card या PIN data access होना नहीं है
  • Linux system पूरी architecture का सिर्फ एक हिस्सा है, और ऐसा कोई सबूत नहीं मिला कि display, keypad, card reader को Linux से सीधे access किया जा सकता है
  • screen output भी framebuffer driver द्वारा सीधे handle होने के बजाय, strings को display_tool binary को pass करने और फिर इस binary द्वारा inter-processor message भेजने का तरीका दिखा
  • card, PIN entry, screen display जैसी security-related functions को अलग processor mp1 संभालता दिखता है
  • दूसरे processor mp2 पर चलने वाला Linux networking, update और business logic संभालता है

Boot flow और security image

  • Linux core tamper state से स्वतंत्र रूप से हमेशा boot होता दिखता है
  • इसके बाद Linux secure bootloader loadercode को memory में load करता है
  • loadercode check करता है कि tamper protection trigger हुई है या नहीं
    • tamper detect होने पर red screen दिखाता है
    • कोई issue न हो तो actual secure image mp1.img boot करता है
  • mp1.img Linux filesystem के अंदर है, लेकिन encrypted और दो entities द्वारा signed प्रतीत होता है
  • card, display और keypad संभालने वाली secure image ठीक से encrypted और signed थी

Disclosure schedule और बाकी uncertainties

  • disclosure schedule इस तरह दर्ज किया गया
    • 14 November 2024: root shell discovery
    • 15 November 2024: manufacturer को report किया और 90 दिनों बाद disclosure予定 होने की सूचना दी
    • 18 November 2024: manufacturer ने report receipt confirm की
    • 1 June 2025: disclosure
  • exposed root shell अनावश्यक रूप से बड़ा attack surface है, लेकिन card information जैसे sensitive data इस path से compromise हो सकते हैं, इसका कोई सबूत नहीं मिला
  • कौन-सा firmware version vulnerable है, यह confirm नहीं हुआ
  • research के दौरान root login disabled वाले devices भी मिले
  • debug feature किस समय production firmware में आया, या manufacturer के अंदर इसे पहले ही discover और fix किया गया था या नहीं, यह confirm नहीं हुआ

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-06-02
Hacker News की रायें

  • 2 डॉलर के USB कार्ड रीडर से नकली डेबिट/क्रेडिट कार्ड transaction बनाई जा सकती है
    specs पूरी तरह public हैं और protocol भी documented है। याद से, PDF करीब 5000 पेज की थी, इसलिए पढ़ना बहुत दर्दनाक है
    लेकिन उस transaction को verify करने के लिए उसे Internet के जरिए bank को भेजना पड़ेगा, और तब federal agencies/FBI जैसी जगहों से लोग आपके पास आ सकते हैं
    कार्ड रीडर में खुद असली protection बहुत कम होती है; ज्यादातर एक छोटे Linux पर घटिया passwords इस्तेमाल करने जैसा होता है। protection store और bank के बीच contracts और regulations से आती है

    • यह कहना सही नहीं है कि कार्ड रीडर में protection नहीं होती। सिर्फ signed binaries ही run होती हैं, executable file system read-only होता है, और data file system पर noexec set होता है
      root login disabled होता है, बहुत सारे features निकाले हुए busybox का इस्तेमाल होता है, और boot के समय keys secure area से load होती हैं। master key injection सिर्फ factory loading के दौरान संभव है, boot खुद भी कुछ हद तक secure होता है, और tamper detection trigger होने पर chip खाली कर दी जाती है
      बेशक, अगर एशिया से आया कोई सस्ता, EMV-uncertified Android terminal है, तो standard Linux पर read/write root file system, root login, app चलाने वाले user के लिए sudo तक enabled होने की काफी संभावना है। tamper detection भी नहीं होगा, screen casting locked नहीं होगी, ports भी खोले जा सकेंगे और busybox भी लगभग पूरा हो सकता है
      कई सालों तक कार्ड acquiring के लिए EMV applications develop करने और अब भी कभी-कभी करने के अनुभव से, development mode तक में vendor को developer ID देनी पड़ती है और यह काफी tightly locked होता है
    • यह हिस्सा सही है कि store और bank के बीच contracts और regulations ही protection का मुख्य आधार हैं
      इसलिए portable कार्ड रीडर लेकर घूमते हुए contactless cards से पैसा चुराने जैसी conspiracy theories भी गलत हैं। ऐसी transaction खुद बनाई जा सकती है, लेकिन उसके बाद क्या होता है और पहले से कौन-सी setup चाहिए, समस्या वहां है
      पकड़े और blocked किए जाने से पहले पैसा निकाल पाना भी पक्का नहीं है। आजकल बहुत से लोग transaction push notifications enabled रखते हैं, इसलिए मुझे लगता है यह और मुश्किल है
    • यह सच नहीं है। merchant terminals में bank और card network keys store करने वाला secure hardware built-in होता है
      अगर वे keys leak हो जाएं, तो कोई normal transaction का नाटक कर सकता है
    • मुझे ज्यादा चिंता इस बात की है कि field में मौजूद card reader compromised होकर cached या stored असली card information पढ़वा दे, या interception malware install हो जाए
      इस specific case में यह मुश्किल या असंभव लगता है, लेकिन इसी वजह से इस area की research मायने रखती है
    • “2 डॉलर के USB कार्ड रीडर से fake debit/credit card transaction बनाई जा सकती है” वाली बात थोड़ा और detail में समझा सकते हैं? मेरा मतलब “तरीका सिखाइए” नहीं है

  • मुझे पता नहीं कि क्या देखना चाहिए, लेकिन मेरे पास मौजूद एक Stripe M2 reader को खोलकर अंदर देखने का temptation था
    समस्या यह है कि खरीदे गए 36 readers में से 7 “dead” हो गए। 2 charge hold नहीं करते, 1 NFC scan नहीं कर पाता, और 4 “tampered” दिखाते हैं। ऊपर से देखने पर loss rate बुरा है, लेकिन पूरी तस्वीर के लिए usage frequency और age देखनी होगी
    पर वह जवाब और भी खराब है। devices 1–3 साल पुराने हैं, और total usage days अधिकतम 9 दिन ही हैं। यानी कुल 9 दिन इस्तेमाल में 36 में से 7 किसी न किसी तरह fail हो गए। travel के दौरान भी सभी को foam inserts वाले hard-shell case में, हर reader के लिए अलग slot में रखा जाता है
    इसलिए M2 reader मुझे बहुत पसंद नहीं है, लेकिन फिर भी मेरे लिए यह best option है
    [0] background जोड़ूं तो, हमारी company festivals के payments process करती है। हम event venues पर जाकर iPad और M2 reader से in-person payments process करते हैं, और ज्यादातर payments web/app पर होते हैं। इसलिए 3 साल में “usage days” इतने कम हैं

    • अगले event तक store करने से पहले इन्हें जरूर charge कर लेना बेहतर है। ज्यादातर batteries low charge state में लंबे समय तक रखे जाने को पसंद नहीं करतीं
      और tamper detection को भी शायद ठीक से काम करने वाली battery चाहिए होती है

  • संभव है कि tamper seal trigger होने पर root shell खुलने वाली design हो
    यानी system या तो operation के लिए जरूरी cryptographic keys वाले secure mode में हो, या debugging और failure analysis के लिए root shell खुले हुए non-secure mode में हो, लेकिन उस transition में जरूरी private keys delete हो जाती हों

    • मैंने भी यही अंदाजा लगाया था। शायद नई keys flash करके device को फिर usable बनाना भी possible हो
      सच में एक terminal मिल सकता है या नहीं, यह जानने की curiosity हुई। अगर वे replace होकर गायब हो रहे हैं, तो used वाला ढूंढना शायद इतना मुश्किल न हो

  • जो लोग जल्दी excite हो जाते हैं, उनके लिए जोड़ दूं: इसमें लिखा है, “exposed root shell उतना बड़ा जोखिम नहीं लगता जितना शुरू में डर था। हमें ऐसा evidence नहीं मिला कि card information जैसा sensitive data इस तरीके से compromise हो सकता है”
    फिर भी security designers के लिए यह अच्छा read है

    • device तक physical access लेकर root privileges तक हासिल करने के बाद भी credit card number नहीं पढ़ पाना बहुत suspicious है
      security में physical access, और कुछ कम हद तक root access भी, practically successful hack के लगभग बराबर माना जाता है

  • अगर compromised Linux यह तय करता है कि “compromised mode” code और mp1 security system में से क्या load करना है, तो यह explore करने लायक path लगता है
    bootloader खुद secure बताया गया है, लेकिन actual execution location के हिसाब से अगर वह compromised environment में load होता है, तो उसका बहुत मतलब नहीं रह सकता
    co-processor को एक तरह के Secure Enclave की तरह देखा जा सकता है, लेकिन यह बात चिंताजनक है कि Linux अलग bootloader load और execute कर सकता है

    • अलग bootloader load नहीं किया जा सकता। मैंने loadercode नाम के “secure” bootloader को modify करके देखा, लेकिन boot नहीं हुआ
      इसलिए मेरा अनुमान है कि कोई third party, शायद boot ROM, इसे verify करता है
      साथ ही, Linux tamper state की परवाह किए बिना हमेशा loadercode और mp1.img load करता लगता है। tamper state के अनुसार अलग code path शायद integrity-protected loadercode के अंदर चुना जाता है

  • अगर आसान मोड चाहिए, तो आजकल आने वाले Android-आधारित card terminals देख सकते हैं
    खासकर क्योंकि PIN सीधे स्क्रीन पर दबाया जाता है, इसलिए इसके कहीं ज़्यादा rewarding होने की संभावना है

    • touch controller आम तौर पर security processor द्वारा नियंत्रित multiplexer से जुड़ा होता है
      PIN या PAN जैसे sensitive data डालते समय touch controller का output GUI संभालने वाले Android-वंश के operating system को bypass करके सीधे security processor तक route होता है
    • PIN data, touchpad पर दिखने के बावजूद, फिर भी encrypted रहता है और trusted area में चलने वाले firmware द्वारा नियंत्रित user interface का इस्तेमाल करता है
      इसलिए ऐसे हमलों में accessible intermediate applications PIN नहीं देख सकतीं
    • ऐसा करने पर PIN शायद काफ़ी आसानी से मिल जाए, लेकिन अगर ज़रूरी हिस्से उसी तरह design किए गए हैं कि वे security coprocessor को सौंप दिए जाएँ, तो फिर भी card से बहुत कुछ कर पाना संभव नहीं होगा
      modern cards ऐसे हमलों को रोकने के लिए card के अंदर ही बहुत सारे cryptographic operations करते हैं
      यह हमला शायद केवल उन terminals पर चलेगा जहाँ payment options में सिर्फ़ magnetic card reader बचा हो; ऐसे terminal पर तो PIN prompt दिखने से पहले ही skimmer warning light जल जानी चाहिए
    • अलग-अलग क्षेत्रों में कौन से Android terminals इस्तेमाल होते हैं, यह नहीं पता, लेकिन भारत में ये Android Oreo चलाते हुए लगते हैं। support जनवरी 2021 में खत्म हो गया था

  • शानदार। इस तरह की व्यापक tamper resistance जैसी hardware restrictions को bypass और exploit करने के तरीके सोचना मुझे पसंद है, लेकिन मैं अब तक मानता था कि एक बार यह trigger हो जाए तो game over है
    लेकिन ज़रूरी नहीं कि ऐसा ही हो; अभी भी झांकने लायक कई दिलचस्प हिस्से बचे थे। हालांकि security part का ठीक से disable हो जाना स्वाभाविक है। वरना designers पर मेरा सारा भरोसा खत्म हो जाता

    • hardened processor के बारे में यह बात अब भी सही हो सकती है। मूल लेख भी लिखता है कि compromise हुआ हिस्सा वह नहीं था
      सिर्फ़ text strings display_tool नाम के binary को pass की जाती हैं, और वह binary processors के बीच messages भेजता दिखता है। keypad और card reader के साथ भी ऐसा ही है। मुझे ऐसा कोई सबूत नहीं मिला कि ये peripherals Linux से सीधे accessible हैं
      इसके बजाय mp1 नाम का एक पूरी तरह अलग processor card processing, PIN input और screen information display जैसे “security” काम संभालता दिखता है। दूसरे processor mp2 पर चलने वाला “non-security” Linux सिर्फ़ networking, updates और business logic संभालता है
    • description से लगा कि Linux side tamper event handling में कोई भूमिका निभा सकती है
      फिर भी उम्मीद है कि संरचना ऐसी ही हो जिसमें वह सिर्फ़ यह देख सके कि tampering हुई है। वरना पहले root shell पाने के बाद tamper event द्वारा security keys deletion को रोकने का मौका मिल सकता है

  • device की सारी tamper detection पढ़ते हुए सोचने लगा कि tamper mode trigger करने का सबसे आसान तरीका क्या होगा
    आखिर अगर ऐसी कुछ devices को ही इस हालत में लाया जा सके, तो जिन दुकानों में payment का ज़्यादातर या पूरा हिस्सा इन्हीं terminals से होता है, वहाँ यह एक प्रभावी denial-of-service attack हो सकता है

    • नीचे गिरा देना या उस पर पानी डाल देना

  • ऐसी device में झांकना दिलचस्प है, लेकिन समझ नहीं आया कि इसे सीधे खोलकर tamper state क्यों trigger कर दिया। क्या उन्हें नहीं पता था कि ज़्यादातर readers में ऐसी व्यवस्था होती है?
    tamper state में किए गए actual tests शायद अर्थहीन भी हो सकते हैं। संभव है कि initialization के लिए tamper state में जाने पर shell खुलता हो
    देखने में device खोलना सबसे आखिर में आज़माने वाली चीज़ लगती है

    • पहले मुझे यह समझना ज़रूरी लगा कि मैं किस चीज़ से निपट रहा हूँ। hardware, कौन सा SoC है, interfaces, flash वगैरह
      वरना सब कुछ बहुत अंधेरे में था। हाँ, पीछे मुड़कर देखें तो बस debug connector पर tap लगाकर बात खत्म की जा सकती थी
      और मैंने दूसरी, untampered device पर भी shell हासिल किया

  • ऐसी devices यूरोप में हर जगह हैं। Switzerland के बारे में पक्का नहीं, लेकिन यूरोप के जिन बड़े हिस्सों को मैं जानता हूँ वहाँ लोग credit cards को वास्तव में रखते या बहुत इस्तेमाल नहीं करते
    मैं इसे POS, यानी point-of-sale system कहूँगा। ऐसी devices हर तरह के cards पढ़ सकती हैं। खैर, अच्छा लेख है

    • असल में काफ़ी इस्तेमाल करता हूँ। wallet में इतने सारे cards रखना पसंद नहीं। अलग-अलग वजहों से मेरे पास पहले से ही payment के लिए नहीं बने cards भी ढेर सारे हैं, इसलिए debit card जैसी चीज़ रखने की जगह भी नहीं बचती
      phone या smartwatch में और चीज़ें डालने का आकर्षण भी समझ नहीं आता। मुझे mechanical watch पसंद है, और phone खो जाए तो privacy के लिहाज़ से वह पहले ही काफ़ी बड़ी disaster है। बेशक यह मेरे मामले में है