Phân tích và khai thác lỗ hổng 0day cấp hệ thống của Microsoft
Giới thiệu
Gần đây, bản vá bảo mật của Microsoft đã khắc phục một lỗ hổng nâng quyền win32k đang bị tin tặc 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 sớm, dường như không có hiệu lực trên Windows 11. Bài viết này sẽ phân tích sâu về cách mà kẻ tấn công có thể tiếp tục khai thác các lỗ hổng như vậy trong bối cảnh các biện pháp bảo vệ mới đang được cải thiện. Môi trường phân tích của chúng tôi là Windows Server 2016.
Bối cảnh lỗ hổng
0day lỗ hổng chỉ những lỗ hổng bảo mật 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. Những lỗ hổng này một khi bị khai thác ác ý, thường sẽ gây ra thiệt hại lớn. Lỗ hổng 0day cấp hệ thống Windows được phát hiện lần này có thể cho phép kẻ tấn công chiếm quyền kiểm soát hoàn toàn hệ thống.
Hậu quả của việc hệ thống bị kiểm soát bởi kẻ tấn công rất nghiêm trọng, bao gồm rò rỉ thông tin cá nhân, hệ thống sập, mất dữ liệu, thiệt hại tài sản, và cài đặt phần mềm độc hại. Đối với người dùng tiền điện tử, khóa riêng có thể bị đánh cắp, tài sản số có thể bị chuyển nhượng. Từ một góc nhìn 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 cơ sở 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 số lần tham chiếu của một đối tượng bị xử lý nhiều lần. Bằng cách xem xét các chú thích mã nguồn trước đó, chúng tôi phát hiện ra 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 đối tượng menu bị tham chiếu sai.
Xác minh lỗ hổng
Phân tích ngữ cảnh hàm lỗ hổng, chúng tôi phát hiện rằng menu được truyền vào xxxEnableMenuItem() thường đã được khóa ở hàm cấp trên, vậy cụ thể cần bảo vệ đối tượng menu nào? Phân tích thêm về cách xử lý đối tượng menu trong xxxEnableMenuItem, phát hiện rằng hàm MenuItemState trả về menu có hai khả năng: menu chính của cửa sổ hoặc menu con( bao gồm cả menu con của menu con).
Để xác minh 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 việc kiểm tra trong hàm xxxEnableMenuItem. Khi xxxRedrawTitle trả về tầng 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 trong kernel trả về hàm xxxRedrawTitle, đối tượng menu C đang tham chiếu đã không còn hiệu lực.
Khai thác lỗ hổng
Tư duy tổng thể
Trước khi xác định phương án khai thác, chúng tôi thường tiến hành một số phân tích lý thuyết để tránh lãng phí thời gian vào các phương án không khả thi. Lần khai thác lỗ hổng này chủ yếu xem xét hai hướng:
Thực thi shellcode: Tham khảo các lỗ hổng tương tự trước đây, nhưng có thể gặp phải một số vấn đề khó giải quyết trong các phiên bản Windows cao hơn.
Sử dụng các nguyên thủy đọc ghi để sửa đổi token: ngay cả trong hai năm qua vẫn có các trường hợp công khai để tham khảo. Chúng ta cần tập trung giải quyết cách kiểm soát cbwndextra là giá trị lớn lần đầu tiên khi bộ nhớ UAF được tái sử dụng.
Do đó, chúng tôi chia toàn bộ quá trình khai thác thành hai phần: cách khai thác lỗ hổng UAF để kiểm soát giá trị cbwndextra, và cách thực hiện các nguyên lý đọc/ghi ổn định sau khi kiểm soát giá trị đó.
 Ghi dữ liệu lần đầu
