Phân tích lỗ hổng nghiêm trọng của hệ thống Windows của Microsoft: có thể đe dọa an ninh sinh thái Web3
Bản sửa lỗi bảo mật mà Microsoft phát hành vào tháng trước đã khắc phục một lỗ hổng nâng quyền Windows đang bị hacker khai thác. Lỗ hổng này chủ yếu ảnh hưởng đến các phiên bản hệ thống Windows trước đây, Windows 11 dường như không bị ảnh hưởng.
Bài viết này sẽ phân tích cách mà kẻ tấn công tiếp tục khai thác các lỗ hổng này trong bối cảnh bảo mật ngày càng được củng cố. Phân tích của chúng tôi dựa trên Windows Server 2016.
Bối cảnh lỗ hổng
Đây là một lỗ hổng 0day, tức là lỗ hổng chưa được công bố và sửa chữa. Hacker có thể lợi dụng nó để tấn công mà người dùng không hay biết, gây ra thiệt hại rất lớn.
Thông qua lỗ hổng cấp hệ thống Windows này, hacker có thể giành quyền kiểm soát hoàn toàn hệ thống. Điều này có thể dẫn đến việc lộ thông tin cá nhân, hệ thống bị sập, mất dữ liệu, thiệt hại tài chính và nhiều hậu quả nghiêm trọng khác. Đối với người dùng Web3, khóa riêng và tài sản kỹ thuật số có thể bị đánh cắp. 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 dựa trên hạ tầng Web2.
Phân tích bản vá
Phân tích mã vá, vấn đề dường như nằm ở việc tham chiếu số lượng của một đối tượng đã được xử lý nhiều lần. Bằng cách xem xét chú thích mã nguồn trước đó, chúng tôi phát hiện rằng mã trước đây chỉ khóa đối tượng cửa sổ, không khóa đối tượng menu trong cửa sổ, điều này có thể dẫn đến việc tham chiếu sai đối tượng menu.
Tái hiện lỗ hổng
Phân tích ngữ cảnh của hàm lỗi, chúng tôi phát hiện ra rằng menu được truyền vào xxxEnableMenuItem() thường đã được khóa ở hàm cấp trên, ở đây thật sự có nghi vấn về việc bảo vệ đối tượng menu nào.
Phân tích thêm cho thấy, trong xxxEnableMenuItem, hàm MenuItemState trả về menu có hai khả năng: menu chính của cửa sổ hoặc menu con (, thậm chí là menu con con ).
Chúng tôi đã xây dựng một cấu trúc menu bốn lớp đặc biệt để kích hoạt lỗ hổng, những menu này cần phải đáp ứng một số điều kiện cụ thể để vượt qua các kiểm tra trong hàm. Chìa khóa là khi xxxRedrawTitle trả về lớp người dùng, xóa bỏ mối quan hệ tham chiếu giữa một số menu, giải phóng các đối tượng menu cụ thể. Như vậy, tại điểm trả về của hàm xxxEnableMenuItem, các đối tượng menu mà sắp được tham chiếu sẽ không còn hợp lệ.
Khai thác lỗ hổng
Trong quá trình phát triển chương trình 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: Tham khảo các lỗ hổng tương tự trước đây, nhưng có thể có một số trở ngại trong phiên bản Windows mới.
Sử dụng nguyên thủy đọc/ghi để sửa đổi địa chỉ token: Phương pháp này gần đây vẫn có exp công khai để tham khảo, có tính phổ quát tốt đối với bố cục bộ nhớ ngăn xếp trên máy tính để bàn và nguyên thủy đọc/ghi.
Chúng tôi đã chọn phương án thứ hai, chia toàn bộ quá trình khai thác 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 các nguyên thủy đọc/ghi một cách ổn định.
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 có thể ghi dữ liệu một cách tùy ý. Cuối cùng, chúng tôi đã chọn thực hiện điều này thông qua một phép AND của cờ trong hàm xxxRedrawWindow.
Để đạt được bố cục bộ nhớ ổn định, chúng tôi đã thiết kế ít nhất ba đối tượng HWND liên tiếp có kích thước 0x250 byte, giải phóng các đối tượng ở giữa, và sử dụng đối tượng HWNDClass để chiếm dụng. 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 qua hàm và thực hiện các nguyên tử đọc/ghi cuối cùng.
Chúng tôi cũng xác định chính xác xem đối tượng có được sắp xếp như mong đợi hay không thông qua địa chỉ tay cầm lõi bị rò rỉ. Về mặt nguyên tử đọc/ghi, chúng tôi sử dụng GetMenuBarInfo() để thực hiện đọc tùy ý, và sử dụng SetClassLongPtr() để thực hiện ghi tùy ý.
Kết luận
Microsoft đang cố gắng tái cấu trúc mã liên quan đến win32k bằng Rust, trong tương lai các lỗ hổng như vậy có thể được loại bỏ trong hệ thống mới.
Quy trình khai thác lỗ hổng loại này tương đối đơn giản, chủ yếu phụ thuộc vào việc rò rỉ địa chỉ của các handle heap trên máy tính để bàn. Nếu vấn đề này không được giải quyết triệt để, các hệ thống cũ sẽ tiếp tục đối mặt với các mối đe dọa an ninh.
Việc phát hiện lỗ hổng này có thể nhờ vào công nghệ kiểm tra độ bao phủ mã tốt hơn.
Đối với việc phát hiện khai thác lỗ hổng, ngoài việc giám sát các hàm quan trọng, cũng nên chú ý đến bố trí bộ nhớ bất thường và hành vi đọc/ghi dữ liệu.
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.
9 thích
Phần thưởng
9
6
Đăng lại
Chia sẻ
Bình luận
0/400
rug_connoisseur
· 1giờ trước
Một lỗ hổng Windows nữa, đã quen rồi!
Xem bản gốcTrả lời0
rekt_but_not_broke
· 08-12 05:14
Kiếm tiền không thể chậm trễ, Ví tiền trước tiên cần được bảo vệ tốt!
Xem bản gốcTrả lời0
MetaLord420
· 08-12 05:02
Người chơi Windows còn dám chạm vào web3?!
Xem bản gốcTrả lời0
SighingCashier
· 08-12 05:00
Hệ thống cũ gặp lỗi này, lẽ ra nên thay thế từ lâu.
Xem bản gốcTrả lời0
ForkMaster
· 08-12 04:59
chơi đùa với mọi người không còn được nữa? chạy lỗ hổng Khai thác rồi
Lỗ hổng hệ thống Windows đe dọa an ninh sinh thái Web3 Phân tích sâu về cơ chế khai thác của chuyên gia
Phân tích lỗ hổng nghiêm trọng của hệ thống Windows của Microsoft: có thể đe dọa an ninh sinh thái Web3
Bản sửa lỗi bảo mật mà Microsoft phát hành vào tháng trước đã khắc phục một lỗ hổng nâng quyền Windows đang bị hacker khai thác. Lỗ hổng này chủ yếu ảnh hưởng đến các phiên bản hệ thống Windows trước đây, Windows 11 dường như không bị ảnh hưởng.
Bài viết này sẽ phân tích cách mà kẻ tấn công tiếp tục khai thác các lỗ hổng này trong bối cảnh bảo mật ngày càng được củng cố. Phân tích của chúng tôi dựa trên Windows Server 2016.
Bối cảnh lỗ hổng
Đây là một lỗ hổng 0day, tức là lỗ hổng chưa được công bố và sửa chữa. Hacker có thể lợi dụng nó để tấn công mà người dùng không hay biết, gây ra thiệt hại rất lớn.
Thông qua lỗ hổng cấp hệ thống Windows này, hacker có thể giành quyền kiểm soát hoàn toàn hệ thống. Điều này có thể dẫn đến việc lộ thông tin cá nhân, hệ thống bị sập, mất dữ liệu, thiệt hại tài chính và nhiều hậu quả nghiêm trọng khác. Đối với người dùng Web3, khóa riêng và tài sản kỹ thuật số có thể bị đánh cắp. 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 dựa trên hạ tầng Web2.
Phân tích bản vá
Phân tích mã vá, vấn đề dường như nằm ở việc tham chiếu số lượng của một đối tượng đã được xử lý nhiều lần. Bằng cách xem xét chú thích mã nguồn trước đó, chúng tôi phát hiện rằng mã trước đây chỉ khóa đối tượng cửa sổ, không khóa đối tượng menu trong cửa sổ, điều này có thể dẫn đến việc tham chiếu sai đối tượng menu.
Tái hiện lỗ hổng
Phân tích ngữ cảnh của hàm lỗi, chúng tôi phát hiện ra rằng menu được truyền vào xxxEnableMenuItem() thường đã được khóa ở hàm cấp trên, ở đây thật sự có nghi vấn về việc bảo vệ đối tượng menu nào.
Phân tích thêm cho thấy, trong xxxEnableMenuItem, hàm MenuItemState trả về menu có hai khả năng: menu chính của cửa sổ hoặc menu con (, thậm chí là menu con con ).
Chúng tôi đã xây dựng một cấu trúc menu bốn lớp đặc biệt để kích hoạt lỗ hổng, những menu này cần phải đáp ứng một số điều kiện cụ thể để vượt qua các kiểm tra trong hàm. Chìa khóa là khi xxxRedrawTitle trả về lớp người dùng, xóa bỏ mối quan hệ tham chiếu giữa một số menu, giải phóng các đối tượng menu cụ thể. Như vậy, tại điểm trả về của hàm xxxEnableMenuItem, các đối tượng menu mà sắp được tham chiếu sẽ không còn hợp lệ.
Khai thác lỗ hổng
Trong quá trình phát triển chương trình 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: Tham khảo các lỗ hổng tương tự trước đây, nhưng có thể có một số trở ngại trong phiên bản Windows mới.
Sử dụng nguyên thủy đọc/ghi để sửa đổi địa chỉ token: Phương pháp này gần đây vẫn có exp công khai để tham khảo, có tính phổ quát tốt đối với bố cục bộ nhớ ngăn xếp trên máy tính để bàn và nguyên thủy đọc/ghi.
Chúng tôi đã chọn phương án thứ hai, chia toàn bộ quá trình khai thác 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 các nguyên thủy đọc/ghi một cách ổn định.
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 có thể ghi dữ liệu một cách tùy ý. Cuối cùng, chúng tôi đã chọn thực hiện điều này thông qua một phép AND của cờ trong hàm xxxRedrawWindow.
Để đạt được bố cục bộ nhớ ổn định, chúng tôi đã thiết kế ít nhất ba đối tượng HWND liên tiếp có kích thước 0x250 byte, giải phóng các đối tượng ở giữa, và sử dụng đối tượng HWNDClass để chiếm dụng. 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 qua hàm và thực hiện các nguyên tử đọc/ghi cuối cùng.
Chúng tôi cũng xác định chính xác xem đối tượng có được sắp xếp như mong đợi hay không thông qua địa chỉ tay cầm lõi bị rò rỉ. Về mặt nguyên tử đọc/ghi, chúng tôi sử dụng GetMenuBarInfo() để thực hiện đọc tùy ý, và sử dụng SetClassLongPtr() để thực hiện ghi tùy ý.
Kết luận
Microsoft đang cố gắng tái cấu trúc mã liên quan đến win32k bằng Rust, trong tương lai các lỗ hổng như vậy có thể được loại bỏ trong hệ thống mới.
Quy trình khai thác lỗ hổng loại này tương đối đơn giản, chủ yếu phụ thuộc vào việc rò rỉ địa chỉ của các handle heap trên máy tính để bàn. Nếu vấn đề này không được giải quyết triệt để, các hệ thống cũ sẽ tiếp tục đối mặt với các mối đe dọa an ninh.
Việc phát hiện lỗ hổng này có thể nhờ vào công nghệ kiểm tra độ bao phủ mã tốt hơn.
Đối với việc phát hiện khai thác lỗ hổng, ngoài việc giám sát các hàm quan trọng, cũng nên chú ý đến bố trí bộ nhớ bất thường và hành vi đọc/ghi dữ liệu.