Operation Triangulation: शोधकर्ताओं के iPhone पर हमला करने से क्या हासिल होता है

 (securelist.com)
1 पॉइंट द्वारा GN⁺ 2023-12-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Kaspersky के शोधकर्ताओं ने 37C3 में Operation Triangulation की iPhone 0-click iMessage attack chain को सार्वजनिक किया, और इसे अब तक देखी गई सबसे परिष्कृत chains में से एक माना
  • हमला iOS 16.2 तक काम करने के लिए डिज़ाइन किया गया था, और इसमें 4 zero-days को जोड़कर remote code execution, privilege escalation, PPL bypass, और Safari stage execution हासिल किया गया
  • मुख्य रहस्य CVE-2023-38606 है, जो mitigated section में आता है; हमलावरों ने Apple A12–A16 Bionic SoC के अज्ञात MMIO registers का उपयोग करके hardware-based kernel memory protection को bypass किया
  • विश्लेषण से पता चला कि ये registers संभवतः GPU सहायक प्रोसेसर से जुड़े हैं, और इनमें से कुछ का DeviceTree या firmware में कोई संदर्भ नहीं मिलता, इसलिए हमलावरों को इनके इस्तेमाल का तरीका कैसे पता चला यह स्पष्ट नहीं है
  • 9 जनवरी 2024 के update में, जो values पहले “custom hash” जैसी लग रही थीं, वे वास्तव में Hamming code-based ECC निकलीं, और अब यह अधिक संभव माना जा रहा है कि यह feature memory की बजाय cache तक direct access देने वाला debugging feature था

सार्वजनिक की गई attack chain

  • 27 दिसंबर 2023 की 37C3 प्रस्तुति में Operation Triangulation के दीर्घकालिक विश्लेषण के परिणाम सार्वजनिक किए गए
  • इसी प्रस्तुति में हमले में इस्तेमाल किए गए exploits और vulnerabilities के विवरण पहली बार सामने आए
  • शोधकर्ताओं ने Adobe, Apple, Google, Microsoft उत्पादों में 30 से अधिक actively exploited zero-days खोजे और रिपोर्ट किए हैं, लेकिन इस attack chain को उनमें भी सबसे परिष्कृत स्तर का माना गया

iMessage 0-click से spyware loading तक

  • हमलावर एक malicious iMessage attachment भेजते थे, और application उसे उपयोगकर्ता को दिखाए बिना process कर लेता था
  • attachment ने Apple के लिए विशेष, undocumented ADJUST TrueType font command में मौजूद remote code execution vulnerability CVE-2023-41990 का दुरुपयोग किया
    • यह command 1990 के शुरुआती दशक से मौजूद थी और patch के साथ हटा दी गई
  • इसके बाद return/jump oriented programming और NSExpression/NSPredicate query language में लिखे गए कई stages चलते थे
    • JavaScriptCore environment को patch करके JavaScript में लिखे गए privilege escalation exploit को चलाया जाता था
  • JavaScript exploit को आकार में छोटा किया गया था और पूरी तरह पढ़ने में कठिन obfuscation की गई थी, लेकिन इसका आकार लगभग 11,000 lines था
    • इसका अधिकांश हिस्सा JavaScriptCore और kernel memory parsing/manipulation के लिए इस्तेमाल होता था
  • JavaScriptCore debugging feature DollarVM($vm) का दुरुपयोग करके script से JavaScriptCore memory manipulate की जाती थी और native API functions चलाए जाते थे
  • इसे पुराने और नए दोनों iPhone models को support करने के लिए डिज़ाइन किया गया था, और नए models के exploitation के लिए PAC bypass भी शामिल था

