Phân tích lỗ hổng 0day của hệ thống Microsoft Windows: có thể gây ảnh hưởng lớn đến hệ sinh thái 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ư không thể kích hoạt trên phiên bản hệ thống Windows 11, chỉ tồn tại trên các hệ thống trước đó. Bài viết này sẽ phân tích cách mà 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 đang được cải thiện. Quá trình phân tích được thực hiện trong môi trường Windows Server 2016.

Lỗ hổng 0day là lỗ hổng chưa được công bố và sửa chữa, có thể bị kẻ tấn công lợi dụng một cách ác ý mà không bị phát hiện, thường có tính phá hoại rất lớn. Lỗ hổng 0day được phát hiện lần này tồn tại ở cấp độ hệ thống Windows, tin tặc có thể thông qua lỗ hổng này để chiếm quyền kiểm soát hoàn toàn Windows. Điều này có thể dẫn đến việc đánh cắp thông tin cá nhân, mất dữ liệu do hệ thống sập, tổn thất tài chính, cài đặt phần mềm độc hại, và những hậu quả khác. Từ góc độ Web3, khóa riêng của người dùng có thể bị đánh cắp, tài sản số có thể bị chuyển nhượng. Trên quy mô lớn 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 trên cơ sở hạ tầng Web2.

Phân tích bản vá cho thấy, vấn đề nằm ở việc số lượng tham chiếu của một đối tượng bị xử lý nhiều lần. Qua các chú thích trong mã nguồn trước đây có thể thấy, mã cũ chỉ khóa đối tượng cửa sổ, 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.

Để xác minh lỗ hổng, chúng tôi đã triển khai một bằng chứng khái niệm (PoC). Bằng cách tạo ra các menu lồng ghép nhiều lớp đặc biệt, có thể kích hoạt lỗ hổng trong hàm xxxEnableMenuItem. Chìa khóa là xóa mối quan hệ tham chiếu giữa menu C và menu B vào thời điểm thích hợp, thành công giải phóng đối tượng menu C. Như vậy, khi hàm xxxEnableMenuItem trả về, đối tượng menu C sắp được tham chiếu đã trở nên không hợp lệ.

Trong việc thực hiện khai thác lỗ hổng (Exp), chúng tôi chủ yếu xem xét hai phương án: thực thi mã shellcode và lợi dụng nguyên lý đọc/ghi để sửa đổi địa chỉ token. Cuối cùng, chúng tôi đã chọn phương án sau, vì phương pháp này vẫn có exp công khai để tham khảo trong hai năm qua. Toàn bộ quá trình khai thác được chia thành hai bước: đầu tiên lợi dụng lỗ hổng UAF để kiểm soát giá trị của cbwndextra, sau đó thiết lập nguyên lý đọc/ghi ổn định.

Bằng cách thiết kế cẩn thận bố cục bộ nhớ, chúng ta có thể đạt được kiểm soát chính xác đối tượng mục tiêu. Sử dụng hàm GetMenuBarInfo() và SetClassLongPtr() để lần lượt thực hiện phép đọc tùy ý và phép ghi tùy ý. Ngoài việc thay thế thao tác ghi TOKEN phụ thuộc vào đối tượng lớp của cửa sổ thứ hai, tất cả các ghi khác đều sử dụng đối tượng lớp của cửa sổ đầu tiên để ghi bằng cách sử dụng độ lệch.

Tổng thể mà nói, mặc dù lỗ hổng win32k đã tồn tại từ lâu, nhưng Microsoft đang cố gắng sử dụng Rust để tái cấu trúc phần mã nhân này, trong tương lai, các hệ thống mới có thể loại bỏ các lỗ hổng như vậy. Hiện tại, quy trình khai thác các lỗ hổng này cơ bản không quá khó khăn, chủ yếu dựa vào việc rò rỉ địa chỉ của các handle ngăn xếp trên desktop. Đối với các hệ thống cũ, đây vẫn là một mối nguy hiểm không an toàn.

Từ góc độ phát hiện lỗ hổng, việc kiểm tra độ phủ mã hoàn chỉnh hơn có thể giúp phát hiện các lỗ hổng như vậy. Đối với việc phát hiện lỗ hổng khai thác, bên cạnh việc chú ý đến các điểm chính của hàm kích hoạt lỗ hổng, cũng nên thực hiện kiểm tra đặc biệt đối với việc đọc và ghi lệch dữ liệu bất thường trong bố trí bộ nhớ và dữ liệu bổ sung của loại cửa sổ, điều này có thể là một trong những cách hiệu quả để phát hiện các lỗ hổng cùng loại.