Nội dung bài viết
Những “miếng chêm” cũ và bị lãng quên mà Microsoft không thu hồi được đã khiến việc vượt qua Secure Boot trở nên đơn giản.
Một tiêu chuẩn toàn ngành mà Microsoft đã phát minh ra để bảo vệ Windows và sau này là Linux, các thiết bị khỏi bị lây nhiễm chương trình cơ sở là điều không thể bỏ qua trong 13 trong số 14 năm tồn tại của nó.
Phát hiện này được các nhà nghiên cứu tại công ty bảo mật ESET thực hiện sau khi xác định được 11 hình ảnh chương trình cơ sở, ít nhất một hình ảnh từ năm 2013, được cho là có lỗi nhưng vẫn được công ty phần mềm ký tên.
Các hình ảnh này được gọi là miếng chêm, được phát minh để mở rộng Secure Boot cho các thiết bị và phần mềm tiện ích Linux.
Sử dụng một kỹ thuật đủ đơn giản để những tin tặc mới vào nghề thực hiện, những miếng chêm cũ bị lãng quên này có thể được sử dụng để phá vỡ hoàn toàn lớp bảo vệ được nhúng vào UEFI (Giao diện phần mềm mở rộng hợp nhất) của bo mạch chủ của thiết bị.
Sai lầm này là kết quả của Microsoft, công ty giám sát việc ký các miếng chêm, đã không thu hồi các hình ảnh có sẵn công khai sau khi tìm thấy lỗ hổng trong đó. Mối đe dọa này lan rộng đến cả người dùng Windows và Linux, vì miếng chêm có thể được cài đặt trên các thiết bị chạy cả hai hệ điều hành.
Từ đó, kẻ tấn công có thể phá hủy chuỗi si kỹ thuật số bắt buộc. gned firmware để cài đặt chương trình cơ sở độc hại tải sớm trong quá trình khởi động và tồn tại sau khi hệ điều hành được cài đặt lại hoặc ổ cứng được thay thế.
Nhà nghiên cứu Martin Smolár của ESET đã viết hôm thứ Ba: “Điều khiến những miếng chêm cũ này trở nên nguy hiểm không phải là một lỗ hổng mới”. "Không cần có lỗ hổng mới nào để vượt qua Khởi động an toàn UEFI.
Kẻ tấn công không cần các nguyên tắc khai thác phức tạp—chỉ cần một bản sao của tệp nhị phân shim cũ, vẫn đáng tin cậy nhưng chưa bị thu hồi và hiểu biết cơ bản về cách hoạt động của các miếng chêm UEFI.
Điều đó là đủ để vượt qua tính năng bảo mật thiết yếu như UEFI Secure Boot." Khởi động an toàn được giới thiệu vào năm 2012 để giảm bớt mối đe dọa từ bootkit, thuật ngữ chỉ phần mềm độc hại như vậy.
Nếu không có Khởi động an toàn, những kẻ tấn công có quyền truy cập vật lý ngắn vào thiết bị—ngay cả khi thiết bị đã tắt—có thể cài đặt các bộ khởi động tương tự như LoJax được tin tặc nhà nước Nga sử dụng vào năm 2018, KhảmRegressor được tìm thấy vào năm 2020, CosmicStrand vào năm 2022 và BlackLotus vào năm 2023.
Một số bộ công cụ khởi động phổ biến khác được theo dõi dưới các tên bao gồm ESpecter, FinSpy và MoonBounce. Hầu hết nhưng không phải tất cả phần mềm độc hại bootkit đều yêu cầu kẻ tấn công có quyền truy cập vật lý vào các thiết bị được nhắm mục tiêu.
Quyền truy cập như vậy là một trong những mô hình đe d... ure Boot rõ ràng là cần thiết để bảo vệ chống lại.
Danh sách tất cả 11 miếng chêm do CERT tổng hợp cho thấy một số miếng chêm đã được các nhà phân phối Linux như Redhat, OpenSuse và Oracle sử dụng. Những phần mềm khác là một phần của phần mềm bên thứ ba như Hội đồng thi tuyển sinh PC-Doctor Phần Lan.
Nhiều trong số chúng được xây dựng trước khi tồn tại một số biện pháp bảo vệ nhất định, bao gồm danh sách từ chối SBAT và MOK. Một số khác chứa lỗi tích lũy trong mã của chúng hoặc trong các tệp nhị phân giai đoạn hai mà chúng cho phép.
Bộ tải khởi động UEFI được ký điện tử của Microsoft dành cho Windows là điểm dựa tin cậy duy nhất trên các máy Windows. Để một thành phần tải trong quá trình khởi động, chứng chỉ phải ký rõ ràng tất cả các mã khác được thực thi trong quá trình khởi động.
Miếng chêm hoạt động khác nhau. Chúng là mỏ neo tin cậy thứ cấp và được Microsoft ký bằng một trong các chứng chỉ UEFI khác của hãng.
Từ đó, chứng chỉ thuộc về bo mạch chủ hoặc nhà sản xuất phần mềm được nhúng vào miếng chêm sẽ cấp phép cho tất cả phần mềm được tải sau đó. Khi tìm thấy lỗ hổng trong miếng chêm, Microsoft sẽ thu hồi chúng.
Trong trường hợp của 11 miếng chêm, công ty đã không làm được điều đó, trong một số trường hợp trong hơn một thập kỷ. Công ty cuối cùng đã thu hồi chúng theo định kỳ hàng tháng.
y bản vá được phát hành vào tháng 6, sau khi ESET thu hút sự chú ý của CERT và Microsoft. Microsoft vẫn chưa giải thích làm thế nào hoặc tại sao sai sót này lại xảy ra.
Một nguyên nhân có thể là cách thức hoạt động rất phức tạp của Secure Boot. Cả hai miếng chêm Windows Boot Manager và UEFI đều tải hai cơ sở dữ liệu.
Cơ sở dữ liệu db liệt kê tất cả các chứng chỉ ký được phép và hàm băm Authenticode. Dbx chứa các chứng chỉ và hàm băm không còn đáng tin cậy nữa.
Để một thành phần được tải, nó phải được ủy quyền thông qua db và không bị thu hồi trong dbx. Với số lượng lớn các thành phần Linux được thực thi trong quá trình khởi động, việc liệt kê từng thành phần trong cơ sở dữ liệu này là không thể vì dbx chỉ được phân bổ 32kb dung lượng.
Vì vậy, Microsoft đã sử dụng các phương pháp thu hồi khác, cụ thể là SBAT (Nhắm mục tiêu nâng cao khởi động an toàn) và Số phiên bản bảo mật khởi động an toàn (SVN). “Nói tóm lại, trong đó dbx thu hồi các tệp nhị phân, SBAT và các phiên bản Secure Boot SVN của Microsoft thu hồi,” Smolár giải thích.
“Khi tìm thấy lỗ hổng trong ứng dụng UEFI hỗ trợ một trong các cơ chế thu hồi dựa trên phiên bản này, điều thực sự cần phải tránh là mọi bản dựng và bao gồm cả bản bị lỗi—và điều đó có thể bị nắm bắt bởi số phiên bản m.
dễ dàng hơn nhiều so với một danh sách dài các giá trị băm.” Mỗi thành phần trong trình tải UEFI mang siêu dữ liệu được ký bởi cùng một chứng chỉ xác thực chính tệp nhị phân. Siêu dữ liệu này đặt tên cho thành phần và gán cho nó số thế hệ được tăng lên mỗi khi có bản sửa lỗi bảo mật mới.
Biến chỉ khởi động trong UEFI lưu trữ số lượng thế hệ tối thiểu có thể chấp nhận được cho phép đối với mỗi thành phần. Số biến được thực thi bởi miếng chêm chứ không phải phần sụn.
Miếng chêm cũng nhúng chính sách để việc thực thi không chỉ dựa vào biến bên ngoài. Điều này cho phép kết hợp chính sách mới thông qua cơ chế được gọi là SbatLevel.
“Ở mỗi lần khởi động, miếng chêm trước tiên sẽ xác minh siêu dữ liệu SBAT của chính nó theo chính sách—do đó, một miếng chêm lỗi thời có thể được tạo ra để tự từ chối—và sau đó áp dụng cùng một thử nghiệm cho mọi tệp nhị phân mà nó tải, từ chối bất kỳ thứ gì có số thế hệ giảm xuống dưới mức tối thiểu mà chính sách yêu cầu,” nhà nghiên cứu viết.
Gợi ý thực hành:
1. Theo dõi thông báo từ cơ quan địa phương tại California.
2. Kiểm tra nguồn chính thức trước khi chia sẻ lại thông tin.