Lỗ hổng hệ thống Windows của Microsoft có thể gây ra rủi ro an ninh cho Web3
Bản vá bảo mật mà Microsoft phát hành vào tháng trước chứa một lỗ hổng tăng quyền win32k đang bị khai thác. Lỗ hổng này dường như chỉ tồn tại trên các phiên bản hệ điều hành Windows trước đây và không thể kích hoạt trên Windows 11.
Việc khai thác các lỗ hổng như vậy đã diễn ra từ lâu. Trong bối cảnh các biện pháp bảo mật mới đang được cải thiện liên tục, chúng tôi hy vọng sẽ phân tích cách mà những kẻ tấn công có thể tiếp tục khai thác lỗ hổng này. Quá trình phân tích trong bài viết này được thực hiện trong môi trường Windows Server 2016.
Lỗ hổng zero-day này chưa được công khai và khắc phục, có thể bị khai thác mà không bị phát hiện, mang tính hủy diệt lớn. Thông qua lỗ hổng này, hacker có thể chiếm quyền kiểm soát hoàn toàn hệ thống Windows. Điều này có thể dẫn đến việc thông tin cá nhân bị đánh cắp, hệ thống sập, mất dữ liệu, tổn thất tài chính, cài đặt phần mềm độc hại và nhiều hậu quả nghiêm trọng 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ố có thể bị chuyển nhượng. Nhìn 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 trên cơ sở hạ tầng Web2.
Thông qua việc phân tích bản vá, chúng tôi phát hiện ra vấn đề nằm ở chỗ số lượng tham chiếu của đối tượng đã được xử lý nhiều lần. win32k là mã cũ, các chú thích trong mã nguồn thời kỳ đầu cho thấy, mã trước đây chỉ khóa đối tượng cửa sổ, không khóa đối tượng menu trong đối tượng cửa sổ, điều này có thể dẫn đến việc đối tượng menu bị tham chiếu sai.
Khi thực hiện xác minh khái niệm (PoC), chúng tôi phát hiện rằng menu xxxEnableMenuItem() được truyền vào thường đã bị khóa trong hàm cấp cao hơn, không rõ ở đây cần bảo vệ đối tượng menu nào. Phân tích sâu hơn cho thấy, menu có thể được trả về từ hàm MenuItemState 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.
Để kích hoạt lỗ hổng, 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 một số điều kiện cụ thể để vượt qua kiểm tra của hàm xxxEnableMenuItem. Khi hàm xxxRedrawTitle trở về từ lớp người dùng, chúng tôi đã xóa mối quan hệ tham chiếu giữa menu C và B, thành công giải phóng menu C. Cuối cùng, khi hàm xxxEnableMenuItem trở về hàm xxxRedrawTitle, đối tượng menu C sắp được tham chiếu đã không còn hợp lệ.
Trong quá trình phát triể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 shellcode và sử dụng nguyên lý đọc/ghi để sửa đổi địa chỉ token. Xét về tính khả thi, chúng tôi đã chọn phương án sau. Toàn bộ quá trình khai thác có thể chia thành hai bước: cách khai thác lỗ hổng UAF để kiểm soát giá trị của cbwndextra, và cách thực hiện nguyên lý đọc/ghi ổn định.
Chúng tôi thông qua việc thiết kế cẩn thận bố cục bộ nhớ, sử dụng đối tượng tên cửa sổ trong lớp WNDClass để chiếm giữ đối tượng menu đã được giải phóng. Thông qua các thao tác cụ thể trong hàm xxxRedrawWindow, chúng tôi đã thực hiện việc ghi dữ liệu lần đầu tiên.
Để đạt được bố cục bộ nhớ ổn định, chúng tôi đã thiết kế ba đối tượng HWND liên tiếp, giải phóng một đối tượng ở giữa và sử dụng đối tượng HWNDClass. Các đối tượng HWND phía trước và phía sau lần lượt được sử dụng để kiểm tra và thực hiện các nguyên tử đọc/ghi. Chúng tôi cũng sử dụng việc rò rỉ địa chỉ handle kernel để xác định chính xác xem sự sắp xếp của các đối tượng có phù hợp với mong đợi hay không.
Trong việc triển khai đọ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 ghi tùy ý. Ngoài thao tác thay thế TOKEN, các ghi khác đều được thực hiện thông qua đối tượng class của đối tượng cửa sổ đầu tiên thông qua độ lệch.
Mặc dù lỗ hổng win32k đã tồn tại từ lâu, nhưng Microsoft đang cố gắng tái cấu trúc mã lõi liên quan bằng Rust, trong tương lai, lỗ hổng loại này có thể bị loại trừ trong hệ thống mới. Quy trình khai thác lỗ hổng này tương đối đơn giản, điểm khó khăn chính là cách kiểm soát lần ghi đầu tiên. Lỗ hổng này phụ thuộc nghiêm trọng vào việc rò rỉ địa chỉ của tay cầm heap trên desktop, điều này vẫn là mối nguy an ninh của các hệ thống cũ.
Chúng tôi suy đoán rằng 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. Đối với việc phát hiện lỗ hổng, ngoài việc giám sát các điểm quan trọng, việc phát hiện có mục đích về bố cục bộ nhớ bất thường và việc đọc ghi dữ liệu cửa sổ cũng có thể giúp phát hiện các lỗ hổng như vậy.
Trang này có thể chứa nội dung của bên thứ ba, được cung cấp chỉ nhằm mục đích thông tin (không phải là tuyên bố/bảo đảm) và không được coi là sự chứng thực cho quan điểm của Gate hoặc là lời khuyên về tài chính hoặc chuyên môn. Xem Tuyên bố từ chối trách nhiệm để biết chi tiết.
Lỗ hổng hệ thống Windows đe dọa bảo mật tài sản Web3 Khóa riêng có thể bị đánh cắp
Lỗ hổng hệ thống Windows của Microsoft có thể gây ra rủi ro an ninh cho Web3
Bản vá bảo mật mà Microsoft phát hành vào tháng trước chứa một lỗ hổng tăng quyền win32k đang bị khai thác. Lỗ hổng này dường như chỉ tồn tại trên các phiên bản hệ điều hành Windows trước đây và không thể kích hoạt trên Windows 11.
Việc khai thác các lỗ hổng như vậy đã diễn ra từ lâu. Trong bối cảnh các biện pháp bảo mật mới đang được cải thiện liên tục, chúng tôi hy vọng sẽ phân tích cách mà những kẻ tấn công có thể tiếp tục khai thác lỗ hổng này. Quá trình phân tích trong bài viết này được thực hiện trong môi trường Windows Server 2016.
Lỗ hổng zero-day này chưa được công khai và khắc phục, có thể bị khai thác mà không bị phát hiện, mang tính hủy diệt lớn. Thông qua lỗ hổng này, hacker có thể chiếm quyền kiểm soát hoàn toàn hệ thống Windows. Điều này có thể dẫn đến việc thông tin cá nhân bị đánh cắp, hệ thống sập, mất dữ liệu, tổn thất tài chính, cài đặt phần mềm độc hại và nhiều hậu quả nghiêm trọng 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ố có thể bị chuyển nhượng. Nhìn 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 trên cơ sở hạ tầng Web2.
Thông qua việc phân tích bản vá, chúng tôi phát hiện ra vấn đề nằm ở chỗ số lượng tham chiếu của đối tượng đã được xử lý nhiều lần. win32k là mã cũ, các chú thích trong mã nguồn thời kỳ đầu cho thấy, mã trước đây chỉ khóa đối tượng cửa sổ, không khóa đối tượng menu trong đối tượng cửa sổ, điều này có thể dẫn đến việc đối tượng menu bị tham chiếu sai.
Khi thực hiện xác minh khái niệm (PoC), chúng tôi phát hiện rằng menu xxxEnableMenuItem() được truyền vào thường đã bị khóa trong hàm cấp cao hơn, không rõ ở đây cần bảo vệ đối tượng menu nào. Phân tích sâu hơn cho thấy, menu có thể được trả về từ hàm MenuItemState 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.
Để kích hoạt lỗ hổng, 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 một số điều kiện cụ thể để vượt qua kiểm tra của hàm xxxEnableMenuItem. Khi hàm xxxRedrawTitle trở về từ lớp người dùng, chúng tôi đã xóa mối quan hệ tham chiếu giữa menu C và B, thành công giải phóng menu C. Cuối cùng, khi hàm xxxEnableMenuItem trở về hàm xxxRedrawTitle, đối tượng menu C sắp được tham chiếu đã không còn hợp lệ.
Trong quá trình phát triể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 shellcode và sử dụng nguyên lý đọc/ghi để sửa đổi địa chỉ token. Xét về tính khả thi, chúng tôi đã chọn phương án sau. Toàn bộ quá trình khai thác có thể chia thành hai bước: cách khai thác lỗ hổng UAF để kiểm soát giá trị của cbwndextra, và cách thực hiện nguyên lý đọc/ghi ổn định.
Chúng tôi thông qua việc thiết kế cẩn thận bố cục bộ nhớ, sử dụng đối tượng tên cửa sổ trong lớp WNDClass để chiếm giữ đối tượng menu đã được giải phóng. Thông qua các thao tác cụ thể trong hàm xxxRedrawWindow, chúng tôi đã thực hiện việc ghi dữ liệu lần đầu tiên.
Để đạt được bố cục bộ nhớ ổn định, chúng tôi đã thiết kế ba đối tượng HWND liên tiếp, giải phóng một đối tượng ở giữa và sử dụng đối tượng HWNDClass. Các đối tượng HWND phía trước và phía sau lần lượt được sử dụng để kiểm tra và thực hiện các nguyên tử đọc/ghi. Chúng tôi cũng sử dụng việc rò rỉ địa chỉ handle kernel để xác định chính xác xem sự sắp xếp của các đối tượng có phù hợp với mong đợi hay không.
Trong việc triển khai đọ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 ghi tùy ý. Ngoài thao tác thay thế TOKEN, các ghi khác đều được thực hiện thông qua đối tượng class của đối tượng cửa sổ đầu tiên thông qua độ lệch.
Mặc dù lỗ hổng win32k đã tồn tại từ lâu, nhưng Microsoft đang cố gắng tái cấu trúc mã lõi liên quan bằng Rust, trong tương lai, lỗ hổng loại này có thể bị loại trừ trong hệ thống mới. Quy trình khai thác lỗ hổng này tương đối đơn giản, điểm khó khăn chính là cách kiểm soát lần ghi đầu tiên. Lỗ hổng này phụ thuộc nghiêm trọng vào việc rò rỉ địa chỉ của tay cầm heap trên desktop, điều này vẫn là mối nguy an ninh của các hệ thống cũ.
Chúng tôi suy đoán rằng 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. Đối với việc phát hiện lỗ hổng, ngoài việc giám sát các điểm quan trọng, việc phát hiện có mục đích về bố cục bộ nhớ bất thường và việc đọc ghi dữ liệu cửa sổ cũng có thể giúp phát hiện các lỗ hổng như vậy.