Operation Triangulation: สิ่งที่ได้เมื่อโจมตี iPhone ของนักวิจัย

 (securelist.com)
1 คะแนน โดย GN⁺ 2023-12-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • นักวิจัยของ Kaspersky เปิดเผยเชนการโจมตี iPhone แบบ 0-click ผ่าน iMessage ของ Operation Triangulation ที่งาน 37C3 และประเมินว่าเป็นเชนที่ซับซ้อนที่สุดเท่าที่เคยพบมา
  • การโจมตีถูกออกแบบให้ทำงานได้จนถึง iOS 16.2 โดยผูก zero-day 4 รายการ เข้าด้วยกัน นำไปสู่การรันโค้ดจากระยะไกล การยกระดับสิทธิ์ การหลบเลี่ยง PPL และการรันขั้นตอนผ่าน Safari
  • ปริศนาหลักคือส่วนที่ถูกบรรเทาด้วย CVE-2023-38606 โดยผู้โจมตีใช้ MMIO register ที่ไม่เป็นที่รู้จักของ Apple A12–A16 Bionic SoC เพื่อหลบเลี่ยงการป้องกันหน่วยความจำเคอร์เนลที่อิงฮาร์ดแวร์
  • ผลการวิเคราะห์ชี้ว่า register เหล่านี้น่าจะเกี่ยวข้องกับ GPU coprocessor และบางส่วนไม่ได้ถูกอ้างอิงใน DeviceTree หรือเฟิร์มแวร์ จึงยังไม่ทราบว่าผู้โจมตีรู้วิธีใช้งานได้อย่างไร
  • ในอัปเดตวันที่ 9 มกราคม 2024 ค่าที่เคยดูเหมือน “แฮชแบบกำหนดเอง” ได้รับการยืนยันว่าเป็น ECC ที่อิง Hamming code และมีความเป็นไปได้สูงว่าฟังก์ชันนี้เป็นฟังก์ชันดีบักที่เข้าถึงแคชโดยตรงมากกว่าหน่วยความจำ

เชนการโจมตีที่ถูกเปิดเผย

  • ผลการวิเคราะห์ระยะยาวของ Operation Triangulation ถูกเปิดเผยในการบรรยายที่ 37C3 เมื่อวันที่ 27 ธันวาคม 2023
  • การบรรยายนี้เป็นครั้งแรกที่มีการเปิดเผยรายละเอียดของ exploit และช่องโหว่ที่ใช้ในการโจมตี
  • นักวิจัยเคยค้นพบและรายงาน zero-day ที่ถูกใช้งานจริงมากกว่า 30 รายการในผลิตภัณฑ์ของ Adobe, Apple, Google และ Microsoft แต่ประเมินว่าเชนการโจมตีนี้อยู่ในระดับซับซ้อนที่สุดในบรรดาทั้งหมด

จาก iMessage 0-click ไปจนถึงการโหลดสปายแวร์

  • ผู้โจมตีส่ง ไฟล์แนบ iMessage ที่เป็นอันตราย และแอปพลิเคชันจะประมวลผลไฟล์นั้นโดยไม่แสดงให้ผู้ใช้เห็น
  • ไฟล์แนบใช้ประโยชน์จาก CVE-2023-41990 ซึ่งเป็นช่องโหว่รันโค้ดจากระยะไกลในคำสั่งฟอนต์ ADJUST TrueType แบบไม่เป็นเอกสารของ Apple
    • คำสั่งนี้มีมาตั้งแต่ต้นทศวรรษ 1990 และถูกลบออกด้วยแพตช์
  • จากนั้นตามด้วยหลายขั้นตอนที่เขียนด้วย return/jump oriented programming และภาษา query ของ NSExpression/NSPredicate
    • แพตช์สภาพแวดล้อม JavaScriptCore เพื่อรัน exploit ยกระดับสิทธิ์ที่เขียนด้วย JavaScript
  • JavaScript exploit ถูกลดขนาดและทำ obfuscation จนอ่านแทบไม่ได้ทั้งหมด แต่มีขนาดประมาณ 11,000 บรรทัด
    • ส่วนใหญ่ใช้สำหรับการแยกวิเคราะห์และจัดการหน่วยความจำของ JavaScriptCore และเคอร์เนล
  • ใช้ DollarVM($vm) ซึ่งเป็นฟังก์ชันดีบักของ JavaScriptCore ในทางที่ผิด เพื่อจัดการหน่วยความจำ JavaScriptCore จากสคริปต์และเรียกใช้ฟังก์ชัน API แบบ native
  • ถูกออกแบบให้รองรับทั้ง iPhone รุ่นเก่าและรุ่นใหม่ และรวม การหลบเลี่ยง PAC สำหรับโจมตีรุ่นล่าสุดไว้ด้วย

