4 पॉइंट द्वारा GN⁺ 2025-06-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Worldline Yomani XR क्रेडिट कार्ड टर्मिनल की security research के लिए reverse engineering की गई
  • आंतरिक teardown के दौरान physical tamper detection फीचर अच्छी तरह लागू मिला, लेकिन software स्तर पर external serial port पर root shell उजागर होने की समस्या सामने आई
  • memory dump, firmware extraction और analysis के जरिए Linux 3.6 kernel आधारित system की संरचना और बहुत पुराने components की पुष्टि हुई
  • serial console port के जरिए डिवाइस को खोले बिना भी आसानी से root access हासिल कर malicious code install करना संभव होने का प्रमाण मिला
  • पूरे payment और authentication से जुड़े महत्वपूर्ण काम अलग security processor में होते हैं, इसलिए वास्तव में महत्वपूर्ण data exposure का जोखिम बड़ा नहीं है

प्रोजेक्ट अवलोकन

  • यह प्रोजेक्ट payment terminal की security research के उद्देश्य से Worldline Yomani XR मॉडल की reverse engineering प्रक्रिया पर केंद्रित है
  • स्विट्ज़रलैंड भर में व्यापक रूप से इस्तेमाल होने वाला यह मॉडल अब discontinued है, लेकिन कई बड़े retail stores और छोटे merchants में अब भी उपयोग में है

शुरुआती अवलोकन और hardware teardown

  • UI exploration, port scanning जैसी बुनियादी जांच के बाद hardware teardown शुरू किया गया
  • कई PCB, अच्छी तरह डिज़ाइन किया गया housing, custom ASIC आधारित dual-core Arm processor आदि से काफ़ी मजबूत hardware security दिखाई दी
  • मुख्य SoC Samoa II कोडनेम वाला एक dedicated ASIC है, जिसके बाहर flash और RAM लगे हैं

intrusion detection और tamper protection

  • housing खोले बिना भी pressure-sensing board connection (Zebra strip) में गड़बड़ी या screw ढीला होने मात्र से intrusion event detect हो जाता है
  • battery की वजह से power cut की स्थिति में भी detection सक्रिय रहता है
  • मुख्य PCB पर zigzag traces और card reader के चारों ओर लिपटा flexible PCB क्षतिग्रस्त होने पर intrusion detect हो जाता है
  • थोड़ी देर के लिए dismantle करके फिर reassemble करने पर intrusion detection की वजह से डिवाइस केवल लाल "TAMPER DETECTED" स्क्रीन दिखाता है और external input का जवाब नहीं देता

chip-off firmware extraction

  • onboard flash को desolder करके सीधे connect कर firmware निकाला गया
  • data encrypted नहीं था, लेकिन एक अनोखी ECC संरचना और YAFFS2 file system के metadata layout की पहचान हुई
  • file system reader implement करके पूरी file list हासिल की गई
  • system में 2010 version Buildroot आधारित 3.6 kernel इस्तेमाल हो रहा था, और uClibc, busybox तथा कई पुरानी libraries मौजूद थीं

संयोग से root shell मिलने की प्रक्रिया

  • firmware analysis के बाद flash को फिर जोड़ा गया और serial console lines खोजकर logic analyzer से signal पकड़े गए
  • boot log के साथ login prompt दिखाई दिया
  • "root" दर्ज करते ही बिना password के तुरंत root shell में प्रवेश संभव था
  • वास्तव में यह serial port सिर्फ cover खोलते ही बाहर से सीधे accessible था
  • attacker टर्मिनल को dismantle किए बिना भी तेज़ी से access लेकर malicious code inject कर सकता है

