Honda Civics और दुर्भावनापूर्ण valet parking

 (juniperspring.org)
1 पॉइंट द्वारा GN⁺ 3 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • 2021 मॉडल Honda Civic head unit USB update path से ऐसे updates स्वीकार कर सकता है जिन पर public AOSP test key से signature किया गया हो, जिससे physical access रखने वाला attacker arbitrary code चला सकता है
  • Honda के updates Android recovery के जरिए apply होते हैं, और recovery binary modify की गई होने के बावजूद verify_file signature verification logic default AOSP जैसा ही है
  • Public AOSP test key से sign करके और USB drive format को सही मिलाकर su और setuid के बिना भी मनचाहा code install किया जा सकता है; इसे EvilValet attack कहा गया है
  • नया tool ota-builder ऐसे update files तैयार करना आसान बनाता है जिन्हें head unit स्वीकार करता है, और apk-rebuilder update files को reverse engineering के लिए ज़रूरी output tree में बदलता है
  • Project ने ज़्यादातर investigation work पूरा कर लिया है, लेकिन repository बंद नहीं हुई है; version info, toolchain, custom themes, और AIDL mapping improvements में contributions की ज़रूरत है

Project update की पृष्ठभूमि

  • 3 साल पहले 2021 मॉडल Honda Civic के head unit को समझने और reverse engineer करने के शुरुआती काम को public किया गया था, और यह update उसके बाद की प्रगति को समेटता है
  • शुरुआती प्रतिक्रिया काफी उत्साहजनक थी, और सबसे बड़ी प्रगति update process को समझने के दौरान मिली

राज्य की चाबियाँ

  • Honda USB के जरिए head unit update को support करता है, और अंत में USB drive के भीतर signed AOSP update file को Android recovery के जरिए stage और apply किया जाता है
  • Honda के अपने कई checks मौजूद हैं, लेकिन res/keys में publicly known AOSP test key बची हुई थी, और modified recovery binary की verify_file signature logic भी default AOSP जैसी ही है
  • अगर USB drive को सही तरह format किया जाए और public AOSP test key से sign किया जाए, तो मौजूदा root access के बिना भी head unit पर मनचाही चीज़ install की जा सकती है
    • su पर setuid सेट करके मिलने वाले सामान्य root access की ज़रूरत नहीं है
    • अगर head unit में power है और attacker सबसे आगे वाले USB port तक physical access पा सकता है, तो update path के जरिए head unit पर arbitrary code execution संभव है
  • यह हमला होटल के कमरे में physical access वाले evil maid attack जैसा है, लेकिन इसमें कार के interior तक पहुँचना पड़ता है, इसलिए इसे EvilValet कहा गया है
    • उदाहरण के तौर पर, यदि होटल का valet parking कर्मचारी USB से update install कर दे, तो कार वापस मिलने के बाद driver को head unit में बदलाव का पता नहीं चलेगा
  • यह लेख technical detail document नहीं है; अधिक जानकारी Display Audio Update Files दस्तावेज़ में देखी जा सकती है
  • नया tool ota-builder ऐसे update files आसानी से तैयार करने देता है जिन्हें head unit स्वीकार कर लेता है
    • यह अभी शुरुआती अवस्था में है, लेकिन उदाहरण के लिए setuid सेट किए गए su binary को install करने वाली update file बनाना अब बहुत आसान हो गया है
  • यह मानने के मजबूत कारण हैं कि सभी updates public AOSP test key से sign किए गए थे, लेकिन सभी possible official update files और सभी head unit variant filesystems तक पहुँच नहीं मिली है
    • जिन head units की पुष्टि हुई, उनमें res/keys में AOSP test key थी, लेकिन HondaHack install history होने की वजह से keystore में key inject की गई हो सकती है
    • Publicly available EU software update file MRC_EU_SW_v12_4.zip test key से sign की गई थी, और यह public forum से download की गई बिना बदली हुई file थी
    • यह बहुत संभव है कि सभी updates AOSP test key से sign किए गए हों, लेकिन इस hypothesis को support या refute करने के लिए contributions की ज़रूरत है