การเข้าถึงหน่วยความจำเคอร์เนลและการหลบเลี่ยง PPL

  • exploit ใช้ CVE-2023-32434 ซึ่งเป็นช่องโหว่ integer overflow ใน syscall สำหรับทำ memory mapping ของ XNU คือ mach_make_memory_entry และ vm_map
    • ทำให้ได้สิทธิ์อ่าน/เขียนหน่วยความจำกายภาพทั้งหมดของอุปกรณ์จากระดับผู้ใช้
  • จากนั้นใช้ MMIO register ของฮาร์ดแวร์เพื่อหลบเลี่ยง Page Protection Layer(PPL)
    • ส่วนนี้ถูกบรรเทาด้วย CVE-2023-38606
  • หลังใช้ประโยชน์จากช่องโหว่ทั้งหมดแล้ว JavaScript exploit สามารถดำเนินการใดๆ บนอุปกรณ์ได้
    • ผู้โจมตีรันโปรเซส IMAgent และฉีด payload เพื่อลบร่องรอยของ exploit
    • รันโปรเซส Safari ในโหมดที่มองไม่เห็นและส่งต่อไปยังเว็บเพจขั้นถัดไป
  • เว็บเพจจะตรวจสอบเหยื่อ และหากผ่านเงื่อนไขก็จะส่ง Safari exploit ให้
  • Safari exploit ใช้ CVE-2023-32435 เพื่อรัน shellcode
  • shellcode รัน kernel exploit อีกตัวหนึ่งในรูปแบบไฟล์ Mach object
    • exploit นี้ใช้ CVE-2023-32434 และ CVE-2023-38606 เช่นกัน
    • ส่วนใหญ่แตกต่างจาก JavaScript kernel exploit แต่แชร์โค้ดบางส่วนที่เกี่ยวข้องกับการใช้ประโยชน์จากช่องโหว่เดียวกัน
  • ท้ายที่สุดได้สิทธิ์ root และรันขั้นตอนอื่นเพื่อโหลดสปายแวร์

ปริศนาฮาร์ดแวร์ของ CVE-2023-38606

  • iPhone รุ่นล่าสุดมีฟังก์ชันป้องกันที่อิงฮาร์ดแวร์เพื่อปกป้องพื้นที่หน่วยความจำเคอร์เนลที่อ่อนไหว
  • การป้องกันนี้ถูกออกแบบมาเพื่อไม่ให้ผู้โจมตีควบคุมอุปกรณ์ทั้งหมดได้อย่างสมบูรณ์ แม้จะอ่านและเขียนหน่วยความจำเคอร์เนลได้ก็ตาม
  • ผู้โจมตี Operation Triangulation ใช้ ฟังก์ชันฮาร์ดแวร์ อีกอย่างหนึ่งของ SoC ที่ Apple ออกแบบเพื่อหลบเลี่ยงการป้องกันนี้
  • พฤติกรรมที่พบมีดังนี้
    • เขียนข้อมูล ที่อยู่ปลายทาง และแฮชของข้อมูลลงใน hardware register ที่ไม่เป็นที่รู้จักของชิป
    • register เหล่านี้ดูเหมือนไม่ได้ถูกใช้ในเฟิร์มแวร์
    • ผลคือสามารถเขียนข้อมูลไปยังที่อยู่กายภาพบางตำแหน่งได้โดยหลบเลี่ยงการป้องกันหน่วยความจำที่อิงฮาร์ดแวร์
  • ฟังก์ชันนี้อาจเป็นฟังก์ชันดีบักสำหรับวิศวกร Apple หรือการทดสอบในโรงงาน หรืออาจถูกใส่เข้ามาโดยไม่ตั้งใจ
  • เนื่องจากเป็นฟังก์ชันที่ไม่ได้ถูกใช้ในเฟิร์มแวร์ จึงยังไม่ทราบว่าผู้โจมตีรู้วิธีใช้งานได้อย่างไร

การวิเคราะห์ MMIO และ DeviceTree

  • อุปกรณ์รอบข้างของ SoC สามารถมี hardware register พิเศษเพื่อให้ CPU ควบคุมอุปกรณ์ได้
  • register เหล่านี้ถูก map เข้ากับหน่วยความจำที่ CPU เข้าถึงได้ และเรียกว่า memory-mapped I/O(MMIO)
  • ช่วงที่อยู่ MMIO ของอุปกรณ์รอบข้างในผลิตภัณฑ์ Apple ถูกเก็บในรูปแบบ DeviceTree
    • ไฟล์ DeviceTree สามารถสกัดได้จากเฟิร์มแวร์
    • สามารถดูเนื้อหาได้ด้วยยูทิลิตี dt
  • MMIO ส่วนใหญ่ที่ผู้โจมตีใช้ในการหลบเลี่ยง PPL ไม่ได้อยู่ในช่วง MMIO ใดๆ ที่กำหนดไว้ใน DeviceTree
  • exploit มุ่งเป้าไปที่ Apple A12–A16 Bionic SoC และใช้บล็อก MMIO ที่ไม่เป็นที่รู้จักดังต่อไปนี้
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • ไม่พบการอ้างอิงที่อยู่เหล่านี้ใน DeviceTree ของอุปกรณ์และเฟิร์มแวร์หลายรายการ, ซอร์สโค้ดสาธารณะ, kernel image, kernel extension, iBoot หรือเฟิร์มแวร์ของ coprocessor