kernel memory access और PPL bypass

  • exploit ने XNU memory mapping syscalls mach_make_memory_entry और vm_map में integer overflow vulnerability CVE-2023-32434 का उपयोग किया
    • user level से device की पूरी physical memory पर read/write access हासिल कर लिया जाता था
  • इसके बाद hardware MMIO registers के जरिए Page Protection Layer(PPL) को bypass किया गया
    • इस हिस्से को CVE-2023-38606 के रूप में mitigate किया गया
  • सभी vulnerabilities के exploit होने के बाद JavaScript exploit device पर arbitrary actions कर सकता था
    • हमलावर IMAgent process चलाकर payload inject करते थे और exploit के traces मिटा देते थे
    • Safari process को invisible mode में चलाकर अगले stage के web page पर भेजा जाता था
  • web page पहले victim की पुष्टि करता था, और शर्तें पूरी होने पर Safari exploit पहुँचाता था
  • Safari exploit CVE-2023-32435 का उपयोग करके shellcode चलाता था
  • shellcode Mach object file के रूप में एक और kernel exploit चलाता था
    • यह exploit भी CVE-2023-32434 और CVE-2023-38606 का उपयोग करता था
    • यह JavaScript kernel exploit से अधिकांशतः अलग था, लेकिन vulnerability exploitation से जुड़ा कुछ code साझा करता था
  • अंततः root privileges हासिल किए जाते थे और आगे के stages चलाकर spyware load किया जाता था

CVE-2023-38606 का hardware mystery

  • नवीनतम iPhone models में sensitive kernel memory regions की सुरक्षा के लिए hardware-based protection feature मौजूद है
  • यह protection इस तरह डिज़ाइन की गई है कि भले ही हमलावर kernel memory को पढ़-लिख सकें, वे पूरे device पर पूर्ण नियंत्रण न पा सकें
  • Operation Triangulation के हमलावरों ने Apple-designed SoC की एक दूसरी hardware feature का उपयोग करके इस protection को bypass किया
  • पहचाना गया behavior इस प्रकार था
    • data, destination address, और data hash को chip के अज्ञात hardware registers में लिखा जाता था
    • ये registers firmware में उपयोग होते नहीं दिखते
    • परिणामस्वरूप hardware-based memory protection को bypass करके specific physical addresses पर data लिखा जा सकता था
  • संभव है कि यह feature Apple engineers या factory testing के लिए debugging feature रही हो, या गलती से शामिल रह गई हो
  • चूँकि यह feature firmware में उपयोग होती नहीं दिखती, इसलिए हमलावरों को इसका तरीका कैसे पता चला यह अभी भी अज्ञात है

MMIO और DeviceTree विश्लेषण

  • SoC के peripherals ऐसे special hardware registers दे सकते हैं जिनसे CPU device को control कर सके
  • ये registers CPU-accessible memory में map किए जाते हैं, और इन्हें memory-mapped I/O(MMIO) कहा जाता है
  • Apple products में peripheral MMIO address ranges DeviceTree format में stored होती हैं
    • DeviceTree files को firmware से extract किया जा सकता है
    • dt utility से इनकी contents देखी जा सकती हैं
  • PPL bypass के लिए हमलावरों ने जिन MMIO का उपयोग किया, उनमें से अधिकांश DeviceTree में defined किसी भी MMIO range में नहीं आते थे
  • exploit Apple A12–A16 Bionic SoC को target करता था, और उसने निम्न अज्ञात MMIO blocks का उपयोग किया
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • कई devices और firmware के DeviceTree, public source code, kernel images, kernel extensions, iBoot, और auxiliary processor firmware में इन addresses के references नहीं मिले

GPU सहायक प्रोसेसर से संबंध

  • आसपास के ज्ञात MMIO की जाँच करने पर पता चला कि अज्ञात addresses gfx-asc, यानी GPU auxiliary processor, के पास स्थित थे
  • gfx-asc के दो MMIO ranges हैं
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • exploit ने वास्तव में जिन अज्ञात addresses का उपयोग किया, वे ये थे
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • इनमें से अधिकांश दो gfx-asc regions के बीच थे, और शेष एक पहला gfx-asc region शुरू होने के पास था
  • इस आधार पर माना गया कि ये registers GPU auxiliary processor से जुड़े होने की काफी संभावना है
  • exploit initialization के दौरान ऐसा code भी मिला जो SoC के अनुसार अलग-अलग addresses पर GFX power manager registers को manipulate करता था
    • pmgr utility से पुष्टि हुई कि ये addresses power manager MMIO range के GFX registers से मेल खाते हैं
  • अज्ञात region के registers को access करने पर GPU auxiliary processor “GFX SERROR Exception” संदेश के साथ panic करता था
    • यह परिणाम भी इस निष्कर्ष को मज़बूत करता है कि ये registers GPU auxiliary processor से संबंधित हैं

