Trang chủ » Tin công nghệ » Lỗ hổng CVSS 10.0 trên LXD 7 & MicroCloud: Không cần khóa riêng vẫn chiếm được quyền quản trị máy chủ

Lỗ hổng CVSS 10.0 trên LXD 7 & MicroCloud: Không cần khóa riêng vẫn chiếm được quyền quản trị máy chủ

Picture of @Monica Do

@Monica Do

Content Creator

Một lỗ hổng bảo mật nghiêm trọng trong LXD và MicroCloud của Canonical cho phép kẻ tấn công giả mạo danh tính của một máy khách đáng tin cậy mà không cần sở hữu khóa riêng tương ứng. Nếu khai thác thành công, tin tặc có thể truy cập vào cụm máy chủ, các máy ảo và thậm chí giành quyền truy cập cấp cao nhất vào máy chủ.

LXD và MicroCloud là các phần mềm giúp quản lý máy chủ và máy ảo. Trong hệ thống này, các máy khách (client) muốn kết nối với máy chủ phải chứng minh mình là đối tượng hợp lệ thông qua chứng chỉ số và khóa riêng (private key) tương ứng.Thông thường, chứng chỉ số giống như một chiếc thẻ định danh, còn khóa riêng giống như một chiếc chìa khóa bí mật để chứng minh người đang sử dụng thẻ đó thực sự là chủ sở hữu.

Tuy nhiên, lỗ hổng bảo mật trong LXD và MicroCloud được phát hiện mới đây khiến cơ chế xác minh danh tính này hoạt động sai. Lỗ hổng được định danh là CVE-2026-112816, có điểm CVSS 10.0 – mức nghiêm trọng cao nhất. 

Lỗ hổng CVSS 10.0 trên LXD và MicroCloud: Không cần khóa riêng vẫn chiếm được quyền quản trị máy chủ

Cơ chế khai thác lỗ hổng

LXD và MicroCloud sử dụng cơ chế xác thực TLS hai chiều (Mutual TLS – mTLS) để kiểm tra danh tính của máy khách khi kết nối từ xa đến API. Theo cơ chế này, không chỉ máy khách phải xác minh máy chủ mà máy chủ cũng yêu cầu máy khách cung cấp chứng chỉ số để xác nhận danh tính trước khi cho phép kết nối.

Máy chủ chỉ chấp nhận những máy khách có chứng chỉ nằm trong danh sách chứng chỉ được tin cậy (trusted certificate store). Có thể hiểu đây là danh sách các máy khách đã được hệ thống xác nhận danh tính và cho phép truy cập.

Tuy nhiên, lỗ hổng CVE-2026-112816 xuất phát từ sai sót trong cách máy chủ kiểm tra chứng chỉ. Cụ thể, máy chủ đối chiếu toàn bộ chứng chỉ mà máy khách gửi lên với danh sách chứng chỉ được tin cậy. Trong khi đó, cơ chế TLS chỉ xác minh máy khách có sở hữu khóa riêng tương ứng với chứng chỉ đầu tiên trong chuỗi hay không. Các chứng chỉ còn lại không được xác minh quyền sở hữu theo cách tương tự và có thể do máy khách tự đính kèm.

Kẻ tấn công có thể lợi dụng điểm yếu này bằng cách lấy chứng chỉ công khai của một máy khách đã được hệ thống tin cậy, sau đó đính kèm chứng chỉ đó vào chuỗi chứng chỉ của mình. Vì chứng chỉ công khai không phải thông tin bí mật, kẻ tấn công không cần đánh cắp khóa riêng của máy khách hợp pháp.

Do quá trình xác minh có sai sót, máy chủ có thể nhầm lẫn kẻ tấn công với máy khách hợp lệ và cho phép truy cập bằng danh tính của máy khách đó.

Nếu máy khách bị giả mạo có quyền quản trị, kẻ tấn công có thể sử dụng quyền này để kiểm soát các tài nguyên trong cụm, bao gồm máy chủ và máy ảo. Trong trường hợp nghiêm trọng, đối tượng có thể giành được quyền root – cấp quyền cao nhất trên máy chủ, theo cảnh báo của Canonical.

Những hệ thống nào bị ảnh hưởng?

Để khai thác lỗ hổng, kẻ tấn công cần đáp ứng đồng thời hai điều kiện:

  • Có khả năng truy cập API HTTPS của LXD hoặc MicroCloud thông qua mạng.
  • Có được chứng chỉ công khai của một máy khách đã được hệ thống tin cậy.

Đối với LXD triển khai độc lập, API mạng không được bật theo mặc định. Thông thường, máy chủ chỉ tiếp nhận kết nối thông qua socket cục bộ, trừ khi quản trị viên chủ động cấu hình tham số core.https_address để mở API qua mạng.

Trong khi đó, MicroCloud có nguy cơ đáng chú ý hơn do được thiết kế để kết nối nhiều máy chủ LXD thành một cụm. Theo Canonical, kẻ tấn công có thể thu thập chứng chỉ công khai của một thành viên trong quá trình thành viên này tham gia cụm, sau đó sử dụng chứng chỉ để giả mạo danh tính và truy cập hệ thống.

