Phân tích lỗ hổng 0day của Microsoft: Có thể đe dọa an ninh cơ sở hạ tầng Web3
Trong bản vá bảo mật của Microsoft vào tháng trước có chứa một lỗ hổng nâng quyền win32k đang được khai thác. Lỗ hổng này dường như chỉ tồn tại trên các phiên bản hệ thống sớm hơn và không thể kích hoạt trên Windows 11. Việc khai thác các lỗ hổng kiểu này đã tồn tại từ lâu, 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 lỗ hổng này trong bối cảnh các biện pháp giảm thiểu mới đang không ngừng cải thiện. Chúng tôi đã hoàn thành toàn bộ quá trình phân tích trong môi trường Windows Server 2016.
Lỗi 0day là lỗi chưa được công bố và sửa chữa, có thể bị hacker khai thác một cách ác ý mà không bị phát hiện, thường gây ra thiệt hại lớn. Lỗi 0day mới được phát hiện nằm ở cấp độ hệ thống Windows, hacker có thể thông qua đó chiếm quyền kiểm soát hoàn toàn Windows. Khi bị kiểm soát, điều này có thể dẫn đến việc đánh cắp thông tin cá nhân, hệ thống bị sập, mất dữ liệu, thiệt hại tài chính, cài đặt phần mềm độc hại, và nhiều hậu quả khác. Trong phạm vi nhỏ có thể dẫn đến việc bị đánh cắp khóa riêng, tài sản kỹ thuật số bị chuyển giao; trong phạm vi lớn có thể gây nguy hiểm cho 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 bản vá cho thấy, dường như đây chỉ là một vấn đề liên quan đến việc đếm tham chiếu đối tượng bị xử lý nhiều lần. Nhưng khi xem xét các chú thích mã nguồn trước đây, phát hiện ra 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 tham chiếu sai đối tượng menu.
Phân tích ngữ cảnh của hàm lỗ hổng, chúng tôi phát hiện rằng menu được truyền vào xxxEnableMenuItem() thường đã bị khóa trong hàm cấp trên, vậy chúng ta thực sự cần bảo vệ đối tượng menu nào? Phân tích sâu hơn cho thấy, menu trả về trong xxxEnableMenuItem có hai khả năng: 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).
Để xây dựng POC, chúng tôi đã thiết kế một cấu trúc menu bốn tầng đặc biệt và thực hiện các cài đặt đặc biệt cho từng menu để phát hiện qua chức năng. 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. 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 hợp lệ.
Đối với việc thực hiện EXP, chúng tôi chủ yếu xem xét hai hướng: thực thi mã shellcode và sử dụng các nguyên lý đọc/ghi để thay đổi địa chỉ token. Cân nhắc đến cơ chế bảo mật của Windows phiên bản cao, chúng tôi đã chọn hướng thứ hai. Toàn bộ quá trình khai thác có thể được chia thành hai phần: cách khai thác lỗ hổng UAF để kiểm soát giá trị cbwndextra, và cách thiết lập các nguyên lý đọc/ghi ổn định.
Chúng tôi đã thiết kế một cách cẩn thận bố cục bộ nhớ, sử dụng đối tượng tên cửa sổ của lớp cửa sổ để chiếm dụng và giải phóng các đối tượng menu, và đã tìm thấy thời điểm có thể ghi dữ liệu trong hàm xxxRedrawWindow. Để đạt được bố cục bộ nhớ ổn định, chúng tôi đã thiết kế cấu trúc gồm ba đối tượng HWND liên tiếp và sử dụng địa chỉ của các handle kernel bị rò rỉ trong bộ nhớ heap để xác định chính xác thứ tự sắp xếp của các đối tượng.
Trong việc đọc và ghi nguyên thủy, chúng tôi sử dụng GetMenuBarInfo() để thực hiện đọc tùy ý, SetClassLongPtr() để thực hiện ghi tùy ý. Ngoài việc thay thế thao tá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 sự dịch chuyển.
Tổng thể mà nói, mặc dù lỗ hổng win32k có lịch sử lâu đời, nhưng Microsoft đã cố gắng tái cấu trúc phần mã nhân này bằng Rust trong phiên bản xem trước của Windows 11, có thể trong tương lai các lỗ hổng như vậy sẽ được loại bỏ. Quy trình khai thác lỗ hổng lần này tương đối đơn giản, khó khăn chủ yếu nằm ở việc kiểm soát việc ghi lần đầu tiên. Việc phát hiện lỗ hổng này có thể phụ thuộc vào việc kiểm tra độ phủ mã hoàn chỉnh 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, việc kiểm tra bố cục bộ nhớ bất thường và việc đọc ghi dữ liệu lệch cũng là những phương pháp khả thi để phát hiện những lỗ hổng tương tự.
Xem bản gốc
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.
16 thích
Phần thưởng
16
5
Chia sẻ
Bình luận
0/400
TopBuyerBottomSeller
· 07-21 07:25
Lại một lý do nữa để nâng cấp lên Windows 11~
Xem bản gốcTrả lời0
FlatTax
· 07-20 03:35
Scandal, đừng có giở trò nữa, Microsoft cũ.
Xem bản gốcTrả lời0
SurvivorshipBias
· 07-20 03:34
Hệ thống của ai còn sử dụng win32k vậy?
Xem bản gốcTrả lời0
just_another_wallet
· 07-20 03:33
Suýt nữa thì nổ tung đồng coin của tôi, nhìn thấy mà da đầu tê dại.
Xem bản gốcTrả lời0
MrRightClick
· 07-20 03:14
Phiên bản hệ thống mà ngay cả chó cũng không thèm nhìn - windows11
Lỗ hổng 0day của Microsoft bị lộ, an ninh cơ sở hạ tầng Web3 có thể bị đe dọa
Phân tích lỗ hổng 0day của Microsoft: Có thể đe dọa an ninh cơ sở hạ tầng Web3
Trong bản vá bảo mật của Microsoft vào tháng trước có chứa một lỗ hổng nâng quyền win32k đang được khai thác. Lỗ hổng này dường như chỉ tồn tại trên các phiên bản hệ thống sớm hơn và không thể kích hoạt trên Windows 11. Việc khai thác các lỗ hổng kiểu này đã tồn tại từ lâu, 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 lỗ hổng này trong bối cảnh các biện pháp giảm thiểu mới đang không ngừng cải thiện. Chúng tôi đã hoàn thành toàn bộ quá trình phân tích trong môi trường Windows Server 2016.
Lỗi 0day là lỗi chưa được công bố và sửa chữa, có thể bị hacker khai thác một cách ác ý mà không bị phát hiện, thường gây ra thiệt hại lớn. Lỗi 0day mới được phát hiện nằm ở cấp độ hệ thống Windows, hacker có thể thông qua đó chiếm quyền kiểm soát hoàn toàn Windows. Khi bị kiểm soát, điều này có thể dẫn đến việc đánh cắp thông tin cá nhân, hệ thống bị sập, mất dữ liệu, thiệt hại tài chính, cài đặt phần mềm độc hại, và nhiều hậu quả khác. Trong phạm vi nhỏ có thể dẫn đến việc bị đánh cắp khóa riêng, tài sản kỹ thuật số bị chuyển giao; trong phạm vi lớn có thể gây nguy hiểm cho 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 bản vá cho thấy, dường như đây chỉ là một vấn đề liên quan đến việc đếm tham chiếu đối tượng bị xử lý nhiều lần. Nhưng khi xem xét các chú thích mã nguồn trước đây, phát hiện ra 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 tham chiếu sai đối tượng menu.
Phân tích ngữ cảnh của hàm lỗ hổng, chúng tôi phát hiện rằng menu được truyền vào xxxEnableMenuItem() thường đã bị khóa trong hàm cấp trên, vậy chúng ta thực sự cần bảo vệ đối tượng menu nào? Phân tích sâu hơn cho thấy, menu trả về trong xxxEnableMenuItem có hai khả năng: 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).
Để xây dựng POC, chúng tôi đã thiết kế một cấu trúc menu bốn tầng đặc biệt và thực hiện các cài đặt đặc biệt cho từng menu để phát hiện qua chức năng. 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. 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 hợp lệ.
Đối với việc thực hiện EXP, chúng tôi chủ yếu xem xét hai hướng: thực thi mã shellcode và sử dụng các nguyên lý đọc/ghi để thay đổi địa chỉ token. Cân nhắc đến cơ chế bảo mật của Windows phiên bản cao, chúng tôi đã chọn hướng thứ hai. Toàn bộ quá trình khai thác có thể được chia thành hai phần: cách khai thác lỗ hổng UAF để kiểm soát giá trị cbwndextra, và cách thiết lập các nguyên lý đọc/ghi ổn định.
Chúng tôi đã thiết kế một cách cẩn thận bố cục bộ nhớ, sử dụng đối tượng tên cửa sổ của lớp cửa sổ để chiếm dụng và giải phóng các đối tượng menu, và đã tìm thấy thời điểm có thể ghi dữ liệu trong hàm xxxRedrawWindow. Để đạt được bố cục bộ nhớ ổn định, chúng tôi đã thiết kế cấu trúc gồm ba đối tượng HWND liên tiếp và sử dụng địa chỉ của các handle kernel bị rò rỉ trong bộ nhớ heap để xác định chính xác thứ tự sắp xếp của các đối tượng.
Trong việc đọc và ghi nguyên thủy, chúng tôi sử dụng GetMenuBarInfo() để thực hiện đọc tùy ý, SetClassLongPtr() để thực hiện ghi tùy ý. Ngoài việc thay thế thao tá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 sự dịch chuyển.
Tổng thể mà nói, mặc dù lỗ hổng win32k có lịch sử lâu đời, nhưng Microsoft đã cố gắng tái cấu trúc phần mã nhân này bằng Rust trong phiên bản xem trước của Windows 11, có thể trong tương lai các lỗ hổng như vậy sẽ được loại bỏ. Quy trình khai thác lỗ hổng lần này tương đối đơn giản, khó khăn chủ yếu nằm ở việc kiểm soát việc ghi lần đầu tiên. Việc phát hiện lỗ hổng này có thể phụ thuộc vào việc kiểm tra độ phủ mã hoàn chỉnh 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, việc kiểm tra bố cục bộ nhớ bất thường và việc đọc ghi dữ liệu lệch cũng là những phương pháp khả thi để phát hiện những lỗ hổng tương tự.