Lỗ hổng vượt cơ chế ký driver trên Windows có thể dẫn tới cài rootkit kernel
(bleepingcomputer.com)- Ngay cả với Windows bề ngoài đã cài đầy đủ bản vá mới nhất, nếu quy trình Windows Update bị chiếm quyền thì hệ thống vẫn có thể bị đưa về các thành phần kernel cũ, dẫn tới việc vượt qua Driver Signature Enforcement và phát tán rootkit kernel
- Nhà nghiên cứu Alon Leviev của SafeBreach đã trình diễn tấn công hạ cấp/rollback phiên bản tại BlackHat và DEFCON, và việc chiếm quyền Windows Update vẫn chưa được vá hoàn toàn
- Kẻ tấn công có quyền quản trị có thể thay ci.dll bằng phiên bản chưa được vá ngay cả trên Windows 11 mới nhất, từ đó cho phép nạp driver kernel không ký
- Virtualization-based Security phụ thuộc vào khóa UEFI và cấu hình registry, nên trong cấu hình không có cờ Mandatory, việc sửa registry hoặc thay thế tệp lõi có thể trở thành đường vòng để vượt bảo vệ
- Microsoft đang phát triển bản cập nhật bảo mật để loại bỏ các tệp hệ thống VBS cũ, nhưng thời điểm phát hành vẫn chưa rõ do cần điều tra các phiên bản bị ảnh hưởng, kiểm thử tương thích và tránh hồi quy
Tấn công hạ cấp vô hiệu hóa trạng thái đã vá mới nhất
- Kẻ tấn công có thể kiểm soát quy trình Windows Update để đưa các thành phần cũ có lỗ hổng trở lại vào một hệ thống trông như vẫn đang ở trạng thái mới nhất
- Hệ điều hành vẫn có vẻ đã được vá hoàn chỉnh, nhưng thực tế lại bị phơi nhiễm trở lại với các lỗ hổng đã từng được sửa
- Mục tiêu hạ cấp có thể bao gồm DLL, driver và NT kernel
- Alon Leviev đã công bố công cụ Windows Downdate để cho thấy có thể tạo ra các kịch bản hạ cấp tùy biến
Vượt Driver Signature Enforcement và rủi ro rootkit
- Leviev đã trình diễn rằng vẫn có thể vượt Driver Signature Enforcement(DSE) ngay cả sau khi bảo mật kernel đã được tăng cường
- Khi vượt DSE thành công, kẻ tấn công có thể nạp các driver kernel không có chữ ký
- Các driver như vậy có thể được dùng để triển khai mã độc rootkit nhằm vô hiệu hóa các cơ chế bảo mật và làm khó việc phát hiện xâm nhập
- Leviev gọi phương pháp của mình là
"ItsNotASecurityBoundary" DSE bypass- Đây là một dạng hạ cấp của exploit ItsNotASecurityBoundary
- Exploit này tận dụng một nhóm lỗ hổng Windows về tính bất biến tệp giả (false file immutability) do Gabriel Landau của Elastic xác định, cho phép thực thi mã tùy ý với quyền kernel
Thay thế ci.dll và điều kiện khởi động lại
- Trong nghiên cứu mới, Leviev cho thấy kẻ tấn công có quyền quản trị có thể lạm dụng quy trình Windows Update để vượt bảo vệ DSE ngay cả trên Windows 11 đã được cập nhật đầy đủ
- Điểm mấu chốt là thay ci.dll thực thi DSE bằng một phiên bản chưa vá vốn bỏ qua việc ký driver
- Sau khi thành phần bị hạ xuống phiên bản dễ bị tấn công, hệ thống cần khởi động lại như trong một quy trình cập nhật bình thường
- Leviev đã công bố màn trình diễn trên hệ thống Windows 11 23H2 được vá đầy đủ, trong đó bản vá DSE bị hoàn tác bằng hạ cấp rồi thành phần đó bị khai thác
Đường vòng xuất hiện khi cấu hình VBS yếu
- Leviev cũng đề cập các cách vô hiệu hóa hoặc vượt qua Virtualization-based Security(VBS) của Microsoft
- VBS tạo ra một môi trường cô lập để bảo vệ các tài nguyên bắt buộc và tài sản bảo mật của Windows
- Các thành phần được bảo vệ gồm skci.dll, cơ chế toàn vẹn mã của security kernel, và thông tin xác thực của người dùng đã đăng thực
- VBS thường phụ thuộc vào các lớp bảo vệ như khóa UEFI và cấu hình registry
- Nếu VBS không được cấu hình với cờ “Mandatory” là mức bảo mật cao nhất, nó có thể bị vô hiệu hóa bằng cách sửa các khóa registry mục tiêu
- Nếu VBS chỉ được kích hoạt một phần, các tệp VBS cốt lõi như SecureKernel.exe có thể bị thay bằng phiên bản đã bị can thiệp để làm gián đoạn hoạt động của VBS
- Trạng thái này có thể mở ra đường dẫn tới việc vượt “ItsNotASecurityBoundary” và thay thế ci.dll
Phản ứng của Microsoft và khoảng trống còn lại
- Dù CVE-2024-21302 và CVE-2024-38202 được dùng trong các cuộc tấn công hạ cấp công bố tại BlackHat và DEFCON đã được xử lý, vấn đề chiếm quyền Windows Update vẫn còn tồn tại
- Microsoft cho rằng vấn đề này không vượt qua một ranh giới bảo mật đã được định nghĩa, và việc giành được thực thi mã kernel với quyền quản trị không được xem là vi phạm ranh giới bảo mật
- Leviev nhấn mạnh rằng cho đến khi Microsoft khắc phục vấn đề, các giải pháp bảo mật cần giám sát và phát hiện tấn công hạ cấp
- Microsoft cho biết đang chủ động phát triển các biện pháp giảm thiểu để ngăn rủi ro này
- Công ty đang phát triển một bản cập nhật bảo mật để loại bỏ các tệp hệ thống VBS cũ và chưa được vá
- Quá trình này bao gồm điều tra mọi phiên bản bị ảnh hưởng, phát triển bản cập nhật và kiểm thử tương thích
- Cần tránh lỗi tích hợp hoặc hồi quy để bảo vệ khách hàng và giảm thiểu gián đoạn vận hành
- Do tính phức tạp của vấn đề, thời điểm cung cấp bản cập nhật vẫn chưa rõ
- Trong bản cập nhật ngày 27/10, thông tin đã được làm rõ rằng cuộc tấn công đòi hỏi quyền quản trị, đồng thời bổ sung nội dung để giảm nhầm lẫn rằng Microsoft không thực hiện biện pháp giảm thiểu nào
1 bình luận
Ý kiến trên Hacker News
MS nói UAC không phải là ranh giới bảo mật, vì đây là vấn đề một số người dùng nâng lên quyền quản trị viên
Nhưng trong trường hợp lần này, họ cũng nói việc đi từ quản trị viên lên kernel không phải là ranh giới bảo mật, đồng thời lại nói cưỡng chế ký driver là một tính năng bảo mật
Ở đây chính tính năng đó đang bị vượt qua mà vẫn nói là không vượt qua ranh giới bảo mật, nên mong họ giải thích sao cho nhất quán
UAC dành cho người dùng đã thuộc nhóm quản trị viên, chứ không phải là tính năng để “một số người dùng trở thành quản trị viên”
Ranh giới bảo mật nằm quanh người dùng tiêu chuẩn, không phải người dùng quản trị viên
Có thể không thích điều này, nhưng nếu muốn có ranh giới bảo mật thì đừng đưa người dùng vào nhóm Administrators
Tôi cho rằng xung đột ý kiến thường đến từ sự không thống nhất về định nghĩa và sự không thống nhất về hệ giá trị
Trong trường hợp này, Microsoft coi trọng việc giảm nhẹ mức độ vấn đề này, và nếu đó là ưu tiên cao nhất thì quyết định của họ có thể trông nhất quán theo tiêu chí đó
Sự không thống nhất về định nghĩa tương đối dễ giải quyết. Ví dụ, khi bàn về thiết kế hệ thống phần mềm, mọi người đều dùng thuật ngữ design pattern, nhưng nếu mỗi người hiểu A thành A′ hay A″ khác nhau thì có thể gây ra nhầm lẫn lớn
Phần mềm mã nguồn mở do doanh nghiệp quản lý cũng tương tự
Câu hỏi thật sự là tại sao mọi người lại dùng năng lượng trí tuệ để làm nghiên cứu bảo mật miễn phí cho Microsoft, thay vì cải thiện Linux desktop
UAC và sudo đều gần giống cửa sổ đồng ý cookie ở cấp hệ điều hành, và tôi nghĩ tốt hơn là bỏ cả ba
Nên từ bỏ kiểu nâng quyền dựa trên người dùng như UAC/sudo, và sandbox ứng dụng thay vì người dùng, như Android và iOS
Một điểm thú vị nữa là trên cả Windows lẫn Linux, tài khoản cục bộ quyền thường thực ra gần như hoạt động như quyền tương đương root
Trên Linux, ta được huấn luyện đặt sudo trước các thao tác liên quan đến hệ thống; trên Windows, ta được huấn luyện bấm qua prompt UAC
Lần cuối sudo nói “không được” với ai đó vì lý do khác ngoài gõ sai mật khẩu là khi nào nhỉ
UAC tốt hơn một chút ở chỗ đó là UI do hệ thống quản lý, trong khi sudo chỉ là một chương trình, nên kẻ tấn công có thể thay sudo bằng một alias shell độc hại để đánh cắp mật khẩu
Với cấu hình mặc định, bỏ sudo và UAC đi, và đừng giả vờ rằng có một ranh giới bảo mật vững chắc giữa root và tài khoản cục bộ của người dùng chính, như vậy sẽ tiện hơn cho người dùng và cũng phản ánh đúng trạng thái bảo mật thực tế hơn
Trong terminal cũng có thể dùng pkexec thay cho sudo
Thay vì chạy lệnh tùy ý dưới quyền root, ứng dụng có thể dùng các hành động được định nghĩa sẵn như
org.freedesktop.udisks2.filesystem-mount, và hiển thị cho người dùng một thông điệp đã bản địa hóa về việc ứng dụng muốn làm gì để họ quyết định có cho phép hay khôngQuản trị viên hệ thống cũng có thể cấu hình để không yêu cầu xác thực cho một số hành động như cập nhật flatpak, hoặc ngược lại chặn hoàn toàn một số hành động nhất định
Có vẻ giả định nền tảng là người đã thực hiện cài đặt phải kiểm soát hệ thống. Vì ngay từ đầu họ cũng có thể không cài đặt
sudo cũng như UAC không phải là cơ chế để nói “không được” với con người. Cả hai được tạo ra để con người nói “không được” khi quản trị viên sắp thực hiện một tác vụ quản trị ngoài dự kiến
Người không có quyền quản trị nhưng cần làm việc như vậy thì phải được quản trị viên phê duyệt
Nếu không phải hệ thống dùng cho một người, người thiết lập máy nên tạo một tài khoản hạn chế để dùng hằng ngày
Vì không thường xuyên cần trở thành root, và khi cần thì thường làm nhiều việc liên tiếp
Tôi thấy sudo hữu ích trên máy tính nhiều người dùng, như máy thuộc sở hữu và do công ty quản lý, khi quản trị viên muốn chỉ cho phép một số người dùng thực hiện các tác vụ đặc quyền hạn chế
Lý do chính để luôn dùng tài khoản không phải root là tránh sai sót hơn là bảo mật. Tức là tránh xóa hoặc ghi đè nhầm tệp
Vì vậy, việc thỉnh thoảng phải nhập mật khẩu để đổi vai trò là hoàn toàn hợp lý
Chỉ là không có mẹo “nhấn ctrl+alt+delete để xác nhận”
Windows có lợi thế là không cần viết script cho mọi thứ
Nếu muốn, có thể bọc mọi công cụ bằng
runas/System.Management.Automation.PSCredential, nhưng trong hầu hết trường hợp thì không cầnCó vẻ kernel cưỡng chế quy tắc chia sẻ tệp bằng cách duyệt qua mọi handle tệp đang mở khi mở tệp để kiểm tra khóa bắt buộc xung đột, nhưng lại không kiểm tra các ánh xạ bộ nhớ có quyền xung đột
Đây là một sai sót, nhưng việc sửa có vẻ tương đối đơn giản
Thú vị là Linux vừa loại bỏ dấu vết cuối cùng của khóa bắt buộc. Giờ ghi vào tệp thực thi đã được tải cũng không còn trả về EBUSY nữa
Thật thú vị khi cùng một tính năng lại là phần gánh tải cho hạ tầng bảo mật trên một hệ điều hành, còn trên hệ điều hành khác lại là mảnh di sản cũ cần xóa bỏ
Tôi không phải chuyên gia bảo mật và chỉ hiểu những điều cơ bản, nhưng có vẻ như đang bỏ sót một mô hình khái niệm nào đó
Tôi thắc mắc vì sao Windows lại dễ bị hack đến vậy
Windows là mục tiêu sinh lợi, đặc biệt là hệ điều hành desktop được triển khai rộng rãi nhất trong môi trường doanh nghiệp, nên có rất nhiều thời gian và tiền bạc được đầu tư để phá nó
Chưa có đủ đầu tư để tạo ra một nền tảng điện toán thực sự an toàn
Một nền tảng bảo mật lý tưởng nên cung cấp các bản build có thể tái lập trên hạ tầng có thể kiểm chứng công khai như fdroid, ảo hóa mọi ứng dụng không đáng tin cậy trong sandbox, và triển khai mô hình đặc quyền tối thiểu
Hiện giờ tình trạng bảo mật là tệ nhất. Ở mọi ring, từ ME của CPU, các thành phần UEFI, cho đến driver bên thứ ba của hệ điều hành, đều đang chạy những đoạn mã không rõ nguồn gốc và có lẽ chưa được kiểm thử đầy đủ, không an toàn
SeL4 có kernel đã được kiểm chứng hoàn toàn, nhưng hiện vẫn chưa thực hiện ảo hóa
Một phần đáng kể malware trên Windows đến một thời điểm nào đó dựa vào driver kernel bên thứ ba có lỗ hổng
Ngược lại, trên Linux các module kernel bên thứ ba hiếm và bị xem là không tốt, còn trên macOS thì bị cấm hẳn
Và quá dễ để thuyết phục người dùng chạy bất cứ thứ gì với quyền được nâng cao
Chỉ đến năm 2022, sau khi nhà phân tích CERT Will Dormann hỏi lý do, vấn đề mới được xử lý
Giờ đây nó được cập nhật định kỳ, nhưng thật sự quá khó hiểu https://www.bleepingcomputer.com/news/microsoft/microsoft-fi...
Vụ này tôi đồng ý với lập trường của Microsoft ở một mức độ nào đó
Quản trị viên có thể làm các việc tùy ý trên máy tính, đây không phải chuyện mới
Không rõ có chi tiết khác biệt nào làm tăng mức độ nghiêm trọng hay không
Bài của Raymond Chen tổng hợp kiểu tấn công này cũng đáng tham khảo
https://devblogs.microsoft.com/oldnewthing/20060508-22/?p=31...
Nếu ai đó đã có thể thay thế DLL tùy ý của hệ thống, thì điều kiện tiên quyết để “exploit” này hoạt động đã được đáp ứng, và đến thời điểm đó thì coi như mọi thứ đã xong
Khả năng vượt qua chữ ký driver có lẽ thuộc nhóm nhỏ nhất trong số các điều đáng lo
Cuộc tấn công trông đơn giản đến đáng ngờ
Cách làm là đánh lừa quy trình cập nhật để cài đặt một thành phần kernel cũ có lỗ hổng đã biết
Dù không phải chuyên gia, tôi cũng thắc mắc lẽ ra Microsoft đã phải nghĩ đến chuyện này và có cơ chế như danh sách chặn hoặc cơ chế loại bỏ rồi chứ
Điểm mấu chốt là nguyên nhân gốc rễ nằm ở vấn đề thiết kế hệ điều hành, hay là lỗi quy trình khi không ghi được hash đã hỏng hoặc xấu vào đúng vị trí
Nếu là trường hợp sau thì dễ sửa hơn nhiều, nhưng như thường lệ, thông báo bảo mật được tô vẽ đôi chút dường như lại khẳng định trường hợp trước
Khó tin là có bản demo mà Microsoft lại phản bác
Tài khoản Vimeo đó còn có nhiều phát hiện bảo mật khác. Ví dụ có cả việc WhatsApp chạy script Python, tôi thắc mắc không biết đó là thật hay lừa đảo
Có tiêu chí rằng “các tiến trình và người dùng quản trị viên được xem là thuộc cơ sở điện toán tin cậy (TCB) của Windows, nên không bị cách ly mạnh khỏi ranh giới kernel” [0]
Cũng có một trường hợp khác gần đây
https://arstechnica.com/security/2024/03/hackers-exploited-w...
[0] https://www.microsoft.com/en-us/msrc/windows-security-servic...
Tôi nhớ lại những vất vả mà mọi người từng trải qua ở [1] khi Microsoft lần đầu yêu cầu ký driver trên Windows
Chúng tôi đang làm driver kiểm tra gói tin chuyên sâu cho [2], và thoạt nhìn quy trình còn có vẻ khắt khe hơn cả việc phê duyệt ứng dụng trên Apple Store, tài liệu thì hoàn toàn không rõ ràng
Nghĩ đến nguồn lực mà các công ty đã đổ vào để đáp ứng yêu cầu của Microsoft, việc nó bị lợi dụng theo cách này khiến tôi cảm thấy như một bước lùi lớn
Lỗ hổng thì lúc nào cũng có, nhưng nếu ai đó phát hiện ra việc này sớm hơn thì đã yên tâm hơn
Xin hoan nghênh Alon Leviev và SafeBreach vì đã phát hiện ra
[1] https://www.nektra.com/
[2] https://www.verizon.com/business/en-nl/products/security/man...
Việc “có thể đạt được khả năng thực thi mã kernel với tư cách quản trị viên” rốt cuộc chỉ là câu chuyện bình thường rằng người dùng root có thể cài rootkit
Đừng quên đặt cho nó một cái tên thật ngầu. À, nhà nghiên cứu đã công bố một công cụ tên là Windows Downdate rồi
Đã kiếm được 0xF phút danh tiếng, vậy là làm tốt rồi
Tài khoản người dùng cũng chỉ là một đối tượng bên trong hệ điều hành, và dù hạn chế tài khoản superuser, vẫn có thể thiết kế một hệ điều hành áp đặt các quy tắc nhất định lên mọi tài khoản người dùng
Ví dụ, ngay cả khi tài khoản quản trị bị xâm phạm, vẫn có thể có lý do chính đáng để bảo vệ một bí mật nào đó như TPM, hoặc ngăn quản trị viên vô tình làm hỏng hệ thống đến mức không thể khởi động
Một mục tiêu gây tranh cãi hơn là cưỡng chế DRM
Đây chính là điều Microsoft đang cố làm trên Windows. Hệ điều hành cố ngăn tài khoản quản trị can thiệp vào kernel hoặc cài rootkit
Trong cuộc thảo luận này, việc phân biệt giữa tài khoản người dùng quản trị bên trong hệ điều hành và “quản trị viên” là con người có quyền truy cập vật lý/phần cứng luôn rất quan trọng
0xFKhông phải là sai, nhưng là một lựa chọn hơi lạ nên khiến tôi thấy tò mò. Không biết có phải chỉ vì phong cách không
Khi phải dùng Windows, tôi luôn giả định rằng chiếc máy đó đã bị xâm phạm