Tools बनाना

  • Update process के अलावा सबसे उपयोगी काम apk-rebuilder का development था
  • apk-rebuilder इंटरनेट से प्राप्त Honda Civic update files को input के रूप में लेकर ऐसा साफ output file tree बनाता है जो उन manual tasks को automate करता है जिन्हें reverse engineer को खुद करना पड़ता
    • resource interpretation करता है
    • .smali code reconstruction करता है
    • APK file repackaging करता है
    • ramdisk extraction करता है
    • और अन्य काम भी करता है
  • क्योंकि असली Honda source code को public नहीं किया जा सकता, apk-rebuilder ऐसी function की तरह काम करता है जो public repository में host न की गई update files को input लेकर Honda .smali code, image assets, आदि output करता है
  • तैयार output एक स्पष्ट directory structure का पालन करते हैं, इसलिए sensitive files खुद upload किए बिना भी documentation में उनका reference दिया जा सकता है

बाकी काम और contribution की अपील

  • ज्ञात versions

    • Update process कमजोर है और version number पर काफी निर्भर करता है
    • Version number spoof किया जा सकता है, इसलिए unsigned code चलाने की क्षमता को यह सीमित नहीं करता
    • Update file बनाने के लिए यह जानना ज़रूरी है कि head unit कौन सा version expect करता है
    • उपयोग में मौजूद build से मेल न खाने वाले head unit software changes अनपेक्षित behavior और recovery loop का कारण बन सकते हैं
    • 10वीं पीढ़ी की Honda Civic चलाने वाले और तकनीक-जानकार users repository के Known Versions, Display Audio Software section में योगदान दे सकते हैं
    • खास तौर पर साहसी users ota-builder code पढ़कर update flash करने की कोशिश कर सकते हैं, लेकिन यदि head unit reference device से अलग हुआ तो recovery loop में फँस सकता है और device soft-brick हो सकता है

  • Toolchain

    • Local machine पर एक experimental और work-in-progress toolchain मौजूद है
    • यह toolchain candidate .c code लेकर उसे ARMv7 के लिए उसी compiler version और build flags के साथ compile करता है जो original vendor binary में इस्तेमाल हुए थे
    • Update process को समझने के काम में यह toolchain अनिवार्य था
    • अपने मौजूदा रूप में यह Docker का बहुत उपयोग करता है, लेकिन गंदा है और खास workflow के हिसाब से बहुत tailored है; एक साफ implementation public करने की इच्छा है

  • Custom themes

    • apk-renderer को vibe-coding करते समय कुछ custom themes की पड़ताल की गई
    • Custom themes Mitsubishi के AOSP framework fork के भीतर हैं, और head unit apps को hardcoded resource IDs की अपेक्षा करने के लिए shrink किया गया है, इसलिए deployment कठिन होने की संभावना है
    • Custom themes deploy करने के लिए vendor framework में surgical modifications करनी पड़ सकती हैं और इसे automate करने वाला tool लिखना पड़ सकता है
    • यह काम आसान नहीं है और शायद मेहनत के लायक भी न हो, फिर भी contributors का स्वागत है

  • aidl-rebuilder में सुधार

    • .smali files को parse करके head unit के सभी AIDL interfaces generate और map करने वाले tool पर काम शुरू हो चुका है
    • Tool काम करता है, लेकिन इसकी accuracy की पर्याप्त समीक्षा नहीं हो पाई है
    • यह काम virtual speedometer जैसे custom apps की संभावना खोलता है

Documentation और LLM पर विचार

  • Reference documents की तुलना में tooling पर अधिक ज़ोर दिया गया है
  • यदि भरोसेमंद और deterministic tools head unit code को अधिक समझने योग्य रूप में map कर दें, तो users LLM से उसी रूप पर सवाल पूछकर specific questions के जवाब ले सकते हैं
  • क्योंकि head unit code ही truth का source है, इसलिए ऐसे reference documents को बनाए रखने का बोझ कम किया जा सकता है जो असली code से अलग हो सकते हैं
  • ADB के जरिए head unit से connect करने वाली user guide अब भी उपयोगी है
  • जब Java code खुद LLM के उपयोग के लिए उपलब्ध हो, तब Java code के behavior पर अलग दस्तावेज़ बनाए रखना maintenance burden बन जाता है

समापन

  • Head unit पर किया जाने वाला अधिकांश intended investigation work पूरा हो चुका है
  • यह ऐसा project है जिस पर आगे भी समय लगाया जा सकता है, लेकिन अब संभव है कि ध्यान दूसरे projects की ओर चला जाए
  • Repository abandoned नहीं है, और PR हमेशा स्वागतयोग्य हैं

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

