Phân tích và khai thác lỗ hổng 0day trên hệ thống Windows của Microsoft
Gần đây, bản vá bảo mật do Microsoft phát hành đã sửa một lỗ hổng nâng quyền win32k đang bị khai thác. Lỗ hổng này chỉ tồn tại trên các phiên bản hệ điều hành Windows cũ, không thể kích hoạt trên Windows 11. Bài viết này sẽ phân tích cách mà kẻ tấn công vẫn tiếp tục khai thác những lỗ hổng như vậy trong bối cảnh bảo vệ an ninh hiện tại đang ngày càng hoàn thiện.
Bối cảnh lỗ hổng
Lỗ hổng 0day chỉ những lỗ hổng an ninh chưa được công khai và chưa được sửa chữa, tương tự như khái niệm giao dịch T+0 trong thị trường tài chính. Khi loại lỗ hổng này được phát hiện, nó có thể bị khai thác một cách độc hại mà không bị phát hiện, gây ra thiệt hại lớn.
Lỗ hổng 0day trên hệ thống Windows được phát hiện lần này có thể cho phép kẻ tấn công 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 sản và nhiều hậu quả nghiêm trọng khác. Từ góc độ Web3, điều này có thể khiến khóa riêng bị đánh cắp, tài sản kỹ thuật số bị chuyển nhượng, thậm chí ảnh hưởng đến toàn bộ hệ sinh thái Web3 dựa trên cơ sở hạ tầng Web2.
Phân tích bản vá
Phân tích mã vá cho thấy, vấn đề nằm ở việc xử lý nhiều lần của số đếm tham chiếu đối tượng. Bằng cách xem xét chú thích mã nguồn trước đây, có thể thấy rằng mã trước đây chỉ khóa đối tượng cửa sổ, mà không khóa đối tượng menu trong cửa sổ, có thể dẫn đến việc đối tượng menu bị tham chiếu sai.
Tái hiện lỗ hổng
Thông qua việc phân tích ngữ cảnh của hàm lỗ hổng, phát hiện ra rằng menu 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, menu được trả về bởi hàm MenuItemState có thể là menu chính của cửa sổ, cũng có thể là menu con hoặc menu con của menu con.
Để kích hoạt lỗ hổng, đã 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 đặc điểm sau:
ID của menu cấp thấp nhất D phải là loại menu hệ thống
Menu cấp cao A cũng phải là menu hệ thống, nhưng cần xóa loại menu hệ thống tương ứng.
Xóa tham chiếu của menu C trong menu B
Sự tồn tại của menu B dường như giúp việc phát hành menu C.
Khi xxxRedrawTitle trả về lớp người dùng, hãy xóa mối quan hệ tham chiếu của menu C và B và giải phóng menu C. Như vậy, khi điểm trả về của hàm xxxEnableMenuItem, đối tượng menu C được tham chiếu đã không còn hiệu lực.
Khai thác lỗ hổng
Lỗ hổng chủ yếu được xem xét theo hai hướng:
Thực thi mã shellcode: tham khảo các lỗ hổng như CVE-2017-0263 trước đây, nhưng có thể gặp phải vấn đề với điểm vào và các cơ chế bảo mật như SMEP trong các phiên bản Windows cao hơn.
Sử dụng nguyên lý đọc ghi để sửa đổi địa chỉ token: Trong những năm gần đây, có nhiều exp công khai để tham khảo, có tính tổng quát đối với bố cục bộ nhớ ngăn xếp trên máy tính để bàn và nguyên lý đọc ghi. Chìa khóa là phân tích cách kiểm soát cbwndextra trở thành giá trị lớn lần đầu tiên khi tái sử dụng bộ nhớ UAF.
Lần này sử dụng phương án thứ hai, chia toàn bộ quy trình thành hai bước:
Sử dụng lỗ hổng UAF để kiểm soát giá trị cbwndextra
Kiểm soát cbwndextra để thực hiện các nguyên lý đọc/viết ổn định
lần ghi dữ liệu đầu tiên
Sau khi lỗi xảy ra, hệ thống có thể sử dụng sai dữ liệu của đối tượng cửa sổ bị kiểm soát trong MNGetPopupFromMenu() và xxxMNUpdateShownMenu(). Chúng tôi sử dụng đối tượng tên cửa sổ trong lớp cửa sổ WNDClass để chiếm dụng đối tượng menu đã được giải phóng.
Điều quan trọng 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 để ghi dữ liệu tùy ý, dù chỉ một byte. Cuối cùng đã chọn phương án trong hàm xxxRedrawWindow, thông qua việc kiểm soát dữ liệu bộ nhớ của đối tượng trước đó trong bố cục để xác định thông qua dấu hiệu của đối tượng trong hàm.
Bố cục bộ nhớ ổn định
Thiết kế ít nhất ba đối tượng HWND dài 0x250 byte liên tiếp, giải phóng một đối tượng ở giữa và sử dụng đối tượng HWNDClass. Dữ liệu đuôi của đối tượng HWND trước được sử dụng để kiểm tra bằng cờ trong xxxRedrawWindow, đối tượng menu của đối tượng HWND sau và đối tượng HWNDClass được sử dụng làm phương tiện đọc và ghi cuối cùng.
Thông qua địa chỉ tay cầm hạt nhân bị rò rỉ trong bộ nhớ, 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 theo thứ tự như mong đợi hay không.
đọc viết nguyên ngữ
Sử dụng GetMenuBarInfo() để đọc ngôn ngữ bất kỳ, sử dụng SetClassLongPtr() để ghi ngôn ngữ bất kỳ. Ngoài việc thay thế việc ghi TOKEN, tất cả các ghi khác đều sử dụng đối tượng class của đối tượng cửa sổ đầu tiên và sử dụng độ lệch để ghi.
Tóm tắt
Lỗ hổng win32k có lịch sử lâu dài, nhưng Microsoft đang cố gắng tái cấu trúc mã liên quan bằng Rust, trong tương lai các lỗ hổng loại này có thể sẽ bị loại bỏ trong hệ thống mới.
Quá trình khai thác lỗ hổng 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. Rất phụ thuộc vào việc rò rỉ địa chỉ tay cầm heap của desktop, đây vẫn là một mối nguy hiểm an ninh của hệ thống cũ.
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 khai thác lỗ hổng, ngoài việc chú ý đến điểm kích hoạt chức năng, còn cần chú ý đến bố cục bộ nhớ bất thường và việc đọc ghi dữ liệu cửa sổ lệch.
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.
6 thích
Phần thưởng
6
5
Chia sẻ
Bình luận
0/400
FarmToRiches
· 12giờ trước
Cũng tốt, 11 không bị ảnh hưởng.
Xem bản gốcTrả lời0
ChainSauceMaster
· 08-05 20:25
Cái gì đang xảy ra với ông Win vậy? Mỗi ngày đều có lỗ hổng.
Xem bản gốcTrả lời0
FloorPriceWatcher
· 08-05 20:23
win11 đã thoát khỏi một kiếp nạn
Xem bản gốcTrả lời0
MEVSandwichVictim
· 08-05 20:21
lỗ hổng bao sợi kịch nhiều ai giao dịch ai chơi đùa với mọi người
Phân tích lỗ hổng 0day trên các phiên bản sớm của Windows: Từ nâng cao quyền hạn đến quy trình khai thác toàn bộ
Phân tích và khai thác lỗ hổng 0day trên hệ thống Windows của Microsoft
Gần đây, bản vá bảo mật do Microsoft phát hành đã sửa một lỗ hổng nâng quyền win32k đang bị khai thác. Lỗ hổng này chỉ tồn tại trên các phiên bản hệ điều hành Windows cũ, không thể kích hoạt trên Windows 11. Bài viết này sẽ phân tích cách mà kẻ tấn công vẫn tiếp tục khai thác những lỗ hổng như vậy trong bối cảnh bảo vệ an ninh hiện tại đang ngày càng hoàn thiện.
Bối cảnh lỗ hổng
Lỗ hổng 0day chỉ những lỗ hổng an ninh chưa được công khai và chưa được sửa chữa, tương tự như khái niệm giao dịch T+0 trong thị trường tài chính. Khi loại lỗ hổng này được phát hiện, nó có thể bị khai thác một cách độc hại mà không bị phát hiện, gây ra thiệt hại lớn.
Lỗ hổng 0day trên hệ thống Windows được phát hiện lần này có thể cho phép kẻ tấn công 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 sản và nhiều hậu quả nghiêm trọng khác. Từ góc độ Web3, điều này có thể khiến khóa riêng bị đánh cắp, tài sản kỹ thuật số bị chuyển nhượng, thậm chí ảnh hưởng đến toàn bộ hệ sinh thái Web3 dựa trên cơ sở hạ tầng Web2.
Phân tích bản vá
Phân tích mã vá cho thấy, vấn đề nằm ở việc xử lý nhiều lần của số đếm tham chiếu đối tượng. Bằng cách xem xét chú thích mã nguồn trước đây, có thể thấy rằng mã trước đây chỉ khóa đối tượng cửa sổ, mà không khóa đối tượng menu trong cửa sổ, có thể dẫn đến việc đối tượng menu bị tham chiếu sai.
Tái hiện lỗ hổng
Thông qua việc phân tích ngữ cảnh của hàm lỗ hổng, phát hiện ra rằng menu 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, menu được trả về bởi hàm MenuItemState có thể là menu chính của cửa sổ, cũng có thể là menu con hoặc menu con của menu con.
Để kích hoạt lỗ hổng, đã 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 đặc điểm sau:
Khi xxxRedrawTitle trả về lớp người dùng, hãy xóa mối quan hệ tham chiếu của menu C và B và giải phóng menu C. Như vậy, khi điểm trả về của hàm xxxEnableMenuItem, đối tượng menu C được tham chiếu đã không còn hiệu lực.
Khai thác lỗ hổng
Lỗ hổng chủ yếu được xem xét theo hai hướng:
Thực thi mã shellcode: tham khảo các lỗ hổng như CVE-2017-0263 trước đây, nhưng có thể gặp phải vấn đề với điểm vào và các cơ chế bảo mật như SMEP trong các phiên bản Windows cao hơn.
Sử dụng nguyên lý đọc ghi để sửa đổi địa chỉ token: Trong những năm gần đây, có nhiều exp công khai để tham khảo, có tính tổng quát đối với bố cục bộ nhớ ngăn xếp trên máy tính để bàn và nguyên lý đọc ghi. Chìa khóa là phân tích cách kiểm soát cbwndextra trở thành giá trị lớn lần đầu tiên khi tái sử dụng bộ nhớ UAF.
Lần này sử dụng phương án thứ hai, chia toàn bộ quy trình thành hai bước:
lần ghi dữ liệu đầu tiên
Sau khi lỗi xảy ra, hệ thống có thể sử dụng sai dữ liệu của đối tượng cửa sổ bị kiểm soát trong MNGetPopupFromMenu() và xxxMNUpdateShownMenu(). Chúng tôi sử dụng đối tượng tên cửa sổ trong lớp cửa sổ WNDClass để chiếm dụng đối tượng menu đã được giải phóng.
Điều quan trọng 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 để ghi dữ liệu tùy ý, dù chỉ một byte. Cuối cùng đã chọn phương án trong hàm xxxRedrawWindow, thông qua việc kiểm soát dữ liệu bộ nhớ của đối tượng trước đó trong bố cục để xác định thông qua dấu hiệu của đối tượng trong hàm.
Bố cục bộ nhớ ổn định
Thiết kế ít nhất ba đối tượng HWND dài 0x250 byte liên tiếp, giải phóng một đối tượng ở giữa và sử dụng đối tượng HWNDClass. Dữ liệu đuôi của đối tượng HWND trước được sử dụng để kiểm tra bằng cờ trong xxxRedrawWindow, đối tượng menu của đối tượng HWND sau và đối tượng HWNDClass được sử dụng làm phương tiện đọc và ghi cuối cùng.
Thông qua địa chỉ tay cầm hạt nhân bị rò rỉ trong bộ nhớ, 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 theo thứ tự như mong đợi hay không.
đọc viết nguyên ngữ
Sử dụng GetMenuBarInfo() để đọc ngôn ngữ bất kỳ, sử dụng SetClassLongPtr() để ghi ngôn ngữ bất kỳ. Ngoài việc thay thế việc ghi TOKEN, tất cả các ghi khác đều sử dụng đối tượng class của đối tượng cửa sổ đầu tiên và sử dụng độ lệch để ghi.
Tóm tắt
Lỗ hổng win32k có lịch sử lâu dài, nhưng Microsoft đang cố gắng tái cấu trúc mã liên quan bằng Rust, trong tương lai các lỗ hổng loại này có thể sẽ bị loại bỏ trong hệ thống mới.
Quá trình khai thác lỗ hổng 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. Rất phụ thuộc vào việc rò rỉ địa chỉ tay cầm heap của desktop, đây vẫn là một mối nguy hiểm an ninh của hệ thống cũ.
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 khai thác lỗ hổng, ngoài việc chú ý đến điểm kích hoạt chức năng, còn cần chú ý đến bố cục bộ nhớ bất thường và việc đọc ghi dữ liệu cửa sổ lệch.