Để khắc phục lỗ hổng, Canonical đã phát hành các phiên bản cập nhật cho cả LXD và MicroCloud. Cụ thể, người dùng LXD trên kênh Snap 6/stable cần cập nhật lên phiên bản 6.10.1, kênh 5.21/stable lên phiên bản 5.21.9, kênh 5.0/stable lên phiên bản 5.0.11 và kênh 4.0/stable lên phiên bản 4.0.15.

Đối với MicroCloud, phiên bản đã khắc phục lỗi là 3.4.1 trên kênh 3/stable và 2.1.5 trên kênh 2/stable. Người dùng cần kiểm tra phiên bản đang triển khai để lựa chọn bản cập nhật phù hợp.

Đáng chú ý, lỗ hổng này không chỉ ảnh hưởng đến LXD mà còn tác động đến Incus – dự án cộng đồng được phát triển từ mã nguồn LXD. Incus là dự án đầu tiên phát hiện và báo cáo lỗ hổng thông qua thông báo bảo mật trên GitHub, sau đó Canonical xác nhận LXD cũng bị ảnh hưởng.

Để khắc phục vấn đề, dự án Incus đã phát hành phiên bản 7.6.0 tích hợp bản vá bảo mật. Trong khi đó, theo Canonical, các gói LXD được phân phối thông qua kho lưu trữ chính thức của Ubuntu không bị ảnh hưởng hoặc không được cung cấp trong những phiên bản liên quan đến lỗ hổng này. Vì vậy, các bản cập nhật khắc phục được Canonical công bố chủ yếu áp dụng cho phiên bản LXD và MicroCloud cài đặt thông qua Snap.

Về tình hình khai thác, tại thời điểm công bố, chưa có bằng chứng cho thấy lỗ hổng CVE-2026-112816 đã bị tin tặc lợi dụng trong các cuộc tấn công thực tế. Theo đánh giá ngày 30/10 của Cơ quan An ninh mạng và Cơ sở hạ tầng Mỹ (CISA), lỗ hổng chưa được ghi nhận là đã bị khai thác và không nằm trong danh mục các lỗ hổng đã bị khai thác (Known Exploited Vulnerabilities – KEV) của cơ quan này. Đồng thời, hiện chưa có mã khai thác công khai được phát hành.

Khuyến nghị và biện pháp giảm thiểu rủi ro

Để bảo vệ hệ thống trước nguy cơ bị khai thác, VNCS Global khuyến nghị quản trị viên LXD và MicroCloud cần ưu tiên cập nhật lên các phiên bản đã khắc phục lỗ hổng.

Đối với hệ thống cài đặt thông qua Snap, có thể thực hiện cập nhật bằng các lệnh sau: sudo snap refresh lxd và sudo snap refresh microcloud

Sau khi cập nhật, quản trị viên cần kiểm tra lại phiên bản LXD đang cài đặt để xác nhận hệ thống đã được nâng cấp lên phiên bản có bản vá bảo mật. Canonical lưu ý rằng tại thời điểm công bố, một số bản cập nhật LXD mới chỉ có trên kênh candidate và chưa được triển khai đầy đủ sang kênh stable. Do đó, việc thực hiện lệnh cập nhật không đồng nghĩa với việc hệ thống đã cài đặt thành công bản vá. Quản trị viên cần kiểm tra phiên bản thực tế sau khi cập nhật để bảo đảm lỗ hổng đã được khắc phục.

Trong trường hợp chưa thể cập nhật ngay, quản trị viên nên rà soát và hạn chế tối đa quyền truy cập mạng đến API HTTPS của LXD và MicroCloud, chỉ cho phép các địa chỉ IP hoặc hệ thống thực sự cần thiết kết nối. Đây là biện pháp giảm thiểu quan trọng bởi khả năng khai thác lỗ hổng phụ thuộc trực tiếp vào việc tiếp cận được API qua mạng.

Canonical hiện chưa công bố biện pháp khắc phục tạm thời cụ thể cho LXD. Đối với người dùng Incus, cần cập nhật lên phiên bản 7.6.0. Phiên bản này không chỉ khắc phục lỗ hổng tương tự CVE-2026-112816 mà còn xử lý thêm 17 vấn đề bảo mật khác.

Kết luận: 

Mặc dù chưa ghi nhận hoạt động khai thác công khai, với điểm CVSS 10.0 và khả năng dẫn đến chiếm quyền quản trị máy chủ, CVE-2026-112816 vẫn cần được xem là rủi ro bảo mật ưu tiên cao. Các tổ chức đang vận hành LXD, MicroCloud hoặc Incus nên chủ động rà soát phạm vi ảnh hưởng, kiểm tra cấu hình truy cập API và triển khai bản vá trong thời gian sớm nhất.

Các bài viết liên quan
No posts found.