Phân tích lỗ hổng nghiêm trọng của hệ thống Microsoft Windows: có thể kiểm soát hoàn toàn hệ thống và đe dọa an ninh Web3

Bản vá bảo mật được Microsoft phát hành vào tháng trước đã khắc phục một lỗ hổng tăng quyền hệ thống Windows đang bị tin tặc khai thác. Lỗ hổng này chủ yếu tồn tại trong các phiên bản Windows cũ, không thể kích hoạt trên Windows 11.

Các lỗ hổng ở tầng hệ thống Windows loại này đã tồn tại lâu dài, bài viết này sẽ phân tích cách mà hacker có thể tiếp tục khai thác lỗ hổng này trong bối cảnh bảo mật đang ngày càng được củng cố. Môi trường phân tích của chúng tôi là Windows Server 2016.

Lỗ hổng này thuộc loại lỗ hổng zero-day, tức là lỗ hổng chưa được công khai và chưa được sửa chữa. Sau khi lỗ hổng zero-day được phát hiện, nó có thể bị khai thác một cách ác ý mà người dùng không hề hay biết, có khả năng gây ra thiệt hại lớn. Thông qua lỗ hổng hệ thống Windows này, hacker có thể giành quyền kiểm soát hoàn toàn hệ thống.

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

Phân tích mã vá, vấn đề dường như là số đếm tham chiếu của một đối tượng đã bị xử lý nhiều lần. Theo chú thích mã nguồn win32k trước đó, mã ban đầu chỉ khóa đối tượng cửa sổ, không khóa đối tượng menu trong đối tượng cửa sổ, dẫn đến đối tượng menu có thể bị tham chiếu sai.

Khi thực hiện chứng minh khái niệm lỗ hổng ( PoC ), chúng tôi phát hiện ra rằng việc xử lý đối tượng menu trong hàm xxxEnableMenuItem có vấn đề. Menu trả về có thể là menu chính của cửa sổ, cũng có thể là menu con hoặc thậm chí là menu con của menu con. Chúng tôi đã xây dựng một cấu trúc menu bốn tầng đặc biệt để kích hoạt lỗ hổng.

Trước khi xây dựng (Exp), chúng tôi chủ yếu xem xét hai hướng: thực thi mã shellcode và sử dụng nguyên lý đọc ghi để sửa đổi địa chỉ token. Cân nhắc tính khả thi, chúng tôi đã chọn hướng thứ hai. Toàn bộ quá trình khai thác được chia thành hai bước: lợi dụng lỗ hổng UAF để kiểm soát giá trị cbwndextra, sau đó thiết lập nguyên lý đọc ghi ổn định.

Để thực hiện việc ghi dữ liệu lần đầ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 đối tượng menu đã giải phóng. Bằng cách xây dựng bố cục bộ nhớ một cách cẩn thận, chúng tôi có thể kiểm soát dữ liệu bộ nhớ của các đối tượng liền kề, từ đó sửa đổi giá trị cb-extra của HWNDClass.

Chúng tôi đã thiết kế bố cục bộ nhớ của ba đối tượng HWND liên tiếp, sau khi giải phóng đối tượng ở giữa thì sử dụng đối tượng HWNDClass. Đối tượng HWND trước được sử dụng để kiểm tra qua hàm, đối tượng sau dùng cho các phép đọc ghi nguyên thủy cuối cùng. Thông qua địa chỉ của tay cầm hạt nhân bị rò rỉ, chúng tôi có thể kiểm soát chính xác thứ tự sắp xếp của các đối tượng.

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

Nói chung, mặc dù phiên bản xem trước của Windows 11 đã bắt đầu tái cấu trúc mã win32k bằng Rust, nhưng những lỗ hổng như vậy vẫn là mối nguy hiểm an ninh đối với hệ thống cũ. Quá trình khai thác lỗ hổng tương đối đơn giản, chủ yếu dựa vào việc rò rỉ địa chỉ tay cầm ngăn xếp desktop. Việc phát hiện lỗ hổng có thể được hưởng lợi từ việc kiểm tra độ bao phủ mã tốt hơn. Đối với việc phát hiện lỗ hổng, ngoài việc chú ý đến các điểm quan trọng trong hàm kích hoạt, cũng cần chú ý đến cấu trúc bộ nhớ bất thường và các thao tác đọc/ghi dữ liệu.