Phân tích lỗ hổng zero-day của hệ thống Windows của Microsoft: Có thể gây ảnh hưởng lớn đến hệ sinh thái Web3
Vào tháng trước, bản cập nhật bảo mật của Microsoft đã sửa một lỗ hổng nâng quyền trong nhân Windows đang bị khai thác một cách độc hại. Lỗ hổng này chủ yếu ảnh hưởng đến các phiên bản Windows cũ hơn, 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 có thể tiếp tục khai thác các lỗ hổng kiểu này trong bối cảnh các biện pháp bảo vệ an ninh đang ngày càng được củng cố.
Chúng tôi đã hoàn thành toàn bộ công việc phân tích trong môi trường Windows Server 2016.
Lỗ hổng zero-day là những lỗ hổng hệ thống chưa được phát hiện và 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 bị khai thác một cách ác ý, các lỗ hổng zero-day thường gây ra thiệt hại lớn. Lỗ hổng zero-day được phát hiện lần này trên hệ điều hành Windows cho phép kẻ tấn công có được quyền kiểm soát hoàn toàn hệ thống.
Hậu quả của việc bị hệ thống bị tấn công là rất nghiêm trọng, bao gồm nhưng không giới hạn ở việc rò rỉ thông tin cá nhân, mất dữ liệu do hệ thống bị sập, tổn thất tài sản, cài đặt phần mềm độc hại, v.v. Đối với người dùng cá nhân, điều này có thể dẫn đến việc khóa riêng tư của tiền điện tử bị đánh cắp, tài sản kỹ thuật số bị chuyển nhượng; từ mộ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 cơ sở hạ tầng Web2.
Phân tích bản vá
Phân tích bản vá, chúng tôi phát hiện ra rằng vấn đề dường như chỉ là một đối tượng bị xử lý quá nhiều lần trong việc đếm tham chiếu. Do win32k là mã nguồn từ sớm, chúng tôi có thể tìm thấy một số chú thích mã nguồn sớm cho thấy mã trước đó 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.
Chứng minh khái niệm khai thác lỗ hổng ( PoC ) thực hiện
Phân tích ngữ cảnh hàm lỗ hổng, chúng tôi phát hiện ra rằng menu được truyền vào xxxEnableMenuItem() thường đã được khóa trong hàm cấp trên, vậy thì thực sự ở đây cần bảo vệ đối tượng menu nào?
Phân tích sâu hơn về quá trình xử lý đối tượng menu trong xxxEnableMenuItem, chúng tôi phát hiện ra rằng hàm MenuItemState trả về hai khả năng menu: menu chính của cửa sổ, hoặc menu con của menu ( thậm chí là menu con của menu con ).
Trong PoC, chúng tôi đã xây dựng một cấu trúc menu bốn lớp đặc biệt, trong đó các menu liền kề có quan hệ cha con. Những menu này có một số đặc điểm cụ thể để được phát hiện và xác định thông qua hàm xxxEnableMenuItem.
Khi xxxRedrawTitle trả về lớp người dùng, chúng tôi đã xóa mối quan hệ tham chiếu của menu C và menu 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 mà sẽ được tham chiếu đã không còn hợp lệ.
Khai thác lỗ hổng ( Exploit ) thực hiện
Trước khi xác định phương pháp khai thác, chúng tôi thường thực hiện một số đánh giá lý thuyết ban đầu để 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 mã shellcode: tham khảo CVE-2017-0263 và CVE-2016-0167 từ sớm. Tuy nhiên, trong các phiên bản Windows cao hơn, phương pháp này có thể gặp phải một số vấn đề khó giải quyết.
Sử dụng nguyên thủy đọc/ghi để sửa đổi địa chỉ token: Trong những năm gần đây đã có các phương pháp công khai để tham khảo. Bố cục bộ nhớ ngăn xếp trên máy tính để bàn và nguyên thủy đọc/ghi có tính phổ quát lâu dài. Chúng ta chủ yếu cần phân tích cách kiểm soát cbwndextra lần đầu tiên là giá trị cực lớn khi bộ nhớ UAF được tái sử dụng.
Chúng tôi chia toàn bộ quá trình khai thác thành hai vấn đề: làm thế nào để khai thác lỗ hổng UAF để kiểm soát giá trị cbwndextra, và sau khi kiểm soát giá trị cbwndextra, làm thế nào để thực hiện các nguyên thủy đọc/ghi ổn định.
Cuối cùng, chúng tôi đã chọn ghi vào cb-extra của HWNDClass thông qua thao tác AND 2 của cờ trong hàm xxxRedrawWindow. Điều này là do độ lệch cb-extra của HWNDClass khá nhỏ, chúng tôi có thể kiểm soát dữ liệu bộ nhớ của đối tượng trước đó thông qua bố trí bộ nhớ, từ đó thực hiện việc xác định cờ của đối tượng 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 có kích thước liên tiếp 0x250 byte. Sau khi giải phóng đối tượng ở giữa, một đối tượng HWNDClass kích thước 0x250 byte sẽ chiếm vị trí đó. Dữ liệu đuôi của đối tượng HWND trước được sử dụng để kiểm tra bằng cờ của xxxRedrawWindow, trong khi đối tượng menu của đối tượng HWND tiếp theo và đối tượng HWNDClass được sử dụng làm phương tiện cho các nguyên tử đọc và ghi cuối cùng.
Chúng tôi cố gắng giữ cho kích thước của đối tượng cửa sổ và đối tượng HWNDClass nhất quán, và đảm bảo rằng dữ liệu mở rộng của đối tượng cửa sổ đủ lớn. Bằng cách sử dụng đị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 sắp xếp theo thứ tự như mong đợi hay chưa.
Trong việc đọc và ghi nguyên mẫu, chúng tôi sử dụng GetMenuBarInfo() để thực hiện đọc tùy ý, sử dụng SetClassLongPtr() để thực hiện ghi tùy ý. Ngoài việc thay thế hoạt động ghi của TOKEN phụ thuộc vào đối tượng class của cửa sổ thứ hai, các hoạt động ghi khác đều sử dụng đối tượng class của cửa sổ đầu tiên thông qua độ lệch để thực hiện.
Tóm tắt
Tình trạng win32k: Microsoft đang cố gắng sử dụng Rust để tái cấu trúc mã nhân liên quan trong phiên bản xem trước Windows 11, hệ thống mới trong tương lai có thể loại bỏ các lỗ hổng như vậy.
Quá trình khai thác lỗ hổng tương đối đơn giản: Ngoài việc cần cẩn thận thử nghiệm cách kiểm soát lần ghi đầu tiên, cơ bản không cần sử dụng công nghệ khai thác mới. Loại lỗ hổng này nghiêm trọng phụ thuộc vào việc rò rỉ địa chỉ của các tay cầm ngăn xếp trên desktop.
Phát hiện lỗ hổng: Dự đoán có thể phụ thuộc vào việc kiểm tra độ phủ mã hoàn thiện hơn. Khi API của hệ thống có thể đạt đế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ổ đang ở trạng thái tham chiếu lồng ghép nhiều lần, thì lỗ hổng đó có thể được phát hiện qua thử nghiệm mờ.
Các phương pháp phát hiện khác: Ngoài việc phát hiện các điểm quan trọng của hàm kích hoạt lỗ hổng, việc phát hiện các bố trí bộ nhớ không phổ biến và việc đọc/ghi các độ lệch bất thường của dữ liệu bổ sung trong cửa sổ hoặc lớp cửa sổ cũng có thể là một trong những cách phát hiện lỗ hổng tương tự.
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.
12 thích
Phần thưởng
12
2
Chia sẻ
Bình luận
0/400
AltcoinHunter
· 19giờ trước
Nhìn thấu mà không nói ra, đồ ngốc trong thế giới tiền điện tử.
Phân tích lỗ hổng zero-day trên Windows: Hệ sinh thái Web3 có thể bị ảnh hưởng nghiêm trọng
Phân tích lỗ hổng zero-day của hệ thống Windows của Microsoft: Có thể gây ảnh hưởng lớn đến hệ sinh thái Web3
Vào tháng trước, bản cập nhật bảo mật của Microsoft đã sửa một lỗ hổng nâng quyền trong nhân Windows đang bị khai thác một cách độc hại. Lỗ hổng này chủ yếu ảnh hưởng đến các phiên bản Windows cũ hơn, 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 có thể tiếp tục khai thác các lỗ hổng kiểu này trong bối cảnh các biện pháp bảo vệ an ninh đang ngày càng được củng cố.
Chúng tôi đã hoàn thành toàn bộ công việc phân tích trong môi trường Windows Server 2016.
Lỗ hổng zero-day là những lỗ hổng hệ thống chưa được phát hiện và 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 bị khai thác một cách ác ý, các lỗ hổng zero-day thường gây ra thiệt hại lớn. Lỗ hổng zero-day được phát hiện lần này trên hệ điều hành Windows cho phép kẻ tấn công có được quyền kiểm soát hoàn toàn hệ thống.
Hậu quả của việc bị hệ thống bị tấn công là rất nghiêm trọng, bao gồm nhưng không giới hạn ở việc rò rỉ thông tin cá nhân, mất dữ liệu do hệ thống bị sập, tổn thất tài sản, cài đặt phần mềm độc hại, v.v. Đối với người dùng cá nhân, điều này có thể dẫn đến việc khóa riêng tư của tiền điện tử bị đánh cắp, tài sản kỹ thuật số bị chuyển nhượng; từ mộ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 cơ sở hạ tầng Web2.
Phân tích bản vá
Phân tích bản vá, chúng tôi phát hiện ra rằng vấn đề dường như chỉ là một đối tượng bị xử lý quá nhiều lần trong việc đếm tham chiếu. Do win32k là mã nguồn từ sớm, chúng tôi có thể tìm thấy một số chú thích mã nguồn sớm cho thấy mã trước đó 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.
Chứng minh khái niệm khai thác lỗ hổng ( PoC ) thực hiện
Phân tích ngữ cảnh hàm lỗ hổng, chúng tôi phát hiện ra rằng menu được truyền vào xxxEnableMenuItem() thường đã được khóa trong hàm cấp trên, vậy thì thực sự ở đây cần bảo vệ đối tượng menu nào?
Phân tích sâu hơn về quá trình xử lý đối tượng menu trong xxxEnableMenuItem, chúng tôi phát hiện ra rằng hàm MenuItemState trả về hai khả năng menu: menu chính của cửa sổ, hoặc menu con của menu ( thậm chí là menu con của menu con ).
Trong PoC, chúng tôi đã xây dựng một cấu trúc menu bốn lớp đặc biệt, trong đó các menu liền kề có quan hệ cha con. Những menu này có một số đặc điểm cụ thể để được phát hiện và xác định thông qua hàm xxxEnableMenuItem.
Khi xxxRedrawTitle trả về lớp người dùng, chúng tôi đã xóa mối quan hệ tham chiếu của menu C và menu 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 mà sẽ được tham chiếu đã không còn hợp lệ.
Khai thác lỗ hổng ( Exploit ) thực hiện
Trước khi xác định phương pháp khai thác, chúng tôi thường thực hiện một số đánh giá lý thuyết ban đầu để 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 mã shellcode: tham khảo CVE-2017-0263 và CVE-2016-0167 từ sớm. Tuy nhiên, trong các phiên bản Windows cao hơn, phương pháp này có thể gặp phải một số vấn đề khó giải quyết.
Sử dụng nguyên thủy đọc/ghi để sửa đổi địa chỉ token: Trong những năm gần đây đã có các phương pháp công khai để tham khảo. Bố cục bộ nhớ ngăn xếp trên máy tính để bàn và nguyên thủy đọc/ghi có tính phổ quát lâu dài. Chúng ta chủ yếu cần phân tích cách kiểm soát cbwndextra lần đầu tiên là giá trị cực lớn khi bộ nhớ UAF được tái sử dụng.
Chúng tôi chia toàn bộ quá trình khai thác thành hai vấn đề: làm thế nào để khai thác lỗ hổng UAF để kiểm soát giá trị cbwndextra, và sau khi kiểm soát giá trị cbwndextra, làm thế nào để thực hiện các nguyên thủy đọc/ghi ổn định.
Cuối cùng, chúng tôi đã chọn ghi vào cb-extra của HWNDClass thông qua thao tác AND 2 của cờ trong hàm xxxRedrawWindow. Điều này là do độ lệch cb-extra của HWNDClass khá nhỏ, chúng tôi có thể kiểm soát dữ liệu bộ nhớ của đối tượng trước đó thông qua bố trí bộ nhớ, từ đó thực hiện việc xác định cờ của đối tượng 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 có kích thước liên tiếp 0x250 byte. Sau khi giải phóng đối tượng ở giữa, một đối tượng HWNDClass kích thước 0x250 byte sẽ chiếm vị trí đó. Dữ liệu đuôi của đối tượng HWND trước được sử dụng để kiểm tra bằng cờ của xxxRedrawWindow, trong khi đối tượng menu của đối tượng HWND tiếp theo và đối tượng HWNDClass được sử dụng làm phương tiện cho các nguyên tử đọc và ghi cuối cùng.
Chúng tôi cố gắng giữ cho kích thước của đối tượng cửa sổ và đối tượng HWNDClass nhất quán, và đảm bảo rằng dữ liệu mở rộng của đối tượng cửa sổ đủ lớn. Bằng cách sử dụng đị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 sắp xếp theo thứ tự như mong đợi hay chưa.
Trong việc đọc và ghi nguyên mẫu, chúng tôi sử dụng GetMenuBarInfo() để thực hiện đọc tùy ý, sử dụng SetClassLongPtr() để thực hiện ghi tùy ý. Ngoài việc thay thế hoạt động ghi của TOKEN phụ thuộc vào đối tượng class của cửa sổ thứ hai, các hoạt động ghi khác đều sử dụng đối tượng class của cửa sổ đầu tiên thông qua độ lệch để thực hiện.
Tóm tắt
Tình trạng win32k: Microsoft đang cố gắng sử dụng Rust để tái cấu trúc mã nhân liên quan trong phiên bản xem trước Windows 11, hệ thống mới trong tương lai có thể loại bỏ các lỗ hổng như vậy.
Quá trình khai thác lỗ hổng tương đối đơn giản: Ngoài việc cần cẩn thận thử nghiệm cách kiểm soát lần ghi đầu tiên, cơ bản không cần sử dụng công nghệ khai thác mới. Loại lỗ hổng này nghiêm trọng phụ thuộc vào việc rò rỉ địa chỉ của các tay cầm ngăn xếp trên desktop.
Phát hiện lỗ hổng: Dự đoán có thể phụ thuộc vào việc kiểm tra độ phủ mã hoàn thiện hơn. Khi API của hệ thống có thể đạt đế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ổ đang ở trạng thái tham chiếu lồng ghép nhiều lần, thì lỗ hổng đó có thể được phát hiện qua thử nghiệm mờ.
Các phương pháp phát hiện khác: Ngoài việc phát hiện các điểm quan trọng của hàm kích hoạt lỗ hổng, việc phát hiện các bố trí bộ nhớ không phổ biến và việc đọc/ghi các độ lệch bất thường của dữ liệu bổ sung trong cửa sổ hoặc lớp cửa sổ cũng có thể là một trong những cách phát hiện lỗ hổng tương tự.