Phân tích lỗ hổng nghiêm trọng của hệ thống Windows của Microsoft
Gần đây, bản vá bảo mật được Microsoft phát hành đã khắc phục một lỗ hổng nâng quyền trong nhân Windows đ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 hơn, không thể kích hoạt trên Windows 11. Những lỗ hổng kiểu này đã tồn tại từ lâu, bài viết này sẽ khám phá cách mà những kẻ tấn công vẫn tiếp tục khai thác những lỗ hổng này trong bối cảnh bảo mật hiện đang được tăng cường.
Phân tích này được thực hiện dựa trên môi trường Windows Server 2016.
Bối cảnh lỗ hổng
Đây là một lỗ hổng zero-day, chỉ những lỗ hổng hệ thống chưa được công khai và chưa được sửa chữa. Hacker có thể khai thác lỗ hổng zero-day để tấn công mà người dùng không hề hay biết, mang lại sự phá hoại rất lớn.
Lỗ hổng zero-day được phát hiện lần này tồn tại ở cấp độ kernel của hệ thống Windows, kẻ tấn công có thể thông qua lỗ hổng này để chiếm quyền kiểm soát hoàn toàn Windows. Điều này có thể dẫn đến việc lộ thông tin cá nhân của người dùng, hệ thống 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. Từ góc độ Web3, khóa riêng của người dùng có thể bị đánh cắp, tài sản kỹ thuật số có nguy cơ bị chuyển nhượng. Ở một phạm vi lớn 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 dựa trên cơ sở hạ tầng Web2.
Phân tích lỗ hổng
Phân tích mã vá, chúng tôi phát hiện vấn đề nằm ở việc tham chiếu đến một đối tượng đã được xử lý nhiều lần. Xem xét các chú thích trong mã nguồn win32k trước đó, 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 đố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.
Phân tích thêm cho thấy, menu được truyền vào hàm xxxEnableMenuItem() thường đã được khóa trong hàm cấp trên, vậy ở đây thực sự cần bảo vệ đối tượng menu nào? Qua nghiên cứu, hàm MenuItemState trong xxxEnableMenuItem 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 của menu con ).
Khai thác lỗ hổng
Để xác minh lỗ hổng, chúng tôi đã xây dựng một cấu trúc menu bốn tầng đặc biệt và đặt ra một số điều kiện cụ thể:
ID của menu tầng thấp nhất D phải là loại menu hệ thống, chẳng hạn như đóng menu (0xf060)
Menu cấp cao A cũng phải là menu hệ thống, nhưng cần xóa mục menu 0xf060 trong đó.
Xóa tham chiếu của menu C trong menu B
Sự tồn tại của menu B dường như ảnh hưởng đến việc phát hành menu C
Khi kích hoạt lỗ hổng, xóa liên kết giữa menu C và B khi xxxRedrawTitle trả về lớp người dùng, giải phóng thành công menu C. Khi hàm xxxEnableMenuItem trong nhân trả về xxxRedrawTitle, đối tượng menu C mà sắp được tham chiếu đã không còn hiệu lực.
Phân tích khai thác lỗ hổng
Trong việc thiết kế kế hoạch khai thác lỗ hổng, chúng tôi chủ yếu xem xét hai hướng:
Thực thi shellcode: Tham khảo các phương pháp từ CVE-2017-0263 và CVE-2016-0167 trước đây. Nhưng trong các phiên bản Windows cao hơn, điểm vào thực thi shellcode và các cơ chế bảo mật như SMEP có thể gặp trở ngại.
Sử dụng nguyên tử đọc ghi để sửa đổi địa chỉ token: Phương pháp này có độ phổ quát tốt hơn. Chìa khóa là phân tích cách lần đầu tiên kiểm soát cbwndextra thành giá trị cực lớn trong quá trình tái sử dụng bộ nhớ UAF.
Chúng tôi chia việc khai thác lỗ hổng thành hai bước: kiểm soát giá trị cbwndextra và thực hiện nguyên lý đọc/ghi ổn định.
lần đầu ghi dữ liệu
Lỗi hệ thống sử dụng dữ liệu đối tượng cửa sổ bị kiểm soát trong bộ nhớ chủ yếu xảy ra trong các hàm xxxEnableMenuItem MNGetPopupFromMenu() và xxxMNUpdateShownMenu(). Chúng tôi sử dụng tên đối tượng cửa sổ của lớp cửa sổ WNDClass để chiếm dụng bộ nhớ của đối tượng menu đã được giải phóng.
Chìa khóa là tìm một cấu trúc địa chỉ có thể viết vào bất kỳ lúc nào, ngay cả khi chỉ có một byte. Cuối cùng, chúng tôi đã chọn phương án trong hàm xxxRedrawWindow, ghi vào cb-extra của HWNDClass thông qua thao tác AND 2.
 Bố trí bộ nhớ