Sau khi kích hoạt lỗ hổng, hệ thống không nhất thiết sẽ lập tức sập. Lỗi sử dụng dữ liệu đối tượng cửa sổ trong bộ nhớ bị kiểm soát chủ yếu xảy ra trong các hàm MNGetPopupFromMenu###( và xxxMNUpdateShownMenu)(.
Chúng tôi sử dụng đối tượng tên cửa sổ trong lớp WNDClass để chiếm dụng bộ nhớ của đối tượng menu đã 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 ý, ngay cả chỉ một byte.
Cuối cùng, chúng tôi đã tìm thấy hai phương án khả thi trong hàm xxxRedrawWindow. Cân nhắc đến một số yếu tố hạn chế, chúng tôi đã chọn phương án dựa vào phép AND 2 với cờ và quyết định ghi vào cb-extra của HWNDClass thay vì cb-extra của đối tượng cửa sổ.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + mặt vật lý trong trò chơi Web3])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) Bố cục bộ nhớ ổn định
Chúng tôi đã thiết kế bố cục bộ nhớ cho ít nhất ba đối tượng HWND 0x250 byte liên tiếp. Giải phóng đối tượng ở giữa, sử dụng đối tượng HWNDClass 0x250 byte. Dữ liệu đuôi của đối tượng HWND trước được sử dụng để kiểm tra bằng cờ xxxRedrawWindow, đối tượng menu của đối tượng HWND sau và đối tượng HWNDClass hoạt động như phương tiện đọc/ghi cuối cùng.
Chúng tôi cố gắng kiểm soát kích thước của đối tượng cửa sổ và đối tượng HWNDClass đồng nhất, và đảm bảo rằng dữ liệu mở rộng của đối tượng cửa sổ đủ lớn. Thông qua địa chỉ của các handle kernel bị rò rỉ trong bộ nhớ heap, chúng tôi có thể xác định chính xác xem đối tượng cửa sổ đã được cấp phát có được sắp xếp theo thứ tự như mong đợi hay không.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + mặt vật lý trong trò chơi Web3]###https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
) thực hiện đọc ghi nguyên thủy
Bất kỳ đọc ngôn ngữ gốc vẫn sử dụng GetMenuBarInfo###(. Bất kỳ viết ngôn ngữ gốc thì sử dụng SetClassLongPtr)(. Ngoài việc thay thế TOKEN, các thao tác ghi khác phụ thuộc vào đối tượng class của cửa sổ thứ hai, tất cả các ghi khác đều sử dụng đối tượng class của cửa sổ đầu tiên với các offset để thực hiện.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ Web3 ở cả hệ thống + mặt vật lý])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
Tóm tắt
Lỗ hổng win32k đã tồn tại từ lâu, nhưng Microsoft đang tái cấu trúc mã lõi liên quan bằng Rust, hệ thống mới trong tương lai có thể ngăn chặn loại lỗ hổng này.
Quá trình khai thác lỗ hổng lần này không quá khó, điểm khó chủ yếu là làm thế nào để kiểm soát việc ghi lần đầu tiên. Lỗ hổng vẫn nghiêm trọng phụ thuộc 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 hiểm an ninh đối với các 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 độ phủ mã được cải thiện hơn. Khi API của hệ thống có thể đến điểm lỗ hổng sâu nhất trong đường dẫn thực thi của hàm mục tiêu, và đối tượng cửa sổ ở trạng thái tham chiếu lồng ghép nhiều lần, thì thử nghiệm fuzz có thể phát hiện ra lỗ hổng này.
Đối với việc phát hiện khai thác lỗ hổng, ngoài việc chú ý đến các điểm chính của hàm kích hoạt lỗ hổng, còn cần quan tâm đến cấu trúc bộ nhớ bất thường và việc đọc/ghi dữ liệu lệch thông thường đối với cửa sổ hoặc lớp cửa sổ, điều này có thể giúp phát hiện các lỗ hổng cùng loại.
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.
23 thích
Phần thưởng
23
3
Chia sẻ
Bình luận
0/400
OnChainDetective
· 5giờ trước
ah classic win32k... mẫu hình khớp với các lỗ hổng APT trước đây thật sự
Phân tích và khai thác độ sâu lỗ hổng 0day cấp hệ thống Windows
Phân tích và khai thác lỗ hổng 0day cấp hệ thống của Microsoft
Giới thiệu
Gần đây, bản vá bảo mật của Microsoft đã khắc phục một lỗ hổng nâng quyền win32k đang bị tin tặc 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 sớm, dường như không có hiệu lực trên Windows 11. Bài viết này sẽ phân tích sâu về cách mà kẻ tấn công có thể tiếp tục khai thác các lỗ hổng như vậy trong bối cảnh các biện pháp bảo vệ mới đang được cải thiện. Môi trường phân tích của chúng tôi là Windows Server 2016.
Bối cảnh lỗ hổng
0day lỗ hổng chỉ những lỗ hổng bảo mật 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. Những lỗ hổng này một khi bị khai thác ác ý, thường sẽ gây ra thiệt hại lớn. Lỗ hổng 0day cấp hệ thống Windows được phát hiện lần này có thể cho phép kẻ tấn công chiếm quyền kiểm soát hoàn toàn hệ thống.
Hậu quả của việc hệ thống bị kiểm soát bởi kẻ tấn công rất nghiêm trọng, bao gồm rò rỉ thông tin cá nhân, hệ thống sập, mất dữ liệu, thiệt hại tài sản, và cài đặt phần mềm độc hại. Đối với người dùng tiền điện tử, khóa riêng có thể bị đánh cắp, tài sản số có thể bị chuyển nhượng. Từ một góc nhìn 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 cơ sở 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 số lần tham chiếu của một đối tượng bị xử lý nhiều lần. Bằng cách xem xét các chú thích mã nguồn trước đó, chúng tôi phát hiện ra 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 đối tượng menu bị tham chiếu sai.
Xác minh lỗ hổng
Phân tích ngữ cảnh hàm lỗ hổng, chúng tôi phát hiện rằng menu được truyền vào xxxEnableMenuItem() thường đã được khóa ở hàm cấp trên, vậy cụ thể cần bảo vệ đối tượng menu nào? Phân tích thêm về cách xử lý đối tượng menu trong xxxEnableMenuItem, phát hiện rằng hàm MenuItemState trả về menu có hai khả năng: menu chính của cửa sổ hoặc menu con( bao gồm cả menu con của menu con).
Để xác minh 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 việc kiểm tra trong hàm xxxEnableMenuItem. Khi xxxRedrawTitle trả về tầng 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 trong kernel trả về hàm xxxRedrawTitle, đối tượng menu C đang tham chiếu đã không còn hiệu lực.
Khai thác lỗ hổng
Tư duy tổng thể
Trước khi xác định phương án khai thác, chúng tôi thường tiến hành một số phân tích lý thuyết để tránh lãng phí thời gian vào các phương án không khả thi. Lần khai thác lỗ hổng này chủ yếu xem xét hai hướng:
Thực thi shellcode: Tham khảo các lỗ hổng tương tự trước đây, nhưng có thể gặp phải một số vấn đề khó giải quyết trong các phiên bản Windows cao hơn.
Sử dụng các nguyên thủy đọc ghi để sửa đổi token: ngay cả trong hai năm qua vẫn có các trường hợp công khai để tham khảo. Chúng ta cần tập trung giải quyết cách kiểm soát cbwndextra là giá trị lớn lần đầu tiên khi bộ nhớ UAF được tái sử dụng.
Do đó, chúng tôi chia toàn bộ quá trình khai thác thành hai phần: cách khai thác lỗ hổng UAF để kiểm soát giá trị cbwndextra, và cách thực hiện các nguyên lý đọc/ghi ổn định sau khi kiểm soát giá trị đó.
 Ghi dữ liệu lần đầu
