Phân tích và khai thác lỗ hổng 0day của hệ thống Windows của Microsoft
Gần đây, bản vá bảo mật mà Microsoft phát hành chứa một lỗ hổng nâng quyền win32k đang bị khai thác. Lỗ hổng này chủ yếu tồn tại trong các phiên bản hệ thống Windows sớm, 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 các lỗ hổng loại này trong bối cảnh bảo vệ an ninh ngày càng được củng cố. Quá trình phân tích của chúng tôi được thực hiện trong môi trường Windows Server 2016.
Bối cảnh lỗ hổng
Lỗ hổng 0day 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ị phát hiện có thể bị lợi dụng một cách âm thầm, 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 kiểm soát hoàn toàn hệ thống. Điều này có thể dẫn đến việc rò rỉ thông tin cá nhân, sập hệ thống, mất dữ liệu, tổn thất 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ố bị chuyển nhượng. Trong một phạm vi lớn hơn, lỗ hổng này có thể ảnh hưởng đến toàn bộ hệ sinh thái Web3 hoạt động trên cơ sở hạ tầng Web2.
Phân tích lỗ hổng
Thông qua việc phân tích mã vá, chúng tôi phát hiện đây là một vấn đề liên quan đến lỗi đếm tham chiếu đối tượng. Các chú thích trong mã win32k trước đây cho thấy, chỉ có đối tượng cửa sổ được khóa, mà không có đối tượng menu trong cửa sổ được khóa, điều này có thể dẫn đến việc đối tượng menu bị tham chiếu sai.
Phân tích sâu hơn cho thấy, trong hàm xxxEnableMenuItem, đối tượng menu trả về có thể là menu chính của cửa sổ, cũng có thể là menu con hoặc thậm chí là menu sâu hơn. Điều này cung cấp ý tưởng cho việc xây dựng POC.
Thực hiện POC
Chúng tôi đã xây dựng một cấu trúc menu đa lớp đặc biệt, bao gồm bốn đối tượng menu có mối quan hệ cụ thể. Bằng cách cài đặt cẩn thận các thuộc tính và mối quan hệ của những menu này, có thể vượt qua việc kiểm tra hàm xxxEnableMenuItem và giải phóng các đối tượng menu quan trọng khi hàm trả về. Như vậy, khi tham chiếu đối tượng đó sau này sẽ kích hoạt lỗ hổng UAF.
Khai thác lỗ hổng (EXP)
Tổng thể tư duy
Chúng tôi đã xem xét hai cách khai thác: thực thi shellcode và khai thác các nguyên thủy đọc ghi để sửa đổi token. Cuối cùng, chúng tôi đã chọn cách thứ hai, vì nó khả thi hơn trên các phiên bản Windows cao hơn. Chúng tôi chia toàn bộ quá trình khai thác thành hai bước: cách kiểm soát giá trị cbwndextra thông qua UAF, và cách sử dụng cbwndextra đã được kiểm soát để thực hiện các nguyên thủy đọc ghi ổn định.
ghi dữ liệu ban đầu
Chúng tôi sử dụng đối tượng tên 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. Thông qua việc phân tích các điểm ghi khác nhau, cuối cùng chúng tôi đã chọn ghi giá trị cb-extra của HWNDClass bằng cách sử dụng phép AND trên cờ của đối tượng trong hàm xxxRedrawWindow.
bố cục bộ nhớ
Chúng tôi đã thiết kế một cấu trúc bộ nhớ bao gồm ba đối tượng HWND liên tiếp, đối tượng ở giữa bị giải phóng và được đối tượng HWNDClass chiếm giữ. Các đối tượng HWND ở phía trước và phía sau lần lượt được sử dụng để vượt qua việc phát hiện và thực hiện các nguyên tử đọc và ghi cuối cùng. Thông qua địa chỉ của các handle kernel bị rò rỉ, chúng tôi có thể kiểm soát chính xác sự sắp xếp của các đối tượng này.
thực hiện đọc viết nguyên ngữ
Các thao tác đọc tùy ý sử dụng hàm GetMenuBarInfo, trong khi các thao tác ghi tùy ý sử dụng hàm SetClassLongPtr. Ngoài việc ghi TOKEN phụ thuộc vào đối tượng lớp của cửa sổ thứ hai, các thao tác ghi khác đều sử dụng đối tượng lớp của cửa sổ đầu tiên thông qua độ lệch để thực hiện.
Tóm tắt
Microsoft đang cố gắng sử dụng Rust để tái cấu trúc mã win32k, trong tương lai các lỗ hổng như vậy có thể được giải quyết triệt để trong hệ thống mới.
Quá trình khai thác loại 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 dữ liệu đầu tiên.
Việc phát hiện lỗ hổng có thể nhờ vào công nghệ kiểm tra độ bao phủ mã hoàn thiện hơn.
Đối với việc phát hiện lỗ hổng, ngoài việc chú ý đến các điểm quan trọng của hàm kích hoạt, cũng cần kiểm tra cấu trúc bộ nhớ bất thường và các thao tác đọ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.
7 thích
Phần thưởng
7
6
Chia sẻ
Bình luận
0/400
DeFiGrayling
· 11giờ trước
Microsoft lần này thực sự đã chơi lớn -_-
Xem bản gốcTrả lời0
HackerWhoCares
· 11giờ trước
Không có gì lạ khi máy tính của tôi chậm như vậy!
Xem bản gốcTrả lời0
ResearchChadButBroke
· 11giờ trước
Lần này Microsoft đã chết chắc rồi.
Xem bản gốcTrả lời0
GasWrangler
· 11giờ trước
nói một cách kỹ thuật, lỗi bố trí bộ nhớ này là kém tối ưu af
Lỗ hổng 0day trên hệ thống Windows gây ra mối đe dọa an ninh cho Web3, các chuyên gia phân tích quy trình khai thác.
Phân tích và khai thác lỗ hổng 0day của hệ thống Windows của Microsoft
Gần đây, bản vá bảo mật mà Microsoft phát hành chứa một lỗ hổng nâng quyền win32k đang bị khai thác. Lỗ hổng này chủ yếu tồn tại trong các phiên bản hệ thống Windows sớm, 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 các lỗ hổng loại này trong bối cảnh bảo vệ an ninh ngày càng được củng cố. Quá trình phân tích của chúng tôi được thực hiện trong môi trường Windows Server 2016.
Bối cảnh lỗ hổng
Lỗ hổng 0day 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ị phát hiện có thể bị lợi dụng một cách âm thầm, 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 kiểm soát hoàn toàn hệ thống. Điều này có thể dẫn đến việc rò rỉ thông tin cá nhân, sập hệ thống, mất dữ liệu, tổn thất 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ố bị chuyển nhượng. Trong một phạm vi lớn hơn, lỗ hổng này có thể ảnh hưởng đến toàn bộ hệ sinh thái Web3 hoạt động trên cơ sở hạ tầng Web2.
Phân tích lỗ hổng
Thông qua việc phân tích mã vá, chúng tôi phát hiện đây là một vấn đề liên quan đến lỗi đếm tham chiếu đối tượng. Các chú thích trong mã win32k trước đây cho thấy, chỉ có đối tượng cửa sổ được khóa, mà không có đối tượng menu trong cửa sổ được khóa, điều này có thể dẫn đến việc đối tượng menu bị tham chiếu sai.
Phân tích sâu hơn cho thấy, trong hàm xxxEnableMenuItem, đối tượng menu trả về có thể là menu chính của cửa sổ, cũng có thể là menu con hoặc thậm chí là menu sâu hơn. Điều này cung cấp ý tưởng cho việc xây dựng POC.
Thực hiện POC
Chúng tôi đã xây dựng một cấu trúc menu đa lớp đặc biệt, bao gồm bốn đối tượng menu có mối quan hệ cụ thể. Bằng cách cài đặt cẩn thận các thuộc tính và mối quan hệ của những menu này, có thể vượt qua việc kiểm tra hàm xxxEnableMenuItem và giải phóng các đối tượng menu quan trọng khi hàm trả về. Như vậy, khi tham chiếu đối tượng đó sau này sẽ kích hoạt lỗ hổng UAF.
Khai thác lỗ hổng (EXP)
Tổng thể tư duy
Chúng tôi đã xem xét hai cách khai thác: thực thi shellcode và khai thác các nguyên thủy đọc ghi để sửa đổi token. Cuối cùng, chúng tôi đã chọn cách thứ hai, vì nó khả thi hơn trên các phiên bản Windows cao hơn. Chúng tôi chia toàn bộ quá trình khai thác thành hai bước: cách kiểm soát giá trị cbwndextra thông qua UAF, và cách sử dụng cbwndextra đã được kiểm soát để thực hiện các nguyên thủy đọc ghi ổn định.
ghi dữ liệu ban đầu
Chúng tôi sử dụng đối tượng tên 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. Thông qua việc phân tích các điểm ghi khác nhau, cuối cùng chúng tôi đã chọn ghi giá trị cb-extra của HWNDClass bằng cách sử dụng phép AND trên cờ của đối tượng trong hàm xxxRedrawWindow.
bố cục bộ nhớ
Chúng tôi đã thiết kế một cấu trúc bộ nhớ bao gồm ba đối tượng HWND liên tiếp, đối tượng ở giữa bị giải phóng và được đối tượng HWNDClass chiếm giữ. Các đối tượng HWND ở phía trước và phía sau lần lượt được sử dụng để vượt qua việc phát hiện và thực hiện các nguyên tử đọc và ghi cuối cùng. Thông qua địa chỉ của các handle kernel bị rò rỉ, chúng tôi có thể kiểm soát chính xác sự sắp xếp của các đối tượng này.
thực hiện đọc viết nguyên ngữ
Các thao tác đọc tùy ý sử dụng hàm GetMenuBarInfo, trong khi các thao tác ghi tùy ý sử dụng hàm SetClassLongPtr. Ngoài việc ghi TOKEN phụ thuộc vào đối tượng lớp của cửa sổ thứ hai, các thao tác ghi khác đều sử dụng đối tượng lớp của cửa sổ đầu tiên thông qua độ lệch để thực hiện.
Tóm tắt
Microsoft đang cố gắng sử dụng Rust để tái cấu trúc mã win32k, trong tương lai các lỗ hổng như vậy có thể được giải quyết triệt để trong hệ thống mới.
Quá trình khai thác loại 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 dữ liệu đầu tiên.
Việc phát hiện lỗ hổng có thể nhờ vào công nghệ kiểm tra độ bao phủ mã hoàn thiện hơn.
Đối với việc phát hiện lỗ hổng, ngoài việc chú ý đến các điểm quan trọng của hàm kích hoạt, cũng cần kiểm tra cấu trúc bộ nhớ bất thường và các thao tác đọc ghi dữ liệu.