Chúng tôi đã thiết kế bố cục bộ nhớ cho ba đối tượng HWND 0x250 byte liên tiếp, giải phóng đối tượng ở giữa và chiếm dụng bởi đố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 qua xxxRedrawWindow, menu của đối tượng HWND sau và đối tượng HWNDClass được sử dụng cho các phép đọc và ghi cuối cùng.
Chúng tôi cố gắng làm cho kích thước của đối tượng cửa sổ và đối tượng HWNDClass nhất quán, và thông qua địa chỉ của các handle hạt nhân bị rò rỉ để xác định chính xác xem sự sắp xếp của các đối tượng có đúng như mong đợi hay không.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + tầng vật lý Web3]###https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) đọc viết nguyên ngữ
Sử dụng GetMenuBarInfo###( để đọc nguyên bản tùy ý, sử dụng SetClassLongPtr)( để ghi nguyên bản tùy ý. Ngoài việc ghi TOKEN, tất cả các ghi khác đều sử dụng đối tượng lớp của đối tượng cửa sổ đầu tiên để thực hiện ghi dịch.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + mặt vật lý Web3])https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
Tóm tắt
Microsoft đang tái cấu trúc mã lõi 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 này tương đối đơn giản, chủ yếu dựa vào việc rò rỉ địa chỉ 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ũ vẫn sẽ tồn tại nguy cơ an ninh.
Việc phát hiện lỗ hổng này có thể nhờ vào việc kiểm tra độ phủ mã hoàn thiện hơn.
Đối với phát hiện khai thác lỗ hổng, ngoài việc chú ý đến các điểm quan trọng của hàm kích hoạt lỗ hổng, còn cần chú ý đến việc phát hiện các sự lệch dữ liệu bất thường trong bố cục bộ nhớ và đọc/ghi dữ liệu bổ sung của lớp cửa sổ.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ Web3 ở cả hệ thống + cấp độ vật lý])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
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
Đăng lại
Chia sẻ
Bình luận
0/400
MultiSigFailMaster
· 17giờ trước
win11 đã thắng mà không cần nỗ lực
Xem bản gốcTrả lời0
RunWithRugs
· 18giờ trước
May quá trong phòng máy chủ đều lắp đặt linux rồi~
Xem bản gốcTrả lời0
MevShadowranger
· 18giờ trước
Học mã nguồn giao thức WalletConnect trong ba năm, đam mê phát triển Bots MEV, tập trung vào khai thác điểm nóng Tài chính phi tập trung
Xin vui lòng bằng tiếng Trung, dựa trên danh tính tài khoản này, tạo một bình luận:
Các bạn vẫn đang dùng win sao? Chạy nút sớm đã đổi sang linux rồi.
Phân tích lỗ hổng nghiêm trọng của nhân Windows: Rủi ro tăng quyền hoặc đe dọa bảo mật tài sản mã hóa
Phân tích lỗ hổng nghiêm trọng của hệ thống Windows của Microsoft
Gần đây, bản vá bảo mật được Microsoft phát hành đã khắc phục một lỗ hổng nâng quyền trong nhân Windows đ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 hơn, không thể kích hoạt trên Windows 11. Những lỗ hổng kiểu này đã tồn tại từ lâu, bài viết này sẽ khám phá cách mà những kẻ tấn công vẫn tiếp tục khai thác những lỗ hổng này trong bối cảnh bảo mật hiện đang được tăng cường.
Phân tích này được thực hiện dựa trên môi trường Windows Server 2016.
Bối cảnh lỗ hổng
Đây là một lỗ hổng zero-day, chỉ những lỗ hổng hệ thống chưa được công khai và chưa được sửa chữa. Hacker có thể khai thác lỗ hổng zero-day để tấn công mà người dùng không hề hay biết, mang lại sự phá hoại rất lớn.
Lỗ hổng zero-day được phát hiện lần này tồn tại ở cấp độ kernel của hệ thống Windows, kẻ tấn công có thể thông qua lỗ hổng này để chiếm quyền kiểm soát hoàn toàn Windows. Điều này có thể dẫn đến việc lộ thông tin cá nhân của người dùng, hệ thống 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. Từ góc độ Web3, khóa riêng của người dùng có thể bị đánh cắp, tài sản kỹ thuật số có nguy cơ bị chuyển nhượng. Ở một phạm vi lớn 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 dựa trên cơ sở hạ tầng Web2.
Phân tích lỗ hổng
Phân tích mã vá, chúng tôi phát hiện vấn đề nằm ở việc tham chiếu đến một đối tượng đã được xử lý nhiều lần. Xem xét các chú thích trong mã nguồn win32k trước đó, 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 đố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.
Phân tích thêm cho thấy, menu được truyền vào hàm xxxEnableMenuItem() thường đã được khóa trong hàm cấp trên, vậy ở đây thực sự cần bảo vệ đối tượng menu nào? Qua nghiên cứu, hàm MenuItemState trong xxxEnableMenuItem 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 của menu con ).
Khai thác lỗ hổng
Để xác minh lỗ hổng, chúng tôi đã xây dựng một cấu trúc menu bốn tầng đặc biệt và đặt ra một số điều kiện cụ thể:
Khi kích hoạt lỗ hổng, xóa liên kết giữa menu C và B khi xxxRedrawTitle trả về lớp người dùng, giải phóng thành công menu C. Khi hàm xxxEnableMenuItem trong nhân trả về xxxRedrawTitle, đối tượng menu C mà sắp được tham chiếu đã không còn hiệu lực.
Phân tích khai thác lỗ hổng
Trong việc thiết kế kế hoạch khai thác lỗ hổng, chúng tôi chủ yếu xem xét hai hướng:
Thực thi shellcode: Tham khảo các phương pháp từ CVE-2017-0263 và CVE-2016-0167 trước đây. Nhưng trong các phiên bản Windows cao hơn, điểm vào thực thi shellcode và các cơ chế bảo mật như SMEP có thể gặp trở ngại.
Sử dụng nguyên tử đọc ghi để sửa đổi địa chỉ token: Phương pháp này có độ phổ quát tốt hơn. Chìa khóa là phân tích cách lần đầu tiên kiểm soát cbwndextra thành giá trị cực lớn trong quá trình tái sử dụng bộ nhớ UAF.
Chúng tôi chia việc khai thác lỗ hổng thành hai bước: kiểm soát giá trị cbwndextra và thực hiện nguyên lý đọc/ghi ổn định.
lần đầu ghi dữ liệu
Lỗi hệ thống sử dụng dữ liệu đối tượng cửa sổ bị kiểm soát trong bộ nhớ chủ yếu xảy ra trong các hàm xxxEnableMenuItem MNGetPopupFromMenu() và xxxMNUpdateShownMenu(). Chúng tôi sử dụng tên đối tượng cửa sổ của lớp cửa sổ WNDClass để chiếm dụng bộ nhớ của đối tượng menu đã được giải phóng.
Chìa khóa là tìm một cấu trúc địa chỉ có thể viết vào bất kỳ lúc nào, ngay cả khi chỉ có một byte. Cuối cùng, chúng tôi đã chọn phương án trong hàm xxxRedrawWindow, ghi vào cb-extra của HWNDClass thông qua thao tác AND 2.
 Bố trí bộ nhớ
