Phân tích lỗ hổng 0day của Microsoft: có thể gây ra mối đe dọa lớn cho cơ sở hạ tầng Web3

Tháng trước, bản vá bảo mật của Microsoft đã chứa một lỗ hổng nâng quyền win32k có thể bị khai thác. Lỗ hổng này dường như chỉ tồn tại trên các hệ thống Windows sớm hơn, không thể kích hoạt trên Windows 11.

Lợi dụng loại lỗ hổng này đã tồn tại từ lâu. Bài viết này sẽ phân tích cách mà các kẻ tấn công có thể tiếp tục khai thác lỗ hổng này trong bối cảnh các biện pháp giảm thiểu mới hiện nay đang được cải thiện liên tục. Chúng tôi đã hoàn thành toàn bộ quá trình phân tích trong môi trường Windows Server 2016.

Lỗ hổng 0day chỉ những lỗ hổng chưa được công bố và sửa chữa, có thể bị khai thác một cách độc hại mà không bị phát hiện, mang lại sự phá hoại lớn. Lỗ hổng 0day được phát hiện lần này nằm ở cấp độ hệ thống Windows, tin tặc có thể chiếm quyền điều khiển hoàn toàn Windows thông qua lỗ hổng này.

Hệ thống bị hacker kiểm soát có thể dẫn đến việc rò rỉ thông tin cá nhân, hệ thống sập, mất dữ liệu, thiệt hại tài chính, cài đặt phần mềm độc hại và nhiều hậu quả khác. Đối với người dùng Web3, khóa riêng có thể bị đánh cắp, tài sản kỹ thuật số bị chuyển nhượng. Từ một góc độ rộng hơn, lỗ hổng này thậm chí có thể ảnh hưởng đến toàn bộ hệ sinh thái Web3 hoạt động dựa trên cơ sở hạ tầng Web2.

Phân tích bản vá

Phân tích sau khi áp dụng bản vá cho thấy, vấn đề dường như chỉ là một đối tượng bị xử lý quá nhiều lần. Do mã win32k khá cũ, chúng tôi có thể tìm thấy một số chú thích mã nguồn sớm hơn, cho thấy mã trước đây chỉ khóa đối tượng cửa sổ, mà không khóa đối tượng menu trong đối tượng cửa sổ, ở đây đối tượng menu có thể bị tham chiếu sai.

Khái niệm kiểm chứng khai thác lỗ hổng ( PoC )

Chúng tôi phát hiện ra rằng, menu được truyền vào xxxEnableMenuItem() thường đã bị khóa trong hàm cấp trên. Phân tích thêm cho thấy, hàm MenuItemState trong xxxEnableMenuItem trả về hai khả năng menu: menu chính của cửa sổ, hoặc submenu trong menu( thậm chí là submenu con).

Trong PoC, chúng tôi đã xây dựng một cấu trúc menu bốn lớp đặc biệt và thiết lập các thuộc tính cụ thể cho từng cấp menu, để thông qua việc kiểm tra và xác định trong hàm xxxEnableMenuItem. Các bước chính bao gồm việc xóa một số mối quan hệ tham chiếu menu, giải phóng các đối tượng menu cụ thể khi xxxRedrawTitle trả về lớp người dùng, v.v.

Khai thác lỗ hổng (Exp) thực hiện

Tổng thể tư duy

Chúng tôi chủ yếu xem xét hai hướng khai thác: thực thi mã shellcode và khai thác các nguyên thủy đọc/ghi để chỉnh sửa địa chỉ token. Cân nhắc nhiều yếu tố, chúng tôi đã chọn phương án sau.

Toàn bộ exp có thể được phân tách thành hai vấn đề chính: làm thế nào để tận dụng lỗ hổng UAF để kiểm soát giá trị của cbwndextra, và làm thế nào để thực hiện các nguyên tử đọc/ghi ổn định sau khi đã kiểm soát giá trị cbwndextra.

thực hiện lần ghi dữ liệu đầu tiên

Chúng tôi sử dụng đối tượng tên cửa sổ trong lớp WNDClass để chiếm dụng các đối tượng menu đã giải phóng. Chìa khóa là tìm một vị trí trong cấu trúc địa chỉ mà chúng tôi có thể xây dựng, nơi có thể ghi dữ liệu tùy ý.

Cuối cùng, chúng tôi đã chọn thực hiện việc ghi thông qua thao tác AND 2 trên một cờ trong hàm xxxRedrawWindow. Chúng tôi ghi vào cb-extra của HWNDClass thay vì cb-extra của đối tượng cửa sổ, để kiểm soát tốt hơn bố cục bộ nhớ.

Bố trí bộ nhớ ổn định

Chúng tôi đã thiết kế ít nhất ba bố cục bộ nhớ cho các đối tượng HWND 0x250 byte liên tiếp, giải phóng đối tượng ở giữa, chiếm dụng bởi đối tượng HWNDClass 0x250 byte. Các đối tượng HWND trước và sau lần lượt được sử dụng để kiểm tra tham số và làm phương tiện đọc/ghi nguyên thủy.

Chúng tôi xác định chính xác xem đối tượng cửa sổ được yêu cầu có được sắp xếp như mong đợi hay không thông qua địa chỉ handle kernel bị rò rỉ trong bộ nhớ ngăn xếp.

Sửa đổi nguyên ngữ đọc và viết

Chúng tôi sử dụng GetMenuBarInfo() để thực hiện việc đọc tùy ý, sử dụng SetClassLongPtr() để thực hiện việc ghi tùy ý. Ngoài việc thay thế TOKEN trong thao tác ghi, các thao tác ghi khác đều sử dụng đối tượng class của đối tượng cửa sổ đầu tiên với việc sử dụng độ lệch để hoàn thành.

Tóm tắt

1. Lỗ hổng win32k mặc dù đã tồn tại từ lâu, nhưng Microsoft đang cố gắng sử dụng Rust để tái cấu trúc mã nhân liên quan, và trong hệ thống mới trong tương lai, các lỗ hổng như vậy có thể được ngăn chặn.

2. Quá trình khai thác lỗ hổng lần này tương đối đơn giản, khó khăn chính nằm ở việc kiểm soát lần ghi đầu tiên. Lỗ hổng vẫn phụ thuộc nghiêm trọng vào việc rò rỉ địa chỉ của handle heap trên desktop, điều này vẫn là một mối nguy hiểm an ninh đối với các hệ thống cũ.

3. Việc phát hiện lỗ hổng này có thể nhờ vào việc kiểm tra độ bao phủ mã hoàn thiện hơn.

4. Đối với việc phát hiện khai thác lỗ hổng, ngoài việc chú ý đến các điểm quan trọng của hàm kích hoạt lỗ hổng, cũng nên kiểm tra mục tiêu về bố cục bộ nhớ bất thường và các thao tác đọc/ghi dữ liệu của cửa sổ.