ความเชื่อมโยงกับ GPU coprocessor

  • เมื่อตรวจสอบ MMIO ที่รู้จักรอบๆ พบว่าที่อยู่ที่ไม่เป็นที่รู้จักอยู่ใกล้กับ gfx-asc หรือ GPU coprocessor
  • gfx-asc มีช่วง MMIO สองช่วง
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • ที่อยู่ที่ไม่เป็นที่รู้จักซึ่ง exploit ใช้งานจริงมีดังนี้
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • ส่วนใหญ่อยู่ระหว่างพื้นที่ gfx-asc ทั้งสอง และอีกหนึ่งรายการอยู่ใกล้จุดเริ่มต้นของพื้นที่ gfx-asc แรก
  • จึงประเมินว่า register เหล่านี้มีแนวโน้มสูงที่จะเป็นของ GPU coprocessor
  • ในกระบวนการเริ่มต้นของ exploit ยังพบโค้ดที่จัดการ register ของ GFX power manager ที่มีที่อยู่ต่างกันตาม SoC
    • ยืนยันด้วยยูทิลิตี pmgr ว่าที่อยู่เหล่านี้สอดคล้องกับ GFX register ในช่วง MMIO ของ power manager
  • เมื่อเข้าถึง register ในพื้นที่ที่ไม่เป็นที่รู้จัก GPU coprocessor เกิด panic พร้อมข้อความ “GFX SERROR Exception”
    • ผลนี้สนับสนุนข้อสรุปว่า register เหล่านี้เป็นของ GPU coprocessor

CoreSight และพื้นที่ UTT เฉพาะของ Apple

  • register 0x206040000 ถูกใช้เฉพาะในขั้นตอนเริ่มต้นและสิ้นสุดของ exploit
    • ถูกตั้งค่าเป็นอย่างแรกในขั้นเริ่มต้น และถูกจัดการเป็นอย่างสุดท้ายในขั้นสิ้นสุด
  • วิเคราะห์ได้ว่า register นี้มีบทบาทในการเปิด/ปิดฟังก์ชันฮาร์ดแวร์หรือควบคุม interrupt
  • พฤติกรรมของ exploit สอดคล้องกับฟังก์ชัน ml_dbgwrap_halt_cpu ในซอร์สโค้ด XNU dbgwrap.c
  • dbgwrap.c เป็นโค้ดที่จัดการ ARM CoreSight MMIO debug register ของ CPU หลัก
  • ซอร์สโค้ด XNU กล่าวถึงพื้นที่ MMIO ที่เกี่ยวข้องกับ CoreSight สี่พื้นที่ ได้แก่ ED, CTI, PMU และ UTT
    • แต่ละพื้นที่มีขนาด 0x10000 ไบต์
    • ทั้งสี่พื้นที่อยู่ติดกัน
  • ในซอร์สโค้ดระบุว่าพื้นที่ UTT ไม่ได้มาจาก ARM แต่เป็นฟังก์ชันเฉพาะของ Apple ที่เพิ่มเข้ามาเพื่อความสะดวก
  • เมื่อเขียน ARM_DBG_LOCK_ACCESS_KEY ไปยังตำแหน่งดังกล่าว สามารถยืนยันได้ว่า 0x206000000–0x206050000 คือบล็อก CoreSight MMIO debug register ของ GPU coprocessor
  • คอร์แต่ละคอร์ของ CPU หลักก็มีบล็อก CoreSight MMIO debug register ของตัวเองเช่นกัน แต่ต่างจาก GPU coprocessor ตรงที่ที่อยู่เหล่านั้นหาได้จาก DeviceTree
  • ผู้เขียน exploit ยังรู้วิธีปลด CPU halt โดยใช้พื้นที่ UTT เฉพาะของ Apple ด้วย
    • โค้ดนี้ไม่ได้รวมอยู่ในซอร์สโค้ด XNU