CoreSight और Apple-विशिष्ट UTT region

  • 0x206040000 register exploit के initialization और cleanup stages में ही इस्तेमाल हुआ
    • initialization में इसे सबसे पहले set किया गया, और cleanup में सबसे अंत में handle किया गया
  • विश्लेषण से पता चला कि यह register hardware feature को on/off करने या interrupts को control करने की भूमिका निभाता है
  • exploit का behavior XNU source code dbgwrap.c की ml_dbgwrap_halt_cpu function से मेल खाता है
  • dbgwrap.c मुख्य CPU के ARM CoreSight MMIO debug registers को संभालने वाला code है
  • XNU source code CoreSight से संबंधित MMIO regions के रूप में ED, CTI, PMU, और UTT चार क्षेत्रों का उल्लेख करता है
    • हर region 0x10000 bytes का है
    • चारों regions एक-दूसरे से सटे हुए हैं
  • source code में लिखा है कि UTT region ARM से नहीं आया, बल्कि सुविधा के लिए जोड़ा गया Apple-विशिष्ट feature है
  • संबंधित स्थान पर ARM_DBG_LOCK_ACCESS_KEY लिखने से पुष्टि हुई कि 0x206000000–0x206050000 GPU auxiliary processor का CoreSight MMIO debug register block है
  • मुख्य CPU के हर core का अपना CoreSight MMIO debug register block भी है, लेकिन GPU auxiliary processor के विपरीत उसके addresses DeviceTree में मिल जाते हैं
  • exploit लेखक Apple-विशिष्ट UTT region का उपयोग करके CPU halt को release करने का तरीका भी जानते थे
    • यह code XNU source code में शामिल नहीं है

DMA जैसी दिखने वाली अज्ञात feature

  • 0x206140008 और 0x206140108 registers exploit में उपयोग की गई hardware feature के enable/disable और execution को control करते हैं
  • 0x206150020 केवल Apple A15/A16 Bionic SoC पर इस्तेमाल होता है
    • initialization stage में इसे 1 पर set किया जाता है, और cleanup stage में original value पर restore किया जाता है
  • 0x206150040 का उपयोग flags और destination physical address के lower half को store करने के लिए होता है
  • 0x206150048 का उपयोग लिखे जाने वाले data, destination physical address के upper half, data hash, और एक अन्य value को साथ store करने के लिए होता है
    • hardware feature aligned 0x40-byte blocks की इकाइयों में data लिखती है
    • 0x206150048 register पर लगातार 9 writes करनी पड़ती हैं
  • यदि पूरी प्रक्रिया सही हो, तो hardware DMA जैसा operation करके requested location पर data लिख देता है
  • exploit इस feature का उपयोग PPL bypass के लिए करता है, मुख्यतः page table entries को patch करने में
  • इसे protected __PPLDATA segment के data patch करने के लिए भी इस्तेमाल किया जा सकता है
  • kernel code patching के लिए इस feature का उपयोग नहीं किया गया
    • testing के दौरान एक बार __TEXT_EXEC segment में kernel instruction को overwrite करके expected address और value के साथ “Undefined Kernel Instruction” panic मिला
    • अन्य प्रयासों में AMCC panic हुआ

hash, ECC, और cache access की संभावना

  • शुरुआती विश्लेषण में लगा था कि यह feature किसी custom hash की मांग करती है
    • hash की गणना predefined sbox table के उपयोग से होती दिखी
    • बड़े binary collection में उस table को खोजा गया, लेकिन वह नहीं मिली
  • hash 20-bit का दिखा, यानी दो बार 10-bit value की गणना जैसा
  • यदि हमलावरों को इसकी calculation और usage का तरीका न पता हो, तो यह संरचना security by obscurity के काफ़ी करीब लगती है
  • 9 जनवरी 2024 के update में Hector Martin ने पुष्टि की कि यह value साधारण custom hash नहीं, बल्कि error-correcting code(ECC) है
    • और अधिक सटीक रूप से, यह custom lookup table का उपयोग करने वाला Hamming code है
  • इस खोज ने अज्ञात hardware feature के मूल उद्देश्य को समझने का संकेत दिया
    • पहले यह direct memory access देने वाली debugging feature के साथ जुड़ा कोई “dummy” hash लगता था
    • लेकिन ECC के उपयोग और kernel code patching के समय देखे गए unstable behavior के कारण अब अधिक संभावना है कि यह feature cache तक direct access देती हो