Sau khi kích hoạt lỗ hổng, hệ thống không nhất thiết sẽ lập tức sập. Lỗi sử dụng dữ liệu đối tượng cửa sổ trong bộ nhớ bị kiểm soát chủ yếu xảy ra trong các hàm MNGetPopupFromMenu###( và xxxMNUpdateShownMenu)(.
Chúng tôi sử dụng đối tượng tên cửa sổ trong lớp WNDClass để chiếm dụng bộ nhớ của đối tượng menu đã 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 ý, ngay cả chỉ một byte.
Cuối cùng, chúng tôi đã tìm thấy hai phương án khả thi trong hàm xxxRedrawWindow. Cân nhắc đến một số yếu tố hạn chế, chúng tôi đã chọn phương án dựa vào phép AND 2 với cờ và quyết định ghi vào cb-extra của HWNDClass thay vì cb-extra của đối tượng cửa sổ.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + mặt vật lý trong trò chơi Web3])https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) Bố cục bộ nhớ ổn định
Chúng tôi đã thiết kế bố cục bộ nhớ cho ít nhất ba đối tượng HWND 0x250 byte liên tiếp. Giải phóng đối tượng ở giữa, sử dụng đối tượng HWNDClass 0x250 byte. Dữ liệu đuôi của đối tượng HWND trước được sử dụng để kiểm tra bằng cờ xxxRedrawWindow, đối tượng menu của đối tượng HWND sau và đối tượng HWNDClass hoạt động như phương tiện đọc/ghi cuối cùng.
Chúng tôi cố gắng kiểm soát kích thước của đối tượng cửa sổ và đối tượng HWNDClass đồng nhất, và đảm bảo rằng dữ liệu mở rộng của đối tượng cửa sổ đủ lớn. Thông qua địa chỉ của các handle kernel bị rò rỉ trong bộ nhớ heap, chúng tôi có thể xác định chính xác xem đối tượng cửa sổ đã được cấp phát có được sắp xếp theo thứ tự như mong đợi hay không.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + mặt vật lý trong trò chơi Web3]###https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
) thực hiện đọc ghi nguyên thủy
Bất kỳ đọc ngôn ngữ gốc vẫn sử dụng GetMenuBarInfo###(. Bất kỳ viết ngôn ngữ gốc thì sử dụng SetClassLongPtr)(. Ngoài việc thay thế TOKEN, các thao tác ghi khác phụ thuộc vào đối tượng class của cửa sổ thứ hai, tất cả các ghi khác đều sử dụng đối tượng class của cửa sổ đầu tiên với các offset để thực hiện.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ Web3 ở cả hệ thống + mặt vật lý])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
Tóm tắt
Lỗ hổng win32k đã tồn tại từ lâu, nhưng Microsoft đang tái cấu trúc mã lõi liên quan bằng Rust, hệ thống mới trong tương lai có thể ngăn chặn loại lỗ hổng này.
Quá trình khai thác lỗ hổng lần này không quá khó, điểm khó chủ yếu là làm thế nào để kiểm soát việc ghi lần đầu tiên. Lỗ hổng vẫn nghiêm trọng phụ thuộc 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 hiểm an ninh đối với các 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 độ phủ mã được cải thiện hơn. Khi API của hệ thống có thể đến điểm lỗ hổng sâu nhất trong đường dẫn thực thi của hàm mục tiêu, và đối tượng cửa sổ ở trạng thái tham chiếu lồng ghép nhiều lần, thì thử nghiệm fuzz có thể phát hiện ra lỗ hổng này.
Đối với việc phát hiện khai thác lỗ hổng, ngoài việc chú ý đến các điểm chính của hàm kích hoạt lỗ hổng, còn cần quan tâm đến cấu trúc bộ nhớ bất thường và việc đọc/ghi dữ liệu lệch thông thường đối với cửa sổ hoặc lớp cửa sổ, điều này có thể giúp phát hiện các lỗ hổng cùng loại.