ฟังก์ชันที่ยังไม่ระบุซึ่งทำงานคล้าย DMA

  • register 0x206140008 และ 0x206140108 ควบคุมการเปิด/ปิดและการรันฟังก์ชันฮาร์ดแวร์ที่ exploit ใช้
  • 0x206150020 ใช้เฉพาะใน Apple A15/A16 Bionic SoC
    • ถูกตั้งค่าเป็น 1 ในขั้นเริ่มต้น และคืนค่าเดิมในขั้นสิ้นสุด
  • 0x206150040 ใช้เก็บ flag และครึ่งล่างของที่อยู่กายภาพปลายทาง
  • 0x206150048 ใช้เก็บข้อมูลที่จะเขียน ครึ่งบนของที่อยู่กายภาพปลายทาง แฮชของข้อมูล และค่าอื่นอีกหนึ่งค่าไว้ด้วยกัน
    • ฟังก์ชันฮาร์ดแวร์เขียนข้อมูลเป็นหน่วยบล็อก 0x40 ไบต์ที่จัดแนวแล้ว
    • register 0x206150048 ต้องถูกเขียนต่อเนื่อง 9 ครั้ง
  • หากขั้นตอนทั้งหมดถูกต้อง ฮาร์ดแวร์จะดำเนินการแบบ DMA เพื่อเขียนข้อมูลไปยังตำแหน่งที่ร้องขอ
  • exploit ใช้ฟังก์ชันนี้ในการหลบเลี่ยง PPL โดยส่วนใหญ่ใช้แพตช์ page table entry
  • ยังสามารถใช้แพตช์ข้อมูลในเซกเมนต์ __PPLDATA ที่ถูกป้องกันได้ด้วย
  • ไม่ได้ใช้ฟังก์ชันนี้เพื่อแพตช์โค้ดเคอร์เนล
    • ระหว่างการทดสอบ มีครั้งหนึ่งที่เขียนทับคำสั่งเคอร์เนลในเซกเมนต์ __TEXT_EXEC และได้ panic “Undefined Kernel Instruction” พร้อมที่อยู่และค่าตามที่คาดไว้
    • ในความพยายามอื่นเกิด AMCC panic

แฮช, ECC และความเป็นไปได้ของการเข้าถึงแคช

  • ในการวิเคราะห์ช่วงแรก ฟังก์ชันนี้ดูเหมือนต้องใช้แฮชแบบกำหนดเอง
    • แฮชคำนวณโดยใช้ตาราง sbox ที่กำหนดไว้ล่วงหน้า
    • มีการค้นหาตารางดังกล่าวในคอลเลกชันไบนารีขนาดใหญ่ แต่ไม่พบ
  • แฮชดูเหมือนมีขนาด 20 บิต หรืออยู่ในรูปแบบที่คำนวณค่า 10 บิตสองครั้ง
  • หากผู้โจมตีไม่รู้วิธีคำนวณและใช้งาน โครงสร้างนี้ก็ใกล้เคียงกับ security by obscurity
  • ในอัปเดตวันที่ 9 มกราคม 2024 Hector Martin ยืนยันว่าค่านี้ไม่ใช่แค่แฮชแบบกำหนดเอง แต่เป็นรหัสแก้ไขข้อผิดพลาด (ECC)
    • ให้แม่นยำกว่านั้นคือ Hamming code ที่ใช้ lookup table แบบกำหนดเอง
  • การค้นพบนี้เป็นเบาะแสในการทำความเข้าใจวัตถุประสงค์ดั้งเดิมของฟังก์ชันฮาร์ดแวร์ที่ยังไม่ระบุ
    • ตอนแรกดูเหมือนเป็นฟังก์ชันดีบักที่ให้การเข้าถึงหน่วยความจำโดยตรงพร้อมแฮช “ปลอม”
    • แต่เนื่องจากมีการใช้ ECC และพบพฤติกรรมไม่เสถียรเมื่อแพตช์โค้ดเคอร์เนล ฟังก์ชันนี้จึงมีแนวโน้มสูงว่าจะเป็นฟังก์ชันที่ เข้าถึงแคชโดยตรง

การทดลองบน M1 และการบรรเทาใน iOS 16.6

  • ได้รับการยืนยันว่า ชิป M1 ของ Mac ก็มีฟังก์ชันฮาร์ดแวร์ที่ไม่เป็นที่รู้จักนี้เช่นกัน
  • ใช้ฟังก์ชัน trace_range ของเครื่องมือ m1n1 เพื่อติดตามการเข้าถึง MMIO ในช่วง 0x206110000–0x206400000
    • ไม่พบรายงานร่องรอยว่า macOS ใช้ register เหล่านี้
  • ใน iOS 16.6 Apple บรรเทาช่องโหว่โดยเพิ่มช่วง MMIO ที่ exploit ใช้เข้าไปใน pmap-io-ranges ของ DeviceTree
    • ช่วงที่เพิ่มคือ 0x206000000–0x206050000 และ 0x206110000–0x206400000
  • XNU ใช้ข้อมูล pmap-io-ranges เพื่อพิจารณาว่าจะอนุญาตการ map ที่อยู่กายภาพบางรายการหรือไม่
  • รายการ pmap-io-ranges ทั่วไปจะมีชื่อแท็กที่สื่อความหมาย เช่น PCIe, DART, DAPF แต่ชื่อแท็กของพื้นที่ที่เกี่ยวข้องกับช่องโหว่นี้มีรูปแบบที่โดดเด่นต่างจากรายการอื่น