M1 experiments और iOS 16.6 mitigation

  • यह पुष्टि हुई कि Mac के M1 chip में भी यह अज्ञात hardware feature मौजूद है
  • m1n1 tool की trace_range feature से 0x206110000–0x206400000 range में MMIO accesses को trace किया गया
    • macOS द्वारा इन registers के उपयोग के कोई संकेत रिपोर्ट नहीं हुए
  • iOS 16.6 में Apple ने exploit द्वारा उपयोग की गई MMIO ranges को DeviceTree के pmap-io-ranges में जोड़कर vulnerability को mitigate किया
    • जोड़ी गई ranges 0x206000000–0x206050000 और 0x206110000–0x206400000 थीं
  • XNU pmap-io-ranges जानकारी का उपयोग यह तय करने के लिए करता है कि कुछ physical address mappings की अनुमति देनी है या नहीं
  • सामान्य pmap-io-ranges entries में PCIe, DART, DAPF जैसे अर्थपूर्ण tag names होते हैं, लेकिन इस vulnerability से जुड़े regions के tag names अन्य entries की तुलना में अलग और ध्यान खींचने वाले थे

बचे हुए सवाल और सुरक्षा निहितार्थ

  • हमलावरों को इस अज्ञात hardware feature का उपयोग कैसे करना है, यह कैसे पता चला, इसकी पुष्टि नहीं हो सकी है
  • इस feature का मूल उद्देश्य भी अभी स्पष्ट नहीं है
    • यह भी अज्ञात है कि यह Apple द्वारा विकसित feature है या ARM CoreSight जैसे किसी third-party component का हिस्सा
  • update के बाद भी रहस्य बना हुआ है
    • केवल प्रयोग करके custom lookup table values को brute force करना संभव हो सकता है
    • लेकिन इसके लिए शक्तिशाली cache debugging feature का अस्तित्व, Hamming code का उपयोग, संबंधित MMIO registers की स्थिति और उद्देश्य, और interaction sequence सब कुछ पता होना भी ज़रूरी है
  • hardware-based protection होने पर भी, यदि उसे bypass करने वाली hardware feature मौजूद हो, तो वह परिष्कृत हमलावरों के सामने बेअसर हो सकती है
  • hardware security का reverse engineering software की तुलना में कहीं अधिक कठिन है, लेकिन जो systems “security through obscurity” पर निर्भर करते हैं वे रहस्य खुलते ही सुरक्षित नहीं रहते

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

