Operation Triangulation: Những gì nhận được khi tấn công iPhone của các nhà nghiên cứu

 (securelist.com)
1 điểm bởi GN⁺ 2023-12-28 | 1 bình luận | Chia sẻ qua WhatsApp
  • Các nhà nghiên cứu Kaspersky đã công bố chuỗi tấn công iMessage 0-click trên iPhone của Operation Triangulation tại 37C3, và đánh giá đây là chuỗi tinh vi nhất họ từng thấy
  • Cuộc tấn công được thiết kế để hoạt động đến iOS 16.2, kết hợp 4 lỗ hổng zero-day để dẫn tới thực thi mã từ xa, leo thang đặc quyền, vượt qua PPL và thực thi giai đoạn Safari
  • Bí ẩn cốt lõi là phần đã được giảm thiểu với CVE-2023-38606: kẻ tấn công dùng các thanh ghi MMIO chưa được biết đến của SoC Apple A12–A16 Bionic để vượt qua cơ chế bảo vệ bộ nhớ kernel dựa trên phần cứng
  • Phân tích cho thấy các thanh ghi này có vẻ liên quan đến bộ đồng xử lý GPU; một số không được tham chiếu trong DeviceTree hay firmware, nên chưa xác định được kẻ tấn công đã biết cách sử dụng chúng như thế nào
  • Trong bản cập nhật ngày 9/1/2024, giá trị từng có vẻ là “hash tùy chỉnh” đã được xác nhận là ECC dựa trên Hamming code, khiến khả năng cao đây là tính năng gỡ lỗi truy cập trực tiếp vào cache thay vì bộ nhớ

Chuỗi tấn công đã được công bố

  • Ngày 27/12/2023, tại bài trình bày ở 37C3, kết quả phân tích dài hạn về Operation Triangulation đã được công bố
  • Đây là lần đầu tiên các chi tiết về exploit và lỗ hổng được dùng trong cuộc tấn công được tiết lộ
  • Các nhà nghiên cứu từng phát hiện và báo cáo hơn 30 zero-day bị khai thác thực tế trong các sản phẩm của Adobe, Apple, Google, Microsoft, nhưng đánh giá chuỗi tấn công này là một trong những chuỗi tinh vi nhất

Từ iMessage 0-click đến nạp spyware

  • Kẻ tấn công gửi tệp đính kèm iMessage độc hại, và ứng dụng xử lý nó mà không hiển thị cho người dùng
  • Tệp đính kèm khai thác CVE-2023-41990, một lỗ hổng thực thi mã từ xa trong lệnh font TrueType ADJUST không được tài liệu hóa, dành riêng cho Apple
    • Lệnh này đã tồn tại từ đầu thập niên 1990 và đã bị loại bỏ bằng bản vá
  • Sau đó là nhiều giai đoạn sử dụng return/jump oriented programming và ngôn ngữ truy vấn NSExpression/NSPredicate
    • Môi trường JavaScriptCore được vá để chạy exploit leo thang đặc quyền viết bằng JavaScript
  • Exploit JavaScript đã được thu nhỏ kích thước và làm rối để hoàn toàn khó đọc, nhưng có quy mô khoảng 11.000 dòng
    • Phần lớn được dùng để phân tích cú pháp và thao tác bộ nhớ JavaScriptCore cũng như bộ nhớ kernel
  • Nó lạm dụng DollarVM($vm), tính năng gỡ lỗi của JavaScriptCore, để thao tác bộ nhớ JavaScriptCore từ script và thực thi các hàm API native
  • Được thiết kế để hỗ trợ cả iPhone đời cũ lẫn đời mới, đồng thời bao gồm cả vượt qua PAC để khai thác các mẫu mới nhất