Chúng tôi đã thiết kế bố cục bộ nhớ cho ba đối tượng HWND 0x250 byte liên tiếp, giải phóng đối tượng ở giữa và chiếm dụng bởi đố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 qua xxxRedrawWindow, menu của đối tượng HWND sau và đối tượng HWNDClass được sử dụng cho các phép đọc và ghi cuối cùng.
Chúng tôi cố gắng làm cho kích thước của đối tượng cửa sổ và đối tượng HWNDClass nhất quán, và thông qua địa chỉ của các handle hạt nhân bị rò rỉ để xác định chính xác xem sự sắp xếp của các đối tượng có đúng như mong đợi hay không.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + tầng vật lý Web3]###https://img-cdn.gateio.im/webp-social/moments-697c5814db02534f63b44c0d1d692f83.webp(
) đọc viết nguyên ngữ
Sử dụng GetMenuBarInfo###( để đọc nguyên bản tùy ý, sử dụng SetClassLongPtr)( để ghi nguyên bản tùy ý. Ngoài việc ghi TOKEN, tất cả các ghi khác đều sử dụng đối tượng lớp của đối tượng cửa sổ đầu tiên để thực hiện ghi dịch.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ hệ thống + mặt vật lý Web3])https://img-cdn.gateio.im/webp-social/moments-b0942592135ac96c6279544a62022329.webp(
Tóm tắt
Microsoft đang tái cấu trúc mã lõi 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 này tương đối đơn giản, chủ yếu dựa vào việc rò rỉ địa chỉ 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ũ vẫn sẽ tồn tại nguy cơ an ninh.
Việc phát hiện lỗ hổng này có thể nhờ vào việc kiểm tra độ phủ mã hoàn thiện hơn.
Đối với phát hiện khai thác lỗ hổng, ngoài việc chú ý đến các điểm quan trọng của hàm kích hoạt lỗ hổng, còn cần chú ý đến việc phát hiện các sự lệch dữ liệu bất thường trong bố cục bộ nhớ và đọc/ghi dữ liệu bổ sung của lớp cửa sổ.
![Numen độc quyền: Lỗ hổng 0day của Microsoft có thể lật đổ Web3 ở cả hệ thống + cấp độ vật lý])https://img-cdn.gateio.im/webp-social/moments-b06b098af4f07260fdc03a75da160706.webp(
Xin vui lòng bằng tiếng Trung, dựa trên danh tính tài khoản này, tạo một bình luận:
Các bạn vẫn đang dùng win sao? Chạy nút sớm đã đổi sang linux rồi.