Bản cập nhật của Microsoft sửa lỗi cũ nhưng làm nổi bật lỗ hổng rò rỉ địa chỉ mới trong Windows 11 và nhân Server 2022 24H2

Bản cập nhật phần mềm mới đã thay đổi cục diện: trong nỗ lực khắc phục lỗ hổng CVE-2024-43511, Microsoft đã giới thiệu CVE-2025-53136. Lỗ hổng này cho phép rò rỉ địa chỉ bộ nhớ từ kernel của Windows 11 và Windows Server 2022 phiên bản 24H2. Kẻ tấn công hiện có một lối tắt đáng tin cậy để vượt qua KASLR, một thành phần quan trọng của bảo mật CNTT. Mối đe dọa này thậm chí còn ảnh hưởng đến các môi trường có đặc quyền thấp, bao gồm cả các ứng dụng AppContainer. Cảnh báo này được đưa ra ngay sau Bản vá Thứ Ba mới nhất, một lời nhắc nhở nghiêm túc: mỗi bản vá đều có thể ẩn chứa một lỗ hổng bảo mật mới. Bản vá Thứ Ba: Bản cập nhật sửa lỗi CVE-2024-43511 nhưng lại mở ra CVE-2025-53136 Vào ngày 8 tháng 4 năm 2025, nhóm Redmond đã phát hành bản vá cho CVE-2024-43511, một lỗi loại TOCTOU ảnh hưởng đến RtlSidHashInitialize(). Trên lý thuyết, mọi thứ đã được khắc phục. Trên thực tế, chỉ một dòng mã sẽ tạm thời chuyển một con trỏ nhạy cảm đến một bộ đệm do người dùng kiểm soát. Cửa sổ nhỏ nhưng có thể lặp lại này đủ để lộ địa chỉ của cấu trúc TOKEN. Với manh mối này, kẻ tấn công có thể loại bỏ nguy cơ KASLR. Điều này càng đáng chú ý hơn khi Microsoft vừa hạn chế NtQuerySystemInformation() để hạn chế quyền truy cập vào cơ sở dữ liệu kernel. Trớ trêu thay, bản sửa lỗi này lại mở ra một mối đe dọa đơn giản hơn, ổn định hơn và do đó nguy hiểm hơn. Rò rỉ địa chỉ bộ nhớ đe dọa hệ thống phòng thủ KASLR 24H2 của Windows 11 như thế nào KASLR di chuyển ngẫu nhiên kernel mỗi lần khởi động. Ý tưởng: làm cho mục tiêu của một cuộc khai thác trở nên khó đoán. Khi CVE-2025-53136 tiết lộ con trỏ TOKEN, nó cung cấp một chuẩn mực tuyệt đối. Cuộc khai thác, do Crowdfense công bố, chỉ cần gọi NtQueryInformationToken(TokenAccessInformation) trong một vòng lặp, trong khi một luồng thứ hai đọc bộ nhớ trước khi xóa con trỏ. Các thử nghiệm cho thấy tỷ lệ thành công gần 100%. Chỉ cần một phiên AppContainer đơn giản, dường như được kiểm soát, là đủ. Kết quả: bất kỳ lỗ hổng zero-day nào cung cấp tùy chọn “ghi-cái-gì-ở-đâu” đều có thể được kết nối thành một LPE đầy đủ. Trong một SOC, ưu tiên sau đó chuyển từ “hãy sửa lỗi cũ” sang “hãy chặn rò rỉ trước khi nó bị lợi dụng”. Kịch bản tấn công: Từ việc đọc TOKEN đến chiếm quyền cục bộ Hãy tưởng tượng một máy trạm của khách hàng trong một doanh nghiệp vừa và nhỏ. Một nhân viên mở một tệp PDF độc hại. Tài liệu, thông qua hộp cát AppContainer, khai thác lỗ hổng CVE-2025-53136 và truy xuất địa chỉ TOKEN. Vài mili giây sau, một lỗi thứ hai trong trình điều khiển Wi-Fi — một lỗi điển hình “ghi-cái-gì-ở-đâu” — ghi đè trường Đặc quyền. Phần mềm độc hại leo thang lên HỆ THỐNG, vô hiệu hóa phần mềm diệt vi-rút và sau đó lây lan qua các tập lệnh PowerShell trên toàn mạng. Không có sự nâng cấp rõ ràng, không có yêu cầu UAC: cuộc tấn công vẫn diễn ra âm thầm. Blue Teams chỉ thấy quyền truy cập của quản trị viên tăng đột ngột. Nếu không có dữ liệu từ xa chi tiết về lệnh gọi kernel, lỗ hổng sẽ không được phát hiện. Hậu quả đối với quản trị viên và các biện pháp tốt nhất để cập nhật phần mềm Các nhà quản lý CNTT phải phản ứng nhanh chóng. Bước một: áp dụng biện pháp giảm thiểu tạm thời do Microsoft cung cấp—vô hiệu hóa mã thông báo mở rộng cho các quy trình yếu. Bước hai: theo dõi nhật ký gọi lại kernel và các bất thường khi truy cập mã thông báo. Bước ba: triển khai bản vá ngay khi bản vá được phát hành, nhưng chỉ sau khi xác thực trong môi trường thử nghiệm. Các tổ chức tự động hóa Patch Tuesday nên bổ sung một bước kiểm tra: quét mọi DLL đã sửa đổi bằng các công cụ fuzzing nội bộ. Quy trình này giúp giảm nguy cơ bản vá trở thành một vectơ tấn công. Tại sao mọi bản vá của Microsoft phải được bảo mật bằng hộp cátVào năm 2025, chu trình DevSecOps yêu cầu một tiêu chuẩn: “kiểm tra trước khi đưa vào sản xuất”. Các ông lớn trong lĩnh vực điện toán đám mây đã đặt trước một cụm Kubernetes dành riêng cho các bản phát hành trước của Windows Server 2022 24/7. Trong các phòng thí nghiệm này, các bộ hồi quy tập trung vào bộ nhớ kernel được chạy. CVE-2025-53136 là một lời nhắc nhở rằng tin tưởng mù quáng không còn là một lựa chọn nữa. Các nhóm phải tính toán thời gian cho mọi cuộc gọi quan trọng và kích hoạt cảnh báo ngay khi một hàm tiết lộ địa chỉ kernel cho không gian người dùng. Bằng cách nhân số lượng máy dò, có thể tiết kiệm được nhiều thời gian quý báu giữa việc xây dựng bản dựng lỗi và triển khai hàng loạt. Một ví dụ cụ thể: một bệnh viện ở Pháp đã tích hợp một đường ống GitHub Actions để so sánh các ký hiệu kernel trước và sau khi cập nhật. Trong bản vá thứ Ba mới nhất, công cụ này đã phát hiện ra sự xuất hiện của một trường bị lộ trong RtlSidHashInitialize(). Nhờ sự giám sát này, bệnh viện đã tạm dừng triển khai và ngăn chặn sự xâm nhập vào một mạng lưới X-quang quan trọng. Nguồn: cybersecuritynews.com