Truy cập bộ nhớ kernel và vượt qua PPL

  • Exploit sử dụng CVE-2023-32434, lỗ hổng tràn số nguyên trong các syscall ánh xạ bộ nhớ XNU là mach_make_memory_entry và vm_map
    • Nhờ đó có được quyền đọc/ghi từ mức người dùng đối với toàn bộ bộ nhớ vật lý của thiết bị
  • Sau đó nó vượt qua Page Protection Layer(PPL) bằng thanh ghi MMIO phần cứng
  • Sau khi khai thác tất cả lỗ hổng, exploit JavaScript có thể thực hiện hành vi tùy ý trên thiết bị
    • Kẻ tấn công chạy tiến trình IMAgent và tiêm payload để xóa dấu vết exploit
    • Chạy tiến trình Safari ở chế độ không hiển thị và chuyển sang trang web giai đoạn tiếp theo
  • Trang web xác minh nạn nhân, rồi nếu vượt qua điều kiện sẽ chuyển exploit Safari
  • Exploit Safari dùng CVE-2023-32435 để thực thi shellcode
  • Shellcode chạy một exploit kernel khác ở dạng tệp Mach object
    • Exploit này cũng dùng CVE-2023-32434 và CVE-2023-38606
    • Nó khác phần lớn so với exploit kernel JavaScript, chỉ chia sẻ một số đoạn mã liên quan đến việc khai thác cùng các lỗ hổng
  • Cuối cùng, nó giành quyền root và chạy các giai đoạn khác để nạp spyware

Bí ẩn phần cứng của CVE-2023-38606

  • Các mẫu iPhone mới có cơ chế bảo vệ dựa trên phần cứng nhằm bảo vệ các vùng bộ nhớ kernel nhạy cảm
  • Cơ chế này được thiết kế để ngăn kẻ tấn công kiểm soát hoàn toàn thiết bị ngay cả khi có thể đọc và ghi bộ nhớ kernel
  • Kẻ tấn công Operation Triangulation đã dùng một tính năng phần cứng khác của SoC do Apple thiết kế để vượt qua cơ chế bảo vệ này
  • Hành vi quan sát được như sau
    • Ghi dữ liệu, địa chỉ đích và hash dữ liệu vào các thanh ghi phần cứng chưa xác định trên chip
    • Các thanh ghi này có vẻ không được firmware sử dụng
    • Kết quả là có thể ghi dữ liệu vào địa chỉ vật lý cụ thể, vượt qua cơ chế bảo vệ bộ nhớ dựa trên phần cứng
  • Tính năng này có thể từng là tính năng gỡ lỗi dành cho kỹ sư Apple hoặc kiểm thử tại nhà máy, hoặc có thể đã được đưa vào do nhầm lẫn
  • Vì đây là tính năng không được dùng trong firmware, chưa xác định được kẻ tấn công đã biết cách sử dụng nó như thế nào

Phân tích MMIO và DeviceTree

  • Thiết bị ngoại vi của SoC có thể cung cấp các thanh ghi phần cứng đặc biệt để CPU điều khiển thiết bị
  • Các thanh ghi này được ánh xạ vào bộ nhớ CPU có thể truy cập và được gọi là memory-mapped I/O(MMIO)
  • Dải địa chỉ MMIO của thiết bị ngoại vi trong sản phẩm Apple được lưu ở định dạng DeviceTree
    • Có thể trích xuất tệp DeviceTree từ firmware
    • Có thể xem nội dung bằng tiện ích dt
  • Phần lớn MMIO mà kẻ tấn công dùng để vượt qua PPL không thuộc bất kỳ dải MMIO nào được định nghĩa trong DeviceTree
  • Exploit nhắm tới SoC Apple A12–A16 Bionic và sử dụng các khối MMIO chưa biết sau
    • 0x206040000
    • 0x206140000
    • 0x206150000
  • Không tìm thấy tham chiếu đến các địa chỉ này trong DeviceTree của nhiều thiết bị và firmware, mã nguồn công khai, image kernel, kernel extension, iBoot hay firmware của bộ đồng xử lý

Liên hệ với bộ đồng xử lý GPU

  • Khi kiểm tra các MMIO đã biết xung quanh, các địa chỉ chưa biết nằm gần gfx-asc, tức bộ đồng xử lý GPU
  • gfx-asc có hai dải MMIO
    • 0x206400000–0x20646C000
    • 0x206050000–0x206050008
  • Các địa chỉ chưa biết mà exploit thực sự sử dụng là
    • 0x206040000
    • 0x206140008
    • 0x206140108
    • 0x206150020
    • 0x206150040
    • 0x206150048
  • Phần lớn nằm giữa hai vùng gfx-asc, địa chỉ còn lại nằm gần điểm bắt đầu của vùng gfx-asc thứ nhất
  • Các thanh ghi này được đánh giá nhiều khả năng thuộc về bộ đồng xử lý GPU
  • Trong quá trình khởi tạo exploit, cũng phát hiện mã thao tác thanh ghi trình quản lý nguồn GFX ở các địa chỉ khác nhau tùy SoC
    • Tiện ích pmgr xác nhận các địa chỉ đó tương ứng với thanh ghi GFX trong dải MMIO của trình quản lý nguồn
  • Khi truy cập các thanh ghi ở vùng chưa biết, bộ đồng xử lý GPU bị panic với thông báo “GFX SERROR Exception”
    • Kết quả này cũng củng cố nhận định rằng các thanh ghi đó thuộc về bộ đồng xử lý GPU