คำถามที่ยังเหลือและนัยด้านความปลอดภัย

  • ยังไม่ทราบว่าผู้โจมตีรู้วิธีใช้ฟังก์ชันฮาร์ดแวร์ที่ไม่เป็นที่รู้จักนี้ได้อย่างไร
  • วัตถุประสงค์ดั้งเดิมของฟังก์ชันนี้ก็ยังไม่ชัดเจน
    • ไม่อาจรู้ได้ว่าเป็นฟังก์ชันที่ Apple พัฒนาขึ้นเอง หรือเป็นคอมโพเนนต์จากบุคคลที่สามอย่าง ARM CoreSight
  • แม้หลังอัปเดตแล้ว ปริศนาก็ยังคงอยู่
    • ผู้โจมตีอาจ brute force ค่าใน lookup table แบบกำหนดเองได้ด้วยการทดลองเพียงอย่างเดียว
    • แต่ต้องรู้ทั้งหมด ทั้งการมีอยู่ของฟังก์ชันดีบักแคชที่ทรงพลัง การใช้ Hamming code ตำแหน่งและจุดประสงค์ของ MMIO register ที่เกี่ยวข้อง และลำดับการโต้ตอบ
  • แม้จะมีการป้องกันที่อิงฮาร์ดแวร์ แต่หากมีฟังก์ชันฮาร์ดแวร์ที่ใช้หลบเลี่ยงได้ ก็อาจไร้ผลเมื่อเจอกับผู้โจมตีที่มีความซับซ้อนสูง
  • ความปลอดภัยของฮาร์ดแวร์ทำ reverse engineering ได้ยากกว่าซอฟต์แวร์มาก แต่ระบบที่พึ่งพา “security through obscurity” จะไม่ปลอดภัยทันทีที่ความลับถูกเปิดเผย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2023-12-28