1 टिप्पणियां

 
GN⁺ 2023-12-28
Hacker News की राय

  • प्रस्तुति का वीडियो भी अब अपलोड हो गया है: https://www.youtube.com/watch?v=7VWNUUldBEE

  • यह काफ़ी चौंकाने वाली बात है। MMIO exploitation का मतलब है कि हमलावरों के पास या तो बेहद असाधारण research क्षमता थी, या फिर उन्होंने Apple को hack करके आंतरिक hardware दस्तावेज़ हासिल किए थे; इनमें दूसरा ज़्यादा संभव लगता है
    custom hash function S-box सामने आने तक मुझे लगा था कि NSA-स्तर की बड़ी research team के लिए यह शायद संभव हो, लेकिन उस हिस्से से ऐसा लगता है कि Apple को पता था कि यह फ़ंक्शन ख़तरनाक है और उन्होंने जानबूझकर इसे छिपाया, और यह जो भी था उसे किसी तरह के कमज़ोर digital signature फ़ंक्शन से भी सुरक्षित किया गया था
    जैसा कि blog post बताती है, पूरे silicon को खोलकर reverse engineer करने के अलावा इस फ़ंक्शन को चलाने के लिए सही “magic knock” ढूँढने का कोई स्पष्ट तरीका नहीं है। ऐसे process node पर यह व्यावहारिक रूप से अवास्तविक है, इसलिए यही बचता है कि किसी developer को hack करके आंतरिक दस्तावेज़ चुराए गए हों
    बहुत महँगी zero-day chain को लंबी तरह से इस्तेमाल करके invisible Safari खोला गया, फिर एक बिल्कुल अलग exploit chain से web page लोड करके डिवाइस को दोबारा hack किया गया — इससे किसी बेहद बड़े संगठन की गंध आती है जहाँ internal siloing गंभीर हो
    यह देखते हुए कि शोधकर्ता Kaspersky के रूसी हैं, यह लगभग निश्चित रूप से NSA का काम लगता है, या शायद GCHQ का
    प्रस्तुति का एक और दिलचस्प हिस्सा यह है कि malware ad tracking चालू कर सकता है और security researchers द्वारा अक्सर इस्तेमाल की जाने वाली cloud iPhone hosting को detect भी कर सकता है। iOS/macOS malware platform शायद 10 साल से ज़्यादा समय में विकसित हुआ है, और यह फोटो के bytes अपलोड करने से बचने के लिए डिवाइस पर ही object recognition और OCR के लिए machine learning चलाता है, फिर सिर्फ़ बने हुए labels अपलोड करता है। इसमें बहुत मेहनत लगी, लेकिन आख़िरकार चालाक रूसी छात्रों के सामने यह काफ़ी नहीं था
    हालाँकि, प्रस्तोता के इस कथन से मैं पूरी तरह सहमत नहीं हूँ कि “security through obscurity काम नहीं करती।” यह platform 10 साल तक production में रहा, और किसी को नहीं पता कि उस छिपे hardware “feature” का दुरुपयोग कितने समय तक हुआ। अगर वह hardware feature सार्वजनिक रूप से documented होता, तो वह बहुत, बहुत पहले खोज लिया गया होता

    • “अगर hardware feature सार्वजनिक रूप से documented होता, तो वह बहुत पहले खोज लिया गया होता” का मतलब यह है कि Kerckhoffs's principle के अनुसार उसे शुरुआत से ही सार्वजनिक रूप से documented होना चाहिए था, और release से पहले दस्तावेज़ देखने वाला कोई भी व्यक्ति कहता कि “इसे ऐसे ship नहीं करना चाहिए, यह feature हटाना चाहिए”
    • iTunes backup में Operation Triangulation के compromise indicators स्कैन करने के लिए एक IoC script भी है: https://github.com/KasperskyLab/triangle_check
    • यह सचमुच कमाल का attack है, और मैं ऊपर के analysis से सहमत हूँ। hidden Safari tab से डिवाइस को “फिर से hack” करने वाला हिस्सा, जैसा कहा गया, संगठन के अंदर बुरे siloing का नतीजा हो सकता है, या फिर 90s के script kiddies के “virus बनाने” वाले तरीके की याद भी दिलाता है
      यह तेज़ adaptation के लिए modular design भी हो सकता है, यानी संभव है कि संरचना कम targeted हो
    • या फिर Apple ने उनके विनम्र अनुरोध पर यह “API” बस implement कर दी हो
    • इस thread में बहुत ग़लत जानकारी है। यह, जैसा यहाँ[1] में समझाया गया है, Hamming ECC है
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis ने Twitter पर इसका सबसे अच्छा सार दिया:
    “यह iMessage exploit पागलपन है। इसमें 90s से मौजूद TrueType vulnerability, 2 kernel exploits, browser exploit, और यहाँ तक कि released software में इस्तेमाल न की गई undocumented hardware feature भी शामिल है”
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • अगर आप Kaspersky शोधकर्ताओं की प्रस्तुति देखना चाहते हैं, तो edited video अभी तक अपलोड नहीं हुआ था, लेकिन streaming replay यहाँ देखी जा सकती है:
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    प्रस्तुति 26:20 से शुरू होती है

  • 37c3 प्रस्तुति पर जर्मन में Fefe¹ की पोस्ट भी है: https://blog.fefe.de/?ts=9b729398
    उसके अनुसार इस exploit chain की कीमत संभवतः 8-अंकीय डॉलर राशि थी
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    लगता है किसी की नौकरी जाएगी

    • क्यों? exploit का “burn” हो जाना इस business का हिस्सा है

  • Coresight कोई backdoor नहीं है, बल्कि हर ARM CPU में मौजूद debug feature है। यह Coresight extension जैसा लगता है जो Apple की memory protection features के साथ काम करने के लिए ज़रूरी है
    भले ही सार्वजनिक दस्तावेज़ न हों, Apple के हज़ारों engineers के पास modified gdb या दूसरे tools तक पहुँच हो सकती है जो इसका इस्तेमाल कर सकें

    • किसी के लिए यह debug tool है, किसी और के लिए backdoor
    • फिर भी यह अजीब hashing समझ में नहीं आती

  • अगर डिवाइस सुपरविजन के तहत है, तो macOS App Store के मुफ़्त Apple Configurator के ज़रिए लोकल MDM से iMessage को disable किया जा सकता है: https://support.apple.com/guide/deployment/restrictions-for-...
    केवल Wi-Fi वाले डिवाइस पर Messages app छिप जाता है
    Wi-Fi और cellular दोनों वाले डिवाइस पर Messages app दिखता रहता है, लेकिन केवल SMS/MMS service इस्तेमाल की जा सकती है
    उदाहरण के लिए, अगर डिवाइस को लंबे समय तक सिर्फ़ Wi-Fi पर इस्तेमाल करना हो, तो SIM PIN के ज़रिए SMS/MMS संदेश और non-emergency cellular wireless traffic को disable किया जा सकता है

    • cellular iPad खरीदकर उसमें अपने देश का SIM कार्ड डालकर SMS लेते रहने की कोशिश की गई थी। वजह यह थी कि उस देश के बैंक अभी भी login के समय SMS authentication मांगते हैं
      लेकिन बाद में पता चला कि cellular iPad, SIM कार्ड carrier द्वारा भेजे गए SMS के अलावा दूसरे SMS लगभग दिखाता ही नहीं है

  • यह बात ध्यान खींचती है कि पूरी तरह 0 वाले data write का hash value भी 0 होता है
    और single bit के मामले में hash value, S-box table की एक single value बन जाती है। यानी इस hash algorithm को internal documentation के बिना भी काफ़ी हद तक reverse engineer किया जा सकता था

    • इसमें उस आम तरीके की “गंध” आती है जो random address पर memory write होने से गलती से इस hardware को trigger होने से रोकने के लिए इस्तेमाल किया जाता है। यह किसी security feature के तौर पर जानबूझकर बनाया गया लगता नहीं है
      सच कहूँ तो अगर किसी ने कहा होता कि bug की वजह से arbitrary write नहीं होना चाहिए, तो मैं भी शायद इसे ऐसे ही implement करता। यह implementation उस स्थिति में भी इस feature के इस्तेमाल को प्रभावी रूप से रोकती है, जब buffer address पता हो लेकिन उसकी contents न पता हों
      अगर हर बार hash value ग़लत होने पर system reboot हो जाए, तो 10-bit security भी उस काम के लिए शायद काफ़ी है। Coresight debug feature चाहे तो system को पूरी तरह reboot कर सकता है

  • इस MMIO register को क्या सभी register addresses पर brute-force search करके खोजा गया होगा?
    सिर्फ़ timing difference से भी यह पता चल गया होगा कि वह address valid है, और hash भी व्यवहारिक रूप से 20-bit hash था, इसलिए शायद brute-force संभव रहा हो

    • register शायद brute-force से काफ़ी आसानी से पहचाना जा सकता था। यह documented GPU register के भौतिक रूप से क़रीब है, और इसे access करने पर GPU panic होता है, इसलिए researchers ने भी इसे GPU component माना। attacker भी ऐसे ही test से register की मौजूदगी जान सकते थे
      जो हिस्सा कम आसानी से समझ में आता है, वह यह है कि debug code चलाने के लिए custom S-box table को कैसे recover किया गया। यहीं पर insider threat का संकेत सबसे मज़बूत लगता है, लेकिन व्यक्तिगत रूप से मुझे नहीं लगता कि इससे दूसरी plausible explanations ख़ारिज हो जाती हैं
      उदाहरण के लिए, attackers ने पुराने firmware, OTA update patch, pre-release development device (जिन्हें किसी समय eBay पर खरीदा जा सकता था), iOS beta release, या दूसरे leak channels से S-box निकाला हो सकता है
      researcher मूल रूप से यह कहते हैं कि “देखे गए दूसरे किसी binary में यह S-box table नहीं मिला।” लेकिन यह Apple-specific लगता है, इसलिए जिन binaries में इसके आने की संभावना थी उनकी संख्या सीमित होना कोई चौंकाने वाली बात नहीं है। जैसा researcher ने भी कहा, इसमें वे binaries भी शामिल हैं जो अभी public नहीं हैं और शायद गलती से distribute हो गए हों। यह काफ़ी plausible है कि attackers ऐसे leaks को व्यवस्थित रूप से ढूँढ़ते रहे हों, किसी समय उन्हें किस्मत से यह मिल गया हो, और researcher को वैसी किस्मत जल्द न मिले
    • उस S-box implementation को देखकर यह मानना मुश्किल है कि chip hardware में इसे lookup table के रूप में implement किया गया होगा। वही नतीजा देने वाला कोई अधिक compact boolean expression मौजूद रहा होगा
      यह तथ्य कि attackers उस boolean expression को नहीं जानते थे, इस ओर इशारा करता है कि उनके पास documentation होने की बजाय उन्होंने इसे reverse engineer किया था

  • https://streaming.media.ccc.de/37c3/relive/11859

    • यह 27:21 से शुरू होता है
      प्रस्तुति की सामग्री के साथ समयक्रम में देखें तो बात कुछ ऐसी है
      सितंबर 2018: undocumented MMIO वाला पहला CPU, Apple A12 Bionic SOC, जारी हुआ
      दिसंबर 2021: शुरुआती exploit chain infrastructure में backuprabbit.com, 2021-12-15T18:33:19Z पर और cloudsponcer.com, 2021-12-17T16:33:50Z पर बनाए गए
      अप्रैल 2022: बाद की exploit chain infrastructure snoweeanalytics.com, 2022-04-20T15:09:17Z पर बनाया गया, जिससे संकेत मिलता है कि इस तारीख़ तक exploit weaponize हो चुका था
      दिसंबर 2023: यह लगभग detection point लगता है। यह “आधा साल” analysis period और 2023 के मध्य के Apple report से उलटी गणना पर आधारित है
      presenters का कहना है कि code के अंदर के निशानों से लगता है कि मूल APT group यही attack codebase “10 साल” से, यानी लगभग 2013 से, इस्तेमाल कर रहा था, और macOS laptop attacks में भी इसका उपयोग करता था। इसमें antivirus bypass भी शामिल है
      presenters यह संभावना भी उठाते हैं कि यह बहुत “backdoor-जैसी” signed debug feature Apple की जानकारी के बिना, मसलन किसी GPU developer द्वारा, chip में शामिल की गई हो
      यानी पहला vulnerable chip बाज़ार में आने के 3.5 साल के भीतर ही, लंबे secret value के ज्ञान की मांग करने वाली Apple Coresight GPU की undocumented debug MMIO series को 10 साल से अधिक इतिहास वाले एक मौजूदा APT group ने सफलतापूर्वक weaponize करके exploit किया। Kaspersky “अनुमान नहीं लगाता”, लेकिन व्यक्तिगत रूप से मुझे लगता है कि किसी बड़े state actor के अलावा यह संभव होना मुश्किल है
      अगर अनुमान लगाएँ, तो Apple को APT से जुड़े लगभग 40 Apple ID के खुद अपनी पहचान उजागर करने के पर्याप्त सबूत मिले थे, इसलिए उसके बाद अमेरिका की राष्ट्रीय सुरक्षा से जुड़ी किसी घोषणा के आधार पर पहचान का अंदाज़ा लगाया जा सकता है। अगर चुप्पी रहे, तो शायद वह NSA होगा
    • अब जो संभवतः असली recording का पहला version है, वह अपलोड हो गया है:
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...