CoreSight và vùng UTT riêng của Apple

  • Thanh ghi 0x206040000 chỉ được dùng trong giai đoạn khởi tạo và kết thúc của exploit
    • Nó được thiết lập đầu tiên khi khởi tạo và được xử lý cuối cùng khi kết thúc
  • Thanh ghi này được phân tích là có vai trò bật/tắt tính năng phần cứng hoặc điều khiển interrupt
  • Hành vi của exploit tương ứng với hàm ml_dbgwrap_halt_cpu trong mã nguồn XNU dbgwrap.c
  • dbgwrap.c là mã xử lý các thanh ghi gỡ lỗi MMIO ARM CoreSight của CPU chính
  • Mã nguồn XNU nhắc đến bốn vùng MMIO liên quan đến CoreSight: ED, CTI, PMU, UTT
    • Mỗi vùng chiếm 0x10000 byte
    • Bốn vùng nằm liền kề nhau
  • Mã nguồn ghi rằng vùng UTT không đến từ ARM mà là tính năng riêng của Apple được thêm vào để thuận tiện
  • Khi ghi ARM_DBG_LOCK_ACCESS_KEY vào vị trí tương ứng, có thể xác nhận 0x206000000–0x206050000 là khối thanh ghi gỡ lỗi CoreSight MMIO của bộ đồng xử lý GPU
  • Mỗi lõi của CPU chính cũng có khối thanh ghi gỡ lỗi CoreSight MMIO riêng, nhưng khác với bộ đồng xử lý GPU, địa chỉ của chúng có thể được tìm thấy trong DeviceTree
  • Tác giả exploit cũng biết cách dùng vùng UTT riêng của Apple để hủy trạng thái halt của CPU
    • Đoạn mã này không có trong mã nguồn XNU

Tính năng chưa xác định hoạt động giống DMA

  • Các thanh ghi 0x206140008 và 0x206140108 điều khiển việc kích hoạt/vô hiệu hóa và thực thi tính năng phần cứng mà exploit sử dụng
  • 0x206150020 chỉ được dùng trên SoC Apple A15/A16 Bionic
    • Được đặt thành 1 trong giai đoạn khởi tạo và được khôi phục về giá trị ban đầu trong giai đoạn kết thúc
  • 0x206150040 được dùng để lưu cờ và nửa thấp của địa chỉ vật lý đích
  • 0x206150048 được dùng để lưu cùng lúc dữ liệu cần ghi, nửa cao của địa chỉ vật lý đích, hash dữ liệu và một giá trị khác
    • Tính năng phần cứng ghi dữ liệu theo từng khối 0x40 byte đã căn chỉnh
    • Thanh ghi 0x206150048 cần 9 lần ghi liên tiếp
  • Nếu toàn bộ quy trình đúng, phần cứng thực hiện hành vi DMA và ghi dữ liệu vào vị trí được yêu cầu
  • Exploit dùng tính năng này để vượt qua PPL, chủ yếu bằng cách vá các page table entry
  • Nó cũng có thể được dùng để vá dữ liệu trong phân đoạn __PPLDATA được bảo vệ
  • Tính năng này không được dùng để vá mã kernel
    • Trong một lần thử nghiệm, khi ghi đè một lệnh kernel trong phân đoạn __TEXT_EXEC, đã thu được panic “Undefined Kernel Instruction” với địa chỉ và giá trị như dự kiến
    • Các lần thử khác gây ra panic AMCC