ความคิดเห็นจาก Hacker News

  • วิดีโอการนำเสนอก็เพิ่งถูกอัปโหลดแล้ว: https://www.youtube.com/watch?v=7VWNUUldBEE

  • เนื้อหาค่อนข้างน่าทึ่งทีเดียว การใช้ประโยชน์จาก MMIO หมายความว่าผู้โจมตีมีศักยภาพด้านการวิจัยมหาศาลจริง ๆ หรือไม่ก็แฮ็ก Apple เพื่อได้เอกสารฮาร์ดแวร์ภายในมา ซึ่งอย่างหลังดูมีความเป็นไปได้มากกว่า
    ก่อนจะมีเรื่อง S-box ของฟังก์ชันแฮชแบบคัสตอม ผมยังคิดว่าอาจเป็นไปได้ถ้ามีทีมวิจัยขนาดใหญ่ระดับ NSA แต่ตั้งแต่จุดนั้นเป็นต้นไป ดูเหมือนว่า Apple รู้ว่าฟีเจอร์นี้อันตราย จึงจงใจซ่อนมันไว้ และไม่ว่ามันคืออะไรกันแน่ ยังปกป้องมันเพิ่มด้วยฟังก์ชันคล้ายลายเซ็นดิจิทัลแบบอ่อนบางอย่างด้วย
    อย่างที่บทความบล็อกชี้ไว้ นอกจากการรื้อทั้งซิลิคอนมา reverse engineering แล้ว ก็ไม่มีวิธีชัดเจนในการหา “magic knock” ที่ถูกต้องเพื่อให้ฟีเจอร์นี้ทำงานได้ ในโหนดกระบวนการผลิตแบบนี้แทบจะเป็นไปไม่ได้ในทางปฏิบัติ ดังนั้นจึงเหลือความเป็นไปได้ว่าแฮ็กนักพัฒนาเพื่อขโมยเอกสารภายใน
    วิธีที่ใช้เชน zero-day ราคาแพงเป็นทอดยาวเพื่อเปิด Safari ที่มองไม่เห็นขึ้นมา แล้วโหลดเว็บเพจด้วยเชน exploit คนละชุดเพื่อแฮ็กอุปกรณ์ซ้ำอีกครั้ง ก็มีกลิ่นขององค์กรขนาดใหญ่ที่มีไซโลภายในรุนแรงมาก
    เมื่อพิจารณาว่านักวิจัยเป็นชาวรัสเซียจาก Kaspersky งานนี้แทบจะเป็น NSA หรืออาจเป็นงานของ GCHQ ก็เป็นได้
    อีกส่วนที่น่าสนใจในการนำเสนอคือ มัลแวร์สามารถเปิดการติดตามโฆษณาได้ และตรวจจับบริการโฮสต์ iPhone บนคลาวด์ที่นักวิจัยด้านความปลอดภัยใช้กันบ่อยได้ด้วย แพลตฟอร์มมัลแวร์ iOS/macOS นี้ดูเหมือนพัฒนามานานกว่า 10 ปีแล้ว ถึงขั้นรัน machine learning บนอุปกรณ์เพื่อทำ object recognition และ OCR เพื่อไม่ต้องอัปโหลดไบต์ของรูปภาพ แล้วอัปโหลดเฉพาะ label ที่สร้างขึ้นเท่านั้น ลงแรงไปมากจริง ๆ แต่สุดท้ายก็ยังไม่พอเมื่อเจอนักศึกษารัสเซียหัวดี
    อย่างไรก็ตาม ผมไม่เห็นด้วยทั้งหมดกับที่ผู้นำเสนอบอกว่า “security by obscurity ใช้ไม่ได้ผล” แพลตฟอร์มนี้อยู่ในสภาพแวดล้อมจริงมา 10 ปีแล้ว และไม่มีใครรู้ว่ามันใช้ประโยชน์จาก “ฟีเจอร์” ฮาร์ดแวร์ที่ซ่อนอยู่นานแค่ไหน ถ้าฟีเจอร์ฮาร์ดแวร์นั้นถูกทำเอกสารสาธารณะไว้ ก็คงถูกค้นพบเร็วกว่านี้มาก ๆ

    • ประเด็นที่ว่า “ถ้าฟีเจอร์ฮาร์ดแวร์ถูกทำเอกสารสาธารณะไว้ ก็คงถูกค้นพบเร็วกว่านี้มาก” หมายความว่า ตาม Kerckhoffs's principle มันควรถูกทำเอกสารให้เปิดเผยตั้งแต่แรก และใครก็ตามที่เห็นเอกสารก่อนการปล่อยใช้งานควรพูดว่า “ปล่อยแบบนี้ไม่ได้ ต้องตัดฟีเจอร์นี้ออก”
    • ยังมี สคริปต์ IoC ที่สแกนตัวชี้วัดการถูกโจมตีของ Operation Triangulation จากแบ็กอัป iTunes ได้ด้วย: https://github.com/KasperskyLab/triangle_check
    • เป็นการโจมตีที่ยอดเยี่ยมจริง ๆ และเห็นด้วยกับบทวิเคราะห์ข้างบน ส่วนที่ “แฮ็กซ้ำ” อุปกรณ์ผ่านแท็บ Safari ที่ซ่อนอยู่ อาจเป็นผลเสียจากไซโลภายในองค์กรอย่างที่ว่าไว้ หรืออาจชวนให้นึกถึงแนวทางแบบ “ทำไวรัส” ที่ script kiddie ยุค 90 ใช้กันก็ได้
      อาจเป็นการออกแบบแบบโมดูลาร์เพื่อปรับตัวได้เร็ว และนั่นก็อาจหมายความว่าโครงสร้างมันเจาะจงเป้าหมายน้อยกว่า
    • หรือไม่ Apple อาจจะแค่ implement “API” นี้ให้พวกเขา หลังจากพวกเขาขออย่างสุภาพก็ได้
    • มีข้อมูลผิด ๆ ในเธรดนี้เยอะเกินไป นี่คือ Hamming ECC ตามที่อธิบายไว้ที่นี่[1]
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis สรุปไว้บน Twitter ได้ดีที่สุด:
    “iMessage exploit ตัวนี้บ้าคลั่งมาก มีช่องโหว่ TrueType ที่มีมาตั้งแต่ยุค 90, kernel exploit 2 ตัว, browser exploit และยังมี ฟีเจอร์ฮาร์ดแวร์ที่ไม่ได้ทำเอกสาร ซึ่งไม่ได้ถูกใช้ในซอฟต์แวร์ที่ปล่อยออกมาจริงด้วย”
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • ถ้าสนใจการนำเสนอของนักวิจัย Kaspersky วิดีโอที่ตัดเรียบร้อยยังไม่ขึ้น แต่ดูย้อนหลังจากสตรีมได้ที่นี่:
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    การนำเสนอเริ่มที่ 26:20

  • เกี่ยวกับการนำเสนอที่ 37c3 ยังมีบทความภาษาเยอรมันของ Fefe¹ ด้วย: https://blog.fefe.de/?ts=9b729398
    ตามที่เขาว่า เชน exploit นี้น่าจะมีมูลค่าในระดับเลข 8 หลักเป็นดอลลาร์
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    คงมีใครบางคนโดนไล่ออกแน่ ๆ

    • ทำไมล่ะ? การที่ exploit ถูก “เผา” ก็เป็นส่วนหนึ่งของธุรกิจนี้อยู่แล้ว

  • Coresight ไม่ใช่ backdoor แต่เป็น ฟีเจอร์ debug ที่มีอยู่ใน CPU ARM ทุกตัว สิ่งนี้ดูเหมือนส่วนขยายของ Coresight ที่จำเป็นเพื่อทำงานร่วมกับฟีเจอร์ป้องกันหน่วยความจำของ Apple
    แม้จะไม่มีเอกสารสาธารณะ วิศวกร Apple หลายพันคนก็น่าจะเข้าถึง gdb ที่ปรับแต่งแล้วหรือเครื่องมืออื่น ๆ ที่ใช้ประโยชน์จากมันได้

    • สำหรับบางคนมันคือเครื่องมือ debug แต่สำหรับอีกคนมันคือ backdoor
    • ถึงอย่างนั้นก็ยังอธิบาย hashing แปลก ๆ ไม่ได้

  • หากเป็นอุปกรณ์ที่อยู่ภายใต้การกำกับดูแล สามารถ ปิดใช้งาน iMessage ผ่าน MDM แบบโลคัลได้ด้วย Apple Configurator ฟรีจาก macOS App Store: https://support.apple.com/guide/deployment/restrictions-for-...
    บนอุปกรณ์ที่ใช้ Wi‑Fi อย่างเดียว แอป Messages จะถูกซ่อนไว้
    บนอุปกรณ์ที่มีทั้ง Wi‑Fi และเซลลูลาร์ แอป Messages จะยังมองเห็นอยู่ แต่จะใช้ได้เฉพาะบริการ SMS/MMS
    ตัวอย่างเช่น เมื่อใช้อุปกรณ์ผ่าน Wi‑Fi อย่างเดียวเป็นเวลานาน สามารถใช้ SIM PIN เพื่อปิดใช้งานข้อความ SMS/MMS และทราฟฟิกวิทยุเซลลูลาร์ที่ไม่ใช่กรณีฉุกเฉินได้

    • เคยซื้อ iPad รุ่นเซลลูลาร์แล้วใส่ซิมการ์ดของประเทศบ้านเกิด เพื่อจะรับ SMS ต่อไป เพราะธนาคารในประเทศนั้นยังคงบังคับใช้ การยืนยันตัวตนผ่าน SMS ตอนล็อกอิน
      แต่กลับพบว่า iPad รุ่นเซลลูลาร์แทบจะไม่แสดง SMS ที่ไม่ได้ส่งมาจากผู้ให้บริการของซิมการ์ดนั้น

  • สิ่งที่สะดุดตาคือค่าแฮชของการเขียนข้อมูลที่เป็นศูนย์ทั้งหมดมีค่าเป็น 0
    และในกรณีของบิตเดียว ค่าแฮชจะกลายเป็นค่าหนึ่งค่าในตาราง S-box กล่าวคือ อัลกอริทึมแฮช นี้อาจสามารถทำรีเวิร์สเอนจิเนียริงได้เพียงพอ แม้ไม่มีเอกสารภายใน

    • เรื่องนี้มีกลิ่นของวิธีการทั่วไปที่ใช้กันเพื่อป้องกันไม่ให้การเขียนหน่วยความจำไปยังแอดเดรสแบบสุ่มไปทริกเกอร์ฮาร์ดแวร์นี้โดยไม่ตั้งใจ ไม่น่าจะตั้งใจให้เป็นฟีเจอร์ด้านความปลอดภัย
      ถ้ามีคนบอกว่าต้องไม่ให้การเขียนตามอำเภอใจเกิดขึ้นได้จากบั๊ก ผมก็คงจะ implement แบบนี้เหมือนกัน การ implement นี้ยังขัดขวางการใช้ฟีเจอร์นี้ได้อย่างมีประสิทธิภาพในกรณีที่รู้แอดเดรสบัฟเฟอร์ แต่ไม่รู้เนื้อหาข้างใน
      ถ้าระบบรีบูตทุกครั้งเมื่อค่าแฮชผิด ความปลอดภัยระดับ 10 บิต ก็น่าจะพอสำหรับการใช้งานแบบนั้น ฟีเจอร์ดีบัก Coresight สามารถรีบูตระบบทั้งระบบได้ถ้าต้องการ

  • มีความเป็นไปได้แค่ไหนที่ MMIO register นี้ถูกค้นพบด้วยการ ไล่ลองแบบ brute force กับแอดเดรส register ทั้งหมด?
    แค่ความต่างด้าน timing ก็อาจทำให้รู้ได้ว่าแอดเดรสนั้นเป็นแอดเดรสที่ใช้ได้ และแฮชก็โดยพื้นฐานแล้วเป็นแฮช 20 บิต จึงอาจ brute force ได้

    • ดูเหมือนว่า register นี้ระบุได้ค่อนข้างง่ายด้วย brute force มันอยู่ใกล้กับ GPU register ที่มีเอกสารกำกับในเชิงกายภาพ และเมื่อเข้าถึงก็ทำให้เกิด GPU panic นักวิจัยจึงจัดให้เป็นส่วนประกอบของ GPU ผู้โจมตีก็น่าจะตรวจพบการมีอยู่ของ register ได้ด้วยการทดสอบแบบเดียวกัน
      ส่วนที่อธิบายได้ยากกว่าคือ พวกเขากู้คืนตาราง S-box แบบกำหนดเองเพื่อรันโค้ดดีบักได้อย่างไร ตรงนี้เป็นจุดที่นัยของ ภัยคุกคามจากคนวงใน แรงที่สุด แต่โดยส่วนตัวไม่คิดว่ามันตัดคำอธิบายอื่น ๆ ที่สมเหตุสมผลออกไป
      ตัวอย่างเช่น ผู้โจมตีอาจดึง S-box ออกมาจากเฟิร์มแวร์รุ่นเก่า แพตช์อัปเดต OTA อุปกรณ์พัฒนาก่อนวางจำหน่าย (ซึ่งมีความเป็นไปได้สูงว่าช่วงหนึ่งเคยซื้อได้บน eBay), iOS beta release หรือช่องทางรั่วไหลอื่น ๆ อีกหลายทาง
      นักวิจัยพูดโดยพื้นฐานว่า “ไม่พบตาราง S-box นี้ในไบนารีอื่นใดที่ตรวจดูมา” แต่เมื่อพิจารณาว่ามันดูเหมือนเป็นของ Apple โดยเฉพาะ จำนวนไบนารีที่มันน่าจะเคยปรากฏก็มีจำกัด จึงไม่ใช่เรื่องน่าประหลาดใจเสมอไป อย่างที่นักวิจัยบอกไว้ ตรงนี้ยังรวมถึงไบนารีที่ตอนนี้ไม่ได้เผยแพร่แล้ว และอาจเคยถูกแจกจ่ายออกไปโดยพลาดพลั้งด้วย เป็นไปได้อย่างสมเหตุสมผลว่าผู้โจมตีค้นหาการรั่วไหลเหล่านี้อย่างเป็นระบบจนโชคดีได้มาในจุดหนึ่ง ขณะที่นักวิจัยอาจไม่ได้โชคดีแบบเดียวกันในเร็ว ๆ นี้
    • เมื่อดู implementation ของ S-box นั้นแล้ว ยากจะเชื่อว่ามันถูก implement ในฮาร์ดแวร์ชิปเป็น lookup table น่าจะมีนิพจน์บูลีนที่กระชับกว่าซึ่งให้ผลลัพธ์เดียวกัน
      ข้อเท็จจริงที่ว่าผู้โจมตีไม่รู้จักนิพจน์บูลีนนั้น ชี้ไปทางว่าพวกเขาทำรีเวิร์สเอนจิเนียริง มากกว่ามีเอกสารอยู่ในมือ

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

    • เริ่มตั้งแต่ 27:21
      เมื่อนำมาจัดเรียงตามลำดับเวลาร่วมกับเนื้อหาในงานนำเสนอ จะได้ดังนี้
      กันยายน 2018: Apple A12 Bionic SOC ซึ่งเป็น CPU ตัวแรกที่มี MMIO ที่ไม่มีเอกสารกำกับ เปิดตัว
      ธันวาคม 2021: โครงสร้างพื้นฐานของ exploit chain ระยะแรก backuprabbit.com ถูกสร้างเมื่อ 2021-12-15T18:33:19Z และ cloudsponcer.com ถูกสร้างเมื่อ 2021-12-17T16:33:50Z
      เมษายน 2022: โครงสร้างพื้นฐานของ exploit chain ระยะถัดมา snoweeanalytics.com ถูกสร้างเมื่อ 2022-04-20T15:09:17Z ซึ่งบ่งชี้ว่า exploit ถูกทำให้พร้อมใช้เป็นอาวุธแล้วภายในวันที่นี้
      ธันวาคม 2023: ดูเหมือนเป็นช่วงเวลาที่ตรวจพบโดยประมาณ คำนวณย้อนจากระยะเวลาวิเคราะห์ “ครึ่งปี” และรายงานของ Apple ช่วงกลางปี 2023
      ผู้นำเสนอระบุว่า จากร่องรอยในโค้ด กลุ่ม APT ต้นทางใช้ codebase การโจมตีเดียวกันมา “10 ปี” คือราวตั้งแต่ปี 2013 และใช้โจมตีโน้ตบุ๊ก macOS ด้วย รวมถึงการหลบเลี่ยงแอนติไวรัส
      ผู้นำเสนอยังชี้ถึงความเป็นไปได้ว่า ฟีเจอร์ดีบักที่เซ็นชื่อแล้วและดู “เหมือนแบ็กดอร์” มาก อาจถูกใส่ไว้ในชิปโดยที่ Apple ไม่รู้ เช่น โดยนักพัฒนา GPU
      กล่าวคือ ไม่ถึง 3.5 ปีหลังจากชิปที่มีช่องโหว่ตัวแรกออกสู่ตลาด ชุด MMIO ดีบักที่ไม่มีเอกสารของ Apple Coresight GPU ซึ่งต้องอาศัยความรู้เกี่ยวกับค่าลับยาว ๆ ก็ถูกกลุ่ม APT เดิมที่มีประวัติเกิน 10 ปีนำไป weaponize และใช้โจมตีได้สำเร็จ Kaspersky บอกว่า “ไม่คาดเดา” แต่โดยส่วนตัวแล้ว ดูมีความเป็นไปได้น้อยถ้าไม่ใช่ ผู้ปฏิบัติการระดับรัฐรายใหญ่
      ถ้าจะคาดเดา Apple น่าจะได้รับหลักฐานเพียงพอว่า Apple ID ที่เกี่ยวข้องกับ APT ราว 40 บัญชีเปิดเผยตัวตนของตัวเอง ดังนั้นอาจดูตัวตนได้จากว่าหลังจากนี้จะมีประกาศด้านความมั่นคงแห่งชาติของสหรัฐฯ หรือไม่ ถ้าเงียบไป ก็น่าจะเป็น NSA
    • ตอนนี้มีสิ่งที่ดูเหมือนเป็นเวอร์ชันแรกของวิดีโอบันทึกจริงถูกอัปโหลดแล้ว:
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...