iPhone lộ lỗ hổng cấp độ phần cứng "phức tạp nhất" trong lịch sử! Tin tặc có thể lấy được tất cả dữ liệu nhạy cảm chỉ bằng một iMessage mà người dùng không hề hay biết. Chuỗi liên quan đến toàn bộ lỗ hổng cực kỳ phức tạp, khiến Karpathy phải thốt lên: Đó không phải là điều người bình thường có thể làm được.
Gần đây, các nhà nghiên cứu của Kaspersky phát hiện ra rằng tin tặc đã để lại một cửa hậu rất ẩn trong hàng nghìn chiếc iPhone trong vòng 4 năm.
Thông qua cửa sau cấp phần cứng này, bạn có thể trực tiếp có được quyền Root cấp cao nhất trên iPhone. Để khai thác thành công cửa hậu này, người ta phải có hiểu biết rất toàn diện và chi tiết về cơ chế cơ bản của các sản phẩm Apple.
Đến mức nhà nghiên cứu của Kaspersky, người phát hiện ra lỗ hổng này đã nói: "Không thể tưởng tượng được lỗ hổng này lại vô tình được phát hiện như thế nào". Theo quan điểm của ông, gần như không ai khác ngoài Apple và ARM biết về lỗ hổng này.
Phần mềm gián điệp có thể sử dụng lỗ hổng phức tạp này để truyền bản ghi micrô, ảnh, vị trí địa lý và dữ liệu nhạy cảm khác đến máy chủ do kẻ tấn công kiểm soát.
Mặc dù việc khởi động lại sẽ đóng lỗ hổng nhưng kẻ tấn công có thể mở lại nó chỉ bằng cách gửi một iMessage độc hại mới tới thiết bị sau khi thiết bị khởi động lại.
Không cần thao tác của người dùng trong thời gian này và sẽ không để lại manh mối nào, khiến nó rất ẩn.
Về vấn đề này, nhà khoa học OpenAI Andrej Karpathy cho biết: Đây chắc chắn là chuỗi tấn công phức tạp nhất mà chúng tôi từng thấy cho đến nay.
Về vấn đề này, Karpathy cho rằng đây không còn là phạm vi hành vi của cá nhân nữa mà phải là hành vi cấp quốc gia.
Một cư dân mạng cho rằng anh vẫn sử dụng điện thoại Palm đã trả lời: "Đây là lý do tại sao tôi nhất quyết sử dụng điện thoại Palm".
Một số cư dân mạng thậm chí còn than thở: "Nếu bạn thành công trong việc chọc tức mọi người bằng loại khả năng kỹ thuật và tài nguyên này, có lẽ điều cuối cùng bạn cần lo lắng là dữ liệu trên điện thoại của mình".
Hiện tại, Apple đã vá lỗ hổng bảo mật cốt lõi này vào ngày 25 tháng 10 năm 2023.
- Kẻ tấn công gửi tệp đính kèm độc hại qua iMessage và ứng dụng sẽ mở ra lỗ hổng mà người dùng không hề hay biết.
- Tệp đính kèm này khai thác lỗ hổng thực thi mã từ xa (CVE-2023-41990) trong chỉ thị phông chữ ADJUST TrueType không được tiết lộ mà chỉ Apple mới biết. Chỉ thị này đã có từ đầu những năm 1990 và đã bị xóa trong một bản cập nhật gần đây.
- Trong cuộc tấn công, nó đã sử dụng một kỹ thuật lập trình nâng cao gọi là "lập trình hướng quay lại/nhảy" và sử dụng nhiều giai đoạn mã được viết bằng ngôn ngữ truy vấn NSExpression/NSPredicate để sửa đổi môi trường thư viện JavaScriptCore để thực thi khai thác leo thang đặc quyền được viết bằng JavaScript.
- Việc khai thác JavaScript này đã được xử lý đặc biệt để làm cho nó gần như không thể đọc được, đồng thời giảm thiểu kích thước của nó. Tuy nhiên, nó vẫn chứa khoảng 11.000 dòng mã. Các mã này chủ yếu được sử dụng để phân tích và thao tác JavaScriptCore và bộ nhớ kernel.
- Nó còn lợi dụng DollarVM ($vm), một chức năng gỡ lỗi của JavaScriptCore, thông qua chức năng này, kẻ tấn công có thể thao túng bộ nhớ của JavaScriptCore trong tập lệnh và gọi các hàm API gốc của hệ thống.
- Công cụ tấn công này được thiết kế để tương thích với cả mẫu iPhone cũ và mới, đồng thời đối với các thiết bị mới hơn, nó bao gồm kỹ thuật vượt qua Mã xác thực con trỏ (PAC), cho phép cuộc tấn công có hiệu quả đối với các thiết bị mới nhất.
- Nó đạt được quyền kiểm soát đọc và ghi ở cấp độ người dùng đối với tất cả bộ nhớ vật lý của thiết bị bằng cách khai thác lỗ hổng tràn số nguyên (CVE-2023-32434) trong các lệnh gọi hệ thống ánh xạ bộ nhớ XNU (mach_make_memory_entry và vm_map).
- Công cụ này cũng sử dụng các thanh ghi I/O (MMIO) được ánh xạ bộ nhớ phần cứng để phá vỡ Lớp bảo vệ trang (PPL), một sự cố đã được giảm thiểu trong CVE-2023-38606.
- Sau khi khai thác hết lỗ hổng, lỗ hổng JavaScript có thể được sử dụng để điều khiển thiết bị theo ý muốn, bao gồm cả việc triển khai phần mềm gián điệp. Tuy nhiên, kẻ tấn công đã chọn: (a) khởi động quy trình IMAgent và tiêm mã để xóa dấu vết khai thác; (b) chạy quy trình Safari ở chế độ ẩn danh và hướng dẫn đến trang web chứa giai đoạn nội dung tiếp theo.
- Có một tập lệnh được nhúng trong trang web này có thể xác nhận danh tính của nạn nhân. Sau khi quá trình xác minh được thông qua, giai đoạn tiếp theo của mã tấn công sẽ được tải: lỗ hổng Safari.
- Lỗ hổng Safari cho phép thực thi shellcode thông qua CVE-2023-32435.
- Shellcode này tiếp tục thực thi một lỗ hổng cấp kernel khác, đồng thời khai thác CVE-2023-32434 và CVE-2023-38606. Nó có kích thước và chức năng rất lớn nhưng rất khác với các cách khai thác kernel được viết bằng JavaScript. Tất cả những gì họ chia sẻ là một phần mã liên quan đến các cách khai thác trên. Tuy nhiên, phần lớn mã của nó cũng tập trung vào việc phân tích cú pháp và thao tác bộ nhớ kernel.
- Lỗ hổng cuối cùng đã giành được quyền root và tiếp tục qua các giai đoạn khác, cho phép tải phần mềm gián điệp.
Thế hệ iPhone mới đã bổ sung thêm các biện pháp bảo mật ở cấp độ phần cứng, được thiết kế đặc biệt để bảo vệ các vùng nhạy cảm trong bộ nhớ kernel.
Ngay cả khi kẻ tấn công có thể đọc và ghi bộ nhớ kernel, chẳng hạn như trong cuộc tấn công khai thác lỗ hổng CVE-2023-32434 này, biện pháp bảo vệ này sẽ ngăn chúng chiếm toàn bộ quyền kiểm soát thiết bị.
Các nhà nghiên cứu phát hiện ra rằng để vượt qua biện pháp bảo vệ phần cứng này, những kẻ tấn công đã lợi dụng một tính năng phần cứng khác trong SoC do Apple thiết kế.
Nói một cách đơn giản, phương pháp của kẻ tấn công như sau: trong khi vượt qua sự bảo vệ phần cứng, chúng ghi dữ liệu, địa chỉ đích và giá trị băm của dữ liệu vào một số thanh ghi phần cứng không xác định trong chip mà phần sụn không sử dụng. dữ liệu đến một địa chỉ vật lý cụ thể.
Các nhà nghiên cứu suy đoán rằng tính năng phần cứng không xác định này có thể được thiết kế để gỡ lỗi hoặc thử nghiệm bởi các kỹ sư hoặc nhà máy của Apple hoặc được đưa vào một cách vô tình. Vì phần sụn không sử dụng tính năng này nên các nhà nghiên cứu không biết làm thế nào kẻ tấn công biết và khai thác tính năng này.
Để đạt được điều này, các thanh ghi phần cứng này được ánh xạ vào bộ nhớ mà CPU có thể truy cập, một phương pháp được gọi là I/O được ánh xạ bộ nhớ (MMIO).
Trong các sản phẩm của Apple, chẳng hạn như iPhone, Mac và các thiết bị khác, dải địa chỉ MMIO của thiết bị ngoại vi được lưu trữ ở định dạng tệp đặc biệt gọi là "DeviceTree".
Các tệp cây thiết bị này có thể được trích xuất từ chương trình cơ sở và có thể xem nội dung của chúng bằng công cụ dt (DeviceTree).
Ví dụ: trong ảnh chụp màn hình này, bạn có thể thấy địa chỉ bắt đầu (0x210f00000) và kích thước (0x50000) của phạm vi MMIO acc-impl của cpu0.
Khi đào sâu vào các lỗ hổng được sử dụng trong cuộc tấn công Operation Triangulation, các nhà nghiên cứu bất ngờ phát hiện ra rằng hầu hết các địa chỉ MMIO được kẻ tấn công sử dụng để vượt qua bảo vệ bộ nhớ kernel cấp phần cứng đều không được xác định trong cây thiết bị.
Lỗ hổng này đặc biệt nhắm vào các SoC của Apple từ A12 đến A16, tấn công khối đăng ký MMIO bí ẩn nằm ở 0x206040000, 0x206140000 và 0x206150000.
Điều này khơi dậy sự tò mò của các nhà nghiên cứu và khiến họ tiến hành một loạt nỗ lực. Tôi đã tìm kiếm trong tệp cây thiết bị và tệp chương trình cơ sở của nhiều thiết bị khác nhau nhưng không tìm thấy bất kỳ manh mối nào.
Điều này khiến các nhà nghiên cứu bối rối, tại sao những địa chỉ MMIO này được kẻ tấn công sử dụng lại không được sử dụng trong firmware? Làm thế nào kẻ tấn công phát hiện ra những địa chỉ này? Những địa chỉ MMIO này thuộc về thiết bị ngoại vi nào?
Sau đó, các nhà nghiên cứu quyết định xem liệu có địa chỉ MMIO nào khác được biết đến gần các khối MMIO chưa biết này hay không. Lần này hắn cuối cùng cũng tìm được một ít tin tức có giá trị.
Trong thông tin mục cây thiết bị của gfx-asc thì đây là bộ đồng xử lý của GPU.
Nó chứa hai phạm vi ánh xạ bộ nhớ MMIO (I/O được ánh xạ bộ nhớ): 0x206400000–0x20646C000 và 0x206050000–0x206050008.
Mối tương quan giữa phạm vi MMIO gfx-asc và địa chỉ được lỗ hổng bảo mật sử dụng
Để mô tả chính xác hơn, lỗ hổng này sử dụng các địa chỉ không xác định sau: 0x206040000, 0x206140008, 0x206140108, 0x206150020, 0x206150040 và 0x206150048.
Các nhà nghiên cứu nhận thấy rằng hầu hết các địa chỉ này nằm ở giữa hai vùng bộ nhớ gfx-asc, trong khi địa chỉ còn lại gần với điểm bắt đầu của vùng gfx-asc đầu tiên.
Điều này ngụ ý rằng tất cả các thanh ghi Đầu ra đầu vào được ánh xạ bộ nhớ (MMIO) này rất có thể là bộ đồng xử lý thuộc Bộ xử lý đồ họa (GPU)!
Sau đó, các nhà nghiên cứu đã tiến hành phân tích sâu hơn về lỗ hổng và phát hiện thêm bằng chứng.
Trong quá trình khởi tạo, trước tiên, lỗ hổng bảo mật sẽ ghi vào một số thanh ghi đầu vào và đầu ra (MMIO) được ánh xạ bộ nhớ đặt tại các địa chỉ cụ thể trong mỗi SoC.
nếu (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) base = 0x23B700408 lệnh = 0x1F0023FF
elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) base = 0x23B7003C8 lệnh = 0x1F0023FF
elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) base = 0x23B7003D0 lệnh = 0x1F0023FF
elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) base = 0x23B080390 lệnh = 0x1F0003FF
elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) base = 0x23B080388 lệnh = 0x1F0003FF
if ((~read_dword(base) & 0xF) != 0): write_dword(base, command) while(True): if ((~read_dword(base) & 0xF) == 0): break
Cuối cùng, xác nhận thứ ba được đưa ra khi các nhà nghiên cứu cố gắng truy cập vào sổ đăng ký ở những vùng chưa xác định này.
Bộ đồng xử lý GPU đã báo lỗi gần như ngay lập tức, hiển thị thông báo: "GFX SERROR Exception class=0x2f (ngắt SError), IL=1, iss=0 – power(1)".
Bằng cách này, các nhà nghiên cứu xác nhận rằng tất cả các thanh ghi MMIO không xác định này, được sử dụng để khai thác, thực sự thuộc về bộ đồng xử lý của GPU.
Điều này đã thôi thúc nhà nghiên cứu tìm hiểu sâu hơn về phần sụn, phần sụn này cũng được viết bằng kiến trúc ARM và không được mã hóa, nhưng anh ta không tìm thấy bất kỳ thông tin nào liên quan đến các thanh ghi này trong phần sụn.
Anh quyết định xem xét kỹ hơn cách lỗ hổng này thao túng các thanh ghi MMIO không xác định này. Trong tất cả các thanh ghi, 0x206040000 đặc biệt đáng chú ý vì nó nằm trong một khối MMIO riêng biệt với tất cả các thanh ghi khác.
Nó chỉ bị thao túng trong giai đoạn khởi tạo và kết thúc của lỗ hổng: trong quá trình khởi tạo, đây là thanh ghi đầu tiên được thiết lập và trong giai đoạn kết thúc, nó là thanh ghi cuối cùng.
Dựa trên kinh nghiệm của nhà nghiên cứu, rõ ràng là thanh ghi này được sử dụng để bật/tắt chức năng phần cứng bị khai thác hoặc để kiểm soát ngắt.
Nhà nghiên cứu bắt đầu lần theo manh mối về sự gián đoạn và không lâu sau, anh ta không chỉ xác định được thanh ghi không xác định 0x206040000 mà còn phát hiện ra chính xác dải địa chỉ 0x206000000–0x206050000 được ánh xạ tới. Dưới đây là kết quả của kỹ thuật đảo ngược mã dễ bị tấn công mà các nhà nghiên cứu có thể xác định được.
def ml_dbgwrap_halt_cpu():
giá trị = read_qword(0x206040000)
if ((giá trị & 0x90000000) != 0): trả về
write_qword(0x206040000, giá trị | 0x80000000)
while (Đúng): if ((read_qword(0x206040000) & 0x10000000) != 0): ngắt
def ml_dbgwrap_unhalt_cpu():
giá trị = read_qword(0x206040000)
giá trị = (giá trị & 0xFFFFFFFF2FFFFFFF) | 0x40000000 write_qword(0x206040000, giá trị)
while (Đúng): if ((read_qword(0x206040000) & 0x10000000) == 0): ngắt
Đã khớp thành công hàm ml_dbgwrap_halt_cpu trong mã giả trước đó với hàm cùng tên trong tệp dbgwrap.c của mã nguồn XNU. Tệp này chứa mã để kiểm soát các thanh ghi gỡ lỗi ARM CoreSight MMIO của CPU chính.
Mã nguồn cho thấy có 4 lĩnh vực MMIO liên quan đến CoreSight là ED, CTI, PMU và UTT. Mỗi vùng chiếm 0x10000 byte và ngay lập tức liền kề với nhau.
Hàm ml_dbgwrap_halt_cpu tận dụng vùng UTT. Không giống như ba lĩnh vực còn lại, UTT không đến từ ARM mà là một tính năng độc quyền được Apple bổ sung đặc biệt để thuận tiện.
Mỗi lõi của CPU chính có khối thanh ghi gỡ lỗi CoreSight MMIO riêng, nhưng không giống như bộ đồng xử lý GPU, địa chỉ của chúng có thể được tìm thấy trong cây thiết bị.
Một phát hiện thú vị khác là (các) tác giả của lỗ hổng đã biết cách khai thác vùng UTT độc quyền của Apple để khởi động lại CPU và phần mã này không có trong mã nguồn XNU. Thật hợp lý khi suy đoán rằng hoạt động này có thể đạt được thông qua các thí nghiệm.
Tuy nhiên, việc thao túng các thanh ghi của kẻ tấn công trong khu vực chưa xác định thứ hai không thể bị phát hiện thông qua các thử nghiệm. Các nhà nghiên cứu không chắc chắn có những khối thanh ghi gỡ lỗi MMIO nào ở đó và nếu những thanh ghi này không được phần sụn sử dụng thì việc kẻ tấn công phát hiện ra công dụng của chúng cũng là một điều bí ẩn.
Bây giờ, hãy tập trung vào các sổ đăng ký chưa xác định khác được khai thác.
định nghĩa dma_ctrl_1():
ctrl=0x206140108
giá trị = read_qword(ctrl) write_qword(ctrl, value | 0x8000000000000001) ngủ(1)
trong khi ((~read_qword(ctrl) & 0x80000000000000001) != 0): ngủ(1)
def dma_ctrl_2(cờ):
ctrl=0x206140008
giá trị = read_qword(ctrl)
if (cờ): if ((value & 0x1000000000000000) == 0): value = value | 0x1000000000000000 write_qword(ctrl, value) else: if ((value & 0x10000000000000000) != 0): value = value & ~0x1000000000000 000 viết_qword (ctrl, giá trị)
def DMA_ctrl_3(giá trị):
ctrl=0x206140108
giá trị = giá trị | 0x8000000000000000
write_qword(ctrl, read_qword(ctrl) & giá trị)
while ((read_qword(ctrl) & 0x80000000000000001) != 0): ngủ(1)
def dma_init(origin_value_0x206140108):
dma_ctrl_1() dma_ctrl_2(Sai) dma_ctrl_3(origin_value_0x206140108)
def dma_done(origin_value_0x206140108):
dma_ctrl_1() dma_ctrl_2(Đúng) dma_ctrl_3(origin_value_0x206140108)
nếu (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) i = 8 mặt nạ = 0x7FFFFFF
elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) i = 8 mặt nạ = 0x3FFFFF
elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) i = 0x28 mặt nạ = 0x3FFFFF
elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) i = 0x28 mặt nạ = 0x3FFFFF
elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) i = 0x28 mặt nạ = 0x3FFFFF
dma_init(gốc_value_0x206140108)
hash1 = tính_hash(dữ liệu)hash2 = tính_hash(dữ liệu+0x20)
write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0))
pos = 0while (pos<0x40): write_qword(0x206150048, read_qword(data + pos)) pos += 8
Phys_addr_upper = ((((phys_addr>>14) & mặt nạ)<<18) & 0x3FFFFFFFFFFFF)value = Phys_addr_upper | (hash1<
dma_done(origin_value_0x206140108)
Miễn là thao tác chính xác, phần cứng sẽ thực hiện thao tác truy cập bộ nhớ trực tiếp (DMA) và ghi dữ liệu vào địa chỉ bộ nhớ được chỉ định.
Bằng cách sử dụng tính năng phần cứng này, kẻ tấn công có thể bỏ qua Lớp bảo vệ trang (PPL), chủ yếu để sửa đổi các mục trong bảng trang. Ngoài ra, nó có thể sửa đổi dữ liệu trong phân đoạn __PPLDATA được bảo vệ. Mặc dù lỗ hổng này không được sử dụng để sửa đổi mã hạt nhân, nhưng trong một thử nghiệm do các nhà nghiên cứu thực hiện, họ đã sửa đổi thành công một lệnh trong phần __TEXT_EXEC của hạt nhân và kích hoạt "lệnh hạt nhân không xác định" hiển thị địa chỉ và giá trị dự kiến.
Điều này chỉ xảy ra một lần, những lần thử khác đều dẫn đến lỗi AMCC. Về nỗ lực thành công đó, nhà nghiên cứu có một số ý tưởng, trong tương lai, nhà nghiên cứu dự định nghiên cứu sâu hơn, vì ông tin rằng sẽ rất hữu ích khi biến lỗ hổng ban đầu được sử dụng để tấn công thành mục đích sử dụng tích cực, chẳng hạn như kích hoạt kernel. gỡ lỗi trên iPhone mới.
Sau khi thảo luận tất cả các công việc liên quan đến thanh ghi MMIO (I/O được ánh xạ bộ nhớ), bây giờ chúng ta hãy tập trung vào chủ đề cuối cùng: phương pháp tính toán các giá trị băm. Thuật toán cụ thể như sau.
sbox = [ 0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016, 0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045 , 0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117, 0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D, 0x06B, 0x 0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105, 0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C, 0x052, 0x07 6, 0x0 8A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3, 0x12D , 0x205 , 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206, 0x209, 0x07C, 0 x0BA, 0x0 D6, 0x155, 0x193, 0x253, 0x28B, 0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058, 0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 0x196, 0x199, 0x256, 0x165, 0x2 59, 0x263, 0x30D, 0x313, 0x098, 0x064 , 0x114, 0x0A2 , 0x15C, 0x0EA, 0x20C, 0x0C1, 0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315, 0x0EC, 0x1A6, 0x29A, 0x2 66, 0x1A9, 0x26 9, 0x319, 0x2C3, 0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141, 0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8, 0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070, 0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144, 0x1B8, 0x224, 0x1D4, 0x182, 0x24 2, 0x2D2, 0x32C, 0x2 81, 0x351, 0x389, 0x1D8, 0x2D4 , 0x352, 0x38A, 0x391 , 0x0D0, 0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0 x2E4, 0x358, 0x394, 0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302 , 0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250, 0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x3 70, 0x3A8, 0x3C4, 0x160, 0x290, 0x308, 0x3B0, 0x3C8 , 0x3D0, 0x1A0, 0x260, 0x310 , 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380]
def tính toán_hash (bộ đệm):
acc = 0 cho i trong phạm vi(8): pos = i * 4 value = read_dword(buffer + pos) cho j trong phạm vi(32): if (((value>>j) & 1) != 0): acc ^= sbox[32 * i + j]
trả lại acc
Bạn có thể nhận thấy rằng hàm băm này không đặc biệt an toàn vì nó chỉ có 20 bit (10 bit được tính hai lần), nhưng miễn là không ai biết cách tính toán và áp dụng nó thì cũng đủ tốt. Cách tiếp cận này được mô tả tốt nhất là "bảo mật bằng cách tối nghĩa".
Nếu kẻ tấn công không sử dụng tính năng phần cứng này và không có hướng dẫn nào trong phần sụn về cách sử dụng nó thì làm sao chúng có thể phát hiện và khai thác nó?
Các nhà nghiên cứu đã làm một thử nghiệm khác. Ông phát hiện ra rằng chip M1 được tích hợp trong máy Mac cũng có tính năng phần cứng chưa được biết đến này. Sau đó, anh tiến hành thử nghiệm bằng công cụ m1n1 mạnh mẽ.
Công cụ này có chức năng trace_range có thể theo dõi tất cả các truy cập vào một phạm vi thanh ghi MMIO được chỉ định, được sử dụng để giám sát hoạt động trong phạm vi bộ nhớ từ 0x206110000 đến 0x206400000, nhưng kết quả cho thấy những thanh ghi này không được macOS sử dụng.
Bộ đồng xử lý GPU liên quan lần này mới chỉ xuất hiện lần đầu tiên trong SoC của Apple. Các nhà nghiên cứu nghi ngờ tính năng phần cứng này có bất kỳ mục đích nào trong phần mềm bán lẻ trước đó.
Tuy nhiên, người ta không thể loại trừ khả năng nó có thể đã vô tình bị rò rỉ trong một bản cập nhật chương trình cơ sở cụ thể hoặc bản phát hành mã nguồn XNU và sau đó bị xóa.
Các nhà nghiên cứu ban đầu hy vọng khám phá những gì ẩn giấu trong khu vực chưa xác định thứ hai thông qua bản sửa lỗi lỗ hổng này trong iOS 16.6. Cuối cùng, chúng tôi đã tìm ra cách Apple khắc phục sự cố nhưng họ đã cố tình tạo ra cách khắc phục khó hiểu.
Apple đã ngăn chặn việc khai thác lỗ hổng này bằng cách thêm các phạm vi MMIO 0x206000000–0x206050000 và 0x206110000–0x206400000 vào phạm vi pmap-io của cây thiết bị.
XNU sử dụng thông tin ở đây để xác định xem có cho phép ánh xạ các địa chỉ vật lý nhất định hay không. Tất cả các mục nhập được ghi lại đều được dán nhãn tên nêu rõ mục đích của các phạm vi bộ nhớ này.
Ví dụ về các mục được lưu trữ trong phạm vi pmap-io
Ở đây, PCIe đề cập đến "Peripheral Component Interconnect Express", DART là "Bảng phân giải địa chỉ thiết bị" và DAPF là viết tắt của "Bộ lọc địa chỉ thiết bị"…
Dưới đây là tên thẻ của các vùng bộ nhớ bị khai thác. Những thẻ này nổi bật trong danh sách.
Mục nhập vùng khai thác
“Bảo mật bằng cách tối nghĩa” không an toàn
Như bạn có thể thấy, lỗ hổng này rất bất thường. Chúng tôi không biết kẻ tấn công đã học cách khai thác tính năng phần cứng không xác định này như thế nào cũng như mục đích sử dụng ban đầu của nó.
Thậm chí còn không chắc liệu nó được phát triển bởi Apple hay là do thành phần bên thứ ba như ARM CoreSight gây ra.
Nhưng lỗ hổng này minh họa một thực tế rằng miễn là có những tính năng phần cứng có thể vượt qua biện pháp bảo vệ an ninh thì cho dù các biện pháp bảo mật phần cứng có tiên tiến đến đâu thì chúng cũng sẽ trở nên vô dụng trước những kẻ tấn công thông thái.
Bảo mật phần cứng thường dựa vào "bảo mật thông qua sự tối nghĩa". So với phần mềm, phần cứng khó thiết kế và phân tích đảo ngược hơn.
Nhưng cách làm này vốn dĩ còn thiếu sót vì mọi bí mật cuối cùng rồi cũng sẽ bị lộ. Các hệ thống dựa vào "bảo mật tối nghĩa" để bảo trì không bao giờ có thể thực sự an toàn.
Nguồn: Arstechnica
Thông qua cửa sau cấp phần cứng này, bạn có thể trực tiếp có được quyền Root cấp cao nhất trên iPhone. Để khai thác thành công cửa hậu này, người ta phải có hiểu biết rất toàn diện và chi tiết về cơ chế cơ bản của các sản phẩm Apple.
Đến mức nhà nghiên cứu của Kaspersky, người phát hiện ra lỗ hổng này đã nói: "Không thể tưởng tượng được lỗ hổng này lại vô tình được phát hiện như thế nào". Theo quan điểm của ông, gần như không ai khác ngoài Apple và ARM biết về lỗ hổng này.
Phần mềm gián điệp có thể sử dụng lỗ hổng phức tạp này để truyền bản ghi micrô, ảnh, vị trí địa lý và dữ liệu nhạy cảm khác đến máy chủ do kẻ tấn công kiểm soát.
Mặc dù việc khởi động lại sẽ đóng lỗ hổng nhưng kẻ tấn công có thể mở lại nó chỉ bằng cách gửi một iMessage độc hại mới tới thiết bị sau khi thiết bị khởi động lại.
Không cần thao tác của người dùng trong thời gian này và sẽ không để lại manh mối nào, khiến nó rất ẩn.
Về vấn đề này, Karpathy cho rằng đây không còn là phạm vi hành vi của cá nhân nữa mà phải là hành vi cấp quốc gia.
Một cư dân mạng cho rằng anh vẫn sử dụng điện thoại Palm đã trả lời: "Đây là lý do tại sao tôi nhất quyết sử dụng điện thoại Palm".
Một số cư dân mạng thậm chí còn than thở: "Nếu bạn thành công trong việc chọc tức mọi người bằng loại khả năng kỹ thuật và tài nguyên này, có lẽ điều cuối cùng bạn cần lo lắng là dữ liệu trên điện thoại của mình".
Hiện tại, Apple đã vá lỗ hổng bảo mật cốt lõi này vào ngày 25 tháng 10 năm 2023.
Chuỗi tấn công "Tam giác hoạt động"
Các nhà nghiên cứu phát hiện ra lỗ hổng này gọi nó là Operation Triangulation.- Kẻ tấn công gửi tệp đính kèm độc hại qua iMessage và ứng dụng sẽ mở ra lỗ hổng mà người dùng không hề hay biết.
- Tệp đính kèm này khai thác lỗ hổng thực thi mã từ xa (CVE-2023-41990) trong chỉ thị phông chữ ADJUST TrueType không được tiết lộ mà chỉ Apple mới biết. Chỉ thị này đã có từ đầu những năm 1990 và đã bị xóa trong một bản cập nhật gần đây.
- Trong cuộc tấn công, nó đã sử dụng một kỹ thuật lập trình nâng cao gọi là "lập trình hướng quay lại/nhảy" và sử dụng nhiều giai đoạn mã được viết bằng ngôn ngữ truy vấn NSExpression/NSPredicate để sửa đổi môi trường thư viện JavaScriptCore để thực thi khai thác leo thang đặc quyền được viết bằng JavaScript.
- Việc khai thác JavaScript này đã được xử lý đặc biệt để làm cho nó gần như không thể đọc được, đồng thời giảm thiểu kích thước của nó. Tuy nhiên, nó vẫn chứa khoảng 11.000 dòng mã. Các mã này chủ yếu được sử dụng để phân tích và thao tác JavaScriptCore và bộ nhớ kernel.
- Nó còn lợi dụng DollarVM ($vm), một chức năng gỡ lỗi của JavaScriptCore, thông qua chức năng này, kẻ tấn công có thể thao túng bộ nhớ của JavaScriptCore trong tập lệnh và gọi các hàm API gốc của hệ thống.
- Công cụ tấn công này được thiết kế để tương thích với cả mẫu iPhone cũ và mới, đồng thời đối với các thiết bị mới hơn, nó bao gồm kỹ thuật vượt qua Mã xác thực con trỏ (PAC), cho phép cuộc tấn công có hiệu quả đối với các thiết bị mới nhất.
- Nó đạt được quyền kiểm soát đọc và ghi ở cấp độ người dùng đối với tất cả bộ nhớ vật lý của thiết bị bằng cách khai thác lỗ hổng tràn số nguyên (CVE-2023-32434) trong các lệnh gọi hệ thống ánh xạ bộ nhớ XNU (mach_make_memory_entry và vm_map).
- Công cụ này cũng sử dụng các thanh ghi I/O (MMIO) được ánh xạ bộ nhớ phần cứng để phá vỡ Lớp bảo vệ trang (PPL), một sự cố đã được giảm thiểu trong CVE-2023-38606.
- Sau khi khai thác hết lỗ hổng, lỗ hổng JavaScript có thể được sử dụng để điều khiển thiết bị theo ý muốn, bao gồm cả việc triển khai phần mềm gián điệp. Tuy nhiên, kẻ tấn công đã chọn: (a) khởi động quy trình IMAgent và tiêm mã để xóa dấu vết khai thác; (b) chạy quy trình Safari ở chế độ ẩn danh và hướng dẫn đến trang web chứa giai đoạn nội dung tiếp theo.
- Có một tập lệnh được nhúng trong trang web này có thể xác nhận danh tính của nạn nhân. Sau khi quá trình xác minh được thông qua, giai đoạn tiếp theo của mã tấn công sẽ được tải: lỗ hổng Safari.
- Lỗ hổng Safari cho phép thực thi shellcode thông qua CVE-2023-32435.
- Shellcode này tiếp tục thực thi một lỗ hổng cấp kernel khác, đồng thời khai thác CVE-2023-32434 và CVE-2023-38606. Nó có kích thước và chức năng rất lớn nhưng rất khác với các cách khai thác kernel được viết bằng JavaScript. Tất cả những gì họ chia sẻ là một phần mã liên quan đến các cách khai thác trên. Tuy nhiên, phần lớn mã của nó cũng tập trung vào việc phân tích cú pháp và thao tác bộ nhớ kernel.
- Lỗ hổng cuối cùng đã giành được quyền root và tiếp tục qua các giai đoạn khác, cho phép tải phần mềm gián điệp.
Lỗ hổng bí ẩn
Trọng tâm của cuộc thảo luận là một lỗ hổng bảo mật đã được sửa, được đánh số CVE-2023-38606.Thế hệ iPhone mới đã bổ sung thêm các biện pháp bảo mật ở cấp độ phần cứng, được thiết kế đặc biệt để bảo vệ các vùng nhạy cảm trong bộ nhớ kernel.
Ngay cả khi kẻ tấn công có thể đọc và ghi bộ nhớ kernel, chẳng hạn như trong cuộc tấn công khai thác lỗ hổng CVE-2023-32434 này, biện pháp bảo vệ này sẽ ngăn chúng chiếm toàn bộ quyền kiểm soát thiết bị.
Các nhà nghiên cứu phát hiện ra rằng để vượt qua biện pháp bảo vệ phần cứng này, những kẻ tấn công đã lợi dụng một tính năng phần cứng khác trong SoC do Apple thiết kế.
Nói một cách đơn giản, phương pháp của kẻ tấn công như sau: trong khi vượt qua sự bảo vệ phần cứng, chúng ghi dữ liệu, địa chỉ đích và giá trị băm của dữ liệu vào một số thanh ghi phần cứng không xác định trong chip mà phần sụn không sử dụng. dữ liệu đến một địa chỉ vật lý cụ thể.
Các nhà nghiên cứu suy đoán rằng tính năng phần cứng không xác định này có thể được thiết kế để gỡ lỗi hoặc thử nghiệm bởi các kỹ sư hoặc nhà máy của Apple hoặc được đưa vào một cách vô tình. Vì phần sụn không sử dụng tính năng này nên các nhà nghiên cứu không biết làm thế nào kẻ tấn công biết và khai thác tính năng này.
Chi tiết kỹ thuật
Trong Hệ thống trên Chip (SoC), nhiều thiết bị ngoại vi khác nhau có thể cung cấp các thanh ghi phần cứng đặc biệt để bộ xử lý trung tâm (CPU) sử dụng nhằm điều khiển các thiết bị ngoại vi này.Để đạt được điều này, các thanh ghi phần cứng này được ánh xạ vào bộ nhớ mà CPU có thể truy cập, một phương pháp được gọi là I/O được ánh xạ bộ nhớ (MMIO).
Trong các sản phẩm của Apple, chẳng hạn như iPhone, Mac và các thiết bị khác, dải địa chỉ MMIO của thiết bị ngoại vi được lưu trữ ở định dạng tệp đặc biệt gọi là "DeviceTree".
Các tệp cây thiết bị này có thể được trích xuất từ chương trình cơ sở và có thể xem nội dung của chúng bằng công cụ dt (DeviceTree).
Ví dụ: trong ảnh chụp màn hình này, bạn có thể thấy địa chỉ bắt đầu (0x210f00000) và kích thước (0x50000) của phạm vi MMIO acc-impl của cpu0.
Khi đào sâu vào các lỗ hổng được sử dụng trong cuộc tấn công Operation Triangulation, các nhà nghiên cứu bất ngờ phát hiện ra rằng hầu hết các địa chỉ MMIO được kẻ tấn công sử dụng để vượt qua bảo vệ bộ nhớ kernel cấp phần cứng đều không được xác định trong cây thiết bị.
Lỗ hổng này đặc biệt nhắm vào các SoC của Apple từ A12 đến A16, tấn công khối đăng ký MMIO bí ẩn nằm ở 0x206040000, 0x206140000 và 0x206150000.
Điều này khơi dậy sự tò mò của các nhà nghiên cứu và khiến họ tiến hành một loạt nỗ lực. Tôi đã tìm kiếm trong tệp cây thiết bị và tệp chương trình cơ sở của nhiều thiết bị khác nhau nhưng không tìm thấy bất kỳ manh mối nào.
Điều này khiến các nhà nghiên cứu bối rối, tại sao những địa chỉ MMIO này được kẻ tấn công sử dụng lại không được sử dụng trong firmware? Làm thế nào kẻ tấn công phát hiện ra những địa chỉ này? Những địa chỉ MMIO này thuộc về thiết bị ngoại vi nào?
Sau đó, các nhà nghiên cứu quyết định xem liệu có địa chỉ MMIO nào khác được biết đến gần các khối MMIO chưa biết này hay không. Lần này hắn cuối cùng cũng tìm được một ít tin tức có giá trị.
Trong thông tin mục cây thiết bị của gfx-asc thì đây là bộ đồng xử lý của GPU.
Để mô tả chính xác hơn, lỗ hổng này sử dụng các địa chỉ không xác định sau: 0x206040000, 0x206140008, 0x206140108, 0x206150020, 0x206150040 và 0x206150048.
Các nhà nghiên cứu nhận thấy rằng hầu hết các địa chỉ này nằm ở giữa hai vùng bộ nhớ gfx-asc, trong khi địa chỉ còn lại gần với điểm bắt đầu của vùng gfx-asc đầu tiên.
Điều này ngụ ý rằng tất cả các thanh ghi Đầu ra đầu vào được ánh xạ bộ nhớ (MMIO) này rất có thể là bộ đồng xử lý thuộc Bộ xử lý đồ họa (GPU)!
Sau đó, các nhà nghiên cứu đã tiến hành phân tích sâu hơn về lỗ hổng và phát hiện thêm bằng chứng.
Trong quá trình khởi tạo, trước tiên, lỗ hổng bảo mật sẽ ghi vào một số thanh ghi đầu vào và đầu ra (MMIO) được ánh xạ bộ nhớ đặt tại các địa chỉ cụ thể trong mỗi SoC.
nếu (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) base = 0x23B700408 lệnh = 0x1F0023FF
elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) base = 0x23B7003C8 lệnh = 0x1F0023FF
elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) base = 0x23B7003D0 lệnh = 0x1F0023FF
elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) base = 0x23B080390 lệnh = 0x1F0003FF
elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) base = 0x23B080388 lệnh = 0x1F0003FF
if ((~read_dword(base) & 0xF) != 0): write_dword(base, command) while(True): if ((~read_dword(base) & 0xF) == 0): break
Mã giả của mã kiểm soát trình quản lý nguồn GFX trong lỗ hổng
Với sự trợ giúp của cây thiết bị và công cụ pmgr do Siguza phát triển, các nhà nghiên cứu nhận thấy rằng tất cả các địa chỉ này đều tương ứng với phạm vi MMIO (Đầu vào/Đầu ra được ánh xạ bộ nhớ) nơi đặt thanh ghi GFX trong trình quản lý nguồn.Cuối cùng, xác nhận thứ ba được đưa ra khi các nhà nghiên cứu cố gắng truy cập vào sổ đăng ký ở những vùng chưa xác định này.
Bộ đồng xử lý GPU đã báo lỗi gần như ngay lập tức, hiển thị thông báo: "GFX SERROR Exception class=0x2f (ngắt SError), IL=1, iss=0 – power(1)".
Bằng cách này, các nhà nghiên cứu xác nhận rằng tất cả các thanh ghi MMIO không xác định này, được sử dụng để khai thác, thực sự thuộc về bộ đồng xử lý của GPU.
Điều này đã thôi thúc nhà nghiên cứu tìm hiểu sâu hơn về phần sụn, phần sụn này cũng được viết bằng kiến trúc ARM và không được mã hóa, nhưng anh ta không tìm thấy bất kỳ thông tin nào liên quan đến các thanh ghi này trong phần sụn.
Anh quyết định xem xét kỹ hơn cách lỗ hổng này thao túng các thanh ghi MMIO không xác định này. Trong tất cả các thanh ghi, 0x206040000 đặc biệt đáng chú ý vì nó nằm trong một khối MMIO riêng biệt với tất cả các thanh ghi khác.
Nó chỉ bị thao túng trong giai đoạn khởi tạo và kết thúc của lỗ hổng: trong quá trình khởi tạo, đây là thanh ghi đầu tiên được thiết lập và trong giai đoạn kết thúc, nó là thanh ghi cuối cùng.
Dựa trên kinh nghiệm của nhà nghiên cứu, rõ ràng là thanh ghi này được sử dụng để bật/tắt chức năng phần cứng bị khai thác hoặc để kiểm soát ngắt.
Nhà nghiên cứu bắt đầu lần theo manh mối về sự gián đoạn và không lâu sau, anh ta không chỉ xác định được thanh ghi không xác định 0x206040000 mà còn phát hiện ra chính xác dải địa chỉ 0x206000000–0x206050000 được ánh xạ tới. Dưới đây là kết quả của kỹ thuật đảo ngược mã dễ bị tấn công mà các nhà nghiên cứu có thể xác định được.
def ml_dbgwrap_halt_cpu():
giá trị = read_qword(0x206040000)
if ((giá trị & 0x90000000) != 0): trả về
write_qword(0x206040000, giá trị | 0x80000000)
while (Đúng): if ((read_qword(0x206040000) & 0x10000000) != 0): ngắt
def ml_dbgwrap_unhalt_cpu():
giá trị = read_qword(0x206040000)
giá trị = (giá trị & 0xFFFFFFFF2FFFFFFF) | 0x40000000 write_qword(0x206040000, giá trị)
while (Đúng): if ((read_qword(0x206040000) & 0x10000000) == 0): ngắt
Đã khớp thành công hàm ml_dbgwrap_halt_cpu trong mã giả trước đó với hàm cùng tên trong tệp dbgwrap.c của mã nguồn XNU. Tệp này chứa mã để kiểm soát các thanh ghi gỡ lỗi ARM CoreSight MMIO của CPU chính.
Mã nguồn cho thấy có 4 lĩnh vực MMIO liên quan đến CoreSight là ED, CTI, PMU và UTT. Mỗi vùng chiếm 0x10000 byte và ngay lập tức liền kề với nhau.
Hàm ml_dbgwrap_halt_cpu tận dụng vùng UTT. Không giống như ba lĩnh vực còn lại, UTT không đến từ ARM mà là một tính năng độc quyền được Apple bổ sung đặc biệt để thuận tiện.
Mỗi lõi của CPU chính có khối thanh ghi gỡ lỗi CoreSight MMIO riêng, nhưng không giống như bộ đồng xử lý GPU, địa chỉ của chúng có thể được tìm thấy trong cây thiết bị.
Một phát hiện thú vị khác là (các) tác giả của lỗ hổng đã biết cách khai thác vùng UTT độc quyền của Apple để khởi động lại CPU và phần mã này không có trong mã nguồn XNU. Thật hợp lý khi suy đoán rằng hoạt động này có thể đạt được thông qua các thí nghiệm.
Tuy nhiên, việc thao túng các thanh ghi của kẻ tấn công trong khu vực chưa xác định thứ hai không thể bị phát hiện thông qua các thử nghiệm. Các nhà nghiên cứu không chắc chắn có những khối thanh ghi gỡ lỗi MMIO nào ở đó và nếu những thanh ghi này không được phần sụn sử dụng thì việc kẻ tấn công phát hiện ra công dụng của chúng cũng là một điều bí ẩn.
Bây giờ, hãy tập trung vào các sổ đăng ký chưa xác định khác được khai thác.
định nghĩa dma_ctrl_1():
ctrl=0x206140108
giá trị = read_qword(ctrl) write_qword(ctrl, value | 0x8000000000000001) ngủ(1)
trong khi ((~read_qword(ctrl) & 0x80000000000000001) != 0): ngủ(1)
def dma_ctrl_2(cờ):
ctrl=0x206140008
giá trị = read_qword(ctrl)
if (cờ): if ((value & 0x1000000000000000) == 0): value = value | 0x1000000000000000 write_qword(ctrl, value) else: if ((value & 0x10000000000000000) != 0): value = value & ~0x1000000000000 000 viết_qword (ctrl, giá trị)
def DMA_ctrl_3(giá trị):
ctrl=0x206140108
giá trị = giá trị | 0x8000000000000000
write_qword(ctrl, read_qword(ctrl) & giá trị)
while ((read_qword(ctrl) & 0x80000000000000001) != 0): ngủ(1)
def dma_init(origin_value_0x206140108):
dma_ctrl_1() dma_ctrl_2(Sai) dma_ctrl_3(origin_value_0x206140108)
def dma_done(origin_value_0x206140108):
dma_ctrl_1() dma_ctrl_2(Đúng) dma_ctrl_3(origin_value_0x206140108)
nếu (cpuid == 0x8765EDEA): # CPUFAMILY_ARM_EVEREST_SAWTOOTH (A16) i = 8 mặt nạ = 0x7FFFFFF
elif (cpuid == 0xDA33D83D): # CPUFAMILY_ARM_AVALANCHE_BLIZZARD (A15) i = 8 mặt nạ = 0x3FFFFF
elif (cpuid == 0x1B588BB3): # CPUFAMILY_ARM_FIRESTORM_ICESTORM (A14) i = 0x28 mặt nạ = 0x3FFFFF
elif (cpuid == 0x462504D2): # CPUFAMILY_ARM_LIGHTNING_THUNDER (A13) i = 0x28 mặt nạ = 0x3FFFFF
elif (cpuid == 0x07D34B9F): # CPUFAMILY_ARM_VORTEX_TEMPEST (A12) i = 0x28 mặt nạ = 0x3FFFFF
dma_init(gốc_value_0x206140108)
hash1 = tính_hash(dữ liệu)hash2 = tính_hash(dữ liệu+0x20)
write_qword(0x206150040, 0x2000000 | (phys_addr & 0x3FC0))
pos = 0while (pos<0x40): write_qword(0x206150048, read_qword(data + pos)) pos += 8
Phys_addr_upper = ((((phys_addr>>14) & mặt nạ)<<18) & 0x3FFFFFFFFFFFF)value = Phys_addr_upper | (hash1<
dma_done(origin_value_0x206140108)
Miễn là thao tác chính xác, phần cứng sẽ thực hiện thao tác truy cập bộ nhớ trực tiếp (DMA) và ghi dữ liệu vào địa chỉ bộ nhớ được chỉ định.
Bằng cách sử dụng tính năng phần cứng này, kẻ tấn công có thể bỏ qua Lớp bảo vệ trang (PPL), chủ yếu để sửa đổi các mục trong bảng trang. Ngoài ra, nó có thể sửa đổi dữ liệu trong phân đoạn __PPLDATA được bảo vệ. Mặc dù lỗ hổng này không được sử dụng để sửa đổi mã hạt nhân, nhưng trong một thử nghiệm do các nhà nghiên cứu thực hiện, họ đã sửa đổi thành công một lệnh trong phần __TEXT_EXEC của hạt nhân và kích hoạt "lệnh hạt nhân không xác định" hiển thị địa chỉ và giá trị dự kiến.
Điều này chỉ xảy ra một lần, những lần thử khác đều dẫn đến lỗi AMCC. Về nỗ lực thành công đó, nhà nghiên cứu có một số ý tưởng, trong tương lai, nhà nghiên cứu dự định nghiên cứu sâu hơn, vì ông tin rằng sẽ rất hữu ích khi biến lỗ hổng ban đầu được sử dụng để tấn công thành mục đích sử dụng tích cực, chẳng hạn như kích hoạt kernel. gỡ lỗi trên iPhone mới.
Sau khi thảo luận tất cả các công việc liên quan đến thanh ghi MMIO (I/O được ánh xạ bộ nhớ), bây giờ chúng ta hãy tập trung vào chủ đề cuối cùng: phương pháp tính toán các giá trị băm. Thuật toán cụ thể như sau.
sbox = [ 0x007, 0x00B, 0x00D, 0x013, 0x00E, 0x015, 0x01F, 0x016, 0x019, 0x023, 0x02F, 0x037, 0x04F, 0x01A, 0x025, 0x043, 0x03B, 0x057, 0x08F, 0x01C, 0x026, 0x029, 0x03D, 0x045 , 0x05B, 0x083, 0x097, 0x03E, 0x05D, 0x09B, 0x067, 0x117, 0x02A, 0x031, 0x046, 0x049, 0x085, 0x103, 0x05E, 0x09D, 0x06B, 0x 0A7, 0x11B, 0x217, 0x09E, 0x06D, 0x0AB, 0x0C7, 0x127, 0x02C, 0x032, 0x04A, 0x051, 0x086, 0x089, 0x105, 0x203, 0x06E, 0x0AD, 0x12B, 0x147, 0x227, 0x034, 0x04C, 0x052, 0x07 6, 0x0 8A, 0x091, 0x0AE, 0x106, 0x109, 0x0D3, 0x12D , 0x205 , 0x22B, 0x247, 0x07A, 0x0D5, 0x153, 0x22D, 0x038, 0x054, 0x08C, 0x092, 0x061, 0x10A, 0x111, 0x206, 0x209, 0x07C, 0 x0BA, 0x0 D6, 0x155, 0x193, 0x253, 0x28B, 0x307, 0x0BC, 0x0DA, 0x156, 0x255, 0x293, 0x30B, 0x058, 0x094, 0x062, 0x10C, 0x112, 0x0A1, 0x20A, 0x211, 0x0DC, 0x196, 0x199, 0x256, 0x165, 0x2 59, 0x263, 0x30D, 0x313, 0x098, 0x064 , 0x114, 0x0A2 , 0x15C, 0x0EA, 0x20C, 0x0C1, 0x121, 0x212, 0x166, 0x19A, 0x299, 0x265, 0x2A3, 0x315, 0x0EC, 0x1A6, 0x29A, 0x2 66, 0x1A9, 0x26 9, 0x319, 0x2C3, 0x323, 0x068, 0x0A4, 0x118, 0x0C2, 0x122, 0x214, 0x141, 0x221, 0x0F4, 0x16C, 0x1AA, 0x2A9, 0x325, 0x343, 0x0F8, 0x174, 0x1AC, 0x2AA, 0x326, 0x329, 0x345, 0x383, 0x070, 0x0A8, 0x0C4, 0x124, 0x218, 0x142, 0x222, 0x181, 0x241, 0x178, 0x2AC, 0x32A, 0x2D1, 0x0B0, 0x0C8, 0x128, 0x144, 0x1B8, 0x224, 0x1D4, 0x182, 0x24 2, 0x2D2, 0x32C, 0x2 81, 0x351, 0x389, 0x1D8, 0x2D4 , 0x352, 0x38A, 0x391 , 0x0D0, 0x130, 0x148, 0x228, 0x184, 0x244, 0x282, 0x301, 0x1E4, 0x2D8, 0x354, 0x38C, 0x392, 0x1E8, 0 x2E4, 0x358, 0x394, 0x362, 0x3A1, 0x150, 0x230, 0x188, 0x248, 0x284, 0x302 , 0x1F0, 0x2E8, 0x364, 0x398, 0x3A2, 0x0E0, 0x190, 0x250, 0x2F0, 0x288, 0x368, 0x304, 0x3A4, 0x3 70, 0x3A8, 0x3C4, 0x160, 0x290, 0x308, 0x3B0, 0x3C8 , 0x3D0, 0x1A0, 0x260, 0x310 , 0x1C0, 0x2A0, 0x3E0, 0x2C0, 0x320, 0x340, 0x380]
def tính toán_hash (bộ đệm):
acc = 0 cho i trong phạm vi(8): pos = i * 4 value = read_dword(buffer + pos) cho j trong phạm vi(32): if (((value>>j) & 1) != 0): acc ^= sbox[32 * i + j]
trả lại acc
Mã giả cho hàm băm được sử dụng bởi hàm phần cứng không xác định này
Như bạn có thể thấy, đây là thuật toán tùy chỉnh có phép tính hàm băm dựa trên bảng sbox được xác định trước. Anh đã cố gắng tìm kiếm nó trong thư viện nhị phân rộng lớn nhưng không tìm thấy gì.Bạn có thể nhận thấy rằng hàm băm này không đặc biệt an toàn vì nó chỉ có 20 bit (10 bit được tính hai lần), nhưng miễn là không ai biết cách tính toán và áp dụng nó thì cũng đủ tốt. Cách tiếp cận này được mô tả tốt nhất là "bảo mật bằng cách tối nghĩa".
Nếu kẻ tấn công không sử dụng tính năng phần cứng này và không có hướng dẫn nào trong phần sụn về cách sử dụng nó thì làm sao chúng có thể phát hiện và khai thác nó?
Các nhà nghiên cứu đã làm một thử nghiệm khác. Ông phát hiện ra rằng chip M1 được tích hợp trong máy Mac cũng có tính năng phần cứng chưa được biết đến này. Sau đó, anh tiến hành thử nghiệm bằng công cụ m1n1 mạnh mẽ.
Công cụ này có chức năng trace_range có thể theo dõi tất cả các truy cập vào một phạm vi thanh ghi MMIO được chỉ định, được sử dụng để giám sát hoạt động trong phạm vi bộ nhớ từ 0x206110000 đến 0x206400000, nhưng kết quả cho thấy những thanh ghi này không được macOS sử dụng.
Bộ đồng xử lý GPU liên quan lần này mới chỉ xuất hiện lần đầu tiên trong SoC của Apple. Các nhà nghiên cứu nghi ngờ tính năng phần cứng này có bất kỳ mục đích nào trong phần mềm bán lẻ trước đó.
Tuy nhiên, người ta không thể loại trừ khả năng nó có thể đã vô tình bị rò rỉ trong một bản cập nhật chương trình cơ sở cụ thể hoặc bản phát hành mã nguồn XNU và sau đó bị xóa.
Các nhà nghiên cứu ban đầu hy vọng khám phá những gì ẩn giấu trong khu vực chưa xác định thứ hai thông qua bản sửa lỗi lỗ hổng này trong iOS 16.6. Cuối cùng, chúng tôi đã tìm ra cách Apple khắc phục sự cố nhưng họ đã cố tình tạo ra cách khắc phục khó hiểu.
Apple đã ngăn chặn việc khai thác lỗ hổng này bằng cách thêm các phạm vi MMIO 0x206000000–0x206050000 và 0x206110000–0x206400000 vào phạm vi pmap-io của cây thiết bị.
XNU sử dụng thông tin ở đây để xác định xem có cho phép ánh xạ các địa chỉ vật lý nhất định hay không. Tất cả các mục nhập được ghi lại đều được dán nhãn tên nêu rõ mục đích của các phạm vi bộ nhớ này.
Ở đây, PCIe đề cập đến "Peripheral Component Interconnect Express", DART là "Bảng phân giải địa chỉ thiết bị" và DAPF là viết tắt của "Bộ lọc địa chỉ thiết bị"…
Dưới đây là tên thẻ của các vùng bộ nhớ bị khai thác. Những thẻ này nổi bật trong danh sách.
Mục nhập vùng khai thác
“Bảo mật bằng cách tối nghĩa” không an toàn
Như bạn có thể thấy, lỗ hổng này rất bất thường. Chúng tôi không biết kẻ tấn công đã học cách khai thác tính năng phần cứng không xác định này như thế nào cũng như mục đích sử dụng ban đầu của nó.
Thậm chí còn không chắc liệu nó được phát triển bởi Apple hay là do thành phần bên thứ ba như ARM CoreSight gây ra.
Nhưng lỗ hổng này minh họa một thực tế rằng miễn là có những tính năng phần cứng có thể vượt qua biện pháp bảo vệ an ninh thì cho dù các biện pháp bảo mật phần cứng có tiên tiến đến đâu thì chúng cũng sẽ trở nên vô dụng trước những kẻ tấn công thông thái.
Bảo mật phần cứng thường dựa vào "bảo mật thông qua sự tối nghĩa". So với phần mềm, phần cứng khó thiết kế và phân tích đảo ngược hơn.
Nhưng cách làm này vốn dĩ còn thiếu sót vì mọi bí mật cuối cùng rồi cũng sẽ bị lộ. Các hệ thống dựa vào "bảo mật tối nghĩa" để bảo trì không bao giờ có thể thực sự an toàn.
Nguồn: Arstechnica