Hash, ECC và khả năng truy cập cache

  • Phân tích ban đầu cho thấy tính năng này dường như yêu cầu một hash tùy chỉnh
    • Hash được tính bằng bảng sbox định sẵn
    • Đã tìm bảng này trong một bộ sưu tập nhị phân lớn nhưng không thấy
  • Hash dường như dài 20 bit, tức tính hai lần giá trị 10 bit
  • Nếu kẻ tấn công không biết cách tính và cách dùng, cấu trúc này gần với security by obscurity
  • Trong bản cập nhật ngày 9/1/2024, Hector Martin xác nhận giá trị này không phải hash tùy chỉnh đơn giản mà là mã sửa lỗi(ECC)
    • Chính xác hơn, đó là Hamming code dùng lookup table tùy chỉnh
  • Phát hiện này là manh mối để hiểu mục đích ban đầu của tính năng phần cứng chưa xác định
    • Ban đầu, nó trông như một tính năng gỡ lỗi cung cấp truy cập bộ nhớ trực tiếp kèm hash “giả”
    • Do ECC được sử dụng và hành vi không ổn định được quan sát khi vá mã kernel, khả năng cao tính năng này là chức năng truy cập trực tiếp vào cache

Thử nghiệm M1 và giảm thiểu trong iOS 16.6

  • Đã xác nhận rằng chip M1 của Mac cũng có tính năng phần cứng chưa biết này
  • Dùng tính năng trace_range của công cụ m1n1 để theo dõi truy cập MMIO trong dải 0x206110000–0x206400000
    • Không có báo cáo dấu vết cho thấy macOS sử dụng các thanh ghi này
  • Trong iOS 16.6, Apple đã giảm thiểu lỗ hổng bằng cách thêm các dải MMIO mà exploit sử dụng vào pmap-io-ranges của DeviceTree
    • Các dải được thêm là 0x206000000–0x206050000 và 0x206110000–0x206400000
  • XNU dùng thông tin pmap-io-ranges để quyết định có cho phép ánh xạ một địa chỉ vật lý cụ thể hay không
  • Các mục pmap-io-ranges thông thường có tên tag có ý nghĩa như PCIe, DART, DAPF, nhưng tên tag của vùng liên quan đến lỗ hổng này nổi bật khác với các mục khác

Câu hỏi còn lại và hàm ý bảo mật

  • Chưa xác định được kẻ tấn công đã biết cách sử dụng tính năng phần cứng chưa biết này như thế nào
  • Mục đích ban đầu của tính năng này cũng vẫn chưa rõ
    • Không biết đây là tính năng do Apple phát triển hay là thành phần bên thứ ba như ARM CoreSight
  • Ngay cả sau bản cập nhật, bí ẩn vẫn còn
    • Kẻ tấn công có thể brute force các giá trị trong lookup table tùy chỉnh chỉ bằng thử nghiệm
    • Nhưng họ cần biết sự tồn tại của một tính năng gỡ lỗi cache mạnh, việc dùng Hamming code, vị trí và mục đích của các thanh ghi MMIO liên quan, cũng như thứ tự tương tác
  • Ngay cả khi có bảo vệ dựa trên phần cứng, nếu tồn tại tính năng phần cứng có thể vượt qua nó, cơ chế đó có thể trở nên vô hiệu trước các kẻ tấn công tinh vi
  • Bảo mật phần cứng khó đảo ngược hơn phần mềm rất nhiều, nhưng các hệ thống dựa vào “security through obscurity” sẽ không còn an toàn ngay khi bí mật bị lộ

Bài viết liên quan