यह समस्या कितनी गंभीर है?

  • boot और system configuration analysis से पता चला कि Linux केवल network, updates और कुछ business logic संभालता है
  • card payment, PIN input, display सहित सभी security-related functions अलग mp1 processor द्वारा प्रबंधित होते हैं
  • Linux (mp2) हमेशा boot होता है, और उसके बाद signed·encrypted image को security bootloader द्वारा secure core में load किया जाता है
  • अंदरूनी रूप से secure core protection सही ढंग से काम कर रही थी, और security-critical data root shell exposure से लीक नहीं होता

disclosure और reporting timeline

  • 14 नवंबर 2024: root shell मिला
  • 15 नवंबर 2024: निर्माता को 90-दिन disclosure योजना के साथ सूचित किया गया
  • 18 नवंबर 2024: निर्माता की ओर से report receipt की पुष्टि मिली
  • 1 जून 2025: प्रोजेक्ट सार्वजनिक किया गया

निष्कर्ष

  • external serial port के जरिए root shell exposure स्पष्ट रूप से एक अनावश्यक attack surface और engineering mistake है
  • हालांकि security processor separation design की वजह से वास्तविक payment information exposure का जोखिम कम है
  • production firmware में root login की अनुमति गलती से लागू हुई हो सकती है, या यह version के अनुसार अलग हो सकता है
  • research के दौरान कुछ डिवाइस ऐसे भी मिले जिनमें root login फीचर पूरी तरह disabled था
  • संभव है कि आंतरिक रूप से इस समस्या को पहले ही पहचाना और ठीक किया जा चुका हो

इस प्रोजेक्ट ने कई दिलचस्प नतीजे दिए और firmware की गहराई से जांच के महत्व को फिर से दिखाया