1 टिप्पणियां

 
GN⁺ 3 시간 전
Hacker News की राय

  • 10वीं पीढ़ी के Honda Civic अपडेट Honda एक विशेष फ़ॉर्मैट वाले USB ड्राइव के ज़रिए वितरित करता है, और असल में यह Android 4.2.2rc1 दौर के recovery package जैसा है जिसमें Honda ने सिर्फ version check जोड़ा है
    इस version check को धोखा दिया जा सकता है, और package को सार्वजनिक AOSP test key से sign किया गया है, इसलिए अगर सामने वाले USB पोर्ट तक physical access हो तो कोई भी मनचाहा package sign करके flash कर सकता है और head unit पर arbitrary code execution संभव है
    root/su की ज़रूरत नहीं पड़ती, इसे 2021 Civic पर आखिर तक चलाकर देखा गया है, और आधिकारिक EU update file भी AOSP test key signature इस्तेमाल करती है, यह अलग से पुष्टि की गई है

    • AOSP, Android Open Source Project का संक्षिप्त रूप है
    • उसी मॉडल वर्ष के Acura head unit भी Android 4.x आधारित हैं, इसलिए उनका analysis करने की कोशिश की थी, लेकिन update file पाने के चरण में अटक गया; update file कैसे मिली, यह जानने की जिज्ञासा है
    • दूसरी गाड़ियों के infotainment system में भी AOSP आधारित सिस्टम काफ़ी मिलते हैं। Hyundai update डाउनलोड करने पर भी याद है कि वह लगभग Android image ही निकला था

  • सड़क पर ज़्यादातर गाड़ियों में infotainment और onboard electronics security की हालत काफ़ी खराब होती है, और आजकल गाड़ियों में लगे mic, camera, GNSS receiver, Wi‑Fi, Bluetooth की वजह से वे चलती-फिरती surveillance platform जैसी बनती जा रही हैं
    ऑस्ट्रेलिया सरकार के Information Security Manual के मार्च 2026 संस्करण में यह control जोड़ा गया कि सरकारी devices को vehicle infotainment से connect न करें, और connected vehicle के अंदर या उसके पास sensitive material न देखें और sensitive बातचीत न करें
    https://www.cyber.gov.au/business-government/asds-cyber-secu...

    • क्या NC sensitivity framework में सबसे निचला स्तर नहीं है?
    • यह मुझे ठीक लगता है। यह car radio है, कोई core system नहीं
      जो लोग ऐसे हमलों के प्रति संवेदनशील हो सकते हैं, उनके पास काम करने की प्रक्रिया और trusted equipment अलग होते हैं, और अमेरिका की law enforcement agencies में भी OnStar आने के बाद rental car के लिए ऐसे ही नियम थे
      आम लोगों के लिए जोखिमभरी telematics जानकारी का अधिकांश हिस्सा तो वैसे भी बेचा जा रहा है

  • एक तरफ़ लोग हमारे जीवन के ज़्यादातर devices में लगातार घटते hardware ownership के खिलाफ़ लड़ते हैं, और दूसरी तरफ़ जैसे ही कोई ज़्यादा खुला device आता है, उसी पर हमला करने लगते हैं
    तकनीक में threat model हमेशा यही मानकर चलता था कि अगर attacker को device पर physical access और समय मिल जाए, तो खेल खत्म है

    • लेकिन यह आम लोगों के लिए modify करने लायक खुला भी तो नहीं है? निर्माता को दिशा तय करनी चाहिए। या तो पूरी तरह खोलें ताकि ज़रूरतमंद लोग खुद इसे harden कर सकें और trade-off समझ सकें, या फिर पूरी तरह बंद करके सुरक्षित बनाएं
      अभी जैसी स्थिति, जहाँ गाड़ी ड्राइव के दौरान उपयोगकर्ता पर नज़र रखने वाला privacy-invasive device भी है, और थोड़ा-सा दिलचस्पी रखने वाले को भी उसका data दे देने वाला unsafe device भी, सबसे खराब है
    • हाल की BitLocker vulnerability में भी ऐसा ही मामला दिखता है। अब जबकि lock खोलने योग्य storage hardware आ गया है, देखना है कि क्या नए मामले सुलझेंगे या लोग जेल जाएंगे
      अगर data ज़ब्त किया जा सकता है तो उसे local में न रखना बेहतर है; क़ानून के तहत unlock करने पर मजबूर भी किया जा सकता है, लेकिन अमेरिका में password देने से इंकार करना सुरक्षित होना चाहिए
      तकनीकी रूप से Google और Apple ने physical security में काफ़ी सुधार किया है, और GrapheneOS ने उसी आधार पर attack surface घटाकर और अच्छे features जोड़कर इसे एक कदम आगे बढ़ाया है। खासकर auto reboot के व्यापक रूप से अपनाए जाने के बाद, फ़ोन के मामले में “physical access मिले तो खेल खत्म” वाले निष्कर्ष को अब संशोधित किया जा सकता है
      https://grapheneos.org/features#auto-reboot
      https://discuss.grapheneos.org/d/35728-demystifying-phone-un...
    • इसका मतलब यह नहीं कि local device security छोड़ दी जाए। physical device में login security होती ही है, और संभव है full-disk encryption भी इस्तेमाल हो रहा हो
      सिर्फ़ इसलिए कि कोई काफ़ी उन्नत और ज़िद्दी attacker physical access से किसी भी device पर क़ब्ज़ा कर सकता है, इसका मतलब यह नहीं कि उसे हर किसी के लिए आसान बना दिया जाए

  • यहाँ Honda दूसरे car makers की तुलना में कहीं ज़्यादा तर्कसंगत लगती है
    अगर कोई valet दुर्भावना के साथ गाड़ी तक physical access पा सकता है, तो वह head unit hack करने में समय बर्बाद नहीं करेगा, बस गाड़ी में कहीं bugging device छिपा देगा
    और फिर Civic driver के किसी intelligence agency का target बनने की संभावना भी नहीं लगती

    • अगर यह मज़ाक था तो ठीक, लेकिन नहीं था तो बात काफ़ी बेतुकी है। Honda ने जानबूझकर इसे ऐसा बनाया होगा, इसकी संभावना भी कम है
      head unit में आम तौर पर sync के बाद बचा हुआ contacts SQLite database, location history, telemetry या log files में बचे पुराने data जैसी historical information होती है
      और head unit को अक्सर vehicle internal bus तक access मिल सकता है, और Gateway module जैसे firewall हों तब भी वे आम तौर पर कमज़ोर होते हैं। Honda के उस मशहूर मामले की तरह, जहाँ headlight जैसे CAN bus path के ज़रिए बिना किसी cryptographic material के unlock और ignition authorization संभव था, infotainment सिर्फ़ tracking device से कहीं ज़्यादा ताकतवर हो सकता है
      ऊपर से head unit में code implant करना या पहले से मौजूद data निकालना, अलग tracker चिपकाने की तुलना में बहुत कम निशान छोड़ता है
    • अगर यह तंज था तो ठीक, लेकिन अगर नहीं, तो समझ नहीं आता कि Civic driver intelligence agency का target क्यों नहीं हो सकता
      Civic सबसे आम गाड़ियों में से एक है, इसलिए background में घुल-मिल जाना आसान है, और scientist, engineer, journalist, lawyer जैसे “साधारण दिखने वाले” लोग भी Honda Civic चला सकते हैं
      गाड़ी में छिपाया गया bugging device मिल सकता है, लेकिन vehicle firmware के अंदर सीधे डाली गई चीज़ के पकड़े जाने की संभावना कम होती है
    • क्या आपको लगता है कि confidential access रखने वाला कोई उबाऊ scientist या engineer रोज़मर्रा की Civic चलाकर दफ़्तर नहीं जाता?

  • मैंने एक product manager को बड़े गर्व से कहते सुना था कि firmware को company के internal signing service से sign किया गया है। अपने आप में यह अच्छी बात है
    लेकिन असल सवाल यह था कि internal compliance requirement के लिए firmware sign किया गया है या नहीं, यह नहीं कि firmware update procedure उस signature को verify भी करती है या नहीं, और हक़ीक़त में वह बिल्कुल verify नहीं करती थी

    • ऐसा ही एक “solution” मैंने भी देखा है। signature algorithm को सीधे update package के भीतर से execute किया जा रहा था

  • "वरना signature algorithm को अपडेट कैसे करेंगे" जैसी बात थी, और सबसे बुरी बात यह है कि एक समय पर यह सही तरीके से किया गया था
    security team ने "post-quantum safe" signature की मांग की, जिससे signing method बदला गया, और उसी प्रक्रिया में यह regression bug के रूप में आ गया

    • अगर नाम BobbyTables2 है, तो उम्मीद थी कि कम-से-कम email PGP signature verify करने का सही तरीका तुरंत दिमाग में आएगा

  • मेरा मानना है कि security और devices को लंबे समय तक उपयोगी बनाए रखने के बीच एक सीमा होती है। किसी malicious maid-स्टाइल हमले से कार में eavesdropping malware इंस्टॉल होने का खतरा कम लगता है
    लेकिन जब ये कारें 10 साल से ज़्यादा पुरानी होकर उन लोगों तक पहुंचेंगी जो इनके साथ छेड़छाड़ करना चाहेंगे, तब software को खोलकर customize करने की क्षमता एक शानदार फायदा होगी
    अच्छा होगा अगर उपयोगी modifications बनाने वाला community बने और devices की उम्र बढ़े। यह उससे कहीं बेहतर लगता है कि end user stock head unit निकालकर उसकी जगह Aliexpress-स्टाइल "Android tablet" unit लगा दे, जिसकी security और engineering quality Honda device से भी खराब होने की संभावना ज़्यादा है

  • यह इस बात का अच्छा संकेत भी हो सकता है कि सिस्टम को मालिक से लॉक करने का विचार तक नहीं था

    • कार में थोड़ी देर के लिए आने वाले किसी भी व्यक्ति को root access देना अच्छी बात नहीं है। यह ऐसा है जैसे दफ्तर में हमेशा चालू और shell खुला हुआ laptop छोड़ देना
      अगर updates को by default पूरी तरह trust नहीं करना था, तो actual owner के लिए update approve करने का mechanism देना चाहिए था
    • hacker-friendly होने से ज़्यादा यह अयोग्यता का नतीजा होने की संभावना है
      अगर यह सच में जानबूझकर किया गया होता, तो unlockable bootloader जैसा कुछ होता जिसके लिए special key चाहिए, या कोई switch जिसे पहुंचना मुश्किल हो

  • शायद कार को पहियों वाला विशाल कंप्यूटर बना देना बुरा विचार था। इस पर और research की ज़रूरत है

  • बाकी security कितनी ठीक है, यह जानने की जिज्ञासा है। head unit शायद CAN gateway से जुड़ा होगा; हो सकता है कि इसे telematics के जरिए call किया जा सके, या CarPlay/Android Auto का दुरुपयोग कर इसे घर से communicate कराने का कोई नया तरीका निकले

    • अगर कार तक physical access है और घर से communicate करना है, तो floor mat के नीचे GPS tracker रखने की सिफारिश करूंगा
      यह सिर्फ Honda Civic की एक generation तक सीमित तरीके से बेहतर है, क्योंकि यह ज़्यादा brands में काम करेगा, और install करना भी शायद तेज होगा

  • मैं देख रहा हूं कि ज़्यादा से ज़्यादा projects इस सोच के साथ code documentation कम कर रहे हैं कि "well-designed code को LLM से query किया जा सकता है", और उसकी जगह functional runbook documentation पर ध्यान दे रहे हैं
    किसी भी समय project की सारी documentation का code के साथ up to date होना वास्तव में बहुत कम संभावना वाली बात है
    कुल मिलाकर मैं इस दिशा से सहमत हूं, लेकिन शर्त यही है कि code well-designed हो

    • documentation से बेहतर है कि unit tests को documentation की तरह देखा जाए
      tests intended usage और दिलचस्प boundary cases दिखा सकते हैं, और वे लगातार run होकर pass भी हो रहे हैं, इसलिए यह भी पता चलता है कि वे up to date हैं
      ज़्यादा tests जोड़ते समय यह एक बड़ा लेकिन अक्सर कम आंका गया फायदा है
      अगर लगता है कि developer किसी behavior या boundary case के बारे में पूछ सकता है, तो उसे दोबारा reasoning करने पर मजबूर करने के बजाय ऐसा test होना बेहतर है जो सीधे उस सवाल का जवाब साबित कर सके