1 bình luận

 
GN⁺ 2023-12-28
Ý kiến trên Hacker News

  • Video bài trình bày cũng đã được đăng: https://www.youtube.com/watch?v=7VWNUUldBEE

  • Nội dung khá đáng kinh ngạc. Lạm dụng MMIO có nghĩa là kẻ tấn công hoặc có năng lực nghiên cứu cực kỳ lớn, hoặc đã hack Apple để lấy tài liệu phần cứng nội bộ; khả năng sau có vẻ hợp lý hơn
    Cho đến trước khi xuất hiện S-box của hàm băm tùy chỉnh, tôi còn nghĩ một nhóm nghiên cứu quy mô cỡ NSA có thể làm được, nhưng từ phần đó trở đi thì có vẻ Apple biết tính năng này nguy hiểm nên cố tình giấu nó, và dù nó là gì đi nữa thì còn bảo vệ nó bằng một dạng chữ ký số yếu nào đó
    Như bài blog đã chỉ ra, ngoài việc bóc tách và reverse engineering toàn bộ silicon, không có cách rõ ràng nào để tìm ra “cú gõ ma thuật” đúng để kích hoạt tính năng này. Ở các node quy trình như vậy thì thực tế là không khả thi, nên chỉ còn khả năng hack nhà phát triển để đánh cắp tài liệu nội bộ
    Việc dùng một chuỗi zero-day đắt đỏ và dài để mở một Safari vô hình, rồi tải một trang web bằng một chuỗi exploit hoàn toàn khác để hack lại thiết bị, cũng mang mùi của một tổ chức khổng lồ với các silo nội bộ nghiêm trọng
    Xét việc các nhà nghiên cứu là người Nga của Kaspersky, đây gần như chắc là NSA, hoặc có lẽ là một chiến dịch của GCHQ
    Một số phần thú vị khác của bài trình bày: malware có thể bật theo dõi quảng cáo và cũng có thể phát hiện dịch vụ hosting iPhone trên cloud mà các nhà nghiên cứu bảo mật hay dùng. Nền tảng malware iOS/macOS dường như đã được phát triển hơn 10 năm; nó thậm chí chạy machine learning trên thiết bị để nhận dạng đối tượng và OCR nhằm tránh upload byte ảnh, chỉ upload các nhãn được tạo ra. Đã bỏ ra rất nhiều công sức, nhưng cuối cùng vẫn không đủ trước những sinh viên Nga thông minh
    Tuy nhiên, tôi không hoàn toàn đồng ý với câu của diễn giả rằng “bảo mật dựa trên sự mơ hồ không hiệu quả”. Nền tảng này đã tồn tại ngoài thực tế 10 năm, và không ai biết tính năng “phần cứng” ẩn đó đã bị lạm dụng bao lâu. Nếu tính năng phần cứng đó được tài liệu hóa công khai, nó đã bị phát hiện nhanh hơn rất, rất nhiều

    • Phần “nếu tính năng phần cứng đó được tài liệu hóa công khai thì đã bị phát hiện nhanh hơn nhiều” có nghĩa là theo nguyên tắc Kerckhoffs, ngay từ đầu nó đáng lẽ phải được tài liệu hóa công khai, và bất kỳ ai xem tài liệu trước khi phát hành cũng đáng lẽ phải nói rằng “không thể phát hành như thế này, phải bỏ tính năng này đi”
    • Cũng có script IoC có thể quét các chỉ báo xâm nhập của Operation Triangulation trong bản sao lưu iTunes: https://github.com/KasperskyLab/triangle_check
    • Đúng là một cuộc tấn công đáng nể, và tôi đồng ý với phân tích trên. Phần “hack lại” thiết bị bằng tab Safari ẩn có thể, như đã nói, là hậu quả xấu của các silo trong tổ chức, và cũng gợi nhớ cách tiếp cận kiểu “tạo virus” của đám script kiddie thập niên 90
      Nó cũng có thể là thiết kế mô-đun để thích ứng nhanh, tức có khả năng là một cấu trúc ít nhắm mục tiêu hơn
    • Hoặc cũng có thể Apple đã đơn giản triển khai “API” này cho họ sau khi họ lịch sự đề nghị
    • Có quá nhiều thông tin sai trong thread này. Đây là Hamming ECC như được giải thích ở đây[1]
      [1] https://social.treehouse.systems/@marcan/111655847458820583

  • Steve Weis đã tóm tắt hay nhất trên Twitter:
    “Exploit iMessage này điên thật. Có một lỗ hổng TrueType tồn tại từ thập niên 90, 2 exploit kernel, một exploit trình duyệt, và cả một tính năng phần cứng không được tài liệu hóa chưa từng được dùng trong phần mềm phát hành”
    https://x.com/sweis/status/1740092722487361809?s=46&t=E3U2EI...

  • Nếu bạn tò mò về bài trình bày của các nhà nghiên cứu Kaspersky, video đã biên tập thì chưa có, nhưng có thể xem lại bản stream ở đây:
    https://streaming.media.ccc.de/37c3/relive/a91c6e01-49cf-422...
    Bài trình bày bắt đầu từ 26:20

  • Về bài trình bày tại 37c3, cũng có bài viết bằng tiếng Đức của Fefe¹: https://blog.fefe.de/?ts=9b729398
    Theo ông ấy, giá trị của chuỗi exploit này có khả năng ở mức 8 chữ số USD
    ¹ https://en.wikipedia.org/wiki/Felix_von_Leitner
    Có lẽ ai đó sẽ bị sa thải

    • Tại sao? Việc exploit bị “đốt” là một phần của ngành này mà

  • Coresight không phải backdoor mà là tính năng debug có trong mọi CPU ARM. Cái này trông giống một phần mở rộng Coresight cần thiết để hoạt động cùng cơ chế bảo vệ bộ nhớ của Apple
    Dù không có tài liệu công khai, hàng nghìn kỹ sư Apple có lẽ có quyền truy cập vào gdb đã được chỉnh sửa hoặc các công cụ khác có thể tận dụng nó

    • Với người này thì là công cụ debug, với người khác thì là backdoor
    • Nhưng vẫn không giải thích được phần hashing kỳ lạ

  • Nếu là thiết bị được giám sát, có thể vô hiệu hóa iMessage bằng MDM cục bộ thông qua Apple Configurator miễn phí trên macOS App Store: https://support.apple.com/guide/deployment/restrictions-for-...
    Trên thiết bị chỉ có Wi-Fi, ứng dụng Messages sẽ bị ẩn
    Trên thiết bị có cả Wi-Fi và mạng di động, ứng dụng Messages vẫn hiển thị nhưng chỉ dùng được dịch vụ SMS/MMS
    Ví dụ, khi dùng thiết bị trong thời gian dài chỉ qua Wi-Fi, có thể dùng SIM PIN để vô hiệu hóa tin nhắn SMS/MMS và lưu lượng vô tuyến di động không khẩn cấp

    • Tôi từng mua iPad bản di động, lắp SIM của nước mình vào để tiếp tục nhận SMS. Vì các ngân hàng ở nước đó vẫn yêu cầu xác thực qua SMS khi đăng nhập
      Nhưng rồi tôi phát hiện iPad bản di động trên thực tế không hiển thị SMS nào không do nhà mạng của SIM gửi

  • Điều đáng chú ý là giá trị băm của thao tác ghi dữ liệu toàn số 0 cũng là 0
    Và với trường hợp một bit đơn lẻ, giá trị băm sẽ trở thành một giá trị đơn trong bảng S-box. Nói cách khác, thuật toán băm này rất có thể đã đủ để bị dịch ngược ngay cả khi không có tài liệu nội bộ

    • Nó có “mùi” của một cách điển hình để ngăn các thao tác ghi bộ nhớ vào địa chỉ ngẫu nhiên vô tình kích hoạt phần cứng này. Có vẻ không phải được thiết kế như một tính năng bảo mật
      Thực tế, nếu ai đó nói rằng không được để xảy ra ghi tùy ý do lỗi, thì tôi cũng sẽ triển khai như vậy. Cách triển khai này cũng ngăn hiệu quả việc dùng tính năng này trong trạng thái biết địa chỉ bộ đệm nhưng không biết nội dung của nó
      Nếu hệ thống khởi động lại mỗi khi giá trị băm sai, thì độ an toàn 10 bit có lẽ cũng đủ cho mục đích đó. Chức năng debug Coresight có thể khởi động lại hoàn toàn hệ thống nếu muốn

  • Khả năng thanh ghi MMIO này được phát hiện bằng cách tìm kiếm vét cạn trên mọi địa chỉ thanh ghi là bao nhiêu?
    Có thể chỉ riêng khác biệt thời gian đã cho biết địa chỉ đó là hợp lệ, và hàm băm thực chất cũng chỉ là băm 20 bit nên có lẽ có thể brute force được

    • Có vẻ các thanh ghi có thể được nhận diện khá dễ bằng brute force. Chúng nằm gần về mặt vật lý với các thanh ghi GPU đã được tài liệu hóa, và khi truy cập sẽ gây GPU panic nên các nhà nghiên cứu cũng quy chúng về thành phần GPU. Kẻ tấn công hẳn cũng có thể phát hiện sự tồn tại của thanh ghi bằng cùng phép thử
      Phần khó giải thích hơn là làm sao họ khôi phục được bảng S-box tùy chỉnh để chạy mã debug. Đây là chỗ hàm ý về mối đe dọa nội gián trở nên mạnh nhất, nhưng cá nhân tôi không cho rằng điều đó loại trừ các cách giải thích hợp lý khác
      Ví dụ, kẻ tấn công có thể đã trích xuất S-box từ firmware cũ, bản vá cập nhật OTA, thiết bị phát triển trước khi ra mắt (rất có khả năng từng mua được trên eBay ở một thời điểm nào đó), bản phát hành beta của iOS, hoặc nhiều kênh rò rỉ khác
      Về cơ bản, nhà nghiên cứu nói rằng “không tìm thấy bảng S-box này trong bất kỳ binary nào khác đã kiểm tra”. Nhưng xét việc nó có vẻ dành riêng cho Apple nên số lượng binary có khả năng chứa nó là hữu hạn, điều đó không hẳn đáng ngạc nhiên. Như nhà nghiên cứu cũng nói, trong số này có cả những binary hiện không công khai nhưng có thể từng bị phân phối nhầm. Hoàn toàn hợp lý khi cho rằng những kẻ tấn công đã tìm kiếm có hệ thống các rò rỉ như vậy và may mắn có được ở một thời điểm nào đó, còn nhà nghiên cứu thì khó sớm có được may mắn tương tự
    • Nhìn vào cách triển khai S-box đó, khó tin rằng nó được triển khai trong phần cứng chip dưới dạng bảng tra cứu. Hẳn phải có một biểu thức Boolean nén gọn hơn cho cùng kết quả
      Việc những kẻ tấn công không biết biểu thức Boolean đó cho thấy nhiều khả năng họ đã dịch ngược hơn là có tài liệu

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

    • Bắt đầu từ 27:21
      Nếu sắp xếp theo trình tự thời gian cùng với nội dung bài trình bày thì như sau
      Tháng 9/2018: Apple A12 Bionic SOC, CPU đầu tiên có MMIO không được tài liệu hóa, được phát hành
      Tháng 12/2021: hạ tầng chuỗi khai thác ban đầu backuprabbit.com được tạo lúc 2021-12-15T18:33:19Z, cloudsponcer.com được tạo lúc 2021-12-17T16:33:50Z
      Tháng 4/2022: hạ tầng chuỗi khai thác sau đó snoweeanalytics.com được tạo lúc 2022-04-20T15:09:17Z, cho thấy exploit đã được vũ khí hóa trước ngày này
      Tháng 12/2023: có vẻ là thời điểm phát hiện xấp xỉ. Đây là giá trị suy ngược từ thời gian phân tích “nửa năm” và báo cáo của Apple vào giữa năm 2023
      Các diễn giả nói rằng dựa trên dấu vết trong mã, nhóm APT nguồn gốc đã dùng cùng codebase tấn công trong “10 năm”, tức từ khoảng năm 2013, và cũng dùng nó để tấn công laptop macOS. Bao gồm cả né tránh antivirus
      Các diễn giả cũng nêu khả năng một chức năng debug đã ký, rất “giống backdoor”, đã được đưa vào chip mà Apple không biết, chẳng hạn bởi nhà phát triển GPU
      Nói cách khác, chưa đầy 3,5 năm sau khi con chip dễ bị tấn công đầu tiên ra thị trường, một loạt MMIO debug không được tài liệu hóa của Apple Coresight GPU, vốn cần biết giá trị bí mật dài, đã được một nhóm APT hiện hữu có lịch sử hơn 10 năm vũ khí hóa và lạm dụng thành công. Kaspersky nói họ “không suy đoán”, nhưng cá nhân tôi thấy khả năng ngoài một tác nhân nhà nước lớn là không cao
      Nếu suy đoán, Apple có lẽ đã nhận đủ bằng chứng cho thấy khoảng 40 Apple ID liên quan đến APT tự làm lộ danh tính, nên có thể phán đoán danh tính dựa trên việc sau đó Mỹ có công bố gì liên quan đến an ninh quốc gia hay không. Nếu im ắng thì có lẽ là NSA
    • Thứ có vẻ là phiên bản đầu tiên của bản ghi hình thực tế nay đã được đăng lên:
      https://media.ccc.de/v/37c3-11859-operation_triangulation_wh...