1 टिप्पणियां

 
GN⁺ 2025-06-02
Hacker News की राय
  • युवा डेवलपर्स के लिए एक बात: “Hacker News” में ‘हैकर’ का मतलब वास्तव में यही है; इस पोस्ट की सिफारिश इस रूप में कि यह एक टिपिकल हैकर यात्रा का आसान step-by-step विश्लेषण दिखाती है; अगर ऐसे और उदाहरण देखने हों तो Hack-a-day देखना उपयोगी हो सकता है; लेखक काफ़ी जिज्ञासु और बुनियादी ज्ञान में बहुत मज़बूत व्यक्ति लगता है; मूल रूप से यह chip datasheet की जाँच, बिना नुकसान desoldering, अगर memory हो तो wire से दोबारा जोड़ना, मौके के हिसाब से काम चलाना और trial and error की कहानी है; अगली बार उथला छेद करते समय pinhole camera का उपयोग करके छेड़छाड़ के निशान से बचने का तरीका भी सोचा जा सकता है; और अगर लेखक tamper check को भी पार करके सामान्य operation तक ले जाता, तो वह सचमुच और भी दिलचस्प होता

    • यह व्याख्या कि ‘हैकर’ शब्द सिर्फ computer security तक सीमित नहीं है, बल्कि इसका कहीं अधिक व्यापक अर्थ और दार्शनिक परिभाषा है; Guy Steele आदि द्वारा संकलित Jargon File का हवाला देते हुए हैकर की परिभाषाएँ दी गईं, जैसे “वह व्यक्ति जो programming systems की बारीकियाँ सीखने और उनकी सीमाएँ बढ़ाने का आनंद लेता है”, “वह जो programming को ही जुनून के साथ enjoy करता है”, और “किसी खास program में निपुण expert” तक; साथ में यह अनुमान कि शायद Hacker News के संस्थापक PG ने भी नाम रखते समय इसी व्यापक अर्थ को ध्यान में रखा होगा; और हैकर शब्दावली के इतिहास में The UNIX-HATERS Handbook का उल्लेख ज़रूर होना चाहिए

    • पहले वाक्य से पूरी तरह सहमत; आजकल अगर एक और LLM wrapper आ गया तो सच में ऊब हो जाएगी

    • यह राय कि सिर्फ इसलिए कि यह साइट VC startup incubator से निकली है, इसका मतलब hacking security नहीं मान लेना चाहिए; शायद इसका अर्थ startup शैली की “move fast and break things” वाली hacking के अधिक क़रीब है, यानी तेज़ी से code निकालकर समस्याओं को तोड़ते हुए आगे बढ़ना

    • लंबे समय तक सिर्फ़ पढ़ते रहने के बाद हाल ही में account बनाकर comments लिखना शुरू किया, और ऐसी जानकारीपूर्ण व execution-केंद्रित पोस्ट ही Hacker News की ‘हैकर’ भावना दिखाती हैं, ऐसी प्रशंसा

    • यह स्वीकारोक्ति कि पोस्ट वास्तव में hacking पर थी, इसलिए पहली बार upvote बटन दबाया; आम तौर पर केवल comments को upvote देता हूँ, लेकिन यह पोस्ट अपवाद थी

  • $2 USB card reader से नकली credit/debit card transaction simulation संभव होने का परिचय; सभी specifications और protocols बहुत विशाल हैं, लेकिन public हैं, इसलिए documentation पढ़कर implementation किया जा सकता है; लेकिन किसी वास्तविक transaction को approve करवाने के लिए internet के ज़रिए bank को data भेजना पड़ेगा, और ऐसा करने पर तुरंत authorities (जैसे FBI) सक्रिय हो सकती हैं, ऐसी चेतावनी; card reader में खुद लगभग कोई सुरक्षा नहीं होती (अधिकांश Linux और कमज़ोर passwords पर चलते हैं), और असली security store और bank के बीच contracts और regulations से आती है

    • card reader में ‘कोई सुरक्षा नहीं’ वाली बात का खंडन; वास्तव में केवल signed binaries ही चल सकती हैं, executable filesystem read-only है, data filesystem पर भी noexec flag है, root login disabled है, busybox सीमित है, keys boot के समय secure area से load होती हैं, master key insertion भी केवल factory में संभव है, boot खुद बहुत secure है, और tamper detect होने पर chip खुद को blank initialize कर देती है; यह भी जोड़ा कि सस्ते non-certified terminals में सुरक्षा लगभग न के बराबर हो सकती है, लेकिन EMV development के अनुभव के आधार पर असली terminals लगभग पूरी तरह locked down होते हैं

    • ‘store और bank के बीच regulation ही एकमात्र security है’ वाले हिस्से को सही मानना; इसलिए portable card reader से contactless card से पैसा चुरा लेने जैसी conspiracy theories को व्यवहार में लाना बहुत कठिन है; अगर transaction बना भी लिया जाए, तब भी बाद की प्रक्रिया और पहले की तैयारी के कारण पैसे को सुरक्षित निकाल लेना लगभग असंभव के करीब है; खासकर आजकल transaction push notifications के कारण अपराध का प्रयास जल्दी सामने आ सकता है

    • ज़्यादा चिंता इस बात की है कि field में card reader hack होकर cached CC data पढ़ लिया जाए या intercepting malware install हो जाए; इसी वजह से इस क्षेत्र का research महत्वपूर्ण है

    • यह कहना कि approval के लिए transactions को internet से bank तक भेजना ज़रूरी है, तथ्यात्मक रूप से सही नहीं; banks के पास card transactions process करने के लिए internet पर कोई open API नहीं होता

    • card reader security को कमज़ोर कहना ठीक नहीं; वास्तव में store terminals में bank और payment network keys को सुरक्षित रखने के लिए secure hardware built-in होता है; और अगर वे keys leak हो जाएँ तो वैध transactions को forge करना संभव हो सकता है

  • Stripe M2 reader के 36 units खरीदकर इस्तेमाल करने का अनुभव, जिनमें 7 खराब हो गए; 2 की battery charge नहीं रखती, 1 NFC scan नहीं कर पाता, और 4 ‘tampered’ error दिखाकर बंद हो गए; ऊपर-ऊपर से failure rate गंभीर लगता है, लेकिन usage days और उम्र जैसे context भी देखने चाहिए; फिर भी यह ज़्यादा गंभीर लगता है कि कुल मिलाकर 1–3 साल पुराने readers को सिर्फ 9 दिन इस्तेमाल किया गया था और फिर भी 7 खराब हो गए; transport के समय हर unit को hardshell case और foam insert में बहुत सावधानी से रखा जाता है, इसलिए storage mishandling भी कारण नहीं लगता; इसके बावजूद Stripe M2 reader अभी भी सबसे उपयोगी विकल्प है, इसलिए मजबूरी में वही इस्तेमाल हो रहा है; साथ में यह संदर्भ भी कि कंपनी festivals में payment संभालती है, इसलिए कम समय के लिए बड़ी संख्या में units इस्तेमाल होते हैं

    • अगली event से पहले devices को पूरी तरह charged रखकर store करने की सलाह; अधिकांश batteries लंबे समय तक low charge state में पड़े रहना पसंद नहीं करतीं, और tamper detection feature भी शायद battery ठीक होने पर ही सही से काम करता हो
  • यह कल्पना कि physical tamper protection activate होने पर root shell खुल सकता है; यानी system या तो उस security mode में जाता होगा जहाँ ज़रूरी cryptographic keys मौजूद हों, या फिर root shell खोलकर debugging/failure analysis mode में switch करता होगा; बस उम्मीद यही कि उस समय महत्वपूर्ण private keys अपने आप delete हो जाती हों

    • यह राय कि root shell के ज़रिए नई keys flash करके reuse संभव हो सकता है या नहीं, यह जानने की जिज्ञासा हुई; और अगर terminal retirement के क़रीब हो, तो सेकंड-हैंड हासिल करना शायद बहुत मुश्किल नहीं होगा
  • मूल पोस्ट के इस कथन के साथ कि ‘root shell खुलने पर भी card information जोखिम में नहीं पड़ती’, इसे security designers के लिए ज़रूर पढ़ने लायक सामग्री बताया गया

    • यह राय कि अगर terminal तक physical access भी हो और root privileges भी, तो फिर card numbers पढ़ना असंभव है—यह बात बिल्कुल समझ में नहीं आती; security की दुनिया में physical access और root access का मतलब आम तौर पर compromise हो जाना ही है
  • यह राय कि (tampered) Linux यह तय करता है कि “compromised mode” code पढ़ना है या mp1 security system; भले bootloader खुद secure हो, लेकिन वह वास्तव में किस environment में run होता है, इससे उसकी अहमियत बदल सकती है; co-processor Secure Enclave जैसी भूमिका निभा सकता है, लेकिन अगर Linux कोई अलग bootloader लोड कर सके तो यह सुरक्षा के लिहाज़ से गंभीर समस्या होगी

    • अलग bootloader load नहीं किया जा सकता, ऐसा जवाब; खुद tamper करके bootloader बदलने की कोशिश की गई लेकिन system सामान्य रूप से boot नहीं हुआ, इसलिए अंदाज़ा है कि कोई तीसरा boot ROM verification करता है; साथ ही Linux tamper state की परवाह किए बिना हमेशा loadercode और mp1.img दोनों को साथ लोड करता है, और tamper state के आधार पर branching (integrity-protected) loadercode के भीतर होती है
  • beginners के लिए सलाह कि पहले आधुनिक Android-आधारित credit card terminal पर हाथ आज़माएँ; touchscreen पर PIN डालना इसे और मज़ेदार बनाता है

    • touchscreen controller आम तौर पर security processor द्वारा नियंत्रित MUX से जुड़ा होता है, और secure input के समय touch input सीधे security processor को जाता है, Android जैसे operating system के दखल के बिना

    • यह भी कि touchpad पर दिखने के बावजूद PIN data trust zone में चल रहे firmware द्वारा managed और encrypted रहता है; बीच में मौजूद apps PIN नहीं देख सकते

    • ऐसी Android terminal को hack कर लेने पर भी, अगर security design वही है, तो card खुद जटिल encryption करता है, इसलिए व्यावहारिक रूप से उपयोगी information नहीं मिलेगी; ऐसा हमला तभी काम आएगा जब सिर्फ़ credit card reader बचा हो, और ऐसी terminal तो अपने-आप में user के लिए skimmer risk का संकेत होगी

    • यह संक्षिप्त टिप्पणी कि भारत में इस्तेमाल होने वाले Android terminals अब भी Android Oreo (जनवरी 2021 में support समाप्त) पर चलते हैं, जो दिलचस्प लगा

  • terminal का analysis शुरू करते ही उसे खोलकर tamper mode trigger कर देना कुछ अजीब लगा; शायद इस बात का अंदाज़ा नहीं था कि अधिकांश readers में tamper detection होता है; tamper mode में test करने का महत्व कम हो सकता है, और यह भी जिज्ञासा कि क्या tamper trigger के बाद initialization के लिए shell खुलती है; अंत में यह सलाह कि क्या शुरुआत से ही खोलना ज़रूरी था, इस पर फिर से सोचना चाहिए

    • शुरुआत में hardware, SoC, interfaces, flash आदि की बुनियादी जानकारी जानना ज़रूरी लगा, इसलिए खोला; बिना pre-research के शुरू करना बहुत अँधेरे में चलने जैसा लगा; बाद में लगा कि शायद सिर्फ़ debug connector को हल्का-सा छूने भर से काम हो सकता था; और यह अतिरिक्त जानकारी भी कि दूसरे, सही-सलामत terminal पर भी shell हासिल करने में सफलता मिली
  • यह प्रशंसा कि ‘इतनी मज़बूत tamper protection के बावजूद bypass करने लायक चीज़ें और दिलचस्प निशान अभी भी काफ़ी बचे हुए हैं’; security part का safely fail होना सही design है

    • इस बात पर ज़ोर कि hardened processor (mp1) अब भी अप्रवेश्य है; वास्तव में Linux सिर्फ़ string को display_tool binary तक भेजता है ताकि दूसरे processor के साथ messages का आदान-प्रदान हो सके; card reader या keypad जैसी चीज़ों तक Linux की direct access नहीं है, बल्कि पूरी तरह अलग mp1 processor card, PIN input, screen display जैसे ‘secure’ काम संभालता है, जबकि mp2 Linux केवल network, updates और business logic चलाता है

    • यह scenario कि Linux पक्ष tamper event handling को detect करने की भूमिका निभा सकता है, लेकिन अगर security keys केवल tamper को पूरी तरह detect करने के बाद ही delete होती हों, तो पहले से root shell लेने के बाद tamper bypass करने की गुंजाइश जोखिम पैदा कर सकती है

  • यह तथ्य कि ऐसे terminals पूरे Europe में फैले हुए हैं; Switzerland का निश्चित पता नहीं, लेकिन अनुभव के अनुसार Europe के कई हिस्सों में लोगों के पास credit card कम होते हैं; इसके बजाय POS terminal तरह-तरह के cards पढ़ सकते हैं, इसलिए इन्हें ‘POS system’ कहना ज़्यादा उचित लगता है; फिर भी पोस्ट पढ़ने में मज़ा आया

    • कई cards को wallet में लेकर घूमना सचमुच नापसंद है; पहले ही कई वजहों से (सिर्फ़ payment नहीं) wallet फटने की हालत में रहता है, इसलिए phone या smartwatch में और चीज़ें जोड़ना भी पसंद नहीं; device खोने पर personal information leak होना बहुत भारी risk लगता है; यह व्यक्तिगत पसंद है, लेकिन mechanical watch पसंद है, और इसी कारण card simplification वाले तरीक़े इस्तेमाल